How important are your APIs?

Working modern applications based on microservices, or based on serverless, or on event-driven architectures, or even efficient supply chain integrations are several technical approaches that are supporting the digital transformation strategy in many different businesses. And for all these paths, APIs (Application Programming Interface) are the interface structure that makes it possible, becoming the common “language” within the solution. But we can go even further: new business models and profound transformations of entire sectors occur through approaches worked through APIs, such as Open Banking and Open Finance in the financial sector, or FHIR (Fast Healthcare Interoperability Resources) with HL7 (Health Level Seven International) in the health sector.

Another way to observe this movement is to see the trend reported by F5 in its study called Continuous API Sprawl, by Rajesh Narayanan and Mike Wiley, from 2021, where it is estimated that the market already reaches about 200 million APIs, between public and private ones. Still based on this study, Bill Doerrfeld, in an article to DevOps.com, states: “APIs are becoming increasingly crucial to the global digital economy. They are the backbone of many digital platforms and drive the composable enterprise model.”

Thus, we have a context of constant growth in the volume of APIs, where they become critical for the businesses on their transformation and modernization. So, the question then becomes: how to manage these APIs? What are the challenges involved? But managing APIs can be seen from two perspectives, commonly referred to as an east-west view and a north-south view, let's work out what these views would be.

An east-west API management approach works with the internal component communication, within the service or the organization, being basically the composition of the service (or microservice) mesh in applications. The north-south approach, on the other hand, works with communication and management of APIs from an external point of view, that is, communication originating from outside the company or infrastructure. The image below illustrates this design (image taken from article). Another interesting reference on the topic is the Service Mesh Guide 2021 published on InfoQ.

Given the definition, there is then the solution direction to manage in each of these approaches. For an east-west, we work with a more technical solution, known as a service mesh. Among the best known are Istio, Linkerd, NGINX Service Mesh. For a north-south approach, technical capacity is also observed, but it is combined with a business vision, as the APIs exposure to external agents raises other topics to be addressed (like, monetization, usage, SLAs, etc.). Therefore, these solutions are known as API Gateway or API Management (varying in terms of capabilities from vendor to vendor). Then, these solutions usually work on the following pillars:

• API Lifecycle Management (Building, Deployment and Retirement).
• Usability (including Accessibility, API catalog and Experience management).
• Usage Monitoring and Analysis (possibly also working the monetization capabilities).
• Performance Metrics Reporting (Including status reporting to clients and SLAs).
• Security Access (Vulnerability intelligence, authentication, authorization, threat, or integration to DevSecOps).

Some well-known solutions are: Google ApiGee, Sensedia Platform, AWS API Gateway, Azure API Management, Software AG.

But API management does not stop at understanding these two views (east-west and north-south), nor at building or implementing the solution or technology to be used. Even this implementation requires nuances and alignment on how to model what is considered internal or external, and what needs to be managed by a service mesh or an API gateway. An example of this discussion can be seen on this article from Cloud Native Computing Foundation. This field goes much further: how to integrate the API lifecycle with the application lifecycle (DevSecOps, CI/CD, SDLC, ...), how to work with version control on APIs, backward compatibility, demand management, reliability, business-aligned SLAs. There are many topics still to be explored, and I believe that with this introduction, I open the space for these discussions in future articles!