Microservices Aren’t Magic, but You Might Need Them
6 benefits of using microservices for your projects
When it comes to architecting a brand new project, solving the scalability problems of an existing one, or even defining the company-wide architectural guidelines, microservices tend to be part of the conversation.
Why do you think that is?
Splitting a single idea (i.e the project) into multiple, individual parts that have to be maintained separately doesn’t sound like the best idea.
And sometimes it isn’t!
But other times (most often), it is, and if you keep reading, you’ll find out why, so don’t go away!
Explaining microservices like you were a 5yr old
Just so we’re all on the same page, I always like to start these types of articles with a definition. That way we can all interact under the assumption that we all understand the concept of “microservices” as the same thing.
To me, microservices are a way to build and run software applications. Imagine you have a huge and important project, like building a big tower with many rooms and floors. Instead of building the whole tower all at once, which can be confusing and difficult (you have to deal with the plans which are huge, then add the plumbing, the electrical wiring, etc, etc), with Microservices, we build each room one by one.
That way, it’s easier to build, manage and make changes to the rooms if needed. Each room is like a small service, and once you have them all ready, you can connect them together (put them one on top of each other) to form the tower!
The end result is exactly what you wanted, but the process of building the tower was more organized and easier for the workers. And if tomorrow, you want to add a new floor or repaint one of the existing ones, you can simply take it out, change it, and add it back in without the whole tower crumbling down into pieces and crushing everyone around it.
Alright, maybe the analogy turned a bit bloody and violent at the end, but you get the point (I hope). So let’s move on.
Better scalability
The first benefit I want to cover is scalability.
And by “scalability” I mean the ability of the platform to withstand more traffic out of the blue. This usually translates to needing more resources, either more RAM, more disk or even more CPU.
Mind you, just by themselves, microservices don’t scale better. If you go ahead and deploy all your microservices inside the same server (like you would with a monolith), then the limitations will be the same. You could get marginally better depending on what you’re doing, but you’ll run into limitations pretty soon.
Instead, what microservices give you, is the flexibility to deploy them in a way that becomes truly more scalable.
Look at the following example:
Essentially here we have a monolith (a single-block application) that contains all of our logic. We can access our database, process payments, log-in users and even manage products. All from within the same app.
Also, everything is deployed within the same server, with a limited number of resources.
Now let’s pretend we suddenly have a surge in users. Our app got famous, and we have 1000% more users browsing through it. They’re not necessarily buying more products (sadly), but our traffic increased and that means the log-in and database access portions of our app are working extra hard to keep up.
With the current setup, the extra resources needed by those portions of the logic will also affect the rest of the platform. Payments and product management will become slower or even unresponsive due to the increase in traffic. And that really makes no sense.
Even if you decide to increase the specs of your server to handle the increased needs, you’ll still be sharing them amongst 4 different services, so chances are you’ll run into a similar situation in no time.
And here is where a properly deployed microservices-based architecture can help you scale.
Look at the following diagram:
Now you have each service deployed on a different server. Each server has different specs, optimized for the task that each service excels at. And when one of them runs out of resources due to an increase in traffic (as signaled by the thicker lines), you can individually increase that server’s specs without affecting the rest of the platform.
On top of that, if one of these services is affected or malfunctioning due to a lack of resources, the rest of the platform can continue functioning without a problem.
Granted, these diagrams are oversimplified to prove the point, a more realistic architecture diagram for a microservices-based platform would have a lot more lines and a lot more services. That said, the same principles apply and the benefits remain the same.
Improve resilience
Overall, a platform that is split into microservices tends to be more resilient than a monolith.
And note how I said “tends” here. Just like with scalability, microservices aren’t inherently more resilient, they just give you the right tools to achieve a stronger and more stable platform a lot easier than if you decided to go with a monolith approach.
Why is that? Well, we kind of covered it already on the previous point, but with a monolithic approach, if a portion of your system stops working ,the entire platform would crash. This is simply because the entire platform is a single program and you can’t really have a portion of the program crashing without affecting the rest of it.
Mind you, you can have a monitoring tool that restarts your platform every time there is a crash, but whenever it happens, ALL your users will be affected.
However, with a microservices approach, when one of your services fails, you can continue working. This means that if you code your microservices in a way that decouples them from the rest, then you can add coping mechanisms for situations like this.
Let’s consider the following example:
This time around, we had a surge of payment requests, and Server 3 simply wasn’t capable of dealing with such traffic. This caused the service to die, and the communication between the “Product Mgnmt” service and the “Payments” service is down (as shown by the red arrow going from product to payment).
If your product service is coded correctly, this failure would not affect it, it would of course prevent you from processing any payments, but you could add them to a waiting queue, or even simply send a notification back to the user explaining that there is a problem and they should try again in few minutes.
Whatever you want to do, you can do it if you code your services accordingly. This is the flexibility that microservices give you.
Of course, if you decide to ignore all of this and simply assume all your services will work no matter what, then you’ll still have a catastrophic failure in your platform the second one of them fails.
This is why microservices aren’t inherently more resilient, but they do give you a lot more options to create a platform that is.
Faster deployments
Once your system is large enough, this becomes one major advantage.
You see, while during the initial stages of development, you’re likely to have to deploy your entire platform over and over again, once you reach a certain level of maturity, you’ll only be deploying fixes or features related to a very limited number of services.
This means that you could cut down deployment times and complexities by several orders of magnitude.
The key to achieving this benefit is, yet again, having a properly designed set of microservices.
In other words, the reason why this can be done, is that microservices give you the opportunity to decouple their implementation from other services. If you add public standard interfaces to them and hide their actual implementation behind those, then you’re free to update them without affecting other services.
Think of the example we’ve been looking at. Imagine you have a payment service that runs payments through PayPal, and you suddenly decided to add another payment gateway.
You could add that extra code into the payment service and deploy JUST that one, in a fraction of the time that would take you to deploy everything together.
This translates into:
- Simpler deploys, which your team will love.
- Faster time to market for new features and fixes.
- A better user experience, since downtimes are shorter and fixes and new features come faster.
Did you like what you read? Consider subscribing to my FREE newsletter where I share my 2 decades’ worth of wisdom in the IT industry with everyone. Join “The Rambling of an old developer” !
Easier development
Let me stop you right there. No, I’m not saying microservices are “easy” to code.
All I’m saying is that from an organizational standpoint, building a complex platform using microservices gives you a lot more tools to manage the development process a lot easier.
To begin with, you can have multiple teams working in parallel, which tends to reduce development times. Of course, you’ll also have to properly define standards between these teams, like.
- How are all services going to communicate with each other (communication protocols, message formats, etc).
- Versioning and dependency graphs, to understand which teams depend on each other to finish their work and how are they going to signal when there are updates.
- Coding standards and common dependencies. While each service could potentially be developed individually, keeping common standards allows you to share team members when needed.
- Sharing types across teams in a microservices architecture improves communication, enables code reuse & consistency, facilitates data governance, increases efficiency, and eases testing & debugging, leading to a more maintainable and scalable system. For this, you could use an open-source toolchain like Bit.
To learn more about sharing types across teams:
Another benefit of having separate projects for each microservice, is that they become smaller and less complex pieces of software. You and your team have to focus on developing a portion of the overall platform, ideally, in an isolated environment only using publicly available communication interfaces. This decouples your implementation for the rest of the platform and makes it more secure, stable and extensible.
You no longer run the risk of accidentally tying your payment process to a function only available from within the product management module.
Overall, using microservices gives you a lot of flexibility to organize the workflow and parallelize a lot of the work. In turn, this translates to — yet again — faster time to market.
Versioning
While it might not be a common use case, imagine having to develop a new version of your app, improving its functionalities but at the same time, having the back end not being backward compatible with the currently deployed version.
This means you have to replace all your clients as well, otherwise, they will stop working once the new version goes live.
The way you’d normally tackle this, is to have a parallel deployment of your entire back end. Then point the new clients to the new version, and slowly migrate the old ones.
Now imagine having to do this due to a single functionality, like the payment service.
Wouldn’t it be nice if you could only deploy the new version of the payment service somewhere and then keep the rest of your app intact?
With microservices and a properly designed versioning and communication strategy, you can!
Communication is crucial here, because you have to find a way to decouple the communication protocol from the internal implementation to make sure that the changes you implemented don’t affect other services and how they talk to the changed one. Something like an event-based system would work great here because it would only introduce a new set of events that only the new / changed services need to know about.
And then versioning would let you deploy multiple instances of your services without having them collide with each other.
Managing those versions is something that might require extra tooling, but the benefits would be worth it.
For example, if you’re using Node for your entire back end, you could use tools like Bit here to simplify the entire process. It would let your developers abstract themselves from the entire workflow and toolset required and they’d be able to compose and deploy different versions only using a single tool.
Flexibility
I know that in the previous point I said that following common coding standards between microservices could help because it simplifies the task of sharing developers between teams.
But you also have to consider that given a big enough platform, there might not be a single piece of technology that fits “right” everywhere.
What I’m trying to say is that you might need different languages and potentially, different programming paradigms, depending on what each microservice is tasked with doing.
In such case, a monolithic approach is not flexible enough, since by definition, the entire project would have to be built using the same language.
On the other hand, if you have individual services working and being developed in parallel by different teams, you could have each service being developed using completely different languages. Imagine using Node.js for your APIs that power the front-end, but at the same time, having Spark processes that deal with real-time data being read from a Kafka topic and pushing that data into a SQL database that is then read, when an event is triggered by the user, by a set of Python services.
And all of them communicating with each other, when needed, through a centralized message bus.
This is the level of flexibility that microservices give you, and the reason why I love them so much.
Microservices are great, I hope you got that from reading this article. But they’re not “magical” — I hope you got that part too — . The reason why they’re so great, is because they provide you with the tools to improve both, the technical aspects of your product as well as the organization of your teams. But you have to use those tools to get those benefits.
Throwing microservices at a problem is hardly ever the solution, instead, the tools that come with them usually are. So try to think about “why” you’d use microservices and the benefits you’re looking to get out of them before going down this route.
If you’d like to read more about this topic, I have multiple articles for you on this list.
From monolithic to composable software with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
