On our journey down the lane of understanding microservices and their evolution, we continued through various phases. We explored what led to the advent of microservices and the various advantages of utilizing them. We also discussed various integration techniques and testing strategies. Let's recap all that we have talked about thus far:
Microservices were never designed from the ground up to be in the present form. Instead, there has been a gradual transition from other forms of prevalent architecture styles to microservices. Prior to microservices, we had the monolithic architecture and service-oriented architecture that reigned over the world of enterprise development.
Let's delve into these two before doing a quick recap of microservices and their various attributes and advantages.
The monolithic architecture has been around for quite some time and it results in self-contained software with a single .NET assembly. It consists of the following components:
The cost paid for being self-contained was that all the components were interconnected and interdependent. A minor change in any module had the capability to impact the entire piece of software. With all the components so tightly coupled in this manner, it made testing...
As part of our exercise, we decided to transition our existing monolithic application FlixOne to a microservice-styled architecture. We saw how to identify decomposition candidates within a monolith, based on the following parameters:
There are definite advantages it provides in regard to cost, security, and scalability apart from technology independence. This also aligns the application more with the business goals rather than the current or possible technical boundaries.
The entire process of transitioning requires you to identify seams that act like boundaries of your microservices along which you can start the separation. You have to be careful about picking up seams on the right parameters. We have talked about how module interdependency, team structure, database, and technology are a few probable candidates. Special care is required to handle master data. It is more a choice whether you want...
The monolith world had a few advantages of its own. Easier monitoring and logging is one of those areas where things are easier compared to microservices. The sheer number of microservices across which an enterprise system might be spread can be mind-boggling.
As discussed in Chapter 1, What are Microservices, in the Prerequisites for a microservice architecture section, an organization should be prepared for the profound change. The monitoring framework was one of the key requirements for this.
Unlike a monolith architecture, monitoring is very much required from the very beginning in a microservice-based architecture. There is a wide range of reasons why monitoring can be categorized:
To begin with monitoring, you could think of different commonly implemented strategies as a solution to your problem. Some of the commonly implemented strategies are:
Just bear in mind that each one of these strategies is focused on solving a specific purpose only. While one could be helpful in analyzing transaction propagation, the other could be suitable for testing purposes. So it is important for you to pick up a combination of these when designing the whole system since just using a single strategy won't suffice the needs.
We have discussed in detail the scale-cube model of scalability and have found what scaling at each axis means. Note that x-axis scaling is achieved through the use of load balancers between multiple instances and the users of the microservices. We also saw how z-axis scaling is based on the transaction origination...
We have progressed well while transitioning our monolithic application to the microservice-styled architecture. We have also briefly touched upon the possibility of introducing reactive traits to our services. We now know what are the key attributes of reactive microservices are:
We also saw the benefits of reactive microservices amounting to less work on our part when it comes to managing communication across/between the microservices. This benefit translates not just into reduced work but the capability to focus on the core job of executing the business logic instead of trying to grapple with the complexities of inter-service communication.
Now let's go ahead and create the FlixOne bookstore from scratch. First, we will scope out our microservices and their functionalities and identify inter-service interactions as well.
Our FlixOne bookstore will have the following set of functionalities available:
In order to understand how these functionalities will map out as different microservices, we need to first understand what it would take to support it and what can be clubbed together as a microservice. We will see how the data store would start to look out of the window of microservices themselves.
We hope that this book was able to get you initiated with the fundamental concepts of the microservice-styled architecture and also helped you dive deeply into the fine aspects of microservices with clear examples to associate the concepts with. The final application is available for you to take a closer look and analyze what you have learned so far at your pace. We wish you luck in utilizing the skills learned in this book and apply them to your real-world challenges.
© 2017 Packt Publishing Limited All Rights Reserved
