Microservices have recently become the preferred technology for developing cloud applications. A survey carried out by Nginx, revealed that about 70% of businesses either use or think about using microservices, with almost a third of companies currently using them in the production environment. Gartner, global research and consulting company, defines a microservice in the following way:
A microservice is a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable.
In this article, we will thoroughly explore microservices.
So, let’s start.
So, what are microservices?
The microservice architecture, or simply microservices, is an SDLC approach that is utilized to develop large applications as sets of small functional modules. These functional modules are independently deployed, scaled, targeted to specific business goals, and communicate with each other over standard protocols such as HTTP, using APIs and lightweight asynchronous messaging.
The main advantage of the microservice architecture is that modules can be implemented using different programming languages, can have their own databases, and can be deployed in different software environments — on-premises or cloud.
Pros of microservices
Microservices have many benefits over monolithic applications, such as:
- Multiple services can be deployed independently in different environments, be it on-premises or cloud.
- Multiple services can be developed independently based on functionality.
- If any of the services fail, other services will continue to run.
- It is easier to scale individual components since there is no need to scale all components at once as in the monolithic architecture.
- One can use a range of technologies to develop different components in the same application.
Cons of microservices
Microservices are trendy, but the architecture has its drawbacks as well. In general, the main disadvantage of microservices is the complexity of any distributed system. Here are some potential limitations related to the nature of microservices:
- Communication between services is complex. Since everything is independent, the requests between modules must be handled carefully.
- More services mean more resources, so it can be hard to manage multiple databases and transactions.
- Global testing becomes more complex, as each dependent service must be validated before the overall testing begins.
- Debugging issues can appear, as each service has its own set of logs that need to be viewed.
- Problems with the deployment can happen due to the coordination of communication between multiple services.
- Microservices are great for large companies but can be too slow to implement and too complex for small companies. Small businesses usually don’t want to get bogged down in complex app orchestration.
Monolithic vs. Service-oriented vs. Microservices Architecture
- Monolithic architecture is like a large container in which all the software components of an application are gathered together and tightly packed.
- Service-oriented architecture is a set of services that interact with each other. The interaction can involve either a simple data transfer or two or more services coordinating some activity.
- Microservice architecture implies structuring an application as a set of small stand-alone services modeled around a business domain.
When to use microservices?
There are at least three cases when using microservices is reasonable:
- When you work on a monolithic application and it grows to the point when scaling issues appear.
- When you can’t reuse components across different projects or platforms but you need to.
- When implementing new features becomes painfully complex and error-prone.
You definitely want every new app you launch to be easily scalable, deployable, and testable. Microservices allow developers to implement software more efficiently using different platforms.
Netflix: Hundreds of microservices, one giant product
Let’s look at how microservices work from the technological side using a simple example.
Say, there is a Maps app that constantly tracks your location and stores comprehensive information about your movements in a file locations.txt. You’ve developed an application called LocoList that searches for the file locations.txt on your phone and shows all these locations as a list. Everything works perfectly.
But one day the developers of the Maps app decide that it will be better to store information about your location elsewhere and update the app, which now does not store this file on your phone. Now LocoList can’t find the file locations.txt, and you can’t get this information from the Maps. LocoList stops working.
All the efforts spent on developing LocoList were in vain because a change in the Maps has broken your app.
This example may not seem like a tragedy, but in a huge service like Netflix, a change in one part will not only destroy the user experience but also lead to reworking other parts to adapt them to this change.
This is how the Monolithic architecture works…
About a decade ago, Netflix brought about the revolutionary Microservice architecture, with which any application, code, and resources became independent of each other. If two applications needed to communicate, they used the API, a specific set of rules applied to both programs. Developers can make changes to each application as long as they comply with the API. And since the programs are familiar with each other’s APIs, the changes won’t prevent the exchange of information.
According to Netflix, the service uses about 700 microservices to monitor every part of the product. For example, there is a special microservice to:
- store information about the series you’ve watched;
- charge a monthly fee from the card;
- provide your device with the necessary video files;
- examine your history to suggest a list of movies you might like, and
- provide the names and images of these movies for the main menu.
This is just the tip of the iceberg. Netflix developers can make changes to any part of the app, knowing that the service will work properly.
Where does Netflix run all the microservices?
You need a powerful network of servers to launch all these services. Netflix previously had its own hardware, but they realized that it would be difficult for them to build scalable systems that would support their service at this rate of growth. The company made a bold decision to get rid of its own servers and move everything they had to the cloud. This meant Netflix started to run everything on the servers of another company that took care of the hardware, while Netflix developers focused on programs and deploying them on the servers. They chose Amazon Web Services for their infrastructure.
Amazon? The company that runs Prime Video? How can Netflix trust everything to their competitor?
Well, many companies competing in the same categories work for each other following some conventions. Samsung, for example, competes with Apple in the production of smartphones, but at the same time, some parts of the iPhone are made by the Korean company. Netflix was an AWS customer before Prime Video, but that doesn’t mean they should be fighting against each other.
It turns out that Netflix-Amazon collaboration is a win-win situation for both companies. Netflix is one of the largest AWS customers and constantly requests the maximum of their capabilities, introducing innovative ways to use AWS servers for their purposes: running microservices, storing movies, and managing traffic. AWS, in turn, is improving systems to allow Netflix to handle the huge workload and is using the acquired knowledge to serve thousands of other enterprise customers. AWS is proud that Netflix is their main customer, and Netflix can quickly improve their services and maintain stability thanks to AWS. This collaboration is beneficial for both parties, even if Netflix affects the popularity of Prime Video or vice versa.
Instead of a regular conclusion, we prepared some useful tips for you if you decide to implement microservices.
Tips for implementing microservices
Step 1. Think about whether your app and business really need it.
Step 2. If so, analyze your existing infrastructure.
Step 3. Prepare your team to implement this development technique.
Step 4. If you are moving from the Monolithic to the Microservice architecture, check that the data administrators are well-informed and understand the task.
Step 5. Select the programming language and platform.
Step 6. Configure the underlying architecture using services, containers, and virtual machine templates.
Step 7. If you have the monolithic architecture, divide the database into many smaller databases.
Step 8. Implement the API gateways.
Step 9. Track and display what is happening.
Step 10. Perform automated testing.
We hope this article helped you understand microservices. If you still have questions or comments, feel free to share your ideas below.