Introduction
From the past decade we have seen a boom in the usage of applications, the sense of scalability that is being achieved today was not even dreamed of a couple of decades ago. Due to ease of access and cheap computing the brands now have more users than ever. How has this changed the development perspective?
Well, the competition is now changed drastically, big companies are adding more and more features so this has increased the importance of writing reusable, component based and much more scalable code.
Software development can be based on different architectures ranging from client service architecture (extensively used for cloud applications) to pear to pear (P2P) architecture (which partitions workload between the peers i.e. the connected systems).
So now let’s see what monolith and micro-service architecture is.
Monolith architecture:
The idea of monolith can be grabbed from the word itself. Monolith means a large block of stone. In the context of software architecture it means the same i.e. the application is built and is deployed as a single standalone application. Now consider the fact that the application might be built in modules such as the database module, the UI module etc but the main thing here is its deployment as a single application. Now example include having a single end to end POS system that you deploy with minor changes to different vendors.
Micro-service architecture:
Contrary to the approach of monolith applications, micro service applications would have divided the application into the interconnected services while maintaining the abstraction of business login. Each of the module work as services such as the database module would provide different APIs for other services. Each of the service can be individually upgraded, changed and deployed. There is an extra need to care the results which other services use are either in the same way or changed in the other services too. In the agile development model this is highly successful as teams are divided in the respected service areas. This also means that each of the service would have its own database if required. For example consider a site like Netflix, it has its own recommendation system service, the database of the recommendation system service keeps track of your searches, other services might keep track of them too. The database of the recommendation system works in itself and provides user centered recommendations without communicating from other services.
Coming to the example lets again consider a POS system like discussed above, there the system was implemented as a whole to the system. If we consider a POS in micro service architecture, it would be like having a UI component, a separate customer component and a separate manager component. If we look closely, we can say that this was also happening in the monolithic architecture. The difference is that there were modules there and the whole application was deployed as a whole, in this case the components work individually and to intercommunicate to form a complete product.
Advantages vs. Disadvantages?
Monolith architecture:
Monolith applications simple to develop, deploy and test. A single copy is first made and tested. Then at the time of deployment, we can have multiple instances of the same application running. This is time efficient and easy to manage.
Monolith applications are hard to upgrade. For example, the UI of a monolith application is based on .net and now needs to be updated to angular or react. This would be an extremely complex task to change it interconnected nature. It would be better to build from scratch again. Whenever there is such changes than the whole system would require testing from end to end. This also shows that the code would get extremely complex when it grows. If the application requires more resources the application becomes slower.
Micro-service architecture:
Applications built on micro service architecture makes the code simpler by having independent services. This is beneficial as they are faster to develop, deploy, and understand. Maintainability of such applications is real simple. Independent services means that technology of a single service can be independently changed. This independent nature increases scalability as the programmers could focus on improving the response time of the bottle neck service.
Apart from having these benefits the microservice applications are a bit harder to develop, as the system needs to communicate between individual services. Good response time in inter-service communication is vital. But if we look at these factors, they are the reasons for improving the scalability. So anyway, it is a win-win situation.
How do I know that I need to move on to the microservice architecture?
If the customers are increasing exponentially then the investment is always good. If the application is requiring too much time for changing then again it is good to change because separability of concerns would be a bottleneck here. Now, it highly depends on the features too as if the code is getting complex and complex and you have new features that you would want to add to your application then again the change is inevitable. This is also a method used by companies to cut operating costs. More complex codes mean more man-hours to fix the old code and build the new code. Efficiency is achieved by successful migration so considering the factors such as finances and the growth of the business you should take your decision.
Things to keep in mind while migrating:
Here are some of the points that you as an application planner would have to take:
First and foremost is the problem that what technology you would be using for your individual service. It is extremely important because the system would in the end have to intercommunicate to achieve the business goals. It is very important to have the most suitable and connected stack of technologies for fast execution.
Secondly, coming from the monolith architecture teams are divided into individual modules like testing, programming, web technologies, and others. In the shift of architecture, you would have to make sure how your team would now be structured. For each service, you would need people from testing to deployment experts to coders. So this major shift in human resources is also very stressful.
Thirdly, maintaining uptime is also a very crucial step. For the time your existing application would be running and the new application might take months to build from end to end. This is an incredibly expensive task, so you need to make sure how to adjust, what would be feasible for your organization.
Last but not the least, deciding the coupling of services is a very important task. If the services are highly coupled with each other it would be difficult to have the advantages of microservice such as scalability due to the fact that it would be no different from monolith applications. Having too little coupling between the services makes it hard to achieve consistency.
Concluding, I would like to say that migrating successfully would take the company to new heights in terms of customer engagement and responsiveness, having a bad go at it would result in a death blow to the company. So managing it is a painstaking task, but if successfully deployed the results would be worth all the hard work.