Java Reference
In-Depth Information
If you decompose the applications in Figure 15-3 along the Y‐axis, you end up with the architecture
in Figure 15-5.
User Account
View
Inventory View
Order View
User
Account
Service
Customer
Service
Stock
Control
Service
Payment
Service
User Account
Data
Customer
Data
Stock Control
Data
Payment Data
FIGURE 15-5:
Y‐axis decomposition
The front‐end views have been split into separate applications that access the functionality of sev-
eral back‐end services. The services have been split from the monolithic application into standalone
applications that manage their own data. You can achieve splits along the Z‐axis by sharding the
data and scaling along the X‐axis by clustering and load balancing.
You have seen how to decompose a monolithic application into microservices and learned the
importance of scalability for the continuance of an application.
Now you'll look more closely at the specii c benei ts and cost of the microservice architecture.
Microservice Benei ts
From the development perspective, the benei ts of a microservice architecture result from the size
and agility of the small applications of which it consists. They are easy for developers to understand
and for the IDE to manage. A large application that consists of many hundreds of modules can take
considerable time to load, which negatively affects the developers' productivity. Each microservice
application can be deployed quicker and often without the cooperation of other teams. Because each
service stands alone, local changes to code do not affect other microservices; therefore, continuous
development is possible. Each microservice can be developed by a dedicated team of developers who
manage the deployment and resource requirements of their service independently of other teams.
The user interface (UI) is normally divorced from back‐end development; your development team
may never see a line of UI code. If you are programming to a REpresentational State Transfer
