Microservices are causing a stir in software engineering.
It’s the new buzzword that everyone in tech talks about for architecting your application.
But what exactly are microservices and why is everyone talking about them?
Microservices are independent deployable services that work together to form an application
To a user, a program run by microservices looks no different from a program that is stored as a monolith.
And a monolith is one giant codebase that stores all the code for the application in one area.
Think of your application as a warehouse for an online store.
A monolith is like storing all of your stock in one large warehouse. It’s great when you first start. You have all your customers buying from you locally in New York, so having a warehouse in New York is convenient.
But suddenly your online store takes off, and you get a lot more orders. You need to store more inventory, which gets difficult to manage and organize.
And now you receive orders from Los Angeles, meaning it takes days to deliver a package from New York to Los Angeles.
Here come microservices to the rescue
With your orders increasing, you decide to split your massive warehouse in New York into loads of small warehouses around the country.
And those warehouses will contain specific stock that is most popular in that area. If your most popular item in Los Angeles is swimming trunks, you can stock swimming trunks in your Los Angeles warehouse. Whereas in New York, you store your most popular item, which is coats.
A microservice is a part of your application, which is split out and only accesses the resources and data it needs.
You are breaking your monolith of a codebase and splitting it out into smaller dedicated pieces.
Now, the warehouse is not a perfect analogy, but it gets you thinking about how splitting out your application is beneficial.
Microservices make running your application on the cloud more sustainable
By splitting out your application into dedicated areas, you reduce the number of dependencies in your code and make it easier to scale your application.
Fewer dependencies in your code
Dependencies in your code are a nightmare.
A dependency results in one expected change in your code, turning into two changes.
This results in:
- Less productive developers, as they have to make changes in your code.
- Increases the likelihood of bugs, as making a change without changing the tightly coupled dependency, can create an error in your code.
- Makes it harder to create automated tests.
By splitting your monolith into microservices, each microservice runs independently, meaning fewer dependencies in your code.
Microservices are easier to scale on cloud services
With a monolith, you have to run one large server to increase the performance of your application. This is scaling vertically, and it is not efficient.
With microservices, you can scale your application horizontally. By adding multiple servers to your application (each microservice gets a server). This gives you the benefit of running servers that are only as powerful as that microservice needs.
For a monolith, you may only have one area of your code that requires a lot of server power. But because you cannot split out the server, your whole project has to run on that powerful server, which is costly.
For microservices, the microservice responsible for the area of your application that requires large server power can have a dedicated, powerful server just for that area. And the rest of the application can run on smaller servers.
This is a lot more cost-beneficial.
Microservices are easier to maintain on cloud services
If there is a bug in your application, it is more likely that it will only affect one microservice in your application.
Whereas a bug in your monolith can grind your application down to a halt.
Easier to deploy changes to a microservice
With a monolith, you have to deploy all of your code again when you make a change.
But with microservices, you only need to deploy that one particular microservice in which the change is occurring.
