You finally did it! You have thought about that side project with the potential to become a unicorn, and you believe you have the skills to bring that project to life. Then all of a sudden, while doing your research, you hear about how companies are switching from a monolithic architecture to a microservice architecture. You are clueless about what any of those buzz words are. You instinctively and wisely looked up what a microservice architecture is and learned how to create one. But now you came across the title of this article, and you are more confused because you thought building your project with a microservice architecture was a good idea.
If you are not the person I described in the introduction, don’t worry. I do not expect anyone to be, but if you are, Hey! We should probably be friends, and here is why building a microservice architecture might not be a good idea.
THE HYPE BEHIND THE MICROSERVICE ARCHITECTURE
A lot of companies are migrating to microservice architectures, and that is for good reasons. Imagine you want to create an eCommerce business that wants to scale to the moon, lets call DogeCommerce. You would need to add user authentication, customer profile, product listings and a payment solution(PayPal, Paystack). You can create the app in a single code repository where all the features are and ship it on AWS(amazon web services), and boom, it has IPO’d for a billion dollars, congratulations! What you have built is an example of a monolithic architecture, where all the features and code have a single codebase running on a single database.
The architecture might seem ideal, and for the most part, it is! A wise man once said the best solution is often the simplest, which applies here too, but the microservice architecture would not be the tea if the monolithic design did not come with some drawbacks. For starters, with a monolith design deploying new features is like trying to bring all the groceries from the car at once. You would think it is a good idea until a plastic strap gives up and you are in serious trouble and would have you looking at your application on a Friday night like :
Single Point of failure is prevalent with monolith designs, so it requires one feature to stop communicating with the client for the whole server to crash. That is where the microservice architecture comes in. It lends you more hands when carrying the groceries. Microservices are an architectural approach to building highly scalable and maintainable applications that allow companies to ship products faster and be competitive. A break in a production team would not cause a collapse in the whole application because of how loosely coupled it is.
Microservices have ‘tiny’ databases where the clients are connected to different devices. This approach comes with a lot of advantages for companies, especially when hiring new employees. They would not have to spend time trying to understand how to work with the entire codebase and just the feature assigned to them. Parallel development is also more manageable. Companies can monitor the amount of load a particular feature takes and scale it up or down in the most cost-efficient way, unlike the monolith design, which is just a blanket approach. So with all these advantages, why should I not build my billion-dollar side project with a microservice? Before I get into that, I should dispel some rumours about the monolith design.
‘!ALL THE CLIENTS ARE CONNECTED TO A SINGLE MACHINE’
The idea that all clients need to connect to a single machine implies that only vertical scaling is possible with monoliths which is not true. Monoliths can scale horizontally too.
WHY YOU SHOULD STICK WITH THE PLAIN OLD MONOLITH DESIGN
Most of the advantages of microservices over monoliths are for working with large teams and is a zero-sum game when starting. Microservices are for when the team scales to the moon, not when users do. Attempting to build a microservice for your app when only two people are working on it is wasteful and dumb because they would be a lot of code duplication for running tests and connections. It also brings many moving parts into the equation to worry about, and it is not sustainable for a small team. Building a microservice also requires skilled hands unless you might be at risk of writing anti-patterns that work against everything you are trying to achieve.
Thank you for reading! If you enjoyed this article, consider giving it claps and following me on Twitter(twitter.com/theisaac3n)