Why I Like Microservices

In order to explain some of my reasons why I like the microservices architecture style, I write and compare monoliths vs microservices based on practical real-life experiences of working with software development for more than 30 years in both small and large companies.

Monolith Development Environment Setup

The setup of a developer environment is one of the most important steps a developer must take when starting a job.  It entails not only the configuration of tools (e.g., IDEs, text editors), networking access, familiarity with databases, and source control, but most of all having an environment that facilitates the development and maintenance of the application.  And this is right off the bat one of the issues I have with monolith systems.  Monoliths are usually very complex to set up.  I have a few real-life examples of spending over a week just to get my development set up for a single monolith application.  It is sometimes licensed to use platforms like J2EE, all the libraries being used, the build itself that involves several components, and the database which is usually much larger.  Having the tests set up and running. Learning about the entire business domain. Everything in a monolith is orders of magnitude more complex than in microservices.

In one job it took me over two weeks to set up my development environment for one of the main monolith applications in that department. The monolith was a J2EE backend server implemented using IBM WebSphere.  It not only required installation of IBM WebSphere locally but lots of various configurations for the various components (database, interface to other systems, access to multiple libraries.) The build was very complex as there were different components being built with different property configuration files.

Monolith Long Meetings and Long Releases

I remember while being a senior architect at a very large enterprise when I used to attend weekly meetings with project managers, the QA manager, and the department manager to discuss the various features that were being implemented for the next release. The wall had all these different features and where each feature was in the development lifecycle phase.  As the timeline for the next release approached we had discussions on what was ready, and what was still in QA testing, and when we would think we could start planning a deployment date.  Everything took longer: development, testing, interaction with various teams, orchestrating the different projects, synchronizing the different features being developed in parallel, contacting the Operations teams to set up time for deployment, and on and on. This is to me one of the great drawbacks of monolith systems, the time it takes to get something in production. It usually encompasses so many steps that can take months just to get a single release in production.

Since there were various features, trying to get all of them in a single release was not always possible, we broke different projects into separate branches.  And those branches would move in parallel. At the same time, developers were cranking code, issues would arise in production therefore requesting hot fix branches to be created.  As if that was not enough we had all the operational issues to deal with.  When to deploy, who was going to deploy, at what time, and so on?

Microservice Development Environment Setup

On the other hand, a microservice typically has smaller databases, fewer libraries, a much less complex business sub-domain component, fewer tests, and of course much fewer lines of code to deal with. I have seen real-life experiences of a contractor joining a team in the morning, and in the afternoon having a development set up to work on a specific or few microservices.  And not only that being able to start coding on the first day!

From my previous experiences with monoliths, once we had converted it to microservices, things became so much easier.  Setting up a development environment in Eclipse or IntelliJIDEA only took a matter of minutes.  All I had to do was to clone the microservice project locally and import it to Eclipse as a Maven project.  Then, running builds was simply executing CLI commands or pressing a button in DevOps Microsoft Azure.  Bottom line from the IDE I was ready to start modifying the code in a matter of minutes.

Why Is It Easier to Work with Microservices?

First, microservices are very small applications that are focused on doing one thing and doing it well.  Therefore, there is no longer all of the monolith's different technologies, components, databases, and libraries to deal with.  Furthermore, the build of microservices becomes much simpler and faster since it does not depend on the various component libraries found in monoliths.  Since microservices are focused on a specific sub-domain the learning curve is much faster. Our brains are more capable of dealing with one smaller problem at a time; versus in a monolith that deals with everything at once.

Getting things up and running, writing a test, writing a feature, being focused, delivering features, fixing bugs everything is SO MUCH faster and easier when you are working on microservices compared to monoliths.  In a microservice, we can become very focused on a small area of the business, and we can ensure that features are delivered faster to production.  That's because testing is easier, and faster.  And builds and deployments are not only easier but much faster.  I have seen cases where a PR was approved in the morning, and the code was in production on the same day.  Also, tracking issues in logs with microservices is simpler because we can set up queries on specific applications.  And that means easier troubleshooting!

Rubens Gomes