Data DevSecOps

Environments – Monoliths Versus Microservices


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.


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.


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

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:


  • 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.

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

Sand Castles and DevOps at Scale

03JUNE, 2022 by Niall Crawford & Carlos "Kami" Maldonado. Modified by Eric Goebelbecker.DevOps at scale is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was back in 2009, most organizations still...

Test Environment Management Explained

Test Environment Management Explained3JUNE, 2022 by Erik Dietrich, Ukpai Ugochi, and Jane Temov. Modified by Eric GoebelbeckerMost companies spend between 45%-55% of their IT budget on non-production activities like  Training, Development & Testing and lose 20-40%...

Serverless Computing for Dummies

3JUNE, 2022 by Eric GoebelbeckerWhat Is Serverless Computing? Serverless computing is a cloud architecture where you don’t have to worry about buying, building, provisioning, or maintaining servers. In return for structuring your code around their APIs, your cloud...

Test Environments – The Tracks for Agile Release Trains

25MAY, 2022 by Niall Crawford & Justin Reynolds. Modified by Eric Goebelbecker.So, you’ve decided to implement a Scaled Agile Framework (SAFe) and promote a continuous delivery pipeline by implementing “Agile Release Trains” (ART)*.  Definition: An Agile Release...

What Is Data Masking and How Do We Do It?

24MAY, 2022 by Michiel Mulders. Modified by Eric Goebelbecker.With the cost of data breaches increasing every year, there’s a need for higher security standards. According to IBM’s 2021 security report, the average total cost of a data breach has risen to $4.24...

Test Environments: Why You Need One and How to Set It Up

24MAY, 2022 by Keshav MalikWith the rise of agile development methodologies, the need to quickly test new features is more critical than ever. This is especially true for websites and applications that rely on real-time data and interaction. The only way to ensure...