APIops-Ervations: API Governance Lessons From the Field
Shifting to an API-first development approach means a whole new way of working for developers and operators. You evangelise the benefits of change and teams put in the effort to follow your documented standards and best practices, but once the initial enthusiasm has worn off, it's a real challenge to make this efficient and repeatable.
I've seen countless examples where it ends up resulting in a trade-off between achieving speed and following governance. In this session, we'll learn from these examples and see how an APIOps approach lets you achieve both at scale by automating the enforcement of governance at the beginning of the pipeline as well as the end.
Speakers
Melissa van der Hecht
Field CTO, EMEA
Kong Inc.
TRANSCRIPTION
[00:00:09] Hi, everyone. I’m Melissa, and I’m EMEA Field CTO at Kong. I’ve been here just under two years and before that about five at MuleSoft.
[00:00:18] So I’ve had the pleasure of working with and learning from companies of all shapes and sizes and at various points in their API programs or buzzwords–digital transformation journeys.
[00:00:30] Like everyone, I’ve had a lot of time for thinking and reflecting last year, and I’ve realized that whilst the technical capabilities of API platforms like Kong are constantly improving and innovating as an industry, we haven’t given the same level of thought yet to the impact that this has on the overall working methods or software development life cycles around the APIs. Companies invest in modern technologies for new and for modern use cases. And yet we haven’t really modernized to the same extent the ways that we approach API governance from a people and a process perspective. Time and time again over the years, I’ve seen companies at the beginning of their API and microservice journey full of enthusiasm, really excited and determined to put the effort in to do things the new way in the right way.
[00:01:25] But nine times out of 10, as soon as the initial enthusiasm’s worn off, business priorities have changed or that’s just too much time pressure. People revert back to habit. It’s human nature. They retreat back to their comfort zone of what they know and what’s worked for them in the past.
[00:01:45] Compounding this challenge further is that we’re not just talking about a handful of restful APIs to manage anymore. We’re looking at hundreds, thousands, tens of thousands or more APIs, microservices distributed across your entire ecosystem using various different protocols, design patterns built by federated development teams with different life cycles working on different projects.
[00:02:12] It can be completely chaotic. You might not be at this scale today. You might not ever get quite to that level. But think about it. Ask ourselves, how many teams do you have right now working on some kind of API or microservice-based initiative? Trying to enforce API governance in all this chaos becomes even more critical now. You cannot run the risk of exposing services that aren’t secured, that aren’t reliable, that don’t comply with local regulations. So governance starts to become this necessary blocker to mitigate this risk. We beat developers round with a stick and tell them they have to do things a certain way or else. This is not a happy environment for anyone. This is actually the number one challenge that most companies I speak with are facing today, how to scale out their API and microservice programs without having to trade off between speed and governance. And this is what we’re going to focus on in my talk today. I’ll show you the two common approaches that most companies have followed, showing neither of them really do what we need in the long term and then we’ll have a look at the API ops approach where we automate the entire API lifecycle, which is the ultimate solution to this problem.
[00:03:42] Let’s look first at a decentralized approach to governance. This tended to be the most common approach a few years ago when the industry was fairly new and not many people or companies had that much experience with API programs.
[00:03:58] What we see here is an investment in an API platform, ultimately, that’s a single global tool to support all of these different federated development teams and API-based or microservice-based projects that they’re working on. This promote the cross-team reuse, the collaboration, the discovery. Each developer or team is provisioned an account and has access to build and publish their APIs in the platform.
[00:04:28] We get off to a flying start. All of your development teams finally have this great technology that they can use to secure their APIs rather than custom coding or that themself. To catalog their services so another team or their external partners and customers can find and reuse them. They have free reign to use the API platform so you’ll tend to see a lot of activity in the first six or 12 months as your API program gets ramped up and your API catalog will probably get populated pretty quickly. But now comes the pain. We haven’t agreed on any standard, so each of these different teams is doing things in their own way, probably in a completely different way from each other. We haven’t figured out a way to prevent the same API from being built several times across the different teams, for example.
[00:05:24] Worryingly, we haven’t actually put any checks in to make sure that everything we build and publish and that the internal and potentially sensitive data that you expose through your APIs complies to your security standards. And of course, without this, you’ve got no way of adhering to GDPR or PCI or any other necessary regulations that we need to comply with. And the downstream impact of this lack of governance can also be very damaging to the business, to your potential revenue streams. In the latest state of API integration report, 84 percent of businesses said that APIs were critical or very critical to their business strategy. How much does it cost you if your APIs aren’t usable? What we ultimately see with this model when there’s no real consistent governance other than what each development team has taken upon itself to define, is that you get stuff in the platform very quickly, but just as quickly it becomes unusable. Essentially, you’re building a whole load of technical debt very quickly. And in the end, do you have to spend more money and more time ripping that all out and starting again. And thus, a second approach was born. Companies had felt or predicted the pain from an approach with too little governance and kind of overcompensated. We saw the introduction of API platform teams or some group of governors who sit centrally and who are responsible for making sure that everything deployed to the platform actually is high quality and is consistent.
[00:07:10] Developers now no longer have complete free reign. Instead, their API designs and implementations need to be reviewed and signed off before they’ll be deployed. We do get the benefit here that the API platform and everything running in it stays nice and shiny and delivers some of the business value it needs to that we didn’t see before. But this comes at a very heavy price. We’ve slowed down the entire development process and in some cases created friction and even unhappiness for both of these teams involved. So our centralized API platform team eventually becomes a bottleneck. They’re meant to ensure that the overall architecture, infrastructure and the capabilities surrounding the entire API platform and meeting all of the different requirements. But they’ve got these manual reviews now piling up from all the different development teams to also spend their limited time on. And this time that they have to spend doing the reviews and then more things just waiting in the backlog to be done obviously causes delays. APIs intentionally cannot get into production as quickly as before, and you may end up in a situation where a developer submits something for review, but weeks later they find out they have to go back to that project and make the changes that are requested by the API platform team because they’ve had a long backlog and I’ve only just had the chance to look at this project.
[00:08:42] But of course, by then the developers moved on to something else. And you are damaging their productivity by asking them. Some of the more mature companies have alleviated this pain to some degree by spending the time documenting what their API best practices are and then setting the expectation with every developer that they have to read and internalize that best practice. The intention here is a very good one. You don’t want developers to be submitting code that they themselves haven’t checked for compliance because then you’ll obviously have even more rework to do. But the trouble here is that there’s no easy way to actually document and share what your best practices are and then check conformance to those standards. The most common ways I’ve seen this done is through a combination of pages and pages of text in something like Confluence and in an internal development portal. But these cannot obviously be successful in isolation. And instead, the these owners or the stewards of the API platform also invest significant time in educating and evangelizing to all of the different API stakeholders across the ecosystem. And this tends to take the form of things I’m sure we’re all familiar with: lunch and learns, hackathons, back when we could travel–roadshows across different offices. Lots of activities that are essentially geared towards winning the hearts and minds of everyone you want to buy into and follow your standards.
[00:10:23] And don’t get me wrong, these are all still necessary activities for large scale change, but seeing success here is now 100 percent dependent on each and every developer reading and remembering the standards and then manually making sure that they do actually follow them. This makes it easier for the API platform team, but actually you’re just shifting the burden of responsibility to the developers now. You haven’t really made it that much easier overall. Now it is the developers who are the ones that are forced to work in a way that doesn’t align with what makes them happy and productive. It is a truth universally acknowledged that documentation can be a serious pain, both reading, understanding and following it. And also spending the time constantly keeping it up to date. In a modern world of automation and self-sufficiency, we can do better than this.
[00:11:24] So beware of too centralized an approach to governance, even if you’ve taken the time to document and share your API standards and Confluence. Because while you now get the governance and the standards, you’ve lost the speed. And if you create too many barriers or roadblocks, your developers won’t follow your process at all.
[00:11:47] ApiOps is our answer here. This is how you sustain both speed and governance. This is how you maintain an efficient, streamlined pipeline. And how you remove all of those manual efforts that we’ve previously been demanding from our developers and from our API platform governance. And this is a simple idea, really. Much like we use GitOps to enable consistent, automated deployment, APIOps gives us the ability to automate much more of the API lifecycle. Here we’re using self-service tooling and testing to automate what was previously a lot of manual effort. So for our developers, rather than asking them to spend the time reading loads of documentation, let’s equip them with tools that they can use to instantly check their API designs and implementations. We want them to find it easy to follow our standards, right? Otherwise they won’t. How much easier can we get than an instant on-demand check that highlights what they need to change and why before they submit an API to the platform. And the same is true for API platform owners. They save a ton of time and pain by following this approach. Firstly, any API is submitted to the platform they can make sure they have been through this conveyor belt or assembly line and have passed all of the checkpoints on route. So the chances of APIs and microservices now not meeting standards at the point of review are much lower. And then the same tooling can be used here again to automatically double check that everything does meet standards still at the time of deployment. And if there are edge cases, they usually are, or things that warrant manual review, perhaps they’re exceptionally complex. We’ve just freed up all of this time, needed to do this properly without causing the bottleneck that we saw before. Now, of course, all of the time spent evangelizing and helping each development team to understand what the best practices are and what life looks like and feels like, following an API driven approach is still necessary. But now, rather than completely relying on it, we’re reinforcing it with the underlying guardrails to ensure that the culture change that’s required is much easier to adopt and the adoption itself is much more pervasive.
[00:14:26] OK, let’s get into a bit more detail and see the individual APIOps steps in the pipeline, which is essentially this assembly line from before. A workflow starts on the left in your API design environment. At Kong, we provide the hugely popular open source tool, Insomnia for this. Check it out if you’re not using it already, we’ve had over eight million downloads at my last check. And this has an Insomnia, specific capabilities designed to support this APIOps model of end-to-end automation. So when designing your API on the left here at the very beginning of the pipeline, your swagger is instantly linted and validated so that you know it follows industry and swagger best practices. You can also build and generate your test kits for the service functionality. And then still within the swagger, prescribe the various Kong policies or plugins that need to be applied to the various employees to ensure that they’ll be properly governed when they’re deployed. And like in all good SDLCs, our designs ultimately need to be committed to Git or whatever source control you use. So check point number one, ensuring the only APIs that have been linted and validated and that pass those checks that you set up can actually be pushed to get in the first place. Continuing on with our life cycle, when someone makes a pull request in that Git repo, you know you’ve got new code to review. For example, a developer has taken a swagger from our design step and now built the API implementation and then added this new code to the repo. As an API platform owner now we need to make sure that API, that code that’s been submitted for review, still meets our standards. Now, this is where things get really cool. Remember the check point that we had before and the fact that we could just lint and validate and test our API design? We still have all these capabilities available to us and not just in the Insomnia application itself, but through the CLI, Inso.
[00:16:40] This means that you can automatically invoke every single one of these governance checks any time a PR is made. And you can configure it so that the PR is only approved once all of the tests have been passed or the other way round. Anything that doesn’t meet your standards is automatically rejected. No manual intervention required. So check point number two, we only merge you code into the repo and ready it for deployment once it’s passed all of our automatic governance and validation checks again. The secret sauce here powering this level of automation is the fact that the entire API lifecycle with Kong is driven by declarative configuration. Whether you’re at the very beginning at the left on the pipeline here writing your swagger or at the point of deployment and production on the right hand side, your API, its structure configuration, its governance is represented by this single source of truth–the declarative config. Which is itself automatically generated by Insomnia and by Inso from that swagger. Then completing the beauty of this workflow is the fact that you can programmatically upload that declarative config to the various modules and runtime in Kong and they will automatically configure themselves based on it. This, if you’re familiar with it, is taking all of the magic and benefits of GitOps when it comes to continuous deployment and applying them to the full API lifecycle.
[00:18:20] So here we’ve replaced all of the manual reviews with automated checks that have to be passed before you can move on to the next stage of the pipeline. This means that we’ve got consistent governance. And because these checks are automated, we can move more quickly. Because we can do these checks early on in the pipeline, we’re catching deviations from our standards as early as possible, which also means we can move more quickly. And once you’re at that point of deployment, that entire process is also automated with the declarative config. So that too means that we can move more quickly.
[00:18:57] This means that with APIOps, you don’t have to sacrifice speed or governance. You can achieve both and in a sustained, automated way. Adopting an API-driven or microservices-based approach, obviously, depending on the set up of your organization today, usually does mean some kind of culture change. And the only way to make that culture change sustainable and stick at scale is to replace what you had before with something that makes everybody’s lives easier. The developers, we’ve enabled them to be autonomous. We’re empowering them to work in a way that makes them most productive because we’re providing them with easy, self-service tooling that they can use for the first round of governance checks.
[00:19:44] This removes all of the frustration of manual effort that we used to ask of developers. Now they can instantly be alerted about any changes that they need to make so they can also do those changes straight away as well. And then for our API platform owners, we’ve given them away to ensure 100 percent coverage of governance checks across all of these different services that are being built. And a way to ensure that all of these governance checks are instant and immediate. So we’ve enabled our developers to be autonomous, but in a safe way, which means that really everybody is happy.
[00:20:24] As you can tell, I’m hugely excited by the potential that we have here. And the companies that I’ve worked with and spoken about this approach with are achieving real impact at scale.
[00:20:24] We still got a few minutes for questions. Feel free to use the Zoom chat, or you can message me in our Slack workspace or send me an email’s up here.
[00:20:47] And I’ve also got a question for all of you. If you have felt the pain of having to make this tradeoff between speed and governance, then I’d love to learn from you what’s works and what hasn’t worked as you try and achieve both and also what you think of this API ops approach.