microservice

1. Microservices
Microdeck
Karun Bakshi

2. What is a Microservice?
2
An New Approach to Software Architecture
An modern architectural approach that emphasizes decoupling complex
functionality into smaller, independent (micro)services. Each
microservice consists of simpler functionality with fewer, focused
concerns that can only be accessed via well defined interfaces (i.e.
callers cannot make rely on knowledge about underlying implementation
details). A collection of microservices jointly comprise an application, and
each microservice is independently deployed, scaled, managed.
Effectively deploying and operating Microservices heavily relies upon
automation (e.g., CI/CD, container orchestration, etc.).
Microservice
A legacy architectural approach that results in an entire application (web
or otherwise) being self-contained and consisting of multiple related but
distinct modules/concerns being bundled, deployed and run together in
the same process and/or server. Most web application deployed to app
servers (e.g. Weblogic, Websphere, JBoss, etc.) fall in this category.
Monolith

3. Why Now? Shorter Cycle Times
3
Converging Trends
CloudNativeSoftware
DevOps
CI/CD
Pipeline
Microservices
Containers
Software
is Eating
the World
Digital
Transformation
Develop
More
Software,
Better/Fas
ter
1. Monolith complexity
slows rapid, incremental
development
2. Cannot build/test
quickly
3. Cannot provision on-
demand, elastic
compute capacity
quickly.
4. Cannot deploy and
manage quicklyBusiness
Trend
Enterprise
Initiative
Operational
Need
Technical
Challenges
Solved
Solved
Solved
Solved
Prerequisite
Prerequisite
Prerequisite
Technology
Trends
Simplified By Enables

4. Disadvantages of Monoliths
4
B
A
D C
A
Poor definition or maintenance of module boundaries can
allow dependent modules (A, B, C) to write code relying on
implementation details of other modules (D). Thus, changes
in one module (D) can force (unnecessary) code changes
and testing in dependent modules (A, B, C). Also, a small
individual module change forces the overhead of a full
release – it cannot be tested released independently.
Finally, implementation technology (e.g. java) for one
module cannot be changed to another (e.g. node.js)
because all modules are deployed and run together.
Thus, each product release where multiple modules are
undergoing enhancement may result in significant
amplification of overhead work to synchronize changes,
thereby slowing down releases.
Module
Dependency
Increased usage of a particular module (A) of a monolithic
application forces the entire app (with all modules) to be
replicated to handle additional load. This results in
unnecessary replication of modules with low load leading
to unnecessary resource consumption (e.g. memory).
Also, failure in one module can result in the entire
application becoming unavailable since all modules run
together.
Original
change
Overhead
synchronization
work
Development
Friction
Deployment
Friction

5. Monolith vs. Microservice
5
C
F
B
G H
ED
A
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
A
Microservice
Microservice
Microservice
B
C
Microservice
Microservice
E
Microservice
Microservice
Microservice
D
Microservice
Microservice
Microservice
H
Microservice
Microservice
Microservice
Microservice
G
Microservice
Microservice
F
Interface
Independently scalable, e.g.
Microservice H may have 3
container instances
First-in First-out
(FIFO)
Queue
Publish-Subscribe
(Pub-Sub)
Queue
Queues, Pub-Sub and other
messaging paradigms enable
asynchronous processing and
independent scaling.
Independent state
Explicit interface
boundary

6. Key Elements of Microservices
6
Bounded Contexts
Microservices have well defined bounded contexts, i.e. scopes. If a particular concern falls within the scope, it is
handled by the microservice, else it should be handled by a different microservice (or an entirely new one should be
created to handle it). As a result, code complexity is low in individual microservices is lower than in a given monolith.
The determination of whether a particular concern falls within the scope of a microservice is a subjective assesment
made by the application architect. However in general, bounded contexts are domain driven and easily identifiable
based on domain expertise, e.g. Netflix might have a microservice for billing, streaming, login/logout, recommendations,
etc. Notably, the same application can have multiple microservices based architectures based on the subjective
assessment of different architects.
Decoupled
Microservices are decoupled. That is, microservices have well defined interfaces and one microservice (A) can interact
with another microservice (B) only through its interface. How microservice B implements its functionality is a black box,
and hence should be able to change without microservice A being affected or even knowing. In advanced scenarios,
microservices may not call each other directly, preferring to communicate implicitly via queues, or joint storage. In such
cases, the “interface” is not callable; it’s a contract about messages and their structures. Microservice interfaces are
generally slow to change. Most code changes usually impact the internal implementation of the microservice.

7. Key Elements of Microservices
7
Continuously Refactorable
A microservices based architecture need not remain static. As architects understand the domain, use case or
customers better, they may choose to break apart a microservice into multiple microservices, or otherwise refactor their
architecture.
Independent State/Storage
Each microservice (generally) maintains its own state, in order to hide implementation details and maintain the integrity
of its interface. In contrast for example, a shared database with another microservice would “couple” both services by
not allowing either microservice to enhance its functionality or change the schema without affecting the other.
Separation of state allows maintenance of independence.
Automation Centric
Because a single application can consist of multiple, distributed microservices, each of which is independently scaled, it
generally makes sense to handle the build, deployment, upgrades, patching and other Day 2 activities through
automated means. The old means of IT manually deploying, scaling, patching etc. the application does not scale in the
microservices world.

8. Key Elements of Microservices
Distributed
Microservices generally run in different process spaces unlike a monolith, where everything runs in the same process
with shared memory. Hence, they can be run in different locations and on different servers (but still collaborate by
invoking each other’s interfaces).

9. Benefits of Microservices
Because microservices focus on a narrow, simpler scope, it is easier for development teams to push out incremental
functionality faster, without being constrained by the slower release cadence of the larger, more complex monolithic
application or be hindered by the complexity of co-mingled functionality that is conceptually separate and belongs in
separate microservices (e.g. Netflix movie recommendations vs. Netflix billing). Thus software can be rapidly developed
and delivered.
Rapid, Incremental Change
Since microservices have focused objectives that they fulfill, their individual code bases are smaller and less complex
than a complete monolithic application, thereby allowing (new) developers to quickly and fully understand it. This helps
them make changes faster than otherwise possible with a large code base. It also simplifies testing and debugging, for
individual microservices and enables faster failure isolation and resolution.
Simpler Testing/Debugging
Given the distributed architecture and deployment of microservices, an outage in one of the microservices can still allow
the remaining application to remain usable thereby enhancing user experience. (See also Spring Cloud Services)
Resiliency/Partial Failure

10. Benefits of Microservices
A stable microservice interface facilitates organizational independence. It enables different teams to make
independent technology choices, set their own release cadence and fully control the microservice roadmap and
underlying software implementation as long as they honor the service contract/interface. Teams can independently
experiment/innovate, change implementation code behind an stable microservice interface or add new functionality,
without breaking older functionality that the rest of the application relies upon. As a result, different teams can move in
parallel, and software organizations as a whole can innovate faster than would be possible with monoliths that have
complex interdependencies.
Organizational Parallelism
A microservices architecture enables scaling of individual services based on their individualized traffic patterns, thereby
optimizing both customer experience and infrastructure cost. `
Optimized/Horizontal Scalability
Microservice APIs afford incredible flexibility to enhance or rework the service implementation for higher quality (e.g.
greater robustness, cleaner code, etc.) as long as the service interface does not change. The decoupled nature of
microservices also makes it easier to retire technology debt due to lower decoupling. As a result, the application code
can easily and continuously be maintained/enhanced to be in line with best practices and the latest technology choices.
High Flexibility

11. Benefits of Microservices
Reuse of microservices already developed and tested in another context (e.g. for another application) lowers risk and
contributes to the quality of the next application that uses it. This is a better solution than simply sharing code libraries
across projects because it avoids confusion resulting from having different versions of the library in different apps. Also,
because it pools traffic from multiple applications, it reduces the resource overhead of having separate the same code
run in multiple monoliths.
Reuse
No longer constrained by the choice of a single technology used in a monolith, developers can to choose the
technology stack that is most suited to the problem at hand, and thus accelerates the development cycle and reduce
delivery risk. For example, the same application can have one microservice using C++ for real-time, in-memory
machine learning used for recommendations while using Java/servlets for the web application UI backend.
Technology Choice

12. Microservices Risks, Costs, Challenges
12
Application Complexity
Microservices provide many benefits, but they also introduce additional application runtime complexity and operational
overhead due to their asynchronous communication and distributed nature.
Thus, for example, application architects need to think about and plan for what happens to a distributed application
when one microservice calls on another that has stopped working – does the entire application “freeze up” or can they
keep unrelated portions still operational? They also need to think about “race conditions” where notification of one event
is processed at different times by multiple dependent components. Thus, a microservices based application runtime
behavior is generally significantly more complex and sophisticated than a comparable monolith.
Similarly, the application complexity also makes operational concerns more complex, such as how to deploy, upgrade,
and monitor tens or hundreds of independent microservice instances. As a result, microservices deployments rely
heavily on automation, e.g. automated container scheduling, CI/CD pipeline, microservices coordination (see Spring
Cloud Services), etc. Typically an investment in a microservices architecture makes sense if the scalability,
resiliency and other benefits outweigh these costs.

13. Microservices Risks, Costs, Challenges
Legacy Workloads Require Migration
Microservices based approaches are easiest to follow when the application under consideration is a “greenfield”
application with a significant amount of new code being developed. In “legacy” or “brownfield” scenarios, with existing
application code, there is significant investment required to convert the application (or portions thereof) to a
microservices based architecture. Such an approach is best done slowly and incrementally, i.e. by separating out one
concern at a time and converting it to a microservice or prioritizing introduction of microservices for new
features/capabilities. However the investment in modernization generally pays off in the long run due to greater agility
and operational savings through automation.
Ill Suited Early in Project
It may not make sense to introduce microservices too early in a project lifecycle when there is insufficient knowledge of
the domain, use case or customer to know which microservices are needed or what granularity to design them at. In
this scenario, monoliths can help you move quickly without having to refactor microservices and their interfaces
continuously as you explore the application domain and use case.
Microservices make sense once you have reached a “critical mass” of understanding the domain of the application –
the key entities, constructs, actors and their interactions that will comprise the core of the application functionality/value
proposition. This is generally true in well defined use cases, e.g. stock trading. Most PCF customers that are existing,
stable and/or large enterprises will know their business well enough and fall in this category as well, unless they are
trying something new.

14. Microservices Risks, Costs, Challenges
Communication Latency
A microservices based application consists of multiple distributed components that communicate with each other to
implement the application functionality. As a result, the microservices cannot communicate and collaborate through
shared memory (as in the case of monolithic apps), and must do so over the network. The constant need to
communicate over the network introduces the delay/overhead of data serialization/deserialization and network
transport. For certain applications, such a delay may not be affordable and microservices may not make sense. (Note,
again, this depends on how the microservices and bounded contexts are defined – if the time sensitive portions are
within the same microservice, this hurdle can be avoided while still embracing microservices.)
Overkill for Simple Use Cases
Microservices make sense for complex enterprise apps where the investment in handling additional complexity is
recouped in other benefits such as elastic scale, resiliency or fast/easy maintenance, etc.. If the app is limited in use
case, and never grows beyond a certain level of complexity, usage or scale, then also microservices may not make
sense – they will be overkill.

15. SOA vs. Microservices
Enterprise Service Bus (ESB)
A B C
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Independent State is a
Key Design Priority
Independent state is generally
not a design priority Designed for application
integration
Designed for independence
Functional
Application
Components
Service Endpoints (interfaces);
usually WSDL based

16. SOA vs. Microservices
Both SOA and Microservices use web service endpoints and
APIs as a mechanism to allow accessing functionality over
the network. The use of the word “service” however is
conflated in the two contexts. In SOA, the service end point is
intended to allow access to logically isolated functionality
(which could be running in a monolith behind the scenes).
Hence the focus on Application Integration and its
implementation through ESBs. With microservices, the
endpoint represents functionality that is not just logically
isolated, but also physically and quite likely
organizationally isolated. The focus is on relative
independence and speed of delivery. Thus, Microservices
represent a specialized form of SOA.
SOA and microservices, use the same mechanism (service
endpoints) but have very different intentions, goals and
philosophies for doing so.
SOA Microservices
Motivation • Application
Integration
• Speed of Development
• Robustness and Scalability of
Deployment
Commonality Web Service Endpoint
(SOAP or REST)
Web Service Endpoint (usually
REST)
Goal +
Benefits
Sought
Reuse: Logical
application refactoring
for reuse in different
contexts.
Each logical
component is wrapped
by a service endpoint.
• Reuse
• Design Simplicity
• Robustness/Resilience
• Deployment Flexibility
• Technical & Organizational
Independence
• Independent, Elastic (horizontal)
Scale
• Rapid, incremental development
Typical Use
Cases
Integrating applications
from the same or
multiple vendors, e.g.
Oracle ERP with
Oracle HCM
Building greenfield applications or
refactoring brownfield applications
into more robust architectures that
enable fast development and
delivery of software functionality.
Positioning Bandaid for Application
Integration
Next generation software
architecture paradigm for cloud
native applications.
Microservices SOA
Source of Confusion

17. Microservices & Pivotal
Concourse
Concourse is an open source CI/CD solution
sponsored by Pivotal. Pivotal also provides a
BOSH managed PCF tile for Concourse that
provides highly available CI/CD capability to
teams using PCF. CI/CD provides build and
deployment automation that is essential for
microservices solutions.
Spring Cloud Services
Spring Cloud Services is a deployment of a
collection of BOSH managed, highly
available, stateful services (PCF tile) based
on components from Spring Cloud. Among
them, it supports Config Server, Service
Registry and Circuit Breaker Dashboard. The
latter 2 are based on code open sourced by
Netflix.
Spring Cloud
Spring Cloud is part of the open source
Spring Project sponsored by Pivotal and
provides java implementations of distributed
computing patterns that are critical in
coordinating and managing microservices,
e.g. leader election, service discovery, etc.
Steeltoe
Steeltoe is an open source project sponsored
by Pivotal that provides .NET language
bindings for Spring Cloud Services.
Pivotal Cloud Foundry
Pivotal Cloud Foundry provides the
integrated collection of automation required
for deploying and operating microservices
(based applications) aka a “platform”.
PCF provides critical automation for
deploying and managing distributed
microservices including buildpacks for
software build/package/deploy, elastic
container scheduling, aggregated logging and
centralized metrics/monitoring. It also forms
the hub to which other microservice support
is attached, e.g. Concourse, Spring Cloud
Services, etc.
Spring Boot
Spring Boot is a sub project of the Spring
project and provides a simplified framework
for developing, packaging, deploying and
running Spring applications. It is designed to
not only alleviate the learning curve of getting
started with Spring by relying on java
annotations (instead of XML configuration),
but also to streamline and accelerate many
common activities that developers spend
significant time on when developing
microservices. Spring Boot accomplishes the
latter by providing reasonable default
beehavior (“conventions”), which developers
can easily override.