Should you adopt a microservices based architecture for your software product?

Microservices have been around for some time now but have recently once again gained a lot of momentum in becoming the preferred way software products and applications are being built. A lot of the recent surge in its trend has to do with the rise of serverless computing which makes infrastructure management a thing of the past and allows software engineers to focus on building the core functionality of the product. Since serverless infrastructure and architectures are microservices-based by default, it has helped fuel the fire. This is all a good thing, as microservices have proven to be the superior way to build scalable & maintainable applications. Let’s understand why that is the case by diving into some of their features.

Easier to build and maintain

We touched on it briefly in the introduction, but it is worth taking a closer look as to why it is easier to build and maintain large applications by adopting a microservices-based approach. Each feature of the application and the functions within that feature are written in isolation from one another. Their fixed scope makes it easier to spec, write and test the code without having to rely on the rest of the application’s state. They are also easier to host and maintain as microservices can run inside their own containers which comprise of all the required libraries, runtimes and dependencies that the service needs. It is an all-encompassing container which can run the services within it without any needing any further intervention or knowledge from entities outside it. This also helps reduce risk as if the container goes down, only that microservice (or services) hosting within the container will be offline, allowing the rest of the product to continue without it (if it is not a critical component).

Better scalability

Since these microservices are hosted within several containers, it allows the infrastructure to scale a lot better as well. Different areas of the application will have different workloads based on their scope and business logic. Smart orchestration layers can be implemented that allow spinning up new instances of containers that are experiencing heavy workloads, allowing the application to serve more users by only adding resources to the area of the infrastructure that requires it and not the entire stack (as would be the case in a monolithic application).

Use the best language and/or framework for the job

Another massive advantage of using a microservices based approach is that the services can be written in different languages and have their own unique stacks. This would not be possible in the case of a monolith as it would need to be consistent across the board. This enables engineers to build services using the best tool for the job, for example, a microservice that is focused on executing machine learning or data science tasks might be written in Python, whereas the rest of the services may be REST APIs written in NodeJS using the Express JS framework. This is entirely possible (and a common use-case) with a microservices based approach. The different services would simply have their own unique containers which would comprise of the runtimes and libraries needed to execute their code.

There are some drawbacks

Of course, as with everything in engineering, there are always trade-offs. Even though the features outlined above are quite compelling and are reasons that a vast majority of the major technology companies (Netflix, Uber, Amazon, Twitter) are adopting microservices, there are some potential pitfalls to keep in mind. The biggest one is that extra care has to be taken when coding and deploying microservices to ensure that communication between services is happening in a secure manner and only the required data/information is being transmit between them. Tokens, access rules and more, need to be implemented to ensure that only authorized parties are making requests to the services and receiving the response. Another drawback can be that deploying these microservices based architectures can be difficult and sometimes cumbersome. However, this is quickly becoming a thing of the past as tools such as Kubernetes, Google Firebase, AWS Lamba and more are bursting onto the scene.

Conclusion

In conclusion, it is safe to say that microservices are the way software engineering will be done for the foreseeable future when an application or product is being built at scale. The impact they have already had on the landscape cannot be overstated and with the rise of serverless computing, it is easier than ever before to build and deploy microservices.