Environments – Monoliths Versus Microservices
05
AUGUST, 2021
by Alexander Fridman
In the beginning there was nothing. Then there was the monolith, though we used to simply call monoliths “software.”
Today we have two rival architectural types: monoliths and microservices. This post will explain what monoliths and microservice-based architectures are, the differences between the two, and the special considerations for each.
Monoliths
All software was a monolith until ten or so years ago. A monolith is basically software code that sits in a single repository that all developers work on. There can be more than one repository if, say, you have front-end code and back-end code. But we’re still talking about a monolith if all domain code is in one place. There’s nothing wrong with this model. It worked fine from the early years of the software industry in the 1950s until the early 2000s or so.
Things Change
In recent years things changed dramatically. Code bases grew to hundreds of thousands of lines of code per app. The number of developers working on each software project grew to hundreds. The number of daily code changes grew rapidly.
All of this resulted in major problems for the monolith model. Making a small change in one part of the application required recompiling and rebuilding the entire application. That takes time. Moreover, bugs were introduced in different parts of the system since there was a large, single code base. When a lot of developers touch the same code base, they can inadvertently step on each other’s feet and introduce bugs through a lack of coordinated effort. Overall, the chance of introducing bugs grows when the number of parameters (code lines, developers, changes per day) increases.
There one more thing to note here: making rapid changes to your code puts a strain on your infrastructure, and DevOps efforts require an infrastructure that can handle a massive code base.
Microservices
The microservices approach was developed to mitigate the issues described above. Instead of having one big monolith of code, the application is split into different microservices. Each is responsible for a small part of the business logic such as registration, login, billing, and invoices. Each sits in a separate repository and is deployed individually. The various microservices usually communicate using RESTful or GraphQL APIs. This separation of concerns, so to speak, minimizes the risk of introducing bugs. Since each microservice handles only a specific area of the application, we can assign dedicated teams to work on them.
In addition, this architecture enables rapid and frequent deployments. Since we usually need to deploy only a few microservices at a time, or in some cases only one, we deploy only a fraction of our code, which takes a fraction of the time. It’s much more efficient than running a pipeline of unit tests, integration tests, and so on for the whole application.
Containers
The rapid adoption of containers as a deployment vehicle also contributed to the adoption of microservices. Although you can deploy microservices using standard virtual machines, containers work perfectly with microservices since they’re small, disposable “envelopes” that run only one process at a time and can be easily and rapidly created and destroyed. Each microservice fits into a container image and can be scaled as needed. For instance, if we face a heavy load on the registration side of the app, we only need to scale the relevant containers instead of the entire application, unlike with virtual machines. This way, we can reduce infrastructure costs in a substantial way.
Microservices And Monolith Considerations
Monolith Considerations
As explained above, managing monoliths is easier, but it can be challenging in some ways. Let’s discuss them in more detail.
Infrastructure Costs
Since each monolith consists of thousands lines of code, the source repositories are heavier. This in turn requires more hardware to store them. In addition, if we want to scale, we have to scale the whole application. We can’t load balance parts of it. This can result in spawning a lot of large instances on expensive machines. In addition, deploying such software in a CI/CD pipeline requires substantial hardware resources because each build can take several hours to complete.
Lack of Agility
Since monoliths contain a lot of legacy code, introducing changes becomes more and more time consuming. And since the large number of developers (usually hundreds on very large projects) spawns a lot of additional bugs, it takes longer to create end-to-end tests and fox bugs, time that’s spent at the expense of creating new features.
Easier to Manage
Since multiple pieces of a monolith don’t need to be synchronized, this might be the right approach for small startups that want to ship a product quickly. Likewise, if your projects are relatively small and well defined, you can probably stick to the monolith architecture.
Microservices Considerations
The flexibility and agility that microservices provide come at a price. Splitting your application can result in the need to manage hundreds of microservices, each with its own repository. Even understanding where code is located can be a challenge.
Synchronizing microservices can become problematic as well, and we need to take the following into consideration when doing so:
Security
- Determining which microservices can talk with each other
- Preventing unauthorized access to the various microservice APIs
Deployments
- Orchestrating daily deployments of dozens of containers
- Saving each container’s version history
- Troubleshooting failed deployments
Communication
- Making sure that each microservice has the right privileges (authentication tokens for instance) to access an API endpoint
- Being sure that each microservice knows the URL of the other microservices (microservice discovery)
- Taking into account the fact that Internet communication can be slow, and it can take time to receive a response from a remote microservice
All these challenges stem from the fact that we split our application into pieces. Any tool that would provide visibility into what’s going on would be critical for our ability to manage all this.
How many microservices do we have? How many microservices are deployed? What is the status of each deployed microservice? Do all the microservices adhere to a unified compliance policy?
There are many tools that can answer some of this questions, but enov8’s Test Environment Platform is holistic one that provides answers to all of them. It can save you a lot of time that might be otherwise wasted on scrutinizing information from different sources.
Conclusion
Both monoliths and microservices are valid models for building and deploying software. Each has its own pros and cons. The rule of thumb that says in the software world, there are no perfect solutions, only trade-offs, applies here. You should survey your company’s needs and use cases before choosing which approach will work best for you.
Post Author
This post was written by Alexander Fridman. Alexander is a veteran in the software industry with over 11 years of experience. He worked his way up the corporate ladder and has held the positions of Senior Software Developer, Team Leader, Software Architect, and CTO. Alexander is experienced in frontend development and DevOps, but he specializes in backend development.
Relevant Articles
Why is Technology Risk Management Important?
Effective TRM is crucial for businesses of all sizes, as it helps safeguard key assets, maintain compliance with industry regulations, and protect against financial losses. With the increasing frequency of cyberattacks and the rapid evolution of digital technologies,...
What is Data Leakage? A Definition and Tips to Prevent
The benefits of using cloud environments to store and access data over the Internet has been highly beneficial for many businesses. Cloud environments help both start-ups and enterprises scale up conveniently. However, as with other major advancements, the convenience...
What is Smoke Testing? A Detailed Explanation
In the realm of software development, ensuring the reliability and functionality of applications is of paramount importance. Central to this process is software testing, which helps identify bugs, glitches, and other issues that could mar the user experience. A...
Test Environments: What They Are and Why You Need Them
Software development is a complex process that requires meticulous attention to detail to ensure that the final product is reliable and of high quality. One of the most critical aspects of this process is testing, and having a dedicated test environment is essential...
What is a Steering Committee? A Helpful Overview
Are you a Product Owner or Technologist looking to understand the role of a steering committee and how it can benefit your organization? This article provides a technologist’s view on what a steering committee is and how it can be used to help guide decision–making....
What is Data Tokenization in Data Security?
In today’s digital age, data security and privacy are crucial concerns for individuals and organizations alike. With the ever-increasing amount of sensitive information being collected and stored, it’s more important than ever to protect this data from...