The term ‘API governance’ often brings with it the feeling of dread combined with heavy processes that slow down the delivery process. However, this doesn’t have to be the case. Instead, API governance is a tool used to prevent current and future problems with your API program. Let’s take a look at three scenarios that show how API instability, poor scalability, and security vulnerabilities were addressed through lightweight governance and an effective API management platform.
Overcoming API instability with lightweight governance
It is important to ensure your API remains stable across releases. Customers don’t want to be forced to make code changes because of a modification to your API design. Worse, they don’t want to wake up to alerts that their code is failing, only to find out that it is your fault for introducing a breaking change in your latest API release.
This was the case for one API provider. They consistently introduced breaking changes, forcing customers to update their code every time this happened. As the problem persisted, they saw customer churn as they left frustrated, seeking out a more stable option.
To address this issue, they introduced a lightweight governance process. This process addressed a simple step to perform automated and manual reviews of API design changes to prevent introducing instability with each new release.
They also introduced the concept of an API stability contract, allowing them to offer previews of their API changes prior to release into production. You can read more about this in our article, Tyk tips limit breaking changes.
These steps, combined with a style guide to encourage consistent API design, helped them to improve their release process and decrease customer churn over time. While the ramifications of their early choices are still being felt, they are now on the road to recovery.
Addressing scalability problems
Part of the API design process includes planning for scale. While not all APIs will require processing a very large number of requests per second, knowing your expected and maximum requests/second is crucial.
If the API will be used rarely or only during peak hours, infrastructure can be provisioned to account for this to reduce cloud spend. If the API will be required to service a large load, appropriate code optimisations and infrastructure budget should be known ahead of time.
A large financial institution was faced with this problem. They created several microservices that were all orchestrated from a single API. Once completed, they realised that each microservice would require between 2 and 5 seconds per request. Digging deeper, they realised that each of the microservices were called in order, resulting in a 10-25 second response time per API request. Not exactly scalable, especially for the needs of a financial institution.
By implementing some basic SLA metrics that were incorporated into their API gateway configuration, they could be alerted to decreases in API performance. They also incorporated performance testing as a requirement prior to each production release. This ensures that every API is benchmarked and evaluated before its release.
Addressing security vulnerabilities
API governance is commonly associated with creating a more consistent API design, typically through API style guides and design review processes. It is also used to ensure proper security risk assessment, but only if the process is implemented effectively.
One example of this is a large organisation with a few renegade teams that opted to circumvent a security review. The result was many unsecured APIs that were identified during an audit. Thankfully, the APIs didn’t release sensitive data. However, the team was forced to make considerable changes to comply with proper security practices.
They decided to implement a few measures to prevent this in the future as part of an expanded API governance process. This included sign-off by one of the security teams before approval into production. Additionally, automated checks were implemented to detect externally-facing deployments that have not been approved. Finally, role-based access control (RBAC) was added as part of the API design review process to ensure proper configuration and enforcement via the API gateway.
Effective API governance
API governance doesn’t have to be a heavy-handed solution. Instead, it should be viewed as a tool that can be used to create consistency and prevent issues with your APIs. Effective API governance should reflect the many choices that have been made to encourage consistent design-time and run-time API concerns. Combined with automation and self-service features, an API governance program can help organisations to design and deliver the right APIs in a consistent manner.