Microservice vs Monolith

June 9, 2020 Justin VanWinkle

A colleague and I set out to write three open-source APIs that would all do the same thing, but each with a different design (monolithic, microservices, and nanoservices). Our reason for this was that we would have a set of APIs that can be used to give talks at various conferences, highlighting the good, the bad, and the ugly of each approach. And on a more granular level, one of the things we wanted to show was that choosing microservices (or the nanoservice anti-pattern) too early and without adequate planning would result in wasted time.

Since we started with the nanoservices, we quickly ran into difficulty maintaining consistency across all of the services as we added new features. Had we started with microservices, it would have been the same. But with a monolith, we would have turned out to be much better suited for our pivots. Let’s look at why.

Pivoting and Refactoring Quickly

With the service-oriented design, we completed a few services an then discovered the new HttpClientFactory that had just been released in ASP.NET Core. So we went back to the services that we created by checking them out one by one from source control, refactoring each one to use the new HttpClientFactory class, committing, and pushing our code back up. Wash, rinse, repeat for every one that we created. But wait–which ones made http requests? We had to sift through and make sure we didn’t miss any.

We discovered soon after the HttpClientFactory refactoring that the data we were accessing via a REST API was accessible to us in a format that we could digest and place in a database. Since the REST API had a very low rate limit which would hinder our ability to do load testing across the three systems, switching over to the database approach only made sense. Back to refactoring one by one! We revisited each of the services to replace the HttpClientFactory with a class to access the database.

While performing our refactors, we noticed that it was significantly easier to refactor the monolithic code because we only had to change out a few lines of code — and only a single time. Comparatively, the monolith refactor cost a fraction of the time compared to the microservice and nanoservice approaches. You read more about this refactor on my blog in the article titled Interfaces in the Wild.

Where to Begin

Microservices are nice for many reasons. Over the last several years, we have seen some really big names implementing microservices like champions. But it is worth noting that those who succeeded all achieved their implementations in a very organic way. For those companies who have succeeded, they leveraged at least one of two things to ultimately succeed: Experience and/or evolution. If you have extensive experience with microservices to lean on, you know the pitfalls, and you can plan well; then a microservice implementation will likely serve you well from the start. On the other hand, if you don’t have extensive experience with microservices, then starting with a monolith that you separate (little by little) into services later on will indubitably be your best bet.

If you choose microservices with little or no experience, this article will provide you with some tools for planning your microservices: Microservices are not Micro; They are Vertical

Wrap Up

A monolith lends itself to an ever-changing world. Microservices do too, but they require a lot more planning and coordination to prevent mega disasters. Nanoservices are just a bad idea all the way around.

If you are currently considering the differences between a monolith and microservice implementation for your next project, starting with a monolith and splitting things out later will keep the schedule moving along quite nicely as you iron out the details of a new system. Bonus: this will also help you identify the boundaries of your services.

Lastly, we have a wealth of knowledge on microservices and monoliths here at New Signature.  We know effective strategies for structuring and managing organizations success, what tools are necessary for ultimate effectiveness, and how to build software systems that serve you and your customer in a top-notch kind of way.  If you are struggling to get to the next level, reach out to our team.

Previous Article
New Signature’s Work From Anywhere Education Resources
New Signature’s Work From Anywhere Education Resources

At New Signature, we not only believe that remote work is possible, but it also can be empowering and produ...

Next Article
Things to Consider When Shifting from TFVC to Git
Things to Consider When Shifting from TFVC to Git

There are a lot of things to consider when migrating from TFVC, a centralized version control, to Git, a di...