A study in microservice
Title is a bit Scherlocky? I know :) This post is actually the things we already know as developers who studied microservices but it will be very helpful for the developers who have no experience on microservices.
Microservice architecture is a design pattern that become very famous in last few years. As I research, I understood why many big and even giant companies adopt and implement this pattern that I’ve been interested in lately.
Consider that our sample project is built on .NET framework used C# language, we used Redis for in-memory data and Microsoft SQL Server for persistent data.
Long before microservice architecture, we were developing our applications in an architecture called monolithic. It was such an architecture that when we finish the development period, we build the project and as result we got some files that required to run our newly developed application and also some other files that our main project file dependent on them.
To run this application we assume that our server have necessary applications installed such as .NET, Redis and Microsoft SQL Server. (And this server doesn’t have to be the same computer that we develop the application)
Even if our application run flawlessly as exptected we will have enourmous problems that will ahead of us in the process of adding new features to the application. We will make some changes in our layers in solution and will hope for the best for not get shocked by any surprise in production line (even if the app tested well done). When all this events occur please remember that we need to make sure the developed application must have been match the version with production server. This is goes for .NET, MSSQL and Redis. If any of these apps have developed using different version that server have, we might have problems on production and our application maybe will never work with the current configuration of the server.
Oh my god, I had stroke imagining maintain a large enterprise app in above approach.
Because we just created a situtation here called single point of failure. We had single database and there is only single entrance to the application. So if anything happens to that entrance, app does not work. Simple as that. Imagine our SQL server is down for any reason, app does not work, as well as Redis down for something that we aren’t responsible, app does not work. And I am not even mention that all of these required apps to run our app is dependent on one single server (if server down, everything down).
By the way, I am not saying that monolithic architecture is bad or like that, it’s just very very hard and very close to impossible to maintain big and giant apps with this approach. I am perfectly okay with the small and mid apps with monolithic approach.
For everything happened above, our beloved software engineer friends split this single application to multiple applications. Split them into SERVICES and call it SOA (a.k.a Service-oriented Architecture). Microservice architecture is based on SOA.
I can make it clear what microservice is with single example:
Let’s imagine we have an e-commerce app that consist of orders, products ,categories, special offers, payment system, cargo tracking system and some more of this type of services. All of these services have their own servers and in their servers they have their database that only but only available to them.
Also let’s imagine we have another service that handles the communication between these services. (order service needs to communicate with product services in order to get information of a specific product for processing an order.). Now we have a very basic microservice architecture.
But I must say this architecture is require very much of resources, makes it harder to test and debugging, have relatively complex deployment process and hard to manage. Why would anyone in the world use such architecture?
Imagine that an error is thrown in our order service and the service is down. In the previous example our app would collapse and nothing would work. But in microservice world, our app will continue working flawlessly. Yes the orders won’t be processed for some time but the orders will be processed right after order service is up again with the big help of an “event-bus” service which keeps the orders that not have been processed.
This is very VERY important for one thing:
RELIANCE OF YOUR APP (Firm trust based on tremendous uptime)
Since your app is not down for a very very very long time, up and running like %99.9999 of the time, the visitors are sure that this web app is reliable. Because it is always there. And even when some services is down the app is not losing it’s functionality (well of course visitors don’t have any clue and not has to). Order service is down but eventually orders will be processed. Visitors only know that this app is just works. So uptime solution is one of the most important solutions microservices provide.
Another problem would be in monolithic approach would be the only single technology should be used in the project. So if project is .NET you need .NET developers. But in microservices world since every app is isolated and have their own servers, that means you can hire very talented prople from various of technologies like Java, Python, C, C++. Do you need a service that has to implement AI and ML? Good news! You can hire Python devs, the implementation of new services only concerns the services that implements the new feature. So nobody has to know Python other than Python devs. Brilliant! This whole “you can hire people from different technologies” is also very good for company’s staff diversity.
And other big solution would be scaling. It’s very hard to scale monolithic apps. Because each time you have to put some resources on the current system, you have to take the app down and install the necessary components and re run the app again. And what if the server reaches it’s maximum hardware limits? Well will you decline the visitors? God no!
Microservices can scale beautifully. You don’t even have to down a single service. You just put new servers and set some replicas of your services and some server orchestration apps (let say Kubernetes, you don’t have to know it) would balance the traffic between this replicas (replicas are simply the servers that have the same service in it.). Beautiful.
And many solutions microservices provide to our business life. I honestly believe that microservices changed the way that we see a project. Now we can look from very different aspect to the subject. It is now quite possible to build enormously large applications led by microservice architecture.
Thanks for reading :)
