Microservices

Notes
By Kaustubh

Aug 28, 2019

What are microservices?

Microservices - also known as the microservice architecture - is an

architectural style that structures an application as a collection of

services that are

Highly maintainable and testable

Loosely coupled

Independently deployable

Organized around business capabilities

Owned by a small team

Microservices, aka Microservice Architecture, is an architectural style

that structures an application as a collection of small autonomous

services, modeled around a business domain.

Each component in a microservices architecture is a small, single

focused, business-centric, autonomous service.

The microservice architecture enables the rapid, frequent and reliable

delivery of large, complex applications.

It also enables an organization to evolve its technology stack.

REF :

https://microservices.io/i/MicroservicePatternLanguage.pdf

https://microservices.io/index.html

Microservices adoption anti

patterns
1. believing that microservices will solve all of your development

problems

2. making the adoption of microservices the goal and measuring

success in terms of the number of services written

3. multiple application development teams attempt to adopt the

microservice architecture without any coordination

4. attempting to adopt the microservice architecture (an advanced

technique) without (or not committing to) practicing basic

software development techniques, such as clean code, good

design, and automated testing

5. focusing on technology aspects of microservices, most commonly

the deployment infrastructure, and neglecting key issues, such

as service decomposition

6. intentionally creating a very fine-grained microservice

architecture

7. retaining the same development process and organization

structure that were used when developing monolithic

applications.
Monolithic Architecture
Large single deployable unit

Consists of multiple components for various business

functionality

Scaling the app usually means deploying another war on another

container and load balancing the servers

Problems with this approach

Large code base, new developers take time to get up to speed

and be productive on application development and maintenance

Overloaded IDE, reduced developer productivity since the IDE is

slow and unresponsive due to large code base

Overloaded container, application take time to deploy and start.

Lot of development time is wasted just waiting for the app to

start

Continuous deployment is difficult. Need to deploy the entire

unit just to test small code change.

Scaling app is difficult. Can add more tomcat instances to

increase transaction volume, but it cannot scale to handle data

volume. components might be CPU intensive or memory

intensive, it is not possible to scale them individually in a

monolith

Application development team may be segregated into UI team,

server side dev team, but it is not possible for these teams to

work independently. Team must coordinate development and

 redeployment, which make it difficult to make changes and
update production

Developing monolith involves long term commitment to the

technology stack. It may not be feasible to reengineer the entire

app to accommodate technology advancements. Thus the stack

is less flexible and has to be kept the same for most of the

application lifecycle. Migrating to updated technology stack may

include application rewriting which is a risky undertaking.

Understanding Microservice
Architecture

Consider this fictitious e commerce website. The application consists of

several components including the StoreFrontUI, which implements the
user interface, along with some back end services for checking credit,

maintaining inventory and shipping orders.

Benefits of this architecture

Enables the continuous delivery and deployment of large,

complex applications.

Improved maintainability

each service is relatively small

easy to understand and change

Better testability - services are smaller and faster to test

Better deployability - services can be deployed independently

Development effort is around multiple, autonomous teams.

Each team owns and is responsible for one or more

services.

Each team can develop, test, deploy and scale their

services independently of all of the other teams.

Each microservice is relatively small:

Easier for a developer to understand

The IDE is faster making developers more productive

The application starts faster, which makes developers

more productive, and speeds up deployments

Improved fault isolation. For example, if there is a memory leak

in one service then only that service will be affected. The other

services will continue to handle requests.

In comparison, one misbehaving component of a

 monolithic architecture can bring down the entire

system.

Eliminates any long-term commitment to a technology stack.

When developing a new service you can pick a new

technology stack.

When making major changes to an existing service you

can rewrite it using a new technology stack.

Drawbacks
Distributed systems have additional complexity which

developers need to deal with

need to implement inter-service communication

need to deal with partial failures

implenting requests that span multiple services is more

difficult

testing interaction between microservices will be more

difficult

needs careful coordination among teams

Deployment complexity

operational complexity involved when deployning

multiple services

increased memory comsumption

monolith app maybe decomposed into N microservices

which need to be deployed on M instances for isolated

execution. This increases number of jvm runtimes and

hence adds overhead to memory consumption

How to decompose the
application into services?
Decompose by business capability and define services

corresponding to business capabilities.

Decompose by domain-driven design subdomain.

Decompose by verb or use case and define services that are

responsible for particular actions.

e.g. a Shipping Service that’s responsible for shipping

complete orders.

Decompose by by nouns or resources by defining a service that

is responsible for all operations on entities/resources of a given

type.

e.g. an Account Service that is responsible for managing

user accounts.

Decompose by business
capability
A service must be small enough to be developed by a small team and to

be easily tested.

Consider SRP

SRP defines a responsibility of a class as a reason to

change, and states that a class should only have one

 reason to change.

It make sense to apply the SRP to service design as well

and design services that are cohesive and implement a

small set of strongly related functions.

Consider OCP

this is useful when trying to decompose application in a

way so that most new and changed requirements only

affect a single service.

OCP states that classes that change for the same reason

should be in the same package.

So when some business rule changes, developers only

need to change code in a small number - ideally only one

- of packages.

This kind of thinking makes sense when designing

services since it will help ensure that each change

should impact only one service.

Define services corresponding to business capabilities

A business capability is a concept from business architecture

modeling.

It is something that a business does in order to generate value.

A business capability often corresponds to a business object, e.g.

Order Management is responsible for orders

Customer Management is responsible for customers

Model each service corrsponsing to each business capability

Benefits

stable architecture since business capabilities are relatively

stable

services are cohesive and loosely coupled

Decompose by subdomain
Define services corresponding to Domain-Driven Design (DDD)

subdomains

A domain is consists of multiple subdomains. Each subdomain

corresponds to a different part of the business.

Subdomains can be classified as follows

Core

key differentiator for the business

the most valuable part of the applications

 Supporting

related to what the business does but not a

differentiator.

Generic

not specific to the business

ideally implemented using off the shelf software

Identifying business capabilities/subdomains and hence services

requires an understanding of the business.

An organization’s business capabilities are identified by analyzing the

organization’s purpose, structure, business processes, and areas of

expertise.

Bounded contexts are best identified using an iterative process.

Good starting points for identifying business capabilities are:

organization structure - different groups within an organization

might correspond to business capabilities or business capability

groups.

high-level domain model - business capabilities often correspond

to domain objects

Database per service

Services need to be loosely coupled in microservices

architecture
 Different services may have different storage requirements eg

NoSQL such as MongoDb might be a better choice over Oracle.

Some business transactions may span multiple services and

hence may need to update multiple data bases

Database may sometimes be replicated for scaling purposes

To be able to achieve such goals

Keep each microservice’s persistent data private to that service

and accessible only via its API

A service’s transactions only involve its database

Thus services’ database is part of the implementation of that

service. It cannot be accessed directly by other services.

Use options like

Private-tables-per-service – each service owns a set of tables

that must only be accessed by that service

Schema-per-service – each service has a database schema that’s

private to that service

Database-server-per-service – each service has it’s own database

server.

Benifits of database per service

Changes to one service’s database does not impact any other

services.

Each service can use the type of database that is best suited to

its needs
Drawbacks of database per service

Implementing business transactions that span multiple services

is not straightforward

Distributed transactions are best avoided

Implementing queries that join data that is now in multiple

databases is challenging

Complexity of managing multiple SQL and NoSQL databases