Microservices

Johannes Sianipar
18 February 2021
Monolithic Architecture

■ Inflexible – Monolithic applications cannot be built using different

technologies
■ Unreliable – Even if one feature of the system does not work, then the
entire system does not work
■ Unscalable – Applications cannot be scaled easily since each time the
application needs to be updated, the complete system has to be rebuilt
■ Blocks Continous Development– Many features of the applications
cannot be built and deployed at the same time
■ Slow Development – Development in monolithic applications take lot of
time to be built since each and every feature has to be built one after the
other
Microservices
■ Not Fit For Complex Applications – Features of complex applications
have tightly coupled dependencies

Chart 2
Monolithic Architecture (Cont.)

■ Codebases grow as we write code to add new features.

□ Over time, it can be difficult to know where a change needs to be made
because the codebase is so large.
□ Code related to similar functions starts to become spread all over,
making fixing bugs or implementations more difficult.

Microservices

Chart 3
Microservice Representation

■ An architectural style that structures an application as a collection of small

autonomous services, modeled around a business domain
□ each service is self-contained and implements a single business
capability.

Microservices

Chart 4
Microservices Characteristics

■ Small, and Focused on Doing One Thing Well

■ Cohesion — the drive to have related code grouped together — is an
important concept when we think about microservices.
□ Robert C. Martin’s definition of the Single Responsibility Principle
– “Gather together those things that change for the same reason, and
separate those things that change for different reasons.”
■ Microservices take this same approach to independent services.
□ We focus our service boundaries on business boundaries, making it
obvious where code lives for a given piece of functionality.
□ And by keeping this service focused on an explicit boundary, we avoid
the temptation for it to grow too large, with all the associated difficulties Microservices
that this can introduce.

Chart 5
how small is small?

■ Jon Eaves at RealEstate.com.au in Australia characterizes a microservice

as something that could be rewritten in two weeks, a rule of thumb
that makes sense for his particular context
■ A strong factor in helping us answer how small? is how well the service
aligns to team structures. If the codebase is too big to be managed by a
small team, looking to break it down is very sensible. We’ll talk more
about organizational alignment later on.
■ the smaller the service, the more you maximize the benefits and
downsides of microservice architecture
□ the benefits around interdependence increase
□ the complexity that emerges from having more and more moving parts
Microservices

Chart 6
Monolithic vs Microservice

Microservices

Chart 7
Monolithic vs Microservice

Microservices

Chart 8
Microservice Architecture

Microservices

Chart 9
Microservice Architecture (Cont.)

■ Different clients from different devices try to use different services like search,
build, configure and other management capabilities
■ All the services are separated based on their domains and functionalities and
are further allotted to individual microservices
■ These microservices have their own load balancer and execution environment
to execute their functionalities & at the same time captures data in their own
databases
■ All the microservices communicate with each other through a stateless server
which is either REST or Message Bus
■ Microservices know their path of communication with the help of Service
Discovery and perform operational capabilities such as automation, monitoring
■ Then all the functionalities performed by microservices are communicated to
clients via API Gateway
Microservices
■ All the internal points are connected from the API Gateway. So, anybody who
connects to the API Gateway automatically gets connected to the complete
system
Chart 10
Microservices principles

■ One job
□ Each microservice must be optimized for a single function. Each service is smaller and
simpler to write, maintain, and manage.
■ Separate processes
□ Communication between microservices must be conducted through REST API and message
brokers.
■ Execution scope
□ Although microservices can expose themselves through APIs, the focus is not on interfaces,
but on the running components.
■ CI/CD
□ Each microservice can be continuously integrated (CI) and continuously delivered (CD).
– Different services evolve at different rates.
– In the monolithic approach, different aspects of the system are all released at the speed
of the slowest moving part of the system.
■ Resiliency
Microservices
□ You can apply high availability and clustering decisions to each microservice.
□ The monolithic approach of scaling all the services in the monolith at the same level can
lead to the overuse or underuse of services.
Chart 11
Microservices Features

Microservices

Chart 12
Microservices Features (Cont.)

■ Decoupling – Services within a system are largely decoupled. So the application as a

whole can be easily built, altered, and scaled
■ Componentization – Microservices are treated as independent components that can
be easily replaced and upgraded
■ Business Capabilities – Microservices are very simple and focus on a single
capability
■ Autonomy – Developers and teams can work independently of each other, thus
increasing speed
■ Continuous Delivery – Allows frequent releases of software, through systematic
automation of software creation, testing, and approval
■ Responsibility – Microservices do not focus on applications as projects. Instead, they
treat applications as products for which they are responsible
■ Decentralized Governance – The focus is on using the right tool for the right job.
That means there is no standardized pattern or any technology pattern. Developers
Microservices
have the freedom to choose the best useful tools to solve their problems
■ Agility – Microservices support agile development. Any new feature can be quickly
developed and discarded again
Chart 13
Advantages Of Microservices

Microservices

Chart 14
Best Practices To Design Microservices

Microservices

Chart 15
Companies using Microservices

Microservices

Chart 16
Reference

■ Building Microservices by Sam Newman

■ https://www.edureka.co/blog/what-is-microservices/
■ https://www.ibm.com/cloud/architecture/architectures/microservices

Microservices

Chart 17
Thank you
for your attention!
Johannes Sianipar