Microservices may not be the silver bullet agile developers were hoping it to be
Technology is like Darwin’s theory of evolution by natural selection or popularly known as “survival of the fittest”. According to the hypothesis, all species of animals emerge and develop as a result of natural selection of minor, hereditary differences that improve an individual’s capacity to compete and survive.
Does it ring a bell? That’s right. Every new technology that emerges replaces the old one or simply evolves to a better one. It’s like CRT to LCD to LED to OLED. It may not take as long as natural evolution but the principle still stands.
But what this has to do with microservices. Well, microservices emerged from monolithic services as a solution to solve the problem of stack and skills. Meaning a technology stack should not be limited to the skillset of a developer or vice-versa. Since then microservice has been everywhere and evolved to so much more than simple REST APIs.
For those who have been living under the rock, microservice architecture is a unique approach to software development that focuses on creating single-function service with well-defined interfaces and actions.
Microservices is not anything new it’s been there for a very long time. It’s something similar to modular programming but on a network level. As businesses have strived to grow in a more agile fashion and move toward DevOps and continuous testing, the trend has gained popularity in recent years.
It does sound pretty efficient and reliable as so many people are implementing it. Some of them have even formed startups around the whole microservice trend.
Then what’s a draw here.
The microservice isn’t a panacea. It has a number of flaws. Furthermore, there is a slew of challenges to consider when implementing this design. Planning is an extremely crucial factor when implementing a microservice or you may end up with more than what you bargained for.
Networks become your adversary here
Microservice deals with network-level meaning chances of failure are higher. So, as it happens with a traditional monolith service we have multiple functionalities implemented as modules or in OOPs terms implemented as classes. When a process needs to access this logic you can simply call the function on the process level itself. But thing is that all of your code is made of one single language or framework. The microservice on other hand provides one the freedom of choice. You can write one functionality in NodeJs and another one in Python or even have MySQL as a database for one and MongoDB for another it doesn’t matter. But when you have to inter access the functionality you need to make network calls which is a much-complicated process, not for implementation but for execution.
Network calls have to deal with every layer of the TCP/IP stack. If multiple microservices are present on the same system or network, the local or private network call can be made respectively, which are fast but still consume your bandwidth, memory and compute power.
Then what does it mean, should we take a step back and go for monolith one instead. Well not exactly, it’s about making the right choice. For example, if it’s going to be a simple service with database calls and just business logic then hands down go for monolith service. But if things get complicated like having service run complex data processing and predictions logic then for such you can have dedicated servers with the right scaling, this will be one microservice and the rest of the business logic another.
Pattern Language is the way to go
If you must implement a microservice then it’s very important to understand the projects design pattern and plan your microservices accordingly. This is where pattern language appears in the picture.
A pattern language is a compilation of patterns that each represent a problem and a solution that may be used in a variety of ways within a certain field of expertise. The microservice architecture pattern language is a set of patterns that can be used to implement the entire microservice.
Confused???
Let’s make it simple. So let’s say we want to create a project for a video streaming platform. Then as a low-level microservice setup, we can implement a set of streaming service, a user management service, a content management service and a data analysis service. In this design, we have created services that themselves act as a monolith service meant for a single purpose but coming together can become a microservice that is easily scalable as a long term solution.
On a more high level, we can evaluate the design pattern on the application as well as infrastructure level to understand the interdependency of the services.
You can use the pattern language to see if microservices are a good fit for your application and therefore helps you to properly implement the microservice architecture.
What about a hybrid approach?
As the name states a hybrid approach is not a pure microservice nor monolith but rather a combination of both, similar to our earlier video streaming example. Some aspects of the platform are monolithic, while the remainder is based on microservices or even macro services in hybrid architectures.
You can come up with a combination of different services based on your requirements and design pattern evaluation. Hybrid architecture is not limited to just microservice and monoliths. You can throw in macro and mini services, as well as cloud and SAAS services, but make sure the architecture doesn’t let you down later.
Conclusion
I love microservice as I have been implementing them for a while now. They fix intricacies and improve performance and even costs when employed in the proper context and for the relevant reasons. However, they should not be used as the sole solution to all problems because they can be quite difficult to manage in the long run.
The philosophy is simple; choose the best design strategy for the software and your users, whether it’s monolith services, microservices or a hybrid one.
