Why should you use microservices and containers?

What are microservices and containers?

First of all, what are microservices? Microservices is a type of architecture that splits your application into multiple services that does a fine-grained function that’s a part of your application as a whole. Each of your microservices will have a different logical function for your application. Microservices is a more modern approach in an application’s architecture compared to a monolithic architecture where all your application’s components and functions are in a single instance. You can refer to a comparison of a monolithic to a microservices architecture on the diagram below.

Where do we put our microservices? In containers. Containers are packages of your software that includes everything that it needs to run, like code, dependencies, libraries, binaries, and more. Docker is one of the popular choices for building and running containers, but Kubernetes is quickly becoming the defacto standard that is used to orchestrate multiple containers in enterprise environments. Compared to Virtual Machines, containers share the OS kernel instead of having a full copy of it – like making multiple VMs in a single host. Although it is possible to put your microservices in multiple VMs, containers are commonly used in this case since it takes up less space and is faster to boot up.

Why use a microservice architecture?

The microservices architecture was born to address the problems that people saw in a monolithic application. Microservices are already widely used and some large scale websites already transformed their monolithic app to microservices. Some benefits of using a microservices architecture are:

• Developers will work on a smaller codebase compared to a larger one in a monolithic app. When components of the application are loosely coupled, developers will easily understand the source code and not slow down development. Not to mention, your IDE will be faster if you’re working with a lesser number of lines of code. Developers will not need to deal with the complexities and dependencies of functions that can be found in a monolithic app.
• Responsibilities of the developers will be more defined. A team can be assigned by components or microservices of the app. Code reviews will be faster. Making updates will be quicker and there would be no need to build and deploy everything compared to a monolithic app.
• The application’s technology stack can differ through microservices. The application will no longer need to depend on one language or library. Microservices can leverage different programming languages as developers see fit. It is possible to have polyglot microservices like in the diagram below.
• Continuous Delivery will be easier. Compared to a monolithic app, with microservices, you will not need to deploy everything again for a simple change. You may choose to rebuild and deploy the only microservice that needs to be updated. Frequent updates will be faster.
• Scalability will be independent to each microservices. You can choose to scale each component of your app depending on the resource it needs. You wouldn’t need to make multiple instances of everything compared to a monolithic app. Scaling the microservices will efficiently use the resources available instead of having multiple copies of the whole application in a monolithic app.
• Data can be decentralized. You can choose to use different databases/storage for your microservices. You can choose a NoSQL database if your microservice suits it better than a relational database. A microservice may also only need a simple key-store database like Redis. Like in the diagram below, you can choose a combination of Cloudant, MySQL, and MongoDB. You can take advantage of different databases to store different data types.
• Isolate failures. An error or a bug in one microservice does not bring the entire system down. When you have loosely coupled components and a microservice in your application hangs or throws errors, there’s less chance that other microservices will be affected since they are in their own containers and don’t entirely depend on each other. A monolithic app can bring the entire process of your application down if the bug or error is not caught properly.

What are some drawbacks?

While using microservices solves some of the problems of a monolithic architecture, using them has its own set of problems. If you’re trying to split your monolithic application into microservices, the first challenge is on how to split them. You can choose to split them into business functions, such as one microservice to handle shipments and another microservice to handle payment services. In the end, your components should only have a small set of functions or responsibilities.

Some problems in a microservice architecture that I can see are:

• Once your number of microservices grow, it can be hard to keep track of them. Initially setting up Continuous Integration and Continuous Delivery can be hard as you’ll need to deal with the additional complexity of having these multiple microservices.
• Complexity. Microservices would need more coordination especially when multiple teams are involved. Microservices would also introduce more network calls in cases where it needs to interact with other microservices, which wouldn’t be present in a monolithic app. It wouldn’t be as simple as deploying one instance of an app. More things you will also need to consider are: how to handle the communication between microservices, handle errors to avoid disrupting other microservices, and add more test cases in each component.
• Finding and tracing the bugs/errors in your application. It would be easier to find if your microservice only has one route but if a microservice communicates with multiple other microservices, it can consume a lot of your time by just looking for that error.
• Routing your microservices will need more work. You’d need to spend time in configuring and controlling the flow of your microservices. You’ll also need to keep track of the versions of your microservices and deal with its routing.
• Microservices could consume more resources compared to a monolithic app. Although one of the pros I’ve mentioned is that scalability and resources can be utilized better and more efficiently, all the components would need its own instance and containers, potentially leading to more usage in memory and CPU.

Tools that can help you with microservices

Kubernetes

Kubernetes is a container orchestration platform that lets you deploy, scale, and manage all of your containers. It allows you to automate the deployment of your containerized microservices. This makes it easier to manage all of the components and microservices of your application. You’d want to learn Docker for containerizing your microservices. IBM has a public offering with the IBM Cloud Kubernetes Service that manages the cluster for you.

Istio

Istio addresses some of the drawbacks in microservices. Istio is a service mesh that further helps you in managing your microservices. Istio can be installed on top of Kubernetes, where it can help you in tracing and monitoring your microservices. This can also help you quickly trace the errors and bugs in your app if there are any. Istio can also manage the traffic of your microservices like managing and controlling the flow. Your routes can easily be configured. Istio also provides security within your microservices like having mutual TLS or limiting its access to external services. You can also install Istio onto the IBM Cloud Kubernetes Service.

Summary

In my experience, using a container orchestration platform is a must in building your application with microservices. Kubernetes is one of the popular choices by developers as it quickly brings their application from development to production. And, even better, it’s open source!

For developers who are starting to build their applications, they should decide whether it would be beneficial to them to use a microservices architecture rather than a monolithic one. They should consider the long-term usability and scalability of their application. It’s okay to start with a monolithic architecture, but once the application grows in size, it would only get harder to decompose them into microservices. In that case, it would be more beneficial to start off with microservices in the early development phase. For existing monolithic applications, developers should consider how and which components they would decouple in their application.

In spite of the drawbacks, microservices continue to be popular with developers and enterprises as it greatly benefits applications and users’ demands. With its flexibility, developers and enterprises can achieve rapid development or updates in their application once they have the right level of microservices.