2. Why?
To understand why, we first need to have a look at what do we use. In
general, it is a monolithic approach.
3. Monolithic Approach
In simplest terms, Monolithic means composed all in one piece. In this
approach, program components are interconnected and interdependent.
In monolithic approach, we can divide the code in following layers:
Presentation layer
Business layer
Data access layer
4. Monolithic Approach
For example, when a web client (browser) sends a request, following happens:
The business layer performs the business logic.
Data access layer performs database collects/stores specific tasks.
Presentation layer shows the data to the user.
Basically, all code (presentation, business layer, and data access layer) is
maintained within the same code base.
5. Problem 1
Due to one codebase, all changes need to be committed/deployed via single
repository, which, as code grows, becomes very inefficient to manage.
6. Problem 2
Even in order to work in a certain module (say, product), developer needs to pull
the whole codebase to his local and configure it which, in general, shouldn’t be
the case.
7. Problem 3
Often, project tasks are divided based on the layer — UI team, backend team,
database dev team etc. Teams are specialized in their domains, but they have
little knowledge about other layers. So when there's a critical problem, it
encompasses each layer and it takes additional time to decide which layer's
problem it is and which team needs to address it.
In case of a long running project, it may be possible that no single team
understands the entirety of the application.
8. Problem 4
Due to large codebase, Scaling monolithic applications can often be a
challenge. In a large, monolithic application, everything needs to be scaled
together. For example, an application consists of two modules – user and
product. Even if we want to scale product only, it is not possible in monolithic
application.
9. Some more
Adopting new technologies is cumbersome in monolithic applications since
these applications are implemented using a single development stack (i.e.
JEE or PHP etc), which, sometimes, limit the availability of the right
solution for the problem.
Monolithic applications are Fault intolerant so the application can crash,
even by the failure of a single component/functionality.
11. Microservices
A micro service is something which is self-contained, well-defined and does not
depend on the state of other services. It is a small(er) independently deployable
unit.
12. Transition to Microservices
The idea is to split current application into a set of smaller, interconnected
services instead of building a single monolithic application.
Each microservice is a small application that has its own architecture
consisting of business logic along with various adapters.
Most microservices would expose a REST API and most services consume
APIs provided by other services.
13. Technical impact of solution used
It tackled the problem of complexity by decomposing application into a set of
manageable services which are much faster to develop, and much easier
to understand and maintain.
Each service is independent so choosing programming language is more
dependent to actual problem, rather than choices made at the start of the
project which, ultimately, reduced barrier of adopting new technologies.
14. .. Continued
It improved fault isolation so that the application can remain largely
unaffected by the failure of a single service.
Scaling services, as the need arises, is much cost effective. As per earlier
example, an application consists of 2 modules – user and product. Now
we can scale product only. Also, with the AWS Lambda like auto scalable
services, it’s very easy and much more economical to scale micro-service,
in case of increased demand for a particular service.