Microservices is one of the buzz-word in the technology world these days. Every big name likes to say it, lots of salespeople speak of it. This post will discuss about what is a microservice, and how does it change the way we design the software architecture.
A big monolithic application can be split out into smaller components, or in this case, services. A service should have one task, and one task only. This approach increases efficiency, scalability, and allow for smaller development teams.
What are microservices?
A “microservice architecture” is an approach to developing a software application as a series of small services, each running autonomously and communicating with each other, for example, through HTTP requests to their APIs.
Normally there is a minimum number of services that manage common things for others (such as database access), but each microservice is small and corresponds to a business area of the application.
In addition, each one is independent and its code must be able to be displayed without affecting others. Even each one of them can be written in a different programming language since they only expose the API (a common interface, which does not care about the programming language in which the microservice is programmed below) to the rest of the microservices. There are no rules on what size each microservice should have, nor on how to divide the application into microservices.
Comparing the “monolithic” approach with the microservices approach
So that you really understand what we are doing with the microservices, let us examine a very simple example. Imagine that we want to make a web application, Amazon type, but simpler. Users enter our website, see the products we have for sale, and when they buy an item, we manage the delivery of the product to their home.
A first idea of how to deal with this application would be the following monolithic structure: We can access the website of the store, make purchases, etc., thanks to a server, a machine that is executing the code of the application, in the form of a war file, which eventually connects to a database to retrieve information.
When a user purchases a product via the web, the application will respond the way we have programmed, but the code of the different business logic (inventory, payments, shipments) although it may be separated into different modules of the code, it is finally packaged in a single executable file. That’s why we call it monolithic architecture.
In addition, to scale the application (for example, to serve many users) we will have to run copies of our application under load balancers, which will redirect users to one site or another, depending on whether the system is very saturated. In this case, we will have to replicate the entire application, even if only the payment module concentrates the overload.
But on the other hand, if our application is not very complex, the upload will be simple and easy to manage, since in this case, we are talking about a single executable file.
Vision of microservices
Instead of having a single executable, each component is an executable by itself, and the services communicate with each other through calls. In this case, we also have a microservice that implements the web interface with which users interact and certain logic below to call the microservice for payments, inventory, and shipments when necessary.
Characteristics of microservices
Here are some of the characteristics of microservices.
- Components via services. Each small components of the application, e.g. database, payment gateway, shopping cart, etc., can be put into their own services.
- Services organized with a focus on business capabilities. Your payment gateway can be custom-tailored to your business needs. You need to integrate Paypal – make a service that does just that. You need to hide the apartments that do not allow pets from people who have dogs – make a service to do that, and intercept the dataset coming back from the API.
- Products and not projects. Each microservice represents a product. They can be treated separately without the need of knowing what is happening to other microservices.
- Decentralized government. There are no central application to dictate how the whole application works. Each service talks to each other, forming some sort of a peer-to-peer network.
- Decentralized data management. As a best practice, microservices should have their own local data storage. Therefore each service can have the data that is relevant to its task stored locally.
- Evolving design. Business requirements can demand microservices to be put in or pull out as needed. As the business grows, it is much easier to create/remove microservices than to alter the huge code base of a monolithic structure.
Advantages and disadvantages of microservices
Now we know what microservices are as well as their architecture and main characteristics. Therefore, we will detail some of its advantages and disadvantages.
- Minimal work team. Each team can manage the development of a microservice, and this generally does not need a lot of people (small team of 3 to 4 people is preferred)
- Increase in efficiency. By optimizing each microservice, the total efficiency can be improved.
- Scalability. It is much easier to increase the capacity of a microservice, and combine with other services, it boost the the application’s ability to serve more users.
- Modular functionality, independent modules. microservices should be independent from each other. For instance, a microservice should only care about the input data, not where the data is coming from.
- Freedom of the developer to develop and deploy services independently. developers can use any programming languages that he or she feels comfortable with, or it is the most suitable language for the task at hand. In monolithic application, there is less flexibility in choosing which language to use.
- Allowing the deployment and development of the application quickly. With the introduction of Docker, Kubernettes, AWS, etc., continuous integration/continuous deployment is another buzz word now. Business needs to have a quick development phase to keep up with the ever-changing requirements. By deploying microservices concurrently, booting an application to its ready state is much faster.
- High memory consumption. Each microservice needs a certain memory and storage to operate. Having a considerable amount of them can cost a lot of resources.
- The complexity of management of a large number of services. Netflix has over 13,000 git repositories, and most of them are services. Sometimes it is not transparent if there is an existing microservice that resolves a problem.
- Network latency or load balancing. If not structure correctly, microservices will keep calling each other, resulting in a chaotic communication network. As a result, the time to return the result to the end user can be impacted negatively.
- Complex tests or tests for distributed deployment. End-to-end tests can be a nightmare. For example, we need to test the workflow of putting a product into a shopping cart, then use American Express to checkout. This could involve multiple microservices and the testing solutions can be complicated.
As we have seen, microservices have numerous advantages that facilitate processes when using an app. However, being a novel system a large majority of CIOs will be slowed down to implement these systems in their company due to the complexity of some features.
However, the implementation of microservices could have a great impact on large companies in a positive way for increased efficiency. An example of this we see in Amazon or Netflix that have already implemented this technology.
More information on microservices can be found here.
Next post: Microservices – When NOT to use?
By Tuan Nguyen