Applying DevOps to API Development for APIOps

While working on establishing short- and long-term goals with a client, my focus was establishing horizon two and three objectives in the McKinsey Three Horizons Model.

For those who are not aware of this framework, horizons two and three focus on new and next-generation features and functionality. At the top of my priorities list for this project was the adoption of an API gateway.

While building on my existing knowledge of Kong Gateway, “APIOps: End-to-End Automation Throughout the API Lifecycle” caught my eye. This was the first time I had seen the term “APIOps,” and I needed to understand more—especially for my role as a technical architect for a complex service tier.

My takeaway is that APIOps can be summarized as follows:

1. APIOps = DevOps + GitOps applied to the microservice tier.
2. Heavily leverages a specification, like OpenAPI, to define APIs early in the process.
3. Introduces a faster turnaround time from start to finish.
4. Promises quality improvements with APIs being produced.

From a feature team perspective, I quickly understood how APIOps could help my team of service-tier developers make positive strides. However, this exercise made me really want to understand how the adoption of an API gateway impacts DevOps—since DevOps is where the rubber meets the road.

For this exercise, I need to visualize APIOps from a DevOps perspective and focus on these core concepts:

• Design and Testing
• Deployment
• Maintenance

Establishing the Design

In 2021, I wrote two publications that illustrated the value an API gateway can bring to projects and teams offering APIs for consumption:

• How I Stopped Coding Repetitive Service Components with Kong
• Breaking Up a Monolithic Database with Kong

Since Kong Gateway is an open-source solution, I feel like incorporating Kong’s tools in my exploration is ideal. The fact that Kong provides the underlying API technology for a who’s who list of technology leaders (Cisco, GlaxoSmithKline, Honeywell, PayPal, Nasdaq, Samsung) further backs my decision.

Let’s assume the following design:

1. Use OpenAPI to introduce standards-driven contracts in Insomnia.
2. Kong Konnect will serve as the service hub for API consumers.
3. Kong Gateway will centralize common aspects shared across microservices.

Consider the following illustration which documents my approach:

In this flow, API developers will initially focus on creating their designs using the standards-driven OpenAPI specification with Insomnia. This step occurs before any program code is written. The resulting artifact serves as a contract that will reside in the service hub—available for discovery by those seeking API services.

When a published API is selected for use, every request for that API passes through the API gateway to utilize any shared components (like authentication, logging, rate-limiting, and security). Finally, the request is forwarded to the laser-focused microservice dedicated to handling the distinct functionality.

As a result of this approach, a completely DRY (don’t repeat yourself) design will exist from API inception to API management. This is great for both service-tier developers authoring APIs and feature team developers consuming those APIs. But what about the DevOps engineers supplementing these teams?

APIOps and DevOps Adoption

When introducing new API designs, the impact on DevOps engineers is often forgotten. DevOps engineers need to understand and support this design to guarantee the project’s success.

Fortunately, the tools from Kong can leverage a declarative approach, storing all aspects of the services and configuration in a git-based repository. Successful designs do not stop there since the testing, deployment, and maintenance aspects are just as crucial as the declarative design.

Let’s dive in to understand how Kong makes applying DevOps to API development easy.

Design and Testing

Insomnia is far more than just an HTTP client and an OpenAPI (YAML) editor. It can validate, debug, and test new API designs before deploying to Kong Konnect. For this reason, Insomnia should be considered just as important to service-tier developers as their primary IDE used for creating the actual service API.

API designers can apply the following flow with Insomnia to introduce standards-based services:

The Speed-Review API Specifications with Insomnia article from Kong works through every step of this flow, including the use of Insomnia to push code to the Kong Konnect ServiceHub.

Deployment

From a DevOps perspective, these same artifacts can be part of automated continuous integration (CI) processing by utilizing Inso, which is a command-line version of Insomnia.

Below is an illustration demonstrating how Inso can perform automated tasks as part of the CI pipeline residing in a git-based repository:

The Introduction to Inso CLI documentation is an excellent way to get up to speed on using Inso with existing CI/CD pipelines.

Maintaining

At the API gateway level, Kong provides a declarative configuration tool (called decK) to update configurations, including cross-cutting updates across all published APIs running on Kong Gateway. The decK flow is illustrated below:

The Automating Your Developer Pipeline With APIOps post from Kong provides step-by-step procedures for maintaining APIs using CI/CD pipelines.

For example, we can use decK to modify a common rate-limiting component across APIs to meet business needs after an API has been published. The flow above allows the existing configuration to be pulled down for analysis, which can be updated and then deployed back into the API gateway handling the component. Aside from the git-based updates required to make the modification, the remaining process flow can be part of a CI/CD pipeline.

Conclusion

DevOps is where the rubber meets the road. This means that feature teams and service-tier developers can experiment and architect solutions. However, those solutions are prone to failure if DevOps cannot successfully deploy them.

The team at Kong not only provides an excellent product suite that interacts with every phase of API development, but they also provide the necessary tooling to validate, deploy, and maintain those APIs. Even more impressive is the ability to function at a declarative and git-based level, adhering to pipeline-driven approaches that DevOps engineers continue to recommend.

Since last year, I have been trying to live by the following mission statement, which I feel can apply to any IT professional:

“Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

• J. Vester

Kong certainly adheres to my personal mission statement via its commitment to making APIOps a realistic option. Since the inception of the Kong product suite, both declarative design and DevOps integration have always been key focus areas.

Failure to recognize these unwritten requirements will likely create consequences such as stale API specifications, dependency on manual processes, and duplication across the API lifecycle. Any chosen solution should ensure these challenges are accounted for throughout the API lifecycle.

Have a really great day!