This document outlines the principles and practices of microservices architecture, contrasting it with traditional monolithic structures. It emphasizes the importance of organizing services around business capabilities, decentralizing governance, and managing operational complexity through cloud solutions. Additionally, it discusses migration strategies to microservices, deployment best practices, and challenges associated with maintaining distributed systems.

1. © 2015 IBM Corporation
Developing Enterprise
Applications for the Cloud,
from Monolith to Microservice
David Currie
Jack Cai

2. Agenda
• What are microservices?
• Developing and deploying microservices
• Migrating to a microservices architecture
1

3. What are
Microservices?
2

4. Microservices Defined
• Application architected as a suite of small services, each
running in its own process, and communicating with lightweight
mechanisms e.g. REST/HTTP
• Services built around business capabilities
• Each service independently deployable via automation
• Minimal centralised governance
• May be written in different languages
• May use different data storage technologies
3

5. Contrast with a Monolithic Architecture
Monolithic Microservice
Architecture Built as a single logical executable (typically
the server-side part of a three tier client-
server-database architecture)
Built as a suite of small services, each running
separately and communicating with lightweight
mechanisms
Modularity Based on language features Based on business capabilities
Agility Changes to the system involve building and
deploying a new version of the entire
application
Changes can be applied to each service
independently
Scaling Entire application scaled horizontally behind
a load-balancer
Each service scaled independently when needed
Implementation Typically written in one language Each service implemented in the language that
best fits the need
Maintainability Large code base intimidating to new
developers
Smaller code base easier to manage
Transaction ACID BASE
4

6. Componentization via Services
• Component is a unit of software that is independently
replaceable and upgradeable
• Libraries are components that are linked in to a program and
called used in-memory function calls
• Services are out-of-process components who communicate, for
example, via web service requests or RPC
• Unlike libraries, services can be independently redeployed
• Using a service results in an explicit published interface
• Remote calls are more expense leading to coarser-grained APIs
• A service may consist of multiple processes e.g. the application
process, cache, and associated database
5

7. Organized around Business Capabilities
• Monolithic project teams are often aligned around technology
layers meaning even simple changes involve multiple teams
Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization's
communication structure – Melvyn Conway, 1967
• Organize services around business capabilities results in cross-
functional teams
• Typically those teams are small (Amazon “Two pizza team”) but
don‟t get hung up on the „micro‟
• Strong tie-in to DevOps: each team is responsible for the entire
lifecycle of its service
6

8. Smart Endpoints and Dumb Pipes
• Historically there has been an emphasis on putting intelligence
(e.g. routing, transformation and even choreography) in to the
communications channel e.g. Enterprise Service Bus
• Microservices communicate directly using simple protocols such
as REST/HTTP and AMQP
• Significant differentiator from what we traditional think of in a
SOA architecture
• Try to avoid versioning by making services and clients tolerant
to changes
• API Gateway (used to consolidate multiple client calls)
somewhat contrary to this
7

9. Decentralization
• Decentralized governance
• Monoliths tend to standardise on a single technology platform
whereas it may be appropriate to use different tools (e.g.
languages or databases) for different parts of an application
• With microservices, „standardisation‟ is through sharing of
common code/tools
• Decentralized data management
• Each service owns its own data model and data
• Coordination between services must be transaction-less (use
eventual consistency and compensation)
8

10. Microservice Challenges
• Greater operational complexity – more moving parts
• Devs need significant ops skills
• Service interfaces and versioning
• Duplication of effort across service implementations
• Additional complexity of creating a distributed system – network
latency, fault tolerance, serialization, …
• Designing decoupled non-transactional systems is hard
• Avoiding latency overhead of large numbers of small service
invocations
• Locating service instances
• Maintaining availability and consistency with partitioned data
• End-to-end testing
9

11. Developing and
Deploying
Microservices
10

12. Reducing Operational Complexity
• Platform-as-a-Service exists to remove the complexity of
deploying applications – the PaaS provider also handles the
complexity of managing and monitoring the infrastructure
• Cloud Foundry provides a consistent deployment mechanism
regardless of programming language
• Buildpacks ensure that applications are kept up-to-date with
new versions of the runtime and libraries
• Routing and load balancing handled by Cloud Foundry router
• Service dependencies are resolved at deployment time
• Repeatable deployment through IBM DevOps Services or CLI,
Maven/Gradle/Travis/Jenkins plugins (you can even run Jenkins
on Cloud Foundry!)
• Cloud Foundry V3 API to allow multiple processes per app
11

13. Service Discovery
• Within a Cloud Foundry environment, routes and the CF
router provide all that is needed to locate a service instance
• Cloud Controller manages distribution and availability of
application instances
• Blue-green deployments supported by binding multiple
application versions to the same route
• cf cups (create user provided service) provides a convenient
mechanism to inform one microservice of the route for a
microservice on which it is dependent
• Where instances of a microservice are deployed to multiple
Cloud Foundry environments, consider using a runtime registry
e.g. Eureka or highly-available data store e.g. etcd or
Zookeeper
12

14. Configuration
• The same application should be deployable in to multiple
environments – don‟t build configuration in to the application
• Environment variables are a simple mechanism portable across
most runtimes and cloud and non-cloud environments
• Cloud Foundry provides the ability to set environment variables
in the manifest at push time or subsequently via cf set-env
• Netflix Archaius provides a mechanism to poll a hierarchy of
configuration sources
• Property files and URLs out of the box but other configuration
sources are pluggable
13

15. Design for Failure
• Any service call could fail where failure could be anything from
an immediate error code to never returning – need to handle
that gracefully
• Emphasis on real-time monitoring of technical and business
metrics
• Application monitoring through Monitoring and Analytics service
or third-party service e.g. New Relic
• Gives insights which might not be uncovered in a monolithic
application
• Implement patterns from „Release It!‟ e.g. via Netflix Hystrix
• Circuit Breaker – protect from downstream failures
• Bulkhead – limit resources that can be consumed
• Timeout
• Testing for failures: Simian Army
14

16. Communication Protocols
• Cloud Foundry currently only supports inbound HTTP
• Web sockets is an option in preference to long polling
• JSON may be the best fit for client facing services but consider
other options such as Apache Thrift or Google Protocol Buffers
where serialization efficiency is important
• Typically start with synchronous protocols and add
asynchronous (e.g. via MQ Light) where needed to support the
interaction style or performance goals
• Parallel invocation of downstream services may be required to
ensure responsiveness is maintained
• Consider using a reactive programming model (e.g. RxJava) or
Java 8‟s CompletableFuture
15

17. Securing Microservices
• Cloud Foundry applications are all public facing (Application
Security Groups introduced in the CF 1.3 release relate to
outbound traffic)
• Normal rules apply e.g. basic authentication and authorisation
as a starting point
• Bluemix Single Sign On service provides a simple mechanism
to use an existing identity source or Bluemix based user registry
for SSO
16

18. Testing Strategies
• http://martinfowler.com/articles/microservice-testing
• Unit testing inside a microservice
• Integration testing between a microservice and its
dependencies (e.g. other services or external datastore)
• Component testing of a microservice either with or without its
dependencies
• Contract testing by consumers of a microservice
• End-to-end testing of a system of microservices
• Use the Cloud Foundry Java client library from unit tests to
communicate with the environment
• Microservices are typically very amenable to testing with
„shadow traffic‟ where requests are sent to both new and old
versions of the service
17

19. Twelve Factor Apps and Cloud Foundry
1. One codebase tracked in revision control, many deploys
• Cloud Foundry application is unit of deployment
2. Explicitly declare and isolate dependencies
• Cloud Foundry buildpack brings runtime dependencies
3. Store config in the environment
• Facilitated by binding to services
4. Treat backing services as attached resources
• Create and bind to service
5. Strictly separate build and run stages
• Staging to immutable container
6. Execute the app as one or more stateless processes
• Stateless containers
18

20. Twelve Factor Apps and Cloud Foundry
7. Export services via port binding
• HTTP port exposed by container
8. Scale out via the process model
• cf scale
9. Maximize robustness with fast startup and graceful shutdown
• Cloud Foundry can deploy/scale quickly but can your app?
10. Keep development, staging, and production as similar as
possible
• Cloud Foundry everywhere
11. Treat logs as event streams
• Loggregator
12. Run admin/management tasks as one-off processes
• Push single-shot application
19

21. UI
(PHP)
Catalog
Service
Ordering
(Java) Catalog
Service
Catalog
(node.js)
Micro Services Example
AndroidiOS
x3
SendGrid SQLDB Address
Validation
Cloudant
Analytics
Auto
Scaling
Single
Sign-on
MySQL
20

22. Migrating to a
Microservices
Architecture
21

23. Decomposing to Services
• Decomposition isn‟t about services reaching a certain size or a
certain number – aim for each service to have a single
responsibility
• Services should be independently replaceable and upgradeable
• Differences in speed of change may be another reason to
separate services
• Separate databases before separating services
• Dependency analysis tools such as JDepend may assist in
finding natural boundaries
• Ensure existing transactions continue to reside within a single
service or redesign to use compensation and/or eventual
consistency
• Decide what you want the teams to look like first!

24. Extend the Monolith
• Build new features as microservices around an existing
monolith
• Use existing APIs or glue code for integration
• Cloud Integration service in IBM Bluemix provides a mechanism
to access existing enterprise data and systems
23

25. Summary
• What are microservices?
• Developing and deploying microservices
• Migrating to a microservices architecture
24

26. Questions?
25

27. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.

28. Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). 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 according to the terms and conditions of the
agreements under which they are provided.
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 is in compliance with any law.

29. Notices and Disclaimers (con‟t)
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 in connection with 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
PARTICULAR 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, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand,
ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™,
PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,
pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®,
urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, 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.