Java Reference
In-Depth Information
(REST) API (see Chapter 13, “RESTful Web Services”), you are only required to honor the resource
representation contract, not to think about the way the front end will be implemented. This allows
true separation of concerns.
From the perspective of application performance, the main benei t comes from being able to
deploy each microservice onto its own tailored environment. The resource requirements of your
microservice may differ from another, thereby allowing resource allocation to be i ne grained.
A monolithic application is deployed on one environment with shared resources.
Fault tolerance and isolation are increased. A fault in one microservice does not affect the opera-
tions of the others, allowing the application to continue to perform. In a system that uses MOM
to communicate between services, messages destined for a failed microservice wait in the queue
until the fault is resolved and the microservice (consumer) begins to consume the messages. If the
application is scaled horizontally, there's no break in service because one of the duplicate microser-
vices consumes the messages. In a monolithic application, such a fault could bring down the entire
application.
Among all the benei ts attributed to the microservice architecture, the most talked about is
the ease with which you can change the technology stack. Because each microservice is small,
rewriting it is not expensive. In fact, new microservices can be written in any language, allow-
ing you to choose the most suitable language for solving the problem. Technology decisions made
at the beginning of the project do not dictate the technology that you must use throughout the
application's life.
Nothing in Life Is Free
The benei ts of the microservice architecture do not come free. There are costs involved.
The ease with which you can develop a microservice makes it easy for the number of microservices
to grow, and to grow very quickly. Fifteen microservices can easily become thirty or more, especially
when different versions of the same microservice are counted. This poses several difi culties.
The responsibility for operations may move to the development team. With only a handful of
services to maintain, it's not a difi cult task, but as the number of microservices grows, the task
of maintaining them increases. A signii cant investment needs to be made to ensure that the
microservices are deployed and maintained. Processes need to be automated to reduce the burden of
deploying and maintaining a large number of services. There may be a knowledge gap you need to
i ll, adding to the overall running costs.
Cross‐cutting changes to semantics means that all microservices must update their code to keep
in sync. This can be time consuming to perform and has signii cant retesting costs. Alterations to
interface contracts and message formats can be the cause of such changes and require that all teams
work in a coordinated way. Equally, failing to change an interface or message format early on in the
project results in signii cantly greater costs as the number of microservices grows.
Duplicated code is something that you have been taught is bad, and it is. In a microservice environ-
ment, the risk of code duplication is high. To avoid coupling and dependencies, code must some-
times be duplicated, meaning every instance of that code must be tested and maintained. You may
be able to abstract code to a share library, but this does not work in a polyglot environment.
