Part 2: How Dynatrace and GitHub help you deliver better software faster –

In part one of this series, I talked through the common pain points software delivery teams face as they’re asked to support cloud adoption and modernization initiatives. Part one also provided an overview of Dynatrace’s Cloud Automation solution, Microsoft’s GitHub Actions, and open-source examples you can use and extend related to deployment and release monitoring.
This blog continues with more examples of Dynatrace’s Monitoring as Code (Monaco) and Service Level Objectives (SLOs) release validation using Dynatrace SaaS Cloud Automation. For orientation on the use cases in this blog series, refer to the picture below.
The 2021 State of DevOps report found successful organizations enable application teams to set up and configure monitoring and alerting through self-service capabilities, removing the need for manual work from teams responsible for monitoring. Without such rules, configuring your environments can result in chaos, with losses in flexibility, speed, and stability.
The Dynatrace configuration API, helps many Dynatrace customers implement and gain the benefits of this best practice for their Dynatrace configurations such as alerting rules, synthetic scripts, dashboards, and SLO monitors. The Dynatrace configuration API helps customers keep track and manage Dynatrace monitoring environment configurations through GET, ADD, UPDATE, DELETE endpoints for each type of configuration.
Since collections of configurations are typically required for multiple Dynatrace environments, Dynatrace has developed the Monaco toolset to help manage and execute the various configuration files within a project structure. Monaco is implemented as a Command Line Interface (CLI) utility. This CLI extracts a specified Dynatrace environment and project folder containing the collection of Dynatrace configuration files and then it will use these files for the payloads when it calls the Dynatrace configuration API to update the Dynatrace configuration.
Below is a picture illustrating the use case of using Monaco as part of a code delivery pipeline.
To automate Monaco within code delivery pipelines, the Dynatrace team has created an open-source container image with the Dynatrace’s Monaco called the “Monaco Runner“, which is added as a GitHub Action since container images can be run natively by GitHub as part of an Action workflow.
The GitHub action workflow called “Dynatrace Monitoring as Code” pipeline has this logic and actions:
The image below also refers to this example.
Monaco brings DevOps teams a self-service model for establishing monitoring so they can focus more time on building business services, as described in more detail in this blog post. Monaco also fits to the GitOps process and mindset – where one describes the desired state of the whole system using a declarative specification for each environment.
Since 2019, Dynatrace has been leading the development of an open-source initiative called Keptn to help organizations adopt cloud-native concepts for their cutting-edge microservice applications and application modernization initiatives.
Keptn eliminates the need for organizations to custom code scripts that tie together different DevOps tools of choice for delivery and operational automation. Keptn solves the custom tool integration dilemma through an open standard communication protocol-driven through the Continuous Delivery Foundation (CDF). Keptn also automates orchestration decisions through the core project capability of evaluating SLOs between every automation sequence task.
This main use case – automated release evaluation – has also been widely adopted as a capability known as “Quality Gates” which integrates seamlessly into existing continuous delivery automation – adding data-driven decisions without manual coding for new software builds and releases.
To understand the setup for Quality Gates, refer to the picture below. On the left are the set of specific metrics to be collected, known as Service level indicators (SLIs). On the right, are the SLOs that define the pass, fail, and warning criteria for each SLI. SLIs can come from any data provider. As described earlier for monitoring configuration, these SLI and SLO configurations are also checked into a code repo using this declarative specification for each environment and service.
If the SLI metrics provider is Dynatrace, SLIs and SLOs can also be configured within a custom Dynatrace dashboard versus having to manage the individual files. When the SLO evaluation is requested, the Cloud Automation service simply reads the SLOs and SLIs that were defined within the dashboard. This approach provides the benefit of having a dashboard that’s in sync with the SLO automation.
Below is an example that shows a Dynatrace dashboard and SLO evaluation results.
A “Quality Gate” evaluation can be triggered via the Keptn API or the binary. Once triggered, the SLO evaluation service first gathers each SLI actual value, compares them against their targets, and finally aggregates them into a total SLO score. The resulting score is used to determine a pass/fail to allow or to stop the promotion of a release.
To make it easy to integrate the SLO evaluation request into GitHub workflows you can start with an open-source container image, called Keptn Automation, which calls the Keptn CLI. This is the same approach described above for the “Monaco Runner“.
The image below demonstrates this example GitHub action workflow called the “SLO evaluation” pipeline and is carried out through these actions:
The Keptn SLO evaluation in the previous example has the few pre-requisites.
This second set of steps onboard a service and when the service SLI processing rules change.
The good news is these steps can be easily automated and leveraged by multiple teams by using the same open-source GitHub Action, Keptn Automation, described in the previous section.
The “Keptn Automation” GitHub action is simply a Docker container image containing the Keptn CLI and set of Unix bash scripts that have the logic to call the Keptn CLI for these use cases:
If there’s a new version of the Keptn CLI, users simply update and rebuild the Docker container.
Call the following set of Keptn CLI commands to “Onboard a Keptn service”. Refer to the image below for this example GitHub action workflow to onboard a service.
All the examples shared in this blog post are available as open-source and demoed on Microsoft DevRadio, so be sure to try them in your environment and let us know how you get on.
As mentioned earlier in this blog, Keptn is embedded into the Dynatrace Platform and offered commercially for customers to use within our Cloud Automation module and any of the examples from this blog work with either open source Keptn or the Dynatrace Cloud Automation module.
We’d love to hear your feedback on how combination of GitHub Actions and Dynatrace helps you to:
Dynatrace Inc. published this content on 29 September 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 29 September 2021 10:41:10 UTC.