Microservices and
Decomposition
strategies
BITS Pilani Soma Sundaram P
Pilani Campus Guest Faculty
BITS Pilani
Pilani Campus
Merged - CCZG583/SEUSZG583,
Scalable Services
Lecture No. 5
BITS Pilani
Pilani Campus
Advantages and disadvantages of
Microservices
Scale cube
BITS Pilani, Pilani Campus
Advantages
• Technology Heterogeneity
BITS Pilani, Pilani Campus
Advantages
• Resilience
• Ease of Deployment
• Scaling
BITS Pilani, Pilani Campus
Microservices is not a silver
bullet
• Complexity
• Finding the right services is challenging
• Development and testing
• Network congestion and latency
• Data integrity
• Careful Coordination
• Versioning
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Process and Organization
Introduction
BITS Pilani, Pilani Campus
Software development and
delivery organization
• Success means that the engineering team will grow
• The solution is to refactor a large single team into a team
of teams.
• The velocity of the team of teams is significantly higher
than that of a single large team.
• Moreover, it’s very clear who to contact when a service
isn’t meeting its SLA.
BITS Pilani, Pilani Campus
Software development and
delivery process
• If you want to develop an application with the
microservice architecture, it’s essential that you adopt
agile development and deployment practices
• Practice continuous delivery/deployment, which is a part
of DevOps.
• A key characteristic of continuous delivery is that
software is always releasable.
BITS Pilani, Pilani Campus
The human side of adopting
microservices
• Ultimately, it changes the working environment of people
and thus impact them emotionally
Three stage transition model
• Ending, Losing, and Letting Go
• The Neutral Zone
• The New Beginning
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Microservices Design Principles
Single Responsibility
• Sometimes it's important to maintain data consistency by
putting functionality into a single microservice.
• Each microservice implements only one business
responsibility from the bounded domain context.
• The rule of thumb is
“Gather together those things that change for the same
reason, and separate those things that change for
different reasons.” — Robert C. Martin
BITS Pilani, Pilani Campus
Abstraction and Information
Hiding
• A service should only be consumed through a
standardized API and should not expose its internal
implementation details to its consumers
BITS Pilani, Pilani Campus
Loose coupling
• Dependencies between services and their consumers are
minimized with the application of the principle of loose
coupling
BITS Pilani, Pilani Campus
Fault tolerance
• Each service is necessarily fault tolerant so that failures
on the side of its collaborating services will have minimal
impact
BITS Pilani, Pilani Campus
Discoverability
• The aim of discoverability is to communicate a clear
understanding of the business purpose and technical
interface of the microservice.
BITS Pilani, Pilani Campus
Reusability
• Reuse continues to be a principle of microservice design.
However, the scope of reuse has been reduced to
specific domains within the business.
BITS Pilani, Pilani Campus
Steps for defining an application’s
microservice architecture
Step 1: Identify system operations
Step 2: Identify services
Step 3: Define service APIs and collaborations
BITS Pilani, Pilani Campus
What is a Service?
• The first and most important aspect of the architecture is,
the definition of the services.
BITS Pilani, Pilani Campus
The role of Shared Libraries
• On the surface, it looks like a good way to reduce code
duplication in your services.
• But you need to ensure that you don’t accidentally
introduce coupling between your services.
• You should strive to use libraries for functionality that’s
unlikely to change.
BITS Pilani, Pilani Campus
Size of a Service
• Size isn’t a useful metric.
• A much better goal is to define a well-designed service
• Build a set of small, loosely coupled services.
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Monolith to microservices
Rebuild From Scratch
• One of the biggest challenges for us was having a good
understanding of the legacy system.
• Can not use the system until complete
• Longer duration required
BITS Pilani, Pilani Campus
Strangler Pattern
• The Strangler Pattern is a popular design pattern to incrementally transform
your monolithic application into microservices by replacing a particular
functionality with a new service.
• Any new feature to be added is done as part of the new service
BITS Pilani, Pilani Campus
Strangler Pattern
BITS Pilani, Pilani Campus
Strangler Pattern
Steps involved in transition
BITS Pilani, Pilani Campus
Strangler Pattern: Issues
• What component to start with?
• How to handle services and data stores that are
potentially used by both new and legacy systems?
• Migration
BITS Pilani, Pilani Campus
When not to use Strangler
Pattern?
• When requests to the back-end system cannot be
intercepted.
• For smaller systems where the complexity of wholesale
replacement is low.
BITS Pilani, Pilani Campus
BITS Pilani
Pilani Campus
Decomposition based patterns
Decompose by business
capability pattern
• Business capability is something that a business does in
order to generate value.
• Example: The capabilities of an online store include
Order management,Inventory management, Shipping,
and so on.
BITS Pilani, Pilani Campus
Identifying Business
Capabilities
Business capabilities for FTGO include the following:
• Supplier management
• Consumer management
• Order taking and fulfilment
• Accounting
BITS Pilani, Pilani Campus
From business capabilities
to services
• Once you’ve identified the business capabilities, you then
define a service for each capability or group of related
capabilities
BITS Pilani, Pilani Campus
Decompose by sub-domain
pattern
• DDD is an approach for building complex software
applications centered on the development of an object-
oriented, domain model.
• DDD has two concepts that are incredibly useful when
applying the microservice architecture: subdomains and
bounded contexts.
BITS Pilani, Pilani Campus
From Subdomains to
Services
• DDD defines a separate domain model for each
subdomain
• The examples of subdomains in FTGO include order
taking, order management, restaurant order
management, delivery, and financials.
• DDD calls the scope of a domain model a “bounded
context.”
• When using the microservice architecture, each bounded
context is a service or possibly a set of services.
BITS Pilani, Pilani Campus
Decompose by sub-domain
pattern
BITS Pilani, Pilani Campus
Decomposition guidelines
• Single Responsibility Principle
• Common Closure Principle
BITS Pilani, Pilani Campus
References
• Book: Microservices Patterns by Chris Richardson
• Book: Building Microservices by Sam Newman
• Book: Monolith to Microservices by Sam Newman
• Link:
https://docs.microsoft.com/en-us/azure/architecture/micr
oservices/design/
• Link:
https://docs.microsoft.com/en-us/azure/architecture/micr
oservices/design/patterns
BITS Pilani, Pilani Campus
