Monolithic Applications vs. Microservices
More and more businesses are relying on cloud-native microservice apps to increase development speed and take advantage of the cloud's scalability and availability.
5 minutes
According to Solo.io 2022 survey, 85% of modern enterprise companies are modernizing and managing an increasingly complex application environment with microservices (or microservice architecture).
Software architecture has undergone a significant change with the advent of microservices. Organizations that are developing new software or trying to upgrade old software may hear about the latest trends but may not know whether they’re actually right for their specific use cases.
With that in mind, let’s try and break down microservices as well as the more traditional monoliths, along with recommendations on what to use, depending on your needs, of course.
A monolith is a single-tier application that contains everything it needs within itself, including services, databases, load balancers, and application programming interfaces (APIs). The term monolith originally referred to mainframe applications, and that’s still a relevant example of a monolithic system. Another example might be a word processor program. This method of software development has been around for a long time.
With fewer moving parts, monolith applications have the advantage of being easier to deploy and test. Developers don’t need specialized training to build or maintain a monolithic system. It also has more secure data processing since everything is handled in one place.
However, there are some drawbacks.
Development, Scaling, code complexity, and codependent components. Monolithic applications are difficult to scale up, meaning that it can be anywhere from hard to impossible to add new functionality over time. Changes in one part of the code base could potentially affect any other part of the code base due to tight dependency. A problem in any part of the application also has the potential to bring the whole application down. Big applications may end up with slow development cycles, where pull requests may take weeks or even months to get approved. And there’s no easy way to pivot or migrate a monolith to newer technologies, languages, or frameworks. The performance also goes down over time with time while the technical debt increases.
It’s hard to define because the concept is constantly evolving. But developing an application as a microservices typically means separating the application’s functionality into many loosely coupled independent services that each perform one task.
The services can be deployed and scaled independently of one another, and they communicate with each other via an API. If one service should go down, it wouldn’t impact any of the others. This model is fairly new and growing in popularity. Netflix is one example of a microservices platform.
Let’s imagine that your application has a feature to upload your profile picture. In a monolith, you will end up having a form on the profile page, and that form will upload your picture to the same server that serves other pages, showing how tightly everything is coupled. Instead, you could have a specific service (micro) that would be in charge of profile picture uploading, which can evolve independently. Apply this approach to all the features or parts of your application, and you have a microservices architecture.
Flexibility, scaling, and avoiding vendor lock-in. Microservices address many of the flexibility and modularity issues seen with monolithic applications. They offer easy horizontal scaling: each service can scale up and change independently of any other service (true best-of-breed approach), and adding new services can be done without affecting the current implementation. Errors in one service won’t affect any others. They also allow for continuous integration/continuous development (CI/CD), a form of software development where changes may be pushed daily.
All of this requires a more complicated deployment, as potentially many different tech stacks may have to work together. Testing and debugging also become more complex as a result. Developers will need proper training in microservices architecture to implement and maintain all this. High maintenance costs are a risk.
Data organization might also be a bit more complex, but more secure and more optimized. You will have to decide which services are the master of which data and maybe cache and consolidate depending on the features. For this reason, PaaS (Platform as a Service) are really trendy nowadays because you describe your architecture as code, and they manage the rest for you.
To better understand microservices architecture, let’s compare it to the traditional approach, the monolithic architecture.
Monoliths are built as single unified systems. All processes are tightly coupled and run as a single service. Microservices are collections of smaller, independently deployable services that communicate with other services through simple interfaces to solve business problems.
Scroll back up and check those diagrams above that summarize differences in the simplest possible way.
Given the strengths and weaknesses of these two styles, what to use comes down to your available resources and experience, your project’s requirements, and how you expect the project to evolve over time.
Here are some situations where a monolith application may be superior:
- You’re developing a simple application or proof of concept.
- You need to get the application to market quickly.
- You’re a single developer or part of a small team with no microservices experience.
- The application has limited use cases, and demand is not expected to increase over time.
You may want to implement microservices if these conditions are true:
- You’re developing a complex application that will grow and change over time.
- You’re restructuring a large legacy system. (This can be done incrementally, one service at a time)
- You’re part of a larger team with the appropriate microservices experience.
- You have the resources to invest in new tech and hire new developers as needed.
- The application’s user base is expected to grow significantly.
Technical note from a developer perspective: microservices architecture does not mean that you need to have different projects. The best practice is to have a mono repository that is smart, including a CI/CD that is deploying only what changes, etc. As a developer, you want to reuse code, types, etc., within your services. Mono repositories are the best fit for that.
Another thing to keep an eye on while planning is the way monoliths and microservices are trending. What sorts of things will be associated with them in the future? Are those things you need or can afford?
For instance, one undeniable trend is the push to make everything cloud-based. Instead of investing in their own servers, networks, and so on, organizations are turning to dedicated cloud service providers. There are advantages in that you don’t have to invest in or maintain infrastructure, and you can often pay as you go. The cloud may be a great place to deploy microservices in particular. There are many container solutions like Docker and Kubernetes that make this much easier.
However, there will still be room for monoliths in the future because microservices can’t solve every technical issue. As we discussed, they have their own limitations.
The way forward will not be clear without a lot of planning and forethought. It’s important to factor in your requirements and capabilities in order to make the right decision about how an application should be developed.
Resist the urge to automatically run with the newest thing just because it’s new. Consider both monolith and microservice implementation with their strengths and weaknesses in mind.