If you’re about to begin a new project, you might be asking yourself whether you should go with a monolithic or microservices architecture. Or at least you should be asking yourself that question. We’re going to give you some reasons to think seriously about going with microservices.

What is monolithic vs. microservices architecture?

Monolithic applications are built and deployed as a single unit. This is the traditional approach to creating applications: all modules are combined in one self-contained codebase.

All developers work on the same codebase and are committed to a single development stack, including languages, libraries, tools, and everything else used to create the application. Changing any of these elements is a major challenge in a monolithic architecture. Any changes or fixes have the potential to cause problems for everyone involved.

Microservices take the opposite approach. With a microservices architecture, you divide an application into discrete components that can be developed and deployed completely separately. Any coding language can be used and the development teams can be small and autonomous. Each service represents a particular functionality in the application. If one service has a problem, it won’t take down the entire application and fixes can be quickly rolled out by the relevant team.

Monolith vs. microservice: the showdown

Let’s look at ten aspects of applications and see where monolithic and microservices architectures differ.

1. Size

A monolithic application is a single self-contained unit. Monolithic applications can get very big over time and your developers can end up dealing with a huge mass of code.        

In contrast, microservices aim to be small independent services that focus on delivering a specific business objective.

2. Granularity 

All the elements within a monolithic application are tightly coupled and interconnected. Changes made to any part of the application can have effects everywhere. A single bug can mean that the whole application fails.    

Microservices are loosely coupled by design. If there’s a fault, they can be isolated and fixed.

3. Ease of deployment

Monolithic applications are not easy to deploy. Making changes can be complicated and deployment is a big deal, involving the entire application.

Microservices have small teams that can develop and deploy independently. They don’t have to coordinate with everyone else involved in the project.

4. Speed of deployment 

Not only are monolithic applications more difficult to deploy – they’re also slower. It can take a lot of time to wait for all the changes to be ready and for large development teams to make sure that everything is ready to roll out. Those delays can be very costly, especially if your competitors have made the switch to microservices.

Again, microservices are designed to be the opposite. Leaner teams developing and deploying their own part of the application mean that microservices can indulge in rapid deployment. Some microservices can even go with continuous deployment and deliver really quick responses to feedback and feature requests.

5. Communications volume   

Here’s where monolithic applications have an advantage over microservices. Because everything in the application is self-contained, there’s no need for remote calls between services.

Microservices can end up with significant communication overheads because of all the extra remote calls. While this isn’t catastrophic, it does mean that communication between the microservices has to be designed and managed carefully to avoid bottlenecks because of overly chatty services.

6. Persistence of data

All components in a monolithic application share data storage. A single database sits at the lowest level of the architecture of the application and serves information to the entire application. That’s a lot of work for one database and it can mean problems as it gets bigger over time.

One of the basic principles of microservices is that each service is free to choose its own data storage and to manage its own data. In fact, you should make sure that services don’t share a data store so that you can avoid too much unwanted coupling between services. Like with communications, this can be a challenge. You especially need to rely on domain-driven design to make sure that no microservice can modify the databases of another. Keep each microservice focused on its own business objective.

7. Ease of onboarding

A monolithic application can become so complex that it becomes daunting for new hires to understand it all before they get started. It can be difficult for old hands to even explain how everything works!

With microservices, your new developers just need to understand the code used for their own service. Which means you get them onboard and coding faster and safer.     

8. Polyglot programming

With a monolithic application, you’re stuck with a single development stack for the whole thing. You can’t decide to use a different programming language for one component or experiment with new approaches to storage solutions.

Microservices give you the freedom to use a different technology stack whenever you want. You can experiment, optimize, and keep up with new ideas.

9. Communication method    

Monolithic applications communicate with in-process calls and local method calls. As with everything else, it’s all kept internal and dependent on the language used to develop the application.

Microservices make use of APIs and a modern RESTful approach to communicating with each other. The architecture is lightweight and technology-neutral, so again you end up with more freedom.

10. Scalability   

So what about when your application needs to grow?

Monolithic applications can only scale horizontally. You can run multiple copies of the application. Additional servers, additional resources, and a lot of waste.

Microservices can be scaled individually as and when needed. Fewer resources get wasted and real business objectives determine where you add them.

At Blocshop, we’ve both converted monolithic applications to microservices and designed and built microservices from scratch. While we believe that the benefits of microservices are clear, we also know that there are horror stories out there about companies that underestimated the task of building or migrating. Contact us to find out how you can avoid making the same mistake. We’ll guide you through how you can make the change, from quotation to deployment.

Free ebook: From monolith to microservices