Environments – Monoliths Versus Microservices
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.
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.
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.
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.
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
As explained above, managing monoliths is easier, but it can be challenging in some ways. Let’s discuss them in more detail.
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.
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:
- Determining which microservices can talk with each other
- Preventing unauthorized access to the various microservice APIs
- Orchestrating daily deployments of dozens of containers
- Saving each container’s version history
- Troubleshooting failed deployments
- 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.
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.
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.
20DECEMBER, 2021 by Justin Reynolds.How to Manage Test Data in Software Testing. To compete in today’s market, software companies need to create programs that are free of bugs and vulnerabilities. In order to accomplish this, they first need to create test data...
09DECEMBER, 2021 by Justin Reynolds.When it comes down to it, test data is one of the most important components of software development. That’s because test data makes it possible to create applications that align with the exact needs and expectations of today’s...
06DECEMBER, 2021 by Carlos Schults.Today we're here to talk about data regulations and data compliance solutions. Why does all of this matter? HIPAA, GDPR & PCI what is the difference? When it comes to online applications, protecting your users' data is one of...
29NOVEMBER, 2021 by Justin ReynoldsCompanies today are collecting more data than ever and using analytics to influence everything from sales and marketing to research and development. In fact, data is now one of the most valuable assets that a company can own. Yet...
24NOVEMBER, 2021 by Daniel PaesEnhancements on data ingestion made evident the amount of data lost when generating insights. However, without guidance from methodologies like The DataOps Manifesto, some companies are still struggling to blend data pipelines from...
19NOVEMBER, 2021 by Justin ReynoldsOrganizations today are using more data than ever before. Indeed, data is playing a critical role in decision-making for everything from sales and marketing to the production and development of new products and services. There’s no...