The Taming Of Microservices

By making it easier than ever to add powerful new microservices, Kubernetes has become a driving force behind companies breaking up monolith apps and transforming them into microservice architectures. But as their numbers grow, the cost of managing microservices and the dependencies between them increase exponentially as well. This makes things more complicated than many companies have bargained for.

I recently spoke at a conference about the right way to build a cloud-native CI/CD to make managing microservices – well, manageable. I’m happy to share the highlights of my talk with you!

During the presentation, I first built and deployed a small app using Docker. Then, using a simple K8s deployment recipe, I took the app from my local computer and deployed it to our Kubernetes cluster.

Simple enough, right?

Move fast and break things!

Then, I decided to break the app into two microservices. Of course, once that is done, if you want to add functionality, the code needs to be changed in both of them. Naturally, in real-world scenarios, this might cause at least some existing behaviors to break.

Plus there is no clear way to indicate in plain vanilla Kubernetes if microservices are dependent on each other at the application level.

Now, imagine we’re talking about tens or hundreds of microservices, thus exponentially increasing the potential for faulty interactions between them.  To sharpen the issue even further, keep in mind that there is no easy way to test microservices before putting them into production. There’s also no version control for inter-microservice dependencies. So basically, we’ve created a system that is sure to fail!

Helm: Your new BFF

In this situation, Helm, a package manager for K8s, is your friend – in fact, it may just be your best friend.

Helm is important for many reasons. Out of these, one of the most notable is the fact Helm serves as an “abstraction template” for Kubernetes. It uses ‘charts’ to characterize and organize the files, reports, and releases for your microservices. You can also add external dependencies and efficiently deploy multiple services at once.

An umbrella ‘chart of charts’ serves as a single file containing all the microservices. It enables you to specify versions for each microservice and thus becomes a single source of truth for microservice versions. Additional supported capabilities include rollback to previous deployments and injection of different variables.

Getting the CI/CD pipeline right

Using Helm to standardize how you package and deploy each microservice, based on a single umbrella chart, allows your dev team to create a unified way of building services. It empowers them to move faster (and break things quicker) while still keeping the business on safe ground.

To learn more, about how Helm simplifies the CI/CD process, especially when used with a Jenkins shared library, check out the full presentation.‍