Microservices architecture is becoming the next big thing in modern software development. But can it help solve the issues most startups are faced with? Let's find out.
As a software engineer, I love the idea of microservices. And why someone wouldn't? The architecture is the ultimate playground for distributed systems. It just looks and feels right.
Traditionally, software engineers were mostly creating large, monolithic applications. The single monolithic architecture would encompass all the business activities for a single application. As the requirements of the application grew, so did the monolith.
Let's dig deeper in whether we should really use the architecture, and if so, when.
What Are Microservices and How Do They Work?
Microservices are the next big thing in modern software architecture. The idea of microservices architecture is that every piece should be small enough so it focuses on a single purpose and big enough to add value as a component.
Instead of building one huge application, developers are building multiple, smaller, independent instances. These instances (called microservices) are plugged into one, functional application. When talking about them, we can't skip the containers that deliver the code where it needs to go. The containers are plug and play, so if any of the microservices don't work, the developers can replace one microservice with another one. The microservices communicate with each-other using API.
These days, microservices are receiving a lot of attention. I can see many startups and enterprises hoping that this new architecture could solve all of their technical issues.
Many growing companies like Netflix, Uber, Airbnb etc. are using this architecture because it allows them to scale or simply replace certain parts of the system easily. The trend is growing, many other innovative companies decoupled their applications into smaller pieced because technology allows them to do so.
Advantages and Disadvantages
Microservices architecture enforces the development of small services dedicated to specific, well-encapsulated domain areas. They are ideal for complex systems that have many components and multiple development teams working on them. Each service can easily be changed, removed or upgraded without affecting the whole application – as is not the case with monoliths.
Another great advantage is that each service can be written in its own language or framework and it can have its own database. On top of everything, unlike the monoliths applications, with microservices, you can scale only one service at a time.
The biggest disadvantage is the complexity of designing and developing them. It requires a lot more time and effort to build and deploy a series of microservices then a monolith application. From a reliability point of view, there is a higher chance of failure during the communication between the different services when we use microservices. Another pain points are the costs of running microservices, as well as their orchestration and monitoring.
When You Should Use Microservices?
Most of the articles we read talk about decoupling tech systems, removing dependencies between development teams, better horizontal scalability, and so on. If you’re the size of Airbnb or Netflix, then that is all probably true.
When You Shouldn't Use Microservices? Why?
The usage of microservices only starts paying off when the applications are getting too big to maintain.
For early-stage companies, well-designed monolith architecture is just enough to start with. A strong monolith structure will allow you to replace any segment of the application with microservice when needed.
Most of the successful startups we read about (Netflix, Uber, Airbnb, etc.), all started with a monolith architecture. Once they became ready for scale, they switched to microservices. This change allowed them to stay agile and continue to increase velocity in their core business. There are few leading companies whose engineering teams have strong case studies about their experience switching the old architecture with microservices.
