paint-brush
Musings On Software Architecture: Monoliths to Microservices by@leonardo-venturini
1,566 reads
1,566 reads

Musings On Software Architecture: Monoliths to Microservices

by Leonardo VenturiniNovember 1st, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A bad microservices architecture is much worse than a good monolithic architecture, says Leonardo Venturini. Small companies should not try to take the 'leap' to microservices, he says. Developers need to take a lot of extra steps not directly related to code to do their job, i.e. communication and coordination. He says it is easy to build a bad microservice architecture because it involves very high-level tasks which are not intuitive to the average developer or infrastructure manager. The number of people should increase proportionately to the application's growth.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Musings On Software Architecture: Monoliths to Microservices
Leonardo Venturini HackerNoon profile picture

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