The emergence of cloud computing and the adoption of cloud architecture for software applications was a game-changer. It introduced so-called microservices to the fold and allowed to streamline the development process to a more focused and productive state.
At the same time, “microservices” are among the most overused buzzwords in tech blogging throughout the majority of IT-industries. The use of the word without rhyme or reason creates a lot of confusion.
The goal of this article is to clarify a few things. In particular:
- What is a Microservice Architecture?
- What kind of services use it?
- What are the benefits and disadvantages of MA?
- The requirements for microservice architecture.
Microservice architecture is a type of system infrastructure that presents an application as a framework of services designed for specific operations.
The concept of microservices originates from the single responsibility principle. It goes like this:
- “To gather together those things that change for the same reason, and separate those things that change for different reasons.”
In essence, microservice architecture takes services that do one thing well and orchestrate them into a loose framework.
- The application is like a LEGO construction kit, a collection of modules.
- Each service is doing its part for business goals.
- The parts contribute to the whole, and together they form a service.
The services are tied together by the API (aka application program interface) that provides interaction between system components. This approach enables relative independence of the services from each other, which significantly simplifies its development and maintenance.
- Microservice architecture is the preferable choice in cases where your crucial requirement of the system is agility and scalability.
Application decomposition is a significant chunk of work in determining the structure of microservices. There are three commonly used approaches to this task:
- Decomposition according to the business' capabilities (aka actions of the business operation that generate value. For example, ERP for resource management and allocation, etc.). In this case, each microservice handles a specific element of business operation.
- Decomposition by use case - i.e., microservices handle specific actions. For example, Amazon uses a specialized microservice to process shipping orders.
- Decomposition by resources - in this case, microservice covers all operations of a specific field. For example, Spotify uses microservice for user account management. This approach allows them to implement personalization features deeper and keeps user data safe from breaches.
Another significant challenge is maintaining the consistency of data over numerous microservices.
- In the microservice architecture configuration, each service operates with its own databases. The databases then synchronize during the operation.
- The system requires a more flexible approach to keeping track of data transformation to keep data consistent through and through.
- One of the viable solutions can be the Saga pattern. Here’s how it works:
- Every time service transforms data - an even is published.
- The other services in the framework take notice and update their databases.
Walmart switched to microservice architecture in 2012 after a string of system issues during seasonal peaks of customer activity.
The system could not handle the workload. This issue resulted in a decrease in revenue.
After this, Walmart made a complete overhaul of its system and re-platformed core business tasks to microservices. This approach allowed to redistribute the workload, and at the same time, streamline the workflow of the system. In turn, this enabled further refinement of the framework.
The results of the transition to microservices are staggering:
- Hardware costs dropped by 20-50% because of the architecture switch.
- In addition to this, the system used 40% less computing power than previously.
- The system avoids downtime during seasonal peaks of customer activity (as on Black Friday and the likes);
- Microservice architecture enabled full use of mobile applications which added another stream of orders, and thus increased overall amounts of conversions.
Spotify is another prominent example of using microservices to build an efficient system and avoid the challenges of monolithic complex systems.
At the moment, Spotify has over 75 million active users per month. That’s quite a scope to scale.
- These users don’t want to think about the service, so the goal is to make the customer experience seamless.
Here’s how Spotify handles it:
- The system is broken down into self-contained single-purpose microservices with autonomous development teams
- Each microservice deals with a specific goal. For example, a search engine, user behavioral analytics for recommendation engine and autogenerated playlists, content tagging, and so on.
- Because of their isolated nature, these services are less dependent on one another. As a result, customer service is consistent, and the company can continuously refine it without putting the service down.
- In addition to this, any emerging issue is contained within a specific service and doesn’t affect the rest.
Read also: How to Build a Music App Like Spotify
Microservices based architecture is a perfect fit for payment processing. Workflow is structured, and you don’t need to bend over backward to connect the parts of the workflow.
As a payment processor, Paypal’s scope of operation and customer demand is immense. The service needs to be scalable to handle the load properly. In addition to consistent service, the company needs to provide a decent customer experience. It is a challenge considering the scope of operation.
Paypal is using Node.js environment to run virtual machines that distribute the workload and deliver consistent service. As a result, the system can handle over a billion hits a day without breaking a sweat.
Amazon has the most interesting microservice use case because of its sheer scope.
Let’s take a look at the eCommerce Amazon application.
- The service encompasses multiple operations with high workload requirements. There are personalization, notification, search features, price optimization, advertisements, and other features at play. All of them manage the proceedings through APIs.
The microservice approach allows handling each feature with a dedicated team with its own workflows. Because of this, the decision-making process for each feature is streamlined, and the speed of delivery is significantly faster.
Just think about it, the company can make over 50 million deployments a year with no downturn for customers.
PassportScan is using microservice architecture to handle different aspects of the operation and keep the workflow smooth and sound.
Microservices cover the following elements:
- User account management;
- Data storage for sensitive information;
- Booking component;
- Payment component;
- Image recognition component + Natural Language Processing component;
This approach allows structuring data and keeping it safe every step of the way. There is never confusion over the sequence of actions, and this contributes to higher productivity of the workflow.
(If you want to read more about this project - check out our case study)
- One of the preeminent features of microservices is that they are small. Microservice does one thing, so the amount of code to go through is relatively low, which is a blessing for a developer because it takes much less time to understand a small application than to get into a sprawling system.
- As a result, the workflow in the integrated development environment is much faster and more productive. In addition to that, the lesser scope helps to avoid numerous human errors and subsequent bug hunts.
- Because of its isolated nature, the microservice architecture allows to break down the project team into multiple autonomous units. Each unit develops, tests, deploys and scales their piece of the application. Because of this, the overall progression of the project is much faster.
- In addition to that, the isolated nature of microservices makes it easier to fix any emerging issues. For example, you’ve got a memory leak. In the case of monolithic architecture, that situation might bring down the whole system. On the other hand, with microservice architecture, the issue is isolated to a particular service and doesn’t affect the others (albeit it disrupts the workflow).
- The other great feature of microservice architecture is a relative lack of dependence on the overarching tech stack. Each microservice uses its own stack, and it does not affect the other parts of the system. On the one hand, this gives enough room for experiments and innovation. On the other hand, it allows teams whatever they need to do the job.
- From a business standpoint, the main benefit of applying microservice architecture is enabling continuous delivery. Since the application is broken down into specialized components - it is much easier to work on the specific moving parts without disrupting the overall workflow of the app. In other words, an application is up all the time and evolves on the go.
- As a result, it is much easier to maintain the application. Instead of handling an extensive system where each element depends on the other, and even the smallest change can create some issues - you manage a constellation of small self-contained services.
- Since the system is easier to maintain - it is also much easier to test. The microservice application requires fewer resources and goes through the testing sequences in a shorter time frame, which then contributes to the overall pace of the development cycle.
- Because of this, deployment of the system becomes much simpler and less worrisome. The services are deployed independently of each other, therefore, any emerging issue is solved without affecting the overall system.
Despite all the benefits that microservice architecture can offer, there are also a couple of significant challenges that come with it.
Let’s take a closer look at them:
- While microservices themselves are small and self-contained, the connections between them create a complex distributed system, which requires a significant effort for optimization.
- Because of this, overall deployment grows in complexity. The number of moving parts in the system increases its operational complexity. This feature makes deployment much harder, as developers need to manage numerous self-contained services and their cooperation.
- Developers need to implement communication mechanisms between the services and handle partial failures with the involvement of developers from different services.
- The complex structure of the system makes the testing process much more difficult and time-consuming. This is especially the case with the testing of different interactions between services.
- The implementation of multi-service requests requires precise coordination and transparent communication of development teams. In other words, everybody needs to be on the same page at all times.
Microservice architecture is quickly becoming a preferred way of building applications throughout industries.
It is a much more flexible and cheaper method of developing an application that can grow and evolve with the business' requirements while delivering consistent customer service.
Drop us a line