Infrastructure-as-Code series - Kong: APIOps is IaC for APIs
The Computer Weekly Developer Network (CWDN) continues its Infrastructure-as-Code (IaC) series of technical analysis discussions to uncover what this layer of the global IT fabric really means, how it integrates with the current push to orchestrate increasingly cloud-native systems more efficiently and what it means for software application development professionals now looking to take advantage of its core technology proposition.
This post is by Melissa van der Hecht, field CTO, EMEA, Kong
Straight into the core of the subject, van der Hecht writes as follows…
As every business becomes a [software-centric data-driven] technology business (think EdTech, FashionTech, AnythingYouLikeTech…) they are all on a journey to become engineering-led, adopting modern engineering principles in every domain and every workflow.
At the top of the stack, movements like DevOps have revolutionised the way we build applications, giving us faster ways of building and deploying code and better end user experiences.
At the bottom of the stack, IaC gives us automated ways to provision and manage the infrastructure upon which everything runs. However, to become truly engineering-led, we must apply these engineering-led principles to every part of the stack.
APIs sit squarely in the middle.
Liberating data to be used at the front-end and connecting experiences across different infrastructures. APIs are a layer of abstraction between an application at the front-end and the data at the back-end – they form the building blocks of every user experience. If we don’t manage our APIs in equally modern ways, then this invisible, infrastructure-level technology becomes the limiting factor to overall modernisation.
APIOps is the IaC for APIs
I would like to tell you that APIOps is the IaC for APIs
When we say this, we are saying that by combining core DevOps and GitOps philosophies, it enables us to be declarative when provisioning and managing gateways as well as automating the end-to-end API lifecycle.
At the heart of IaC is the concept of declarative configuration: files, stored in version control, that specify what an environment should look like rather than how that setup is achieved. The same is true for APIOps. Declarative config files describe how an API gateway needs to look in order for the APIs it manages to be secured, discoverable and documented – one simple file that the gateway uses to automate its own setup and configuration; a file stored in version control so every deployment is repeatable, auditable, and can easily be rolled back in the event of a problem.
It’s not just the lifecycle of the gateway that can be automated like this; it’s also the lifecycle of each API registered within it. To properly manage APIs, we must treat them like products with their own lifecycle, from design, to build, test, deploy, secure, publish and ultimately to versioning or retirement. If we miss these API best practices, then our APIs end up inconsistent, hard to use and reuse… and can even present security risks, but traditionally it has been a cumbersome process to ensure compliance to standards.
This is where things get interesting: by applying the principles of IaC to the API lifecycle, we can remove this pain.
The design of the API, typically an OAS document, is thought of as the contract for the API functionality.
Melissa van der Hecht
It tells consumers of the API what the API will do and tells builders of the API what they should build. If everyone agrees to the contract, then everything works nicely together. APIOps takes this one step further: the contract also tells operators what should be deployed and gateways that support APIOps will generate the declarative configuration file for an API automatically from that contract.
Like with GitOps, once the person building the API has passed their local testing, they push their code into their version control system of choice by raising a new Pull Request (PR). This triggers a series of automated checks to ensure the new API complies with best practice. This delivers two benefits: speed, because these tests are automated, and quality, because they’re run on every API, catching any deviations from standards.
These capabilities are enabled through an APIOps CLI, called programmatically by your CI tool on each PR:
$ apiops-cli lint spec
$ apiops-cli run tests
Once the tests have passed and the API is ready for deployment, the CLI is used to automatically generate the declarative config for the API. To carry out the deployment, our CI tool tells the gateway to sync itself with the state described in the file:
$ apiops-cli generate config
$ apiops-cli sync gateway
In this APIOps model, the lifecycle, including deployment, is driven by config files and a version control system. Like IaC, this removes the chance of human error and ensures automated, repeatable testing and deployments: critical for infrastructure-level technologies and something as relied upon as APIs.
After all, what’s the point in managing our infrastructure declaratively if everything inside it still follows old processes?