Creating Microservices Applications

Microservices are independently deployable services modeled around a business
domain. They communicate with each other via networks, and as an architecture
choice offers many options for solving the problems you may face. It follows that a
microservice architecture is based on multiple collaborating microservices.
They are a type of service-oriented architecture (SOA), albeit one that is opinionated
about how service boundaries should be drawn, and that independent deployability is
key. Microservices also have the advantage of being technology agnostic.
From a technology viewpoint, microservices expose the business capabilities that they
encapsulate via one or more network endpoints. Microservices communicate with
each other via these networks—making them a form of a distributed system. They also
encapsulate data storage and retrieval, exposing data, via well-defined interfaces. So
databases are hidden inside the service boundary.

Independent Deployability
Independent deployability is the idea that we can make a change to a microservice and
deploy it into a production environment without having to utilize any other services.
More importantly, it’s not just that we can do this; it’s that this is actually how you
manage deployments in your system. It’s a discipline you practice for the bulk of your
releases. This is a simple idea that is nonetheless complex in execution.
If there is only one thing you take out of this book, it should be
this: ensure you embrace the concept of independent deployability
of your microservices. Get into the habit of releasing changes to a
single microservice into production without having to deploy anything
else. From this, many good things will follow.
To guarantee independent deployability, we need to ensure our services are loosely
coupled—in other words, we need to be able to change one service without having to
change anything else. This means we need explicit, well-defined, and stable contracts
between services. Some implementation choices make this difficult—the sharing of
databases, for example, is especially problematic. The desire for loosely coupled services
with stable interfaces guides our thinking about how we find service boundaries
in the first place.

Domain specificity
Making a change across a process boundary is expensive. If you need to make a
change to two services to roll out a feature, and orchestrate the deployment of these
two changes, that takes more work than making the same change inside a single service
(or, for that matter, a monolith). It, therefore, follows that we want to find ways of
ensuring we make cross-service changes as infrequently as possible.
Our business domain becomes the primary force driving our system architecture,
hopefully making it easier to make changes, and making it easier for us to organize
our teams around our business domain. This is so important that before we finish
In this chapter, we’ll revisit the concept of modeling software around a domain, so I can
share some ideas around domain-driven design that shape how we think about our
microservice architecture.

Independent Data Ownership
One of the things I see people having the hardest time with is the idea that microservices
should not share databases. If one service wants to access data held by another
service, then it should go and ask that service for the data it needs. This gives the service
the ability to decide what is shared and what is hidden. It also allows the service
to map from internal implementation details, which can change for various arbitrary
reasons, to a more stable public contract, ensuring stable service interfaces. Having
stable interfaces between services is essential if we want independent deployability—if
the interface a service exposes keeps changing, this will have a ripple effect causing
other services to need to change as well.

Advantages of Microservices
The advantages of microservices are many and varied. The independent nature of the
deployments opens up new models for improving the scale and robustness of systems
and allows you to mix and match technology. As services can be worked on in
parallel, you can bring more developers to bear on a problem without them getting in
each other’s way. It can also be easier for those developers to understand their part of
the system, as they can focus their attention on just one part of it. Process isolation
also makes it possible for us to vary the technology choices we make, perhaps mixing
different programming languages, programming styles, deployment platforms, or
databases to find the right mix.
Perhaps, above all, microservice architectures give you flexibility. They open up many
more options regarding how you can solve problems in the future.
However, it’s important to note that none of these advantages come for free. There are
many ways you can approach system decomposition, and fundamentally what you
are trying to achieve will drive this decomposition in different directions. Understanding
what you are trying to get from your microservice architecture therefore
becomes important.

———————————————————————————————————————————–

Contact Us:

Email Us: sales@blog.srninfotech.com
Mobile: 0731 4963120
Skype: shiva.nayak351