In the previous chapter, we discussed the problems of a layered monolith architecture. In this chapter, we will discuss how we can refactor them from the existing system and build separate microservices for product and order. In this chapter, we will cover the following topics:
Before we start building our microservices, we should be clear about a few of its basic aspects, such as what factors to consider while sizing our microservices and how to ensure their isolation from the rest of the system.
As the name suggests, microservices should be micro. A question arises: what is micro? Microservices is all about size and granularity. To understand this better, let's consider the application discussed in Chapter 1, What are Microservices?
We wanted the teams working on this project to stay synchronized at all times with respect to their code. Staying synchronized is even more important when we make a release of the complete project. For this, we needed to first decompose our application/specific parts into smaller functionalities/segments of the main service. Let's discuss the factors that need to be considered for high-level isolation of microservices:
Before microservices were conceptualized, whenever we thought of enterprise application integration, middleware looked like the most feasible option. Software vendors offered Enterprise Service Bus (ESB), and it was one of the options as middleware.
Besides considering these solutions, our main priority should be inclined toward the architectural features. When microservices arrived, middleware was no more a consideration. Rather, the focus shifted to contemplation on business problems and how to tackle those problems with the help of the architecture.
In order to make a service that can be used and maintained easily by developers and users, it would require the service to have the following features (we can also consider these as characteristics of good services):
Domain-Driven Design (DDD) is a methodology and a process of designing complex systems. In this section, we will briefly discuss DDD and how it is important in the context of microservices.
The main objective of domain design is to understand the exact domain problems and then draft a model that can be written in any set of language/technologies. For example, in our Flix One bookstore application, we need to understand Order Management and Stock Management.
Here are a few characteristics of the domain-driven model:
At the very core of microservices lies the capability to work on a specific functionality in isolation from the rest of the system. This translates into all the advantages discussed earlier, such as reduced module dependency, code reusability, easier code maintenance, and better deployment.
In my opinion, the same attributes that were attained with the implementation of microservices should be maintained during the process of implementation. Why should the whole process of moving monoliths to microservices be painful and not be as rewarding as having the microservices itself? Just remember that the transition can't be done overnight and would need meticulous planning. Many capable solution architects have differed from my approach while presenting their highly capable teams. The answer lies not just in the points already mentioned but the risk to the business itself at the same time.
This is very well attainable. However, we must identify our way to the path correctly in...
In the preceding section, we separated our Order module into Order Services and discussed how we can break down the foreign key relationship between ORDER and PRODUCT tables.
In a monolithic application, we have a single repository that queries the database to fetch the records from both ORDER and PRODUCT tables. However, in our upcoming microservice application, we will segregate repositories between Order Service and Product Service. With each service having its respective database, each one would access its own database only. Order Service would only be able to access order Database, whereas Product Service would be able to access product Database only. Order Service should not be allowed to access product Database and vice versa. Refer to the following image:
We will discuss communication between microservices in Chapter 3, Integration Techniques, in detail.
In the preceding figure, we see that our UI is interacting with Order Service and Product...
In the preceding chapter, we took an example of an imaginary company, Flix One Inc., operating in the e-commerce domain and having its own .NET monolithic application: Flix One book store. We have already discussed:
In this section, we will start writing/transitioning .NET monolith to a microservice application.
We will use the following tools and technologies while transitioning our monolithic application to the microservice-styled architecture:
We already have our product module in place. We are going to pull back this module now and start with a new ASP.NET Core MVC project. For this, follow all the steps we discussed in the preceding sections and in Chapter 1, What Are Microservices...
In this chapter, we discussed different factors that can be used to identify and isolate microservices at a high level. We also discussed the various characteristics of a good service. Talking about DDD, we saw what its importance is in the context of microservices.
Further, we analyzed how we can correctly achieve vertical isolation of microservices through various parameters in detail. While we tried to draw upon our previous understanding of the challenges posed by a monolithic application and its solution in microservices, we saw that we can use factors such as module interdependency, technology utilization, and team structure to identify seams and perform the transition from a monolithic architecture to microservices in an organized manner.
It became apparent that the database can pose a clear challenge in the process. However, we identified how we can still perform this with a simple strategy and the possible approaches to do this. We then discussed that with the foreign keys...
© 2017 Packt Publishing Limited All Rights Reserved
