Leonardo Venturini

Full Stack Developer

Musings On Software Architecture: Monoliths to Microservices

I've been planning some of my personal projects lately and this subject kind of caught my mind. I've seen so much hype about microservices, that I need to put my thoughts into perspective... I know that microservices is a very valid architectural model and perhaps an inevitable stage of cloud software development once it scales…
But I believe it is a bad idea to use the microservice architectural style from the start of a new project. I see that a microservices architecture adds a huge complexity overhead on the infrastructure, and the developers need to take a lot of extra steps not directly related to code to do their job, i.e. communication and coordination.
Basically, you need not only a team to build a microservices architecture, but you need a very good team. It is very easy to build a bad microservices architecture, because it involves very high-level tasks which are not intuitive to the average developer or infrastructure manager.
I see small companies trying to take the “leap” to microservices, but they do not meet the criteria for such leap, mirroring themselves on big companies like Amazon and Netflix.
I've read an interesting article some time ago on small companies trying to emulate the big ones, here it is: You Are Not Google by a guy called Oz Nova.
I am not saying that microservices are only for big companies with huge demands, what I am saying is that you need to have a real need to make the leap for microservices and also have the right people and know-how, otherwise things can go very wrong very quickly.
Do not do it only because other people are doing it. A bad microservices architecture is much worse than a good monolithic architecture. Also take into consideration that successful companies which run microservices have started out with monolithic applications.
I believe that the software architecture a company produces must mirror its communication structure. Crudely, if a company has a single ten-people team with no specialization, its software should be a monolithic application, or as close to that as possible. I think it is inevitable that the number of people should increase proportionately to the application's growth.
Therefore, when the need arises, that single team will be split and grown—considering an optimal team size of ten people—and then there will be a need to start splitting the monolithic application in order to mirror that. Each team becoming responsible for a single service, ideally.
It stands to reason that the software and the organization will evolve together, and at some point, the organization will need more teams, and the software architecture most efficient in this case will be microservices. Therefore, the need for microservices will arise eventually if the software is successful enough.
This natural evolution from monolith to microservices must be respected for optimal results, and you should take the time to train developers and make sure they know what they are doing, if you do not have that expertise readily available.
Do not go head-first into something you do not know about, only because other much bigger companies are doing it.
Developing software is all about pragmatism, circumspection and patience. Great software is not built, but it is grown and then split and then merged and then split again, just like a living organism.
It’s a game of managing the complexity of very complex systems, and what better teacher than nature? Just look around you, sometimes the questions we ask have already been answered by nature—or civilization.
Observe how human organizations have grown and specialized to optimize culture and communication. How cells grow and then split into more cells in order to build something much more complex. How living beings are born, grow, reproduce and then die—gracefully, ideally.
Have great day, and if you have the time, follow me on LinkedIn.
Thanks for reading, I plan on writing more articles, this is just the first one, it helps me make my ideas clearer and hopefully generates value for the community. If you have anything to say, please do, I am often happy to join constructive discussions.
Leonardo Venturini is a young developer and digital entrepreneur from Brazil, having worked on small ERP and CRM systems. He has a huge passion for entrepreneurship, programming, data modeling and software architecture.
Picture: Man Jumping on Intermodal Container by Kaique Rocha



November 1st, 2019

Just out of interest … how comfortable are you with micro-services? I have used them “from the beginning” and to start it was just to see what the new thing was but eventually I ended up using it for everything (including small pet projects). I would agree there is a learning curve (there is to everything new) but in comparison to something like Kubernetes it’s a breeze. The main thing I think people don’t get right with Microservices is

  1. Good reuse patterns by choosing an appropriate granularity
  2. Logging across function boundaries

What do you see as being the costs? In general I would say I find the micro-services architecture much better for the “little guy” than the big company but maybe we’re both right.

November 1st, 2019

One person implementing microservices from the beginning, for a small pet project is certainly not the scenario I had in mind. When you implement microservices you move the complexity up to the architecture and infrastructure. Some of the complexity can be distributed to the developers with a good DevOps strategy, but at the end of the day you need great people managing all of that. Depending on the application, let’s say, an ERP solution with 3m LOC, and 70 microservices is too much for a single team to handle, and there I guess we agree that granularity is very important, perhaps at this point this hypothetical application should already have the resources to have other teams… all I am saying in this article is that the monolith should be the starting point if you want efficiency, on startups for example, efficiency most often is not the goal, and that is why most fail… I might be wrong, but I enjoy the discussion. Thanks for the comment.

More by Leonardo Venturini

Topics of interest