IBM Think 2019 session: Everybody in technology is talking about microservices these days. Microservices aren't the answer to all of your problems. However,  they do address many of the pain points we are seeing with applications developed only a few years ago. Where and how we start a Microservices Transformation can be confusing. Come to this session to learn what the Microservices architectural style is really about, how to ensure your next Microservices Transformation is successful, and what benefits you can realistically expect from your efforts. 

1. The Trial Period is Over:
Microservices Adoption Gains Momentum
—
Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
Shahir A. Daya
IBM Distinguished Engineer, IBM
Jermaine C. Edwards
IBM Chief Architect, IBM

2. IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without
notice and at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product direction and it
should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise, or legal
obligation to deliver any material, code or functionality. Information about potential future products may not
be incorporated into any contract.
The development, release, and timing of any future features or functionality described for our products
remains at our sole discretion.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled
environment. The actual throughput or performance that any user will experience will vary depending upon
many factors, including considerations such as the amount of multiprogramming in the user’s job stream,
the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can
be given that an individual user will achieve results similar to those stated here.
2
Please note
Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation

3. Agenda
3Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
• Microservices – what are they and why should we care
• What are the tenets of the Microservices Architectural Style
• When do Microservices make sense and more importantly when do they not
• How about Microservices for Greenfield vs. Brownfield
• How do we decompose existing monoliths, how do we deal with data, etc.
• Q & A

4. Microservices
Introduction
4Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation

5. Microservices architecture involves building applications as
small, loosely coupled, autonomous components
5Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
• Monolithic
applications are one
large application that
does everything
• Microservices are
several smaller
applications that
each does part of the
whole
• Microservices are
focused on business
capabilities,
concentrating on
business APIs
Sources: Gartner, Forrester, IDC, Martin Fowler & James Lewis, PwC, Apigee, Dzone Microservices vs SOA
▪ Tightly coupled
▪ Full dependency; each
change has unanticipated
effects requiring careful
testing beforehand
▪ Large, single code base
(e.g., capability)
▪ Loosely coupled
▪ Reduced dependencies;
elements are developed
more autonomously, but
must be coordinated to fit
overall design
▪ Greater modularity (e.g.,
domain)
Monolithic Traditional SOA Microservices
Client Server Era Web Era Cloud Era
▪ Decoupled
▪ Zero dependency; new
and/or modified
functionality can by
independently deployable
▪ Small components that
perform a discrete functions
(e.g., feature)
Team Team
Team Team

6. Benefits of the
Microservices
architectural style
6
Microservices provide value benefit
through:
1.Selective granular scaling provides
optimization across all layers of the
stack
2.Componentization isolates risks,
defects and outages, resulting in
greater fault tolerance
3.Designed for fast & frequent change;
unleashed polyglot programming
2Fault Isolation
Resilience
1 Scale
Scale at Size
3 Agility
Innovation
Lightweight SW code, focused on doing
one function well
Functionally & operationally self-contained
Minimal interdependencies with other
components
Deployed, Maintained, Managed, Scaled
independently
“Open” - can be run on bare OS,
Container, Foundry etc
Interoperability – REST API is typical
interfacing mechanism
Every Microservice can be developed in a
different programming language
With thoughtful implementation of well-accepted
design patterns, enables highly resilient systems
4Polyglot
Flexibility
5Teams work
independently
Distributed
Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation

7. Tenets of the
Microservices
Architectural Style
7Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation

8. Tenets of the Microservices
Architectural style
8Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
Large monoliths
are broken down
into many small
services
Services are
optimized for a
single function
Communication
via REST API and
message brokers
Per-service
continuous
integration and
continuous
deployment
(CI/CD)
Per-service high
availability (HA)
and clustering
decisions
Each service runs in its
own process
One service per
container
There is only one
business function per
service
The Single
Responsibility Principle
(A microservice should
have one, and only
one, reason to change)
Avoid tight coupling
introduced by
communication through
a database
Services evolve at
different rates
You let the system
evolve but set
architectural principles
to guide that evolution
One size or scaling
policy is not appropriate
for all
Not all services need to
scale; others require
autoscaling up to large
numbers

9. When to use and
when not to use
Microservices
9Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation

10. When to use
Microservices
10Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
• Services need to be highly available
and continue to be available through
component failure
• Services are likely to have frequent
changes to the production services
which need to be made safely with
little or no outage
• Services are likely to have to scale for
significant peek loads or for future
growth
• No financial business case for
adopting a microservices approach
• Do not have a mature DevOps
culture, skills and tools in place
• Do not have culture, skills, tools to
support microservice monitoring,
management and continuous
feedback
When NOT to use
Microservices

11. How about
Microservices for
Greenfield vs.
Brownfield
11Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation

12. Microservices Considerations for
Greenfield vs. Brownfield
12Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
Greenfield (New Application)
• Clean slate in defining Microservice
architecture based on 12 factor
principles
• Apply Domain Driven Design
principles
Brownfield (Existing Application)
• Strangle the Monolith over time with
new microservices
• Completely rewrite all of it as new
microservices

13. How do we
decompose existing
monoliths, how do
we deal with data,
etc.
13Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation

14. How do we decompose an
existing monolithic application
14Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
1. Separate databases before
separating services.
2. Place existing transactions
within a single service or
redesign the transaction usage
(compensating/eventual
consistency).
3. Consider the team
composition.
4. Implement new features as
microservices around the
existing monolith.

15. How should ACID-style
transactions be handled?
15Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
• ACID-style transactions spanning services is not possible
• Many persistence technologies do not support ACID-style transactions
(e.g. NoSQL DBs)
• Alternatives to ACID-style transactions include:
– The Saga Pattern
– Compensating transactions
– Eventual consistency

16. Distributed Data Management
Patterns
16Think 2019 / 3768A / February 14, 2019 / © 2019 IBM Corporation
Issues related to distributed data management:
• data consistency across stores in each
microservice
• dependency & communication between
microservices
For Event based integration evaluate:
• need for additional software components for
asynchronous messaging and event
management, co-relation
• impact to non-functional requirements like
high availability ( message durability) etc.
• transactional integrity and rollback

17. Modernization Strategy and
Approaches
17Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
• Containerize the monolith. Reduce costs
and simplify operations.
• Expose on-prem assets with APIs. APIs
enable legacy assets that are difficult to
cloud enable.
• Refactor into macroservices. Break down
monoliths into deployable components.
• Add new microservices. Innovate
incrementally and establish success
early.
• Strangle the monolith. Incrementally
sunset the monolith.

18. References
18Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
1. “Data management considerations for microservices”, ibm.com, 2019. [Online].
Available: https://www.ibm.com/cloud/garage/architectures/microservices/data-
management-for-microservices. [Accessed: 08- Jan- 2019]
2. “IBM Application Modernization Field Guide”, ibm.com, 2018. [Online]. Available:
https://www.ibm.com/cloud/garage/content/culture/app-modernization-field-guide/.
[Accessed: 08- Jan- 2019]
3. “Microservices Decision Guides”, ibm.com, 2017. [Online]. Available:
https://www.ibm.com/cloud/garage/files/Microservices-Decision-Guides-FINAL-1.pdf.
[Accessed: 08- Jan- 2019]

19. Notices and disclaimers
19Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
© 2018 International Business Machines Corporation. No part of this
document may be reproduced or transmitted in any form without
written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event,
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted per the terms and conditions of the agreements
under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been previously
installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented as
illustrations of how those customers have used IBM products and the
results they may have achieved. Actual performance, cost, savings or
other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for
informational purposes only, and are neither intended to, nor shall
constitute legal or other guidance or advice to any individual participant
or their specific situation.
It is the customer’s responsibility to insure its own compliance
with legal requirements and to obtain advice of competent legal counsel
as to the identification and interpretation of any relevant laws and
regulatory requirements that may affect the customer’s business and
any actions the customer may need to take to comply with such
laws. IBM does not provide legal advice or represent or warrant that its
services or products will ensure that the customer follows any law.

20. Notices and disclaimers
continued
20Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products about this
publication and cannot confirm the accuracy of performance,
compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed
to the suppliers of those products. IBM does not warrant the quality of
any third-party products, or the ability of any such third-party products
to interoperate with IBM’s products. IBM expressly disclaims all
warranties, expressed or implied, including but not limited to, the
implied warranties of merchantability and fitness for a purpose.
The provision of the information contained herein is not intended to, and
does not, grant any right or license under any IBM patents, copyrights,
trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com and [names of other referenced IBM
products and services used in the presentation] are trademarks of
International Business Machines Corporation, registered in many
jurisdictions worldwide. Other product and service names might
be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at “Copyright and trademark
information” at: www.ibm.com/legal/copytrade.shtml.

21. Thank you
21Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation
Shahir A. Daya
IBM Distinguished Engineer and CTO, IBM
—
sdaya@ca.ibm.com
+1-416-478-6445
ibm.com
Jermaine C. Edwards
IBM Chief Architect, IBM
—
jedward2@us.ibm.com
+1-720-395-1162
ibm.com

22. 22
®
Think 2019 / 6175A / February 15, 2019 / © 2019 IBM Corporation