Lessons from the Kitchen: Monolith vs Microservices

Welcome to this series of Lessons from the Kitchen, where I ramble on personal anecdotes, stories about DevOps, technology and work.

At the start of 2023, I met with two different development teams to discuss two new projects our company is undertaking. Each team had a similar scope and feature set, and both had a similar team headcount.

The discussion is about how the application should be built, and ideas are thrown around, especially the decision about whether to make a monolith application or start building it as a microservice.

It was a heated discussion. One team argued that there is no such thing as a modern monolith and that it will always need to be rebuilt as a microservice in the future. Another team argued that the complexity and time required to build a microservice are too high for the project.

Ultimately, both teams decided to build the app differently, one using a monolith and the other building a microservice app. Two years later, both projects are in the market, and I have learned a lot of lessons and experiences from them.

Lesson #1: Modern development is... easier and faster than ever.

I've been in the industry for more than 8+ years now, and I've seen the hype and fanfare for numerous things, especially one relating to Microservices, with people saying that building microservices is time-consuming and monoliths are faster.

Surprisingly, both applications are completed within a similar amount of time and were able to launch 3-4 weeks apart. I realized that most modern web development frameworks can cater to both development methods and simplify the complexities whenever building a monolith or microservice.

Either the sheer amount of ready-to-use plugins and project skeletons, extensive documentation, more versatile IDEs that are capable of handling multiple projects in a single workspace, or how developers can easily spin up development servers locally with containers, making both monolith and microservice development easier than ever.

While the development time is similar, the launch date and MVP are a different matter, with the Monolith team able to demonstrate the completed project to the client a few months earlier, due to one important thing.

Lesson #2: Deploying Microservices is a hassle and expensive.

19 different services, including multiple frontend and backend services, databases, caching, a load balancer, and a message broker. That's the number of services to run our microservice project compared to only 5 services required to run our monolith.

The complexity is astounding, and it took a lot more time to finalize the entire architecture. Even with the help of a modern Infrastructure stack and toolkit, the final deployment took some time to finish.

Benefits of scalability are also countered by how much more it costs to run a microservice app, with each service requiring a separate node to be scalable; in the end, the cost is almost double what it would need to run a monolith app.

Lessons #3: Knowledge is power, especially for small teams.

Another argument in this debate is maintainability, with the assumption that a monolith is more maintainable, especially in small teams. A few months after launch, I talked with a few people in both teams, and most of them said the amount of work and productivity are similar, and both teams felt efficient enough to deliver.

That's surprising because, at first appearance, the number of services required to manage in a microservice architecture appears daunting, yet the team doesn't seem hobbled at all.

I talked in depth with the technical lead, and in the end, it all makes sense because no matter how big or small the team is, what the architecture is, or where you work, it comes down to the knowledge the team has, how motivated they are and the willingness to learn new things.

Since we only have a small team and a restricted number of individuals, I initially questioned the idea of splitting the architecture model for both projects. However, I came to see that small groups may learn more effectively, share knowledge, and work more quickly, no matter what architecture is chosen.

Conclusion

In the end, I expected one would triumph over the other, but I learn that there's no easy answer between both of them and each has its advantages and disadvantages.

There's no magic solution.

Instead of arguing over designs, consider what your team is capable of creating, whether my team is willing to overcome obstacles, whether I'm solving a real problem, or whether I'm just following the hype.