Hey, Tea Lovers! Today let’s talk about a hot topic in the market, Microservices. We will be discussing how microservices are very simple things and we were doing the basic requirement of it for quite a long time without realizing it. Then I will also share with you what I mean by Chaos in Microservices.
I would be happy to connect with you guys on social media. It’s @coderstea on Twitter, Linkedin, Facebook, Instagram, and YouTube.
Please Subscribe to the newsletter to know about the latest posts from CodersTea.
Software Development’s First Step Towards a Solution is…
If you have noticed, whatever problems we try to resolve in the software development process, the first thing we do (and must do) divides the problem into smaller ones. The smaller the problem gets, to an extent, the easier it is to solve or find a solution. Divide and Conquer is a very effective and must-do step in every type of industry’s problem. If you think about it, almost all things, complex or easy, are built one step at a time and not whole at once.
For example, if we talk about building a Bridge or FlyOver in a city, is it built at once and then placed somewhere? No, right? You would need around 10-15 King Kongs to pick up the whole bridge and place it with care, which they won’t. So what do we do in this case? We divide the bridge into smaller chunks that are easy to transport and have less weight. Then we transport them to the site and attach them one by one, like huge cement and steel Lego pieces.
Similarly, every problem in the software development process is divided and then worked upon. Take a look at the software development life cycle itself. It is divided into smaller parts such as planning, coding, testing, and then deploying.
This is the basic idea behind Microservices, just keep this in mind for now. Because, before going into microservices I need to tell you about the problem we are trying to solve here via microservices. Yes, that huge problem that we will try to divide and conquer.
Monolith: The Problem Microservices are Solving
We divide the problems into smaller parts of the software dev life cycle, right? Then in the coding and dev phase also, we try to divide the project into different modules. With this modularity, the coding and development phase gets faster. After completion, all these smaller modules are combined into a single big module or project, which we call Monolith. For example, suppose we created small boxes independently and in the end, we put all these small boxes into one large box. Well, the end goal was that only, right? But there is a catch in this approach.
For a smaller project with few sub-modules, it is maintainable. If something bad happens in a module, then it is manageable and can be fixed immediately because the project is smaller. And we don’t have to look around for lots of things.
When Monolith Project is Huge
In case you have a huge project with hundreds of modules, then what? Something like an E-Commerce website, where we have lots of different modules. Such as product management, order management, Invoicing, stock maintainer, User handlers, and Payment gateway among other smaller and key modules. What do you think will happen if one of the modules crashes? Since it is a single monolith application, it can take down the whole website or server with it.
Now the whole organization is looking for what has happened and cursing other teams for ruining their Friday night party. And almost 2 hours later you found out that it was a Null Pointer Exception in the module your team was responsible for (Imagine other team members staring at you on Monday morning). You pull an all-nighter and try to fix the issue. And you found out that the issue was because the other module didn’t pass the data properly when it used your module’s Object.
So the question arises if we start with smaller modules then why, in the end, do we have to put all these different things together into a single monolith? If we can develop the module independently then why not deploy and maintain them independently too? Well, we can.
What is a Microservices Architecture?
The question we asked in the earlier paragraph about why not deploy and maintain modules independently. It is exactly what a microservice is. As the name suggests you are dividing a service into different ‘micro‘ ‘services‘. It is as simple as that. You are dividing the services such that you are developing them independently, deploying them independently, and maintaining them independently. The very basic idea of Divide and Conquer.
There is no proper definition of microservices. Because, as I said, It is just an independently operated small service. But how do these “Microservices” then carry out a task if they are independent of each other? Don’t we need them to work together in the first place?
The answer is the Network. Yes, microservices communicate with each other over the network. They may call each other’s API to send and receive messages. There are many options to communicate. The most common and easy method is via REST API.
Microservices Example Using E-Commerce Website
Let’s look at the earlier example of the E-Commerce website. Earlier, we used a monolith approach where we combined all the modules of products, orders, invoices, etc into a single application. Now, instead of combining let’s deploy them independently. Let us see how.
Suppose, Project Module is maintaining the product images, price, and other information. We are getting these details from the Product Server where we have deployed the Product module as a microservice. it has its database, server, and other required things. Similarly, we need we deploy other modules as microservices such as Order and Invoice.
Now, you select a product from the product listing and click on buy now. With this, the information about the product such as price and quantity is being pushed to Order Micro Service. Here, Order Micro Service keeps a log of all the orders and finalizes the shipping and other things by similarly communicating with other services. At last, once the order is confirmed, the Order microservice then calls the Invoice microservice to generate the bill and send it to the customer. And that’s how you get your product shipped to you, ( Not literally but enough for you to understand 😜).
Microservices are Conquering Critical Moments
Let us see some of the advantages of microservices architecture.
Not Bringing Down the Whole Army
Now imagine if the invoice microservice system gets down for some reason. what would happen? Will it bring down your entire E-Commerce website with it? No, it won’t. Since it is an independent service, it won’t bring down the whole system. Yes, the invoicing system gets affected badly but not the whole system. Since it is a small service with only invoice logic in it, we won’t have a hard time finding the issue as we did in our Monolith Application. And no more Monday morning staring at other employees.
Finally, You can code in Your favorite language
These microservices are maintained and deployed independently. You don’t have to worry about the language of other services (modules). You can use whatever programming language or framework. But make sure that it will be able to easily communicate with other microservices. You will be passing data over the REST API anyway, so no matter what language or framework your microservice is running.
Microservices are Scalable and Flexible
Now, Imagine your users are increasing so you need to increase the memory and other resources. In the monolith, you need to scale something you need to do for all the modules or services as a whole. If only the product modules needed more memory, unnecessarily you are giving extra memory to other modules as well, increasing cost. Now in microservices, all are independent so you can easily scale only that server that needs it. You can also scale down some services in case they don’t need them anymore.
Ok so far so good. But, as I said in my previous post, The Magical World of Java, not all good is in the fairyland. Beware of the dark magic.
With Happiness, it Brings Chaos
From big problems to small problems, From a huge Monolith to multiple microservices we are trying to conquer by dividing. But did you notice that one thing became many? One problem became many small problems. One monolith became numerous microservices. We overlooked this because the issues became smaller. We fear one big Tiger, not 10 small cats. Yes, microservices solved many of our problems in developing something, but it creates a few more as well.
Woah! I didn’t realize that the atmosphere became this tense. Don’t worry I don’t want to scare you guys off to not using it. I am just stating the fact. One of the major problems with microservices is the handling of multiple microservices. It becomes a very cumbersome job to manage them as the number of services grows. It just becomes a complete mess if not handled properly.
Well, there are multiple ways to handle them. We have multiple architectural designs to overcome this problem. These architectures can solve your problem depending on your need or what kind of services you are building. The best example would be Netflix. They are like the king in this segment. See the following talk, Mastering Chaos – A Netflix Guide to Microservices.
Conclusion
I know the post got a little bigger than the previous ones. I tried to match the microservices with the existing knowledge we have. It is not something new that you haven’t done in fact, it is similar to what we have been doing up until now. Divide and Conquer. The downside is that as the number of microservices grows you need to properly manage them to reduce the chaos. But there are multiple ways you can avoid these issues by going with a suitable microservice architecture. There are plenty of resources on the same topic.
I hope you have liked the post. Please do share it on Facebook and other social media.
See you in the next post. HAKUNA MATATA!!!
I would be happy to connect with you guys on social media. It’s @coderstea on Twitter, Linkedin, Facebook, Instagram, and YouTube.
Please Subscribe to the newsletter to know about the latest posts from CodersTea.