Observability is one of the foundational building blocks of a useful, powerful, repeatable APIOps lifecycle. There are two sides to this – APIOps and observability – with plenty of nuance along the way. To explore the topic in full, Tyk’s Budha Bhattacharya and Tom Rowson sat down with Osaango’s Marjukka Niinioja and Coen Meerbeek from Amsterdam Schiphol Airport.
The expert panel discussed how to connect APIOps and observability so that one enhances the other in the best possible way. We also picked up some invaluable insights into what to consider when you’re building out your plan and strategy.
In this blog, we’ll look at:
- What the APIOps lifecycle involves and where observability fits into the picture.
- How to move discussions around the value of observability beyond engineering teams and into wider business conversations.
- The role of OpenTelemetry in facilitating collective intelligence.
- The symbiotic relationship between observability and API management.
- Where to start when it comes to data collection.
Watch the full webinar video via the link above or read on for our top takeaways.
What is APIOps?
APIOps is all about automating your API lifecycle management and getting metrics so that you can transparently see what’s going on, explains Osaango’s Marjukka Niinioja. It’s like user experience (UX) meets DevOps for APIs – then observability takes that one step further.
While the development, deployment and operation of APIs sits at the core of APIOps, it’s much broader than that, according to Tyk’s Tom Rowson. Where the real value comes in is around the inclusion at an early stage of key stakeholders – all those good folk you’re developing the API for. It’s about understanding those stakeholders’ needs and developing your API to meet them. You take the design thinking cycle and extend beyond initial technical thoughts into how people are going to consume the API.
You also need to think about how you’re going to ensure you run the API well. Baking in observability at an early stage is a key element of this.
Value drivers for adopting observability practices
In the experience of Coen Meerbeek, who spent over a decade freelancing in the monitoring business, observability is still too much in the engineering space and too little in the business side of things. Many organisations view it as an engineering pain. Yet the insights they need to drive business decisions are generated by those same observability tools.
Terminology can be a barrier here. Marjukka Niinioja observes that the word ‘API’ can make some non-technical businesspeople nervous, let alone the technical terms that start flying around when the topic of observability comes up.
Starting the conversation with the consequences of not using observability can help. For a retail business, not using observability makes it hard to identify why certain shoppers’ cart checkouts are constantly failing, for example. Explaining to non-technical decisionmakers that observability can help make money and reduce churn can demonstrate the business value before too many technical terms are rolled out.
The challenge is then to ensure that value discussions become an open conversation with all stakeholders, rather than taking place in silos within an organisation. This is where it’s important to understand what matters to all those people in the business who are going to be delivering the observability solution. That’s not just the developers, test engineers and site reliability engineers – it’s all those who enable the process to happen, from the top of the business downwards. What do those people care about with respect to the development of the proposed API?
Find out what success looks like for each internal stakeholder, and you’ve started to unlock an organisation-wide approach. Not only that, but as Tyk’s Tom Rowson points out, once you understand the value you want to get out of an API, you can start measuring that. You can start working out what you want to observe during the API’s development and once it’s deployed. You’re building observability into API design.
Whose job is it to communicate value?
Communicating and achieving value is a collaborative effort, according to Amsterdam Schiphol Airport’s Coen Meerbeek. Those contributing to this can include:
- An observability champion – to ensure you get the most value out of your tools and data.
- A product manager or product owner – the individual who decides to build the API and who uses the observability data to inform that process.
- Finops – to implement structures that reward APIs that contribute value to your platform with higher budgets, thus incentivising the creation of APIs that deliver value.
Using OpenTelemetry for collective intelligence
Observability isn’t about pulling together any old dashboard. It requires intelligent thought to go into the analytics. OpenTelemetry can help too, unlocking the value of date an ensuring you’re not tied to a single tool.
Each contributor or department knows their area of the business best, meaning when you put observability across the whole APIOps journey, you can tap into collective intelligence. You can build observability based on each team’s understanding of their signals, in terms of both what good looks like and what’s alarming.
Shipping all that data into different places – including one aggregated place – means you can start to see trends across the whole APIOps lifecycle. OpenTelemetry unlocks the power to achieve that.
Osanngo’s Marjukka Niinioja points to the banking sector as a good example of how powerful this can be. Many banks have a lot of layers to their architecture, with APIs on top of APIs, as well as a whole heap of different channels and interfaces. This can result in quite a fragmented user experience. It also makes it difficult to understand what the end result for the user will be when you’re trying to change or fix your multichannel experience. Observability, though, when you have the right KPIs, design APIs with value in mind and understand how each of your layers contributes to the user journey, can bring the value that is otherwise lacking.
Observability and API management
When it comes to observability and API management, a symbiotic relationship should be the default, according to Coen Meerbeek. It means the development team have everything they need to build, deploy and support their APIs, exposing them securely and seeing the results of their deployment immediately.
Building automation into observability helps even more, adds Marjukka Niinioja, as it lowers the barrier to adoption by making it easier for see results and evaluate them. Automatic dashboard deployment and alert deployment can be particularly helpful here.
Tyk’s Tom Rowson believes that the increasing universality of OpenTelemetry means we are now at an inflection point. Telemetry can be baked in from the beginning of products, rather than added afterwards. It’s becoming a fundamental platform capability.
What does a typical API ops cycle look like?
First comes the discussion of requirements – of known functionals such as capacity and availability – within the business context. Next, it’s time to plan the architecture – data models, API endpoints and so on. After that, you need to develop and test your code before pushing it into your environments.
Once you’ve got to production, you can start looking at all those metrics that you initially discussed, measuring them to inform the development of your APIs based on what’s happening with them in real life.
What data do you start gathering first?
If you’re exposing your APIs through an API management platform, that platform will jumpstart your data collection, providing you with insights into your APIs. It’s also important to talk to your observability team once you start developing an API, to understand the best way to instrument your application.
Based on your analysis of that initial data, you can start adding more – more traces, more metrics – and evolving your data… but enabling it on your API management platform is a solid starting point.
The API management industry is mature enough that it’s easy to know what a lot of those initial metrics should be: red metrics, golden signals, plus bits and pieces such as throughput over time and popularity. Those basics will trigger conversations throughout the business, creating a process of evolution based on demand. Then you need to join up the data you can get about your APIs and how the platform is behaving with the metrics you’re trying to measure, often with a bit of intelligent thought around how to join the dots between these.
Top tips for unlocking the APIOps cycle through observability
The panel’s final discussion centred around the key things you need to do in the space of APIOps and observability. Their top recommendations were:
- Get your developers and businesspeople around the same table to figure out what’s really important – and then measure at least one thing.
- Make observability your default stance when deploying and managing your APIs – something that’s there from the get-go, rather than an optional extra.
- Ensure all your stakeholders are involved in the process of designing the API and are served by the observability that you put in there.
There was a final word of caution, as well, about avoiding going over the top too early. Starting small, iterating, experimenting and letting things grow organically is key to remaining agile.
For more tips on what to avoid (and why), check out Tyk’s bad API observability pocket guide.
