Introduction

Microservices architecture along with DevOps tools gave a new perspective to software development by the integration of development, management, and operations. In DevOps practice, it can be challenging to know which tools/technologies should be used to manage microservices in your team. We have put together a set of tools/technologies to help you decide on which tools should be part of your stack to manage microservices via DevOps.

Before we talk about tools/technologies, let us briefly talk about a couple of architecture styles used to develop software. Monolith architecture is described as a single software application in which different components are combined into a single application from a single platform. Microservices architecture is an approach to application development in which a large application is built as a suite of modular services.

A few challenges of microservices architecture can be taken care of using Netflix OSS stack.

Both architectures have their benefits and challenges, selecting one would depend on project requirements. Let’s see a few challenges of microservices architecture and how they can be taken care of using Netflix OSS stack:

Fig 1. Microservices Challenges and Netflix OSS Solution with ELK Stack for Java-based Microservices

Netflix OSS is for Java stack mostly. They’re sets of libraries/configurations that need to be included in your all Java application along with the business logic. This is a challenge with Netflix, as a developer, you need to focus both on the actual business logic of the application and the Netflix library configurations in every microservice which you want to manage.

Similarly, all software tools/technologies have their benefits and challenges and for that reason, we make use of different tool stacks to overcome the challenges. We have mentioned a list of most widely used tools, you could use the same or it is completely possible to replace them with other alternatives which we will discuss at the end.

Tools and Technology Stack to Manage Microservices

Selecting a tool is always challenging and time-consuming. Before selecting any new tool/technologies always put across the following questions for yourself/team:

• What are the challenges of existing tools/technologies being used in the team?
• Why does the team need these new tools/technology?
• How will this new tool/technology benefit the team?
• What are the challenges of this new tool/technology?
• When/Where can we use this new tool/technology in the existing technology stack?

Fig 2. Technology Stack with Benefits and Challenges

• If we have a monolith application, we can decompose it to microservices by following the strangler pattern.
• Microservices give us few benefits but also have challenges such as service discovery and slower deployments.
• Dockerizing (containerization) microservices helps us with faster deployments and start-up time, but there is no health-checks/auto-restart mechanism for stopped containers.
• Orchestrating the containers provides benefits such as health-checks, auto-restart, and auto-scaling containers/pods.
• PaaS platforms help us by providing many out-of-the-box features along with the underlying infrastructure.
• Finally, we can manage the microservices/APIs either using an API gateway or service mesh.

We can use Docker containers and Kubernetes for containerizing and orchestrating microservices. These are two separate tools, if you are looking for a single tool/product which can handle both containerization and orchestration then you can make use of Openshift, which is a combination of Docker containers and Kubernetes. After using Openshift we still need to manage the APIs (Microservices Interactions) which can be done through an additional API gateway/management tool or using a service mesh like Istio. Istio also handles more complex operational requirements such as canary release, rate limiting, telemetry, service discovery, routing, circuit-breaker, tracing, and failure recovery. What makes Istio so unique is that all these functionalities come with almost no change of application code required. Well, to be honest, most of these features do not require any code change except tracing and circuit breaker where we need to add some configuration to our application.

A brief introduction to the tools used in the above figure:

• Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package an application with all of the parts it needs, such as libraries and other dependencies, and deploy it as one package.
• Kubernetes is an open-source container orchestration system for automating application deployment, scaling, and management.
• OpenShift PaaS platform is a combination of Kubernetes and Docker clusters. The architecture of OpenShift is designed in such a way that it can support and manage Docker containers, which are hosted on top of all the layers using Kubernetes.
• Istio reduces the complexity of managing microservices deployments by providing a uniform way to secure, connect, and monitor microservices.

In the DevOps tools and IT universe, we have plenty of tools to choose from and it is not mandatory to stick with the above stack. Let us look at a few other alternatives,

Conclusion

Selecting the right tool takes time because a lot of things such as functionality, license, benefits, and challenges need to be considered. It is always recommended to first understand the existing tech stack challenges and then research for an appropriate tool that would suit the team’s requirements by weighing the benefits/challenges. In the end, it all boils down to the team’s needs and goals.