It is common to think about one tool versus another. Indeed, many vendors and other open source projects have such a page / table on their websites. The phrase “keptn vs.” may have brought you from a search engine to this page. However, when dealing with Keptn, that mindset is not helpful or accurate.
Rather than “Keptn vs. …” think “Keptn and …”
While Keptn includes some default services (Helm, JMeter and Webhook services), usage of these tools is not mandatory. They can be easily swapped for tooling you prefer.
Keptn is designed to be tool and vendor agnostic. Keptn orchestrates and executes any tooling that you choose. Tools, which Keptn calls “integrations”, are triggered via CloudEvents. This is an open specification for describing event data, and Keptn provides its own event specification based on it. It allows for interoperability and any kinds of integrations in the Keptn ecosystem.
Keptn’s shipyard file is the blueprint for your Keptn environment. While it may look like a pipeline, nowhere does it mention the tooling used to action each task. This is deliberate and by design. It is this factor that allows hot-swapping of tools.
Consider this stub of a shipyard file:
- name: "dev"
- name: "delivery"
- name: "deployment"
- name: "test"
- name: "evaluation"
- name: "release"
In this shipyard file, we can guess that, when we trigger the
delivery sequence in the
deployment task will be executed.
But nowhere does the shipyard define what tool performs this task.
This is the flexibility of Keptn!
Keptn distributes an
and your chosen tool simply listens for and reacts to that event.
Want to swap deployment tool? Easy - just remove the subscription for the original tool, install the new service and configure it to listen for the task instead.
So… out-of-the-box, which tools listen for the tasks above?
You are not restricted to these task names. Define whatever task names you need to implement your custom sequences.
Let’s have a look at some comparisons between popular tooling.
At first glance, a Keptn sequence as expressed in the shipyard file looks a lot like a pipeline. But you are in full control of which tools execute for each task.
deployment.triggered task and run an entire pipeline in response.
The sequence is identical but the two teams are empowered to use different tooling.
Out-of-the box, Keptn includes the JMeter service that listens for the
Prefer a different load testing tool?
Uninstall the Jmeter Service and install a service that listens for the
test.triggered event and you are done.
Keptn uses observability tools (more generally, tools that provide metrics)
as the data source for monitoring during the
evaluation task is an out-of-the-box Keptn feature
that provides a quality gate.
This quality gate can work with any metric from any tool.
During creation of a Keptn project,
Keptn is configured to know which backend metric provider it should use for this particular project.
For example, Prometheus may be chosen as the metric store.
You will also be required to install the relevant service
which listens for the
During the evaluation task, Keptn automatically issues a
Your metric provider then reacts and retrieves metrics from the backend of your choice.
After all, the Prometheus Service should know how to retrieve Prometheus metrics!
Just like any other Keptn service, if you want to change the monitoring provider, simply uninstall the existing service (eg. Prometheus service) and install the new service (eg. Dynatrace service). Now quality gate metrics will be retrieved from Dynatrace and not Prometheus.
Keptn comes pre-installed with services for:
All other existing Keptn integrations are listed on the Integrations page.
Don’t see your tool listed? You have three options:
Use the Webhook service to trigger your tool
Use the Job Executor Service to run your container or script
Develop a custom Keptn service:
More details are provided at the bottom of the Integrations page.
Want to try out Keptn? Head to the Keptn Quick Start page to begin.