Blog
Microservices: why use them for your application?
Microservices: if you work for a software or e-commerce company, you've probably heard this term. Large companies like Netflix, Google, and Amazon swear by it. And as often happens, Dutch startups and scale-ups quickly follow the example of the international tech community. In this blog post, we'll dive a little deeper into microservices. What are microservices? How do they differ from monolithic applications? And is one better than the other?
What are microservices?
Microservices, also known as microservice architecture, can best be viewed as an architectural style for software development. Just like with a building, software deals with different architectural styles. The chosen architectural style determines, among other things, how functions in software are programmed and how these functions relate to each other. In a microservice architecture, the software is built using many small mini-applications. These small applications each have their own task or set of tasks and are connected. Together, these small applications form a cohesive whole for the end user. Because the front end is styled consistently, the application appears unified.
The small applications are called 'microservices' because they each are responsible for specific functions of the software. For example, a microservice might contain all the functions to log into the software. Another microservice might focus on the software's settings. Both microservices are developed separately, often by different software developers or teams. How large or small the microservices are and how many microservices make up a single application varies greatly by company. There's no unified definition of a microservice architecture: everyone can determine it for themselves.
Many developers, therefore, look to large tech companies that have already implemented microservices for their web shops, web applications, or websites. Well-known companies that successfully use microservices include Amazon (which pretty much invented the term), Netflix, and Uber.
Monolithic applications vs. microservices
Another architectural style often mentioned in the same breath as microservices is the monolithic application infrastructure. In many ways, a monolithic application is the opposite of a microservices application. It is one large application that contains all the software's functions in a single environment.
A picture often says more than a thousand words:
Above is an example of the differences between monolithic and microservice architecture. In a monolithic architecture, all business logic and data layers are in one environment. A microservice architecture consists of multiple software services, each serving its own business logic and data layers. The front end makes it appear as if it's one application, while in fact, it's all small mini-applications.
Monolithic applications
A monolithic application is often hosted with one hosting provider, for example, on-premise (own data center, colocation, dedicated server, or virtual machine) or in a private cloud. The hosting provider ensures the application remains stable and helps with scaling, for example, by adding extra storage capacity.
Microservices architecture
Microservices don't need to be hosted in the same place. Some can be hosted in a public cloud like Azure and others in AWS, for example. The microservices communicate with each other through APIs, and because there's one front-end, the end user usually doesn't notice anything. Microservices also often use Docker containers, which speeds up the development process.
Legacy software
Legacy software is the name for software that's a bit older. This software is often monolithic in nature. The microservices application architecture is newer, so you won't find it in older software. But just because the legacy software is older doesn't mean it's not important. Many important business processes can converge in that software. An error in the software or unavailability can be catastrophic for a business.
This legacy software often runs on older forms of application hosting, such as non-virtualized on-premise solutions like colocation or dedicated hosting. Migrating these applications to a virtual machine in the cloud often doesn't deliver the benefits you hope for because the application can't handle things like horizontal and vertical scalability. So, companies have several options when they want to modernize their applications and infrastructure. Gartner describes seven possible strategies for application modernization, from completely redeveloping the application to a 'simple' migration.
However, we see that most companies choose a hybrid, phased approach. By rebuilding certain parts of the legacy software into microservices, for example, the software can be moved to a cloud provider step by step. Nothing changes in the front end for the end user: the software continues to look the same. For the company, however, this offers the best of both worlds: they retain the functionality that's difficult to move to the cloud but can rebuild important functionality into cloud services, allowing developers to renew the software more quickly.
Majestic monoliths
The general discourse is that monolithic applications scale less well than applications built according to a microservices architecture. Working in a microservices way offers a solution. Yet, there are many people within the software development community who disagree. For example, David Heinemeier Hansson (DHH) of Basecamp and the creator of the web application framework Ruby on Rails, a development framework used by GitHub, AirBnB, and Zendesk, among others. In a blog post, DHH advocates for 'majestic monoliths'.
A monolithic application generally has fewer 'moving parts', making management and maintenance much more straightforward. Applications consisting of microservices are generally more complex because they have multiple moving parts, so more can go wrong.
Tl;dr The architectural style in which software is developed strongly depends on what the software needs to do and what the business's wishes are.
The advantages of microservices
Why are developers and companies interested in developing microservices? That's mainly due to the following advantages.
Small, autonomous teams
As organizations grow, communication between development teams also grows. The larger the team, the more consultation there is.
With microservices, it becomes possible to set up agile, small, and autonomous teams. A team can, for example, be responsible for a single microservice or multiple microservices.
Because these small teams work with a code repository like Github or Gitlab, they can work fairly autonomously. They don't have to consider other parts of the web application because they're only responsible for their own piece of code. This also limits the number of meetings and communication.
Flexibility in technology choices
An important reason why teams can be small and autonomous is flexibility in technology choices. Development teams can determine the technology stack per microservice. They're often bound to one programming language, one framework, and one type of database application with a monolithic application, but with microservices, they can set it up exactly as they wish.
Building one microservice with the React framework and another with Laravel? No problem. As long as the two can 'communicate' via APIs, nothing will be noticeable on the front end.
This freedom of choice gives developers an incredible amount of freedom of movement. Much legacy software, for example, is written in old programming languages, making it difficult for new-generation developers to get involved. But if this developer can build the microservice in a framework of their choice, that's a huge plus. It also becomes easier to attract new talent more quickly.
Faster time-to-market
A faster time-to-market is often mentioned in the same breath as companies that have embraced the 'digital transformation' because they can gain a 'competitive advantage'.
If you peel away all the fluff from those terms, you often come to the core. A faster time-to-market is mainly due to developers who can deliver (new) functions in the software and make them quickly available to customers so that feedback can be collected quickly, providing information for the next software release. The shorter the duration of this circle, the faster the progress. And increasingly, this is partly thanks to microservices.
Because development teams work in small, autonomous teams, they can work independently on various microservices in the software. They don't have to wait for each other's code but can improve the software simultaneously. Because you then deal with different versions, they use a Git system (software for version control) and a code repository like GitHub or GitLab. When they commit the code of the microservice, it's first checked before it's added to the master branch. Some teams are already advanced enough to automate this process with a Continuous Integration pipeline.
The nice thing about a Git system like GitHub or GitLab is that development teams can monitor their efficiency. Because everything is measured, much can be improved. For example, that intelligence can be used during a development sprint so the team can deliver faster as they learn.
Find errors faster
Microservices are generally more complex because a microservice architecture consists of many 'moving parts.' There can be an error in virtually any part of the microservice, making it possible for the software to break. Also, a change in one component can cause an unexpected failure in another component. These failures are sometimes difficult to solve if there's too little knowledge about the dependencies and interconnectivity of the microservices.
The good news is that there are countless tools that can monitor all metrics of an application and its associated microservices. With an Application Performance System, for example, the status of APIs can be monitored, but also integrations with third-party tools like Kubernetes, Docker, or VM instances in the public cloud and Github.
An Application Performance Monitoring system helps detect errors or hiccups in the health of the application, including the microservices. This makes errors faster to detect. Because it often involves isolated errors, it doesn't necessarily mean that the entire application is down. With an APM, you can see which components are malfunctioning so you can solve the problem in a very targeted way.
By the way, there's also a new role focused on this: a chaos engineer. That's someone who deliberately looks for errors in a microservice and even deliberately breaks parts of the application to see what the effect is on the entire application.
Increased productivity of development teams
Development teams that develop with microservices generally deal with less cumbersome communication (fewer meetings), are smaller and more autonomous, and have a lot of freedom of choice in the development stack they develop with. In addition, they often work with a Git system like GitHub or GitLab, and they automate unnecessary, repetitive processes with a CI/CD pipeline. A combination of these factors means that developers who work with microservices are generally much more productive.
Of course, there's some nuance here. Productivity gain will differ significantly by company and depends, among other things, on the number of developers and the stage of microservices and CI/CD pipelines that the development team is currently in. At the beginning of their journey, teams will not necessarily be more productive immediately. It takes an incredible amount of time to properly automate something, and coming up with a solid microservice architecture doesn't happen without a hitch.
An essential aspect of this is that development teams adopt a learning mindset. Gradually, the team becomes faster in delivering new functions because they commit multiple times. This repetition, the multiple committing of code, ultimately ensures that teams become sharper, faster, better, and more productive. But that doesn't happen overnight.
Disadvantages of microservices
When we wrote about monolithic applications, we already hinted at them a bit, but microservices are not for every organization. Also, developing with microservices has some disadvantages.
Microservices are more complex
Because each microservice is developed separately, there's a chance of errors in integrations. Some developers also call this 'integration hell'. The more microservices an organization has, the more complex it often becomes. The surface for errors becomes larger as the organization creates and uses more microservices.
Fortunately, in most cases, it's okay to make mistakes. What is important is that these mistakes are signaled in time and that they're also addressed. Many development teams, therefore, choose to combine microservices with a Git system like GitHub or Gitlab, where version control and review are central. Automated tests are also built into the CI/CD process. When these tests fail, the application goes back to the developer to solve the problems. There are always a number of individuals within the organization who must first check and validate the code before it's added to a live production environment.
The complexity of microservices can also be monitored, for example, with an Application Performance Monitoring system. And, if errors occur frequently, they can be checked, for example, with an automated script that runs as soon as the code rolls into the CI/CD pipeline. Making mistakes is kind of part of working with microservices. By making them visible and stopping them before they occur in the production environment, the team becomes smarter and ultimately more productive.
Cultural changes needed
The development of microservices is a technical choice, but it's driven by a business question. Working with microservices also requires a company-wide approach and a cultural change. Not every developer is used to working with microservices, CI/CD pipelines, or Git, which means new skills need to be learned.
In addition to technological skills, people also need to learn to work with incremental changes. 'Release early, release often' is a mantra that most development teams know, but it is sometimes also held back by a management layer or other company constraints.
That's why it's useful if the company accepts and actively encourages management concepts like 'lean' and 'agile'. These concepts contain a number of core truths that are particularly focused on learning by doing, making small changes, and learning from your mistakes. You see the same principles in methodologies like SCRUM, DevOps, and the somewhat newer SRE. The core, however, lies in how people are managed (or, in the case of microservices, how much freedom the development teams get to do their job).
However, this isn't easy to achieve solely from the development department. It must be a company-wide strategy to work and learn smarter and more incrementally.
Conclusion: are microservices good for your web application?
As with many topics, it's wise to ask questions first before fully diving into a new technological trend. In the case of using microservices for the web application, it strongly depends on the business's question. Microservices can help bring legacy software to a public cloud in phases. They can also help release software faster and thus be more innovative than the competition. But then, a number of preconditions must be met.
When developing a new application, it's always useful to ask how many changes need to occur continuously. In some cases, a monolithic application might suffice just fine.
When you do start with microservices, it's prudent that the entire organization supports this choice as broadly as possible. Microservices are part of a broader cultural change among developers. A learning mindset is essential, and there must be support for this within the company. And a bit of patience.
More news & blogs
