February 5, 2021
Since 2011, microservices-based architectures have grown immensely popular. Now, they are taking center stage among other app architectures. What has made microservices so popular? And what can make you decide against them?
Got a project in mind?
Fill in this form or send us an e-mail
Get weekly updates on the newest design stories, case studies and tips right in your mailbox.
In the beginning, there was monolithic architecture. Most apps were built as a single unit, with all the processes tightly connected to each other. This caused a lot of trouble with deployment, bug-fixing, and updating, which is why there was a huge necessity to divide this structure into smaller parts.
The term “microservices” was first introduced in 2011 at a workshop of software architects. They used it to describe the type of a common architectural style that they were using at that time. The idea of the technology itself appeared even earlier, in 2005, when "Micro-Web-Services" was brought up during the Web Services Edge conference.
One decade later, microservices architecture has become hugely popular because it can address many current IT challenges such as app performance speed-up, scalability, and fast testing. But is everything that rosy? Let’s take a close look at microservices and consider both their pros and cons.
In a nutshell, a microservices architecture is one of the structural styles of a service-oriented architecture (SOA) that organizes a complex app as a bunch of smaller units — microservices — that connect with each other through language-agnostic APIs.
In this case, the term "micro" means that each unit can be easily managed by a single development team (around 5-10 developers). Each microservice is built to address the specific function or business need that you’re dealing with. It makes this type of architecture almost perfect for modern always-scalable apps.
Microservices possess certain features that make them suitable for large apps:
Technology-independent
Each microservice is a separate universe that communicates to other microservices via non-technology-related channels. This gives incredible opportunities for developers to choose the technology stack that will be perfect for implementing a function dedicated to a particular unit.
Loosely coupled
Microservices architecture is a true champion of decentralized data management. Instead of a single database with all the app’s data, each microservice will use and store only the necessary data for one particular feature it’s responsible for.
Independently deployable
Since microservices architecture is all about breaking the application into small components, applying changes becomes easy. Each component does not anyhow influence the main codebase. Such a manageable deployment enables the smooth introduction of new features.
Organized around business capabilities
In contrast to monolithic architecture that has technical limits, microservices establish the app’s tech stack on business functionalities. Teams are based on their expertise in building a particular function. That makes microservices for cloud apps and apps with container deployment.
If you want to effectively scale your app, microservices are best for you. They will help you to build a required solution without creating a complex and bulky structure at the macro level. It facilitates the overall management of the system and allows you to keep track of each new function added and each new connection made.
Also, being language-agnostic, microservices do not limit you to choosing only one agency for the whole app. Each task and service can be delegated to a vendor with suitable experience.
Microservices are beneficial in many ways, but not every business can count on this type of architecture. You should have enough resources to orchestrate multiple teams working on different microservices at the same. Too many things should be in constant control so you can react promptly to failures and downs your infrastructure can face. Also, such fragmentation of functions can become inconvenient for testing, so you should think about allocating additional power to this stage too.
Still, microservices architecture is worth implementing for a modern organization. This approach lets teams keep up with the business and evolving demand without messing up with general business processes.
Microservices proved themselves to be an efficient solution for any type of business. Here are some examples of how world-famous enterprises opted for this architecture and improved their services’ performance.
Amazon
In the early 2000s, Amazon, like most web services, was a huge and interdependent monolith. Then, their customer base started growing, and the platform barely met the scaling needs. Amazon quickly realized that they need an update and decided to break their monolith codebase into smaller and easier scalable units—microservices.
This move became the beginning of Amazon supporting this architecture. The company developed such solutions as Amazon AWS (Amazon Web Services) and Apollo that now help enterprises all over the world.
Netflix
Netflix uses the Microservice architecture pattern since 2011. Before this year, the service was built as a monolith that was hard to manage and scale. With growing popularity, the company was not capable of implementing new data centers on time. That is why in 2009 Netflix started to move to more flexible microservices even if the community was hardly familiar with the term “microservice”. Today, an API gateway featured with the Netflix microservice architecture handles more than 2 billion API requests per day.
Wallmart
Walmart Canada moved to microservices shortly after Netflix, in 2012. At that time, the company had 6 million page views per minute, which was hard to handle with a monolithic architecture. With microservices, the company was able to minimize page downtime and update the hardware with cheaper virtual servers. As a result, cost savings totaled around 20 to 50 percent.
As we mentioned, the monolithic architecture was hard to deal with in complex apps, so the main purpose of a microservices architecture is to build and maintain such applications as a whole made up of smaller parts, each managed by its own team. They support the separation of responsibilities which allows the independent work on separate services without intervening into other parts of the same overall application.
A microservices architecture comes with Docker containers — a widely-used deployment construct. You can launch and/or redeploy them in seconds if needed, which makes its scalability easier than ever.
Now, when we figured out the basic information about microservices, it’s time to point out what is so important and valuable about them. The main benefits of microservices architecture will include the following:
Splitting an app into small self-contained blocks facilitates its development, deployment, and further maintenance. All microservices can be built, deployed, and managed independently from each other, and can use not one but several programming languages and tools depending on the needs they are to meet.
Also, a more concise codebase for each element makes scaling, publishing, updating, bug-fixing, and testing more manageable. Each microservice works on its own, so there’s no need to access the source code while changing the functionality. You can easily modify, test, and then deploy microservices independently, delivering the app faster as a result.
Now, as a large-size app is divided into smaller parts performing their own functions, each microservice can be developed by a separate team. At first glance, it can seem unnecessary and costly, but in fact, there are real advantages:
Another advantage of microservices is their process for identifying and fixing any problems with app performance. If one module fails, its developers have the opportunity to use another service redirecting that function to it, so the app will run without any disruptions. The improved fault isolation means that more complex apps don’t get significantly affected by a single small error, which also reduces the risk of downtime.
As a result, with the help of microservices, developers can reverse all updates, change the app’s components, and leave the rest of the app free from redeploying.
Since microservices are basically small independent apps inside a bigger one, developers can easily scale the app up and down depending on the current needs and requirements. If detached, the system allows smooth operation in the event of major changes.
Additionally, it’s possible to scale not only the entire app with new microservices but also each module separately. If a piece of code in any of the microservices becomes a bottleneck that reduces performance, it can be run on more powerful hardware to correspond to the required performance or run on multiple machines to process data in parallel.
Thus, microservices have proven to be an ideal alternative for companies working with a variety of platforms and devices.
Thanks to the loosely coupled structure and absence of solid connections between microservices in an app, each module can be written in a different language or with the help of different tools. It allows you to select the suitable stack of technologies for each function without having to worry about their incompatibility. There’s just no such thing.
Besides, existing microservices can be adapted for use in different contexts without having to create completely new modules.
Microservices architectures work great with continuous integration/continuous delivery (CI/CD) pipelines. We can create different procedures for different configurations of each microservice, especially for large-scale projects. Depending on the team composition and the type of service, different deployment patterns can be implemented.
While developing an app, the team should consider all aspects of the CI/CD and plan the solutions for possible difficulties in order to solve unique problems associated with microservices. The most important things to address are:
Microservices allow individual teams to develop, test, distribute and review them quickly. The ability to balance the workload between teams, combine workflows, and automate manual work considerably speeds up the development process.
If we take into account all the advantages mentioned above, we see that targeting a specific microservice instead of an entire app when updating or bug-fixing allows you to focus more on improving your business performance. Working with each separate module independently also allows you to more accurately analyze if this function really works for users and, if not, to either upgrade it or get rid of it right away.
We are ready to help you build your microservices-based app.
Contact usEven though this type of architecture has plenty of advantages for your app, nothing in this world is perfect. There are some microservices issues you would like to consider before implementing this type of architecture.
At the very first stage of development, microservices do save you from having to re-render large apps in their entirety. But with time, as such an app grows and gains more functionality, the number of microservices also rises, and the connections between them can become tangled. It creates multiple management structures and increases the complexity of using all the functions at the same time.
It's important to carefully manage the app’s microservices during development. In such cases, developers may have to write more code to avoid failures and disruptions. Over time, problems will inevitably arise, costing you more money and resources.
DevOps is an essential part of working with microservices, so before you start to integrate them, you need to build a solid DevOps culture.
While working on microservices, each development team starts operating as an independent business. This is great because teams can work independently and exercise more control with increased productivity. However, it also means that every development team needs to maintain a consistent lifecycle of their microservices, including maintaining a robust API and an independent testing strategy. For some agencies, it can become quite a challenge.
Another important issue here is that you need to determine whether your teams have enough experience to successfully operate microservices-based projects. Developers need to have a deep understanding of how to work with loosely coupled structures, including their launch, testing, and bug-fixing.
In addition, you will definitely need DevOps managers for each team, who will become one of the most valuable assets as you scale.
Also, adopting microservices often involves moving decision-making processes from top managers down to the teams themselves. For some companies, it can be hard to accept such power transitions in their organizational hierarchies.
When the various types of relationships inside your application are clear and easy to distinguish from one another, a microservices architecture will contribute to the quality of development indeed. But what if these connections are unclear?
That's when "different languages for different microservices" can become a problem. In the case of incorrectly configured relations between the modules, fixing and updating the application built with microservices becomes more difficult than refactoring a monolithic architecture. In addition, the interface updates should be discussed with all the teams working on microservices. Also, using different languages for different environments will be ineffective if you need to migrate the functionality of some microservice to another one.
This disadvantage is extremely important for small businesses who want to build a microservices-based app. Microservices will need to communicate with each other, which means a large number of remote calls. This results in increased network latency and processing costs, sometimes even more than what you might expect to pay when using conventional architectures. Developers will need to take this issue into account, building possible solutions that aim to reduce the number of calls to avoid disruption. This also equals higher costs.
Also, microservices consume more additional resources, since each service needs its own central processing unit (CPU) and runtime environment. More tools, more hardware, more servers, more APIs—you will have to use it due to the lack of uniformity in a microservices architecture.
This issue also stems from the "different languages for different microservices" approach: with each service using its own technology stack, the demand for resources grows. You need to account for all things needed for the development, management, updating, and maintenance of each module.
In contrast to a monolithic architecture, microservices brought up some noticeable security challenges due to the huge volume of data exchanged between modules. The logical chain looks like that: you work with multiple small containers — you expose more of your modules to the network — you expose more of the system to potential threats.
Many security concerns are related to the API gateway implementation. With distributed microservices applications, it seems obvious to build a single security policy into components that will be shared by all the services. However, different modules can require different security permissions according to their functions, so a single policy may be the reason for breaches and hackers’ intrusion into the system.
The high replicability of microservices is also worth mentioning. Since the source code of one module can be used in different projects, it can present easy access for hackers, which can snowball into a big problem.
Comparing the pros and cons of microservices, you can see that for smaller businesses, a monolithic architecture will work better as it's simpler, faster, and cheaper. As such businesses grow and their app starts to need scaling, it can still be migrated to microservices when you need to address new business needs.
The bigger the company, the more obvious the need is for microservices, as they help to ensure uptime and scalability along with accommodating more ambitious business goals. In such cases, microservices can provide the necessary infrastructure for building a highly efficient digital solution.
Even though microservices can cut some costs compared to the monolith, it still requires some budget lines to go. Before the development starts, there are several points for consideration:
Sure, the initial costs will depend on your starting point, but later on, they will all pay off. The simple APIs of microservices will reduce the maintenance fee straight away. These savings will already be enough to cover the starting costs in a few years.
The pros and cons of microservices-based architectures really depend on the type and needs of your project. Microservices are scalable, flexible, and resilient—that's good. At the same time, they can easily become complex and expensive to maintain. Choose wisely!
Microservices or no microservices? Turn to us to make the right choice.
Get in touch