Jenkins is dead (for K8S CD)

itielshwartz profile image Itiel shwartz ・4 min read

Komodor close beta now live!

The dream

Our world of dev and ops is changing. Building and shipping software has become increasingly “easy” thanks to the revolution led by the Cloud, Docker and k8s. Companies are breaking off their “outdated” monolithics apps in exchange for microservice architecture in order to ship their products faster than ever. “Move fast and break things” has become the motto of this new era.

The reality

As microservices adoption is increasing, people start seeing the cracks in this utopian world: microservices are hard to design correctly, hard to test and debug and deploying them requires a substantial operational knowledge. What starts as a “quick win” turns into a bloody fight in order to sync the dependency between those microservices.

We identified three main pain points that most companies share:

  1. Build all microservices using the same practices (deploy process, tests etc)
  2. Deploy it with industry’s best practices (e.g. Canary, Green/Blue)
  3. Test and validate deployed app. Rollback / rollforward if problems were found


Our goal at Komodor is to help you achieve a great deployment process, with a minimal effort. Our platform is focused on three pillars:

  1. Before deploying - we help you create your deployment pipelines using a reusable python-based building blocks. It includes industry’s best practices baked-in such as Canary release, Dry run checks and beyond. It offers a simple way to create the right pipeline for your organization and to reuse it across teams, repositories and microservices.
  2. **While deploying - **we run the deployment workflow for you using Argo. We monitor each part in your deployment process by integrating with existing tools like Datadog, New relic, Sentry, etc. We also support automated rollbacks out of the box (no service mesh needed).
  3. **After deploying - **we provide a clear view of which current microservices are deployed, their version and relevant audit trail (who deployed them, when and why). You can easily view what are the differences between different versions, and in case of emergency there is a one-click rollback option. \

We also offer your team an easy way to start a new deployment, via a UI or simple API calls.

Why do we need a CD tool (And not use my CI)?

While interviewing dozens of companies we learned that most of them used their CI tool in order to deploy their system. This may work for a small team, but once you have multiple microservices (and repos) managing the sync process between those microservice and deployment becomes impossible. Here’s where a CI tool comes short:

  1. **Before deploying: **Code reuse is not possible. CI system uses YAML as the main building bloc (unlike the python offered by komodor). You can’t reuse code both inside the same workflow, and between projects. CI building block are just a general place ro run scripts. They don’t know what deployment is or what k8s clusters are.
  2. While deploying: They just sync. A CI deployment is basically to run a single command (helm install, or kubectl apply). It doesn’t validate or test the deployment status afterwards. It doesn't integrate into tools such as Datadog, Sentry, etc to make sure our system is safe & healthy, and your customers are happy.
  3. After deployment: You don’t have any visibility to which of the services are deployed, when ,and by whom. CI doesn’t provide tools for rollback in case of problems (and we all know, there will always be some problems).

I think it’s obvious that by now we established that CI tools can “handle” the deployment for you, but it’s just not the right tool for the job.

Why not gitops?

GitOps is a way to do Kubernetes cluster management and application delivery. It works by using Git as a single source of truth for declarative infrastructure and applications.” weave.works

Gitops is a great solution for teams with a simple pipeline. Here at Komodor we also support this model. The main problem with gitops is that it over simplify the true state of your system. The deployment process takes time (we deploy, we test, we use canary or blue/green) the “single source of truth” is just not representing the current state. Gitops in it’s core simply sync between cluster and git. The deployment is a lot more than that.

Why not Spinnaker?

Spinnaker is the de-facto standard of smart deployment. We think it’s a great tool and we took a lot of our core ideas from using Spinnaker.

BUT spinnaker is hard. The amount of time and resources a team needs to spend in order to integrate and manage Spinnaker is enormous. Another shortcoming of Spinnaker is that it doesn't come with “batteries”. I.e. you need to figure out what’s the best practices and try to write them down yourself. Komodor offers best-practices templates to get you up and running in no time.

So what now?

Our mission is to help R&D team’s to regain control of their deployment process. We just started our closed beta. We invite you all to come and join us!

Posted on by:


markdown guide

You mention that CI tools don't validate or test the deployment status afterwards. But, don't Jenkins pipelines often have a step that tests the deployment? Sometimes pretty good integration tests are run in one namespace, and then the deployment is done to another namespace in a subsequent step.