There is a growing need to expose services via APIs, both internally in organizations as well as externally to customers and suppliers. This creates the need to ensure a consistent way to develop, expose, document and maintain APIs between development teams.
Many of the challenges when exposing API's can be solved by the concepts from DevOps. In DevOps, automation plays a major role, which involves the use of CI and CD pipelines, focusing on Infrastructure as Code. This mindset for API development is called APIOps.
This blog describes our experience with APIOps and the benefits of this approach. Both in general and specifically using Azure API Management and Azure DevOps as the technical foundation.
For managing APIs, Microsoft has developed the Azure API Management (APIM) platform. The platform is designed to help deal with the issues that come with exposing APIs. Azure APIM can e.g. help with the following:
A portal with an overview of all APIs exposed on the platform
Cloud-agnostic, so that APIs exposed by Azure APIM can be hosted by any cloud-service or on-premises
Supports an API-first approach on development
Monitoring and logging of APIs
Security standards for all APIs
Authentication and authorization
Gathering different APIs in one Azure APIM instance enables a standardized and consistent security across APIs. Thus, you only need to implement these things once, and make sure that all APIs have the same standards, as opposed to different teams implementing it in different ways.
Azure APIM consists of two main parts. A developer portal and a gateway.
The developer portal is the user interface on which the consumers of APIs can view and, find new APIs and subscribe to them. The developer portal also allows you to test APIs directly in the browser. Some APIs can be set up to ask for authentication before they can be used, or to be invisible, depending on the user's access.
The gateway is the end point all consumers of APIs on the platform must hit. The gateway retrieves the APIs from the Management Plane where criterias such as policies may have been defined. Through policies, you can e.g. define throttling and validation of requests, so that you secure yourself against getting malicious requests through to your backend after validation. The gateway then forwards the request to the backend.
APIOps merges the concepts DevOps and GitOps and uses them to facilitate the development, testing and deployment of APIs. By automating and using Infrastructure As Code (IaC) principles, APIOps enables:
To ensure faster, easier and more secure API delivery
Facilitates having multi-tenancy on an APIM platform
Increase the quality of APIs through automated testing by validation, linting and breaking change detection, documentation requirements etc.
If we combine these benefits with the benefits which Azure APIM provides, then we get APIs which are both compliant, functional, and easy to find. This is the essence of what a well-functioning API should be able to as also described by Melissa Van Der Hecht here.
To achieve APIOps with Azure APIM, you must control governance as well as your infrastructure. This is done by using version control and IaC. This means that all changes which need to be made to an APIM instance, such as deploying a new API or updating an API, are handled with Git and pipelines in Azure DevOps, rather than a manual change via the Azure portal.
All changes can be managed through pull request towards the branch that represents the current configuration of the API which has been deployed. By using pull request, it’s possible to configure rules, e.g., validation and linting, which must be followed before the pull request can be completed and merged. Once the rules are followed, the merge can be completed whereafter the API is automatically deployed via Azure DevOps. By using IaC we make sure that we always use the same policies, the right authentication methods, etc. when we release an API.
Deployment of the APIM platform itself is also done using IaC, which makes it easy to have multiple environments, e.g., developer testing, consumer testing and production environments. Deployment to the different environments can be managed through different branches and pipelines. This enables a quick and easy development process for the API developers.
Azure APIM is not designed with multi-tenancy. Therefore, it’s more likely that you have an APIM per. team, which quickly becomes expensive, as APIM is an expensive resource. Microsoft has made their own proposal for how this kind of multi-tenancy system might look, which can be seen in the picture above.
Microsoft's approach is based on API developers being able to build an API template based on their API Spec or their own APIM instance. In cVation, we have a slightly different approach to multi-tenancy than the one proposed by Microsoft.
Instead, our approach has been to climb an abstraction level higher. This way, API developers first and foremost avoid having to understand and design policies and API resource schemas and simply need to define an API spec. At the same time, it allows us to offer some out-of-the-box features, to guarantee consistency and control of what an API looks like.
The abstraction has allowed the APIM instance and the APIs to be deployed separately from their respective repositories. In this way, we can give the API developers full autonomy within the organization's rules and guidelines. All repositories deploy to the same APIM instance, using IaC, version control and our rules, which ensures all APIs will be deployed in the same way.
If you are used to working according to the DevOps principles you can transfer the methods to APIs and advantageously combine it with Azure API Management. This way you reach the finishing line easily and get all the benefits of APIOps no matter what kind of organization you work with.
One must however pay special attention on how to handle the multi-tenancy part as described, as the choice has great impact on the cost of the solution.