The Microservices Architecture is a popular style for designing large complex systems.
This article will introduce us to the basics of Microservices.
2. What is a Microservice?
Before talking about the larger architectural pattern, it’s important to first understand what a Microservice is.
A Microservice is a server side application that handles a small piece of business functionality. The key to a Microservice is that it requires few (if any) external dependencies to do its designated job. Examples of Microservices include Authentication, Profile, Chat and other specialized services that perform one major function.
Traditional Web Applications took a more Monolithic approach to designing their system. The single application would be responsible for user authentication, displaying profiles, facilitating chats, etc. Microservices allow us to isolate these concerns into separate, easily understandable code bases.
3. What is Microservices Architecture
We understand what a Microservice is now. What is a Microservices Architecture? It’s a system architecture with each component of functionality broken into a separate Service.
We can use the previous WebApp example from above. We would have a separate system for serving the UI, handling login, handling messaging, storing user profiles, etc. Breaking the code up this way does increase the complexity, but it is well worth it in the end.
4. What are the Benefits?
Why would we purposely design a more complicated system? The biggest benefit in my book is controlled scalability. In the Monolith example from before, we were stuck with a two direction scalability. If the load increased, the only things we could do is increase the number of servers we are running or increase their size (or both).
This system falls apart when you have one small piece of the application that can take up a significant percentage of the resources. For instance, if we allowed users to upload images this could cause us problems. If 1000 users are all uploading pictures, and we take up a thread per user, we could be out of processing power on our machine. We add another machine to handle more traffic and problem solved right? Sure, for now. But you can see this can get expensive because most of the other system resources are sitting idle so the users can upload their pictures.
How would this same scenario look using Microservices? We would give a link to the dedicated Upload service when they want to add a file. The UI opens a socket to this other service and takes up a thread on it. When more traffic comes to the site, won’t block the main server with the upload traffic so it can handle it no problem. If we get a lot of simultaneous uploads we add more Upload servers without impacting the rest of the system.
Separation of concerns also allows development to happen in isolation. We can make changes to multiple systems simultaneously without fear of code conflicts. There’s a lot to be said about increasing developer productivity.
5. When NOT to use it?
The Microservices Architecture is far from perfect. I already mentioned that increases complexity. It also tends to increase the cost of a system. You need more servers to run it and more developers to maintain it.
If you are a small team, building a small project, then Microservices are not a great place to start. Build a Monolith (it’s far easier!) and break it up into Microservices when you get more traffic. The one exception to this rule is if you are building a MicroSaas company. In that case, your Monolith will probably already be a Microservice.
If Microservices are not a good fit because of cost and complexity, and you still don’t want to build a Monolith, there is an alternative. Consider going Serverless and following a Nanoservice architecture. Nanoservices are beyond the scope of this article so I will cover them later.
Microservices Architecture is a great way to design a large and complex system. It allows us to maintain and scale the system much easier. But it isn’t a Silver Bullet so make sure the pattern fits your needs before adopting it.