Don't tell me you haven't heard about Microservices!? Well, that Swiss Knife solves all your business problems! Is the codebase too difficult? Microservices! Your entire workflow is messed up? Microservices! Is programming too hard? Microservices! Are you having difficulty since your neighbor's kids always keep crying? Micro… Wait! That's something Microservices can do nothing about.
Well, here we are! Microservices! That buzzword that every backend engineer talks about. They are more of an architecture pattern and how you organize and think about your application. You might think it is similar to an SOA (Service-Oriented Architecture), but I would say otherwise.
This article is about the what, when, and why of microservices. In what conditions should you use them, and in what conditions you should not? Moving over to something that looks and sounds cool might seem fascinating, but what if that increases the technical debt rather than lowering it?
What exactly are Microservices?
Microservices, as the name suggests, is the idea of splitting your monstrous application (monolith) into small and manageable (independent) services. In other words, you create several small applications that are good at doing one thing!
Now, as I said above, 'doing one thing' doesn't mean that you think of it as, 'This service turns a string into an integer.' Nope! Rather, your business logic can be isolated into one independent application. And when I say the 'I' word, I do mean INDEPENDENT.
A good idea when testing your services is to try it out without any other services up! Does it work on its own? Does it successfully go through the CI/CD pipeline in isolation? Can the deployment of this service be done without any outside requirements?
There are indeed several benefits of using a microservice architecture. The most significant benefit that splitting your codebase into services offers is simplicity! A monstrous codebase with millions of lines of code is hard to manage. Building features is painful since other teams are working on the same codebase.
The above can also lead to unforeseen circumstances, such as conflicts that are harder to resolve, a high start time of the application since it is huge, and a harder time debugging because everything is connected to literally everything. This can lower the developer's productivity; forget lower it will ruin your day!
Though a benefit is that teams that work on different services can choose whatever language, framework, or style of writing code they like. This independence allows faster development time and improves the developer experience. Not only that, adding features is easy, too, since all you have to do is figure out whether this should be integrated into one of the existing services or whether a new service is required. A new service can then again be worked upon by a different team with an entirely different paradigm and be integrated seamlessly.
Discovering Microservices
What do you do when you have to create an application? The idea is to get an MVP ready and ship it out as soon as possible! All you do is figure out the initial challenges, design the application, and start building it.
The above is a common scenario that leads to building a monolithic application style. And it is NOT wrong. The core idea to keep in mind is that, in the end, it is the business that matters. If there are no customers, there is no use for an application. Therefore, monoliths can ship out quickly since you spend less time setting up your codebase and more time building features.
However, as the application scales and grows with time, it brings about several challenges. Application downtime because the tremendous user load fried your servers (at least I can make my nuggets, pun intended), the good old 5xx errors that will make your developers go, 'Oh come on, that again!?', and yes, the best question in the world, 'Should I just spin up another instance on EC2?'
The kingdom of Fyn
Fyn was a kingdom with rich culture, heritage, and charismatic people. But even more charismatic was their princess, Filomena! Filomena was next on the throne of the kingdom of Fyn.
Filomena knew that the throne she was taking was full of challenges. Fyn was a kingdom already in turmoil, all the departments in Fyn were corrupt, and the officials were always after money. The intertwined system of operations in Fyn was so complicated that recruiting new people into departments took work. People found it hard because they had to wait for people from other departments to finish their work, and only then would they be unblocked.
When Filomena became the queen, she swore that she would fix this problem from the very root of it. And so she started. Filomena recruited the best people she knew and asked them to devise a plan. Her most important adviser was Haythor. Haythor was an expert in finance and management.
And finally, it was a meeting day! All the important people gathered, and Filomena raised her glass of wine and said, "Alas! We finally meet! After all the turmoil and trouble we have faced in the past, we shall not let that hamper our future!"
Haythor got up from his seat and said, "Your Highness. I, Haythor, with all my research and thinking, have come up with a plan!"
"Excellent! As I expected from you Haythor! Please guide us through!" said Filomena.
"Your highness! When we see how the system of Fyn works from an overview, we can see that it's not just the departments that are confused but rather departments that are intertwined that are not able to figure out what to do!" explained Haythor!
"Our departments are not departments, but rather bulk houses that are so huge that to get one file across them means that that file will also go through departments that have no use of that file!" explained Haythor further.
"I see!" exclaimed Filomena. "That also is a reason why we have such corruption too! Departments that have nothing to do with finance reports are the ones who are misusing them the most!"
"Yes, your highness!" said Haythor, "henceforth, I present you a solution! We will redesign the entire system of Fyn! We will separate these departments to only concern themselves with one and only one task. If it is finance, then only finance, and if it is management, then only management. We will also have some co-ordinator sitting in front which will ensure that he/she knows where to send what request (spidy-computer-science senses kicking in) too! The co-ordinator won't be and should not concern himself with opening any file or package; s/he will only forward that packaged file to the concerned department by looking at the label. We will also create teams responsible for managing and doing continuous checks for requirements of these departments and act accordingly!"
Therefore a new system was introduced! And this new system in Fyn changed the way the kingdom ran!
Of course, it isn't easy to build and change the underlying systems that judge your kingdom or country, but it is certainly possible. Let's return to our world and figure out what we can figure out from what Haythor suggested!
Micro-services, too work in a similar fashion. We separate services by the principle of separation of concerns. This makes sure that one service is only responsible for doing exactly one job, and it does it well. Yet another thing to note is that micro-services follow a lot more than what I mentioned above!
Don’t make it a burden!
Now tell me all that stuff didn't scare you enough!? To be honest, micro-services aren't some Swiss army knife! They are good if applied to the right problem!
Using a micro-service architecture is overkill if you have a reasonably small project. All it will do is increase complexity and make it harder to maintain that project.
Also, if you're thinking, "Wait, what? How does it make it harder?”
Well, the answer is simple! If the problem was easily solved with a monolith in micro-service, you've got a bunch of stuff to do! Well, first, learn even more technology and maintain that code (in no way am I saying it's bad to learn new stuff but learning it deeply means you know where and when to apply it!), second that now you have written even more boilerplate that could have been slashed in half if it were a monolith!
And finally, the most significant pain point is that in smaller-scale projects, the cost you're going to incur for running a micro-service project will be huge! It will pay off really well if the project or application scales however, in smaller applications, that becomes a bottleneck!
Also, small-scale application means smaller teams! This also means just one developer may be working on several services, which will only make his/her life even harder (let that sink in)!
So think twice and don't make it a burden!
Exploring kingdoms of Micro-services
We’ve been through enough micro-services that we know what they are! However, what are the things involved when we say micro-services?
Welcome to the kingdom of micro-services. There are several tools built by the community for the community that helps us if we want to implement the micro-service architecture.
But in general, a few things must and should be known by every developer working with this architecture. For example, how are services going to talk to each other? This is a common problem we face with micro-services since communication between services is required. After all, how the payment service will know if this user exists or not?
There are several ways micro-services achieve this! Message brokers and event buses help you deliver and emit events and let other services know that something happened.
Here are some tools that are used extensively with MicroServices!
Message Brokers!
- Apache Kafka: Kafka is more of a de-facto standard when it comes to building micro-services. Check Kafka here
- NATS: NATS is also used as NATS the eco-system around NATS has been on the rise too. Check out NATS here
- RabbitMq: RabbitMq has been in the industry for quite long too! The eco-system around RabbitMq is as mature as Kafka. Check out RabbitMq here
DevOps!
- Docker: I don’t really think I need to talk about Docker its your goto containerization tool that just does the job its supposed to do! Check out Docker here!
- Kubernetes: When your ship is filled with a lot of containers, you need an experienced Captain to handle them and orchestrate them. Kubernetes is that orchestrator that your ship is looking for! Check out Kubernetes here!
Structure!
Well, this is a highly opinionated topic, but here is the thing! Monorepos are something that you’re going to love when it comes to MicroServices! Check this out
And that’s a wrap!
Now since we have come to an end, let’s summarize!
Micro-service is an architecture, a structure of your application’s logic, and how it will work in synergy. It simply means to divide your application by the principle of concern of work.
What micro-services are not? Well, they aren’t Swiss army knives, for sure! They have their downsides, and proper discussion and planning are required before making a decision.
Well, for today, that’s that! If you’ve liked what you’ve read, consider sharing this with a friend or on social media. If you want us to audit your application to tell you if you need micro-services, you can reach out to hello@wednesday.is.
Enjoyed this article? Don't miss out on more exclusive insights and real-life digital product stories at LeadReads. Read by Top C Execs.
Join here.
