What is an API Strategy? A Technologist view
More so than ever, we have been hearing from our clients and peers that an API first strategy is a key pillar to modernization. Everybody quotes Jeff Bezos’ infamous API manifesto to their Technology teams.
I am not going to focus on the strategy part here but on what does that mean to a Technologist, who writes code on a day to day basis. A person who creates Solution Architecture for an upcoming project. A person who needs to analyze various different patterns and fit for a given use case.
When it comes to supporting your own vision of API Strategy, the options are endless. When I faced a similar challenge, I did an inventory of all major “API” technologies and a lot of times things overlap with Microservices jargon.
I have summarized this into what I call an “Inverted T” model.
I am hoping just the picture itself will speak to most of what an API Strategy could mean for you, but I will try and explain a bit more towards the end.
On the top of the diagram, some technologists call “North-South” strategy and bottom of the diagram “East-West” strategy. While I like this analogy a lot, I felt that other comparisons to your own Digital Business Transformations are missing with this approach.
So, I wanted this to be a bit broader and bring customer, user, client, or service provider into context to better explain to a day to day developer.
API first strategy — my view consists of serving 3 types of client journeys and encompasses a digital business technology strategy.
Customer — End-user of the APIs, could be other enterprises or your users using Web, Desktop, or Mobile Applications
Service Provider — Your partners who provide data to you for running necessary daily business functions
Enterprise Functions — Your internal functions, could be multiple lines of business platforms, batch processing engines, or compute-intensive customer-facing platforms.
The Technologies and design patterns you use for each of these are fairly unique and need fit-for-purpose tools to meet the demands. I have depicted a combination of open source and commercial vendor products (this is based on my experience, so you could potentially substitute with other equivalent tools).
1. Customer Focused Leg (of the T)
When developing customer-focused APIs, the design patterns are around aggregating curated/derived datasets to your customers through a channel. Given this is externally facing, you would want to make sure these APIs are governed in a central fashion and costs associated with it are properly accounted for.
Several API gateway platforms and API aggregation tools listed here are suited for the need. You would expect the focus here is only in a presentation to the channels and capturing user transactions.
Icons listed: AWS API Gateway, apigee, mulesoft (API gateway, not ESB portion, which we will refer later), GraphQL, Kong, Nginx (which we will refer later as well).
2. Service Provider Leg (of the T)
When developing Service provider APIs, here we are moving into the “data services” realm. External or Upstream data is provided by third parties and enterprises use an orchestrator to ingest data “data pipeline” into the core of the enterprise.
Icons listed: Landing zones will be like object storage, Kafka, Flink, or other AMQP tools for messaging and event-based ingestion, and orchestrated via tools like airflow, etc.,
Core Storage platforms could be relational sources but more often a polyglot data platforms are needed — from NoSQL to Caching solutions.
3. Enterprise Function Leg (of the T)
When it comes to internal enterprise functions, it gets interesting. This generally involves several legacy (or monolithic) application integrations and also several backend platforms.
As enterprises migrate these applications or add ‘open integration’ layers to these applications. There is a spectrum of implementation patterns we see here.
Stage 1: Deploy existing JEE applications to Cloud Service Provider runtime (EC2, ECS, EKS, etc.,)
Stage 2: As the applications themselves are broken down into “multiple” microservices patterns, then the complexity increases and requires patterns such as “service mesh/sidecar” or event/messaging based inter-service integration
There are scenarios where some of these services require massive compute engines and high IO (e.g., Risk engines, Calculation Services, Optimization, etc.,). Here we see enterprise leveraging tools such as Serverless, HPC, and existing Grid platforms to be integrated with Microservices patterns to generate core domain data for consumption.
Domain section is actually core to the T, and these are shared between all of the T legs. Here we see Spring/Spring Cloud, NodeJS type applications which are “REST” or other open integration focused (e.g., protobuf, sockets, sessions for large compute or IO-intensive service interactions).
Icons listed: Spring, Spring Cloud, Kubernetes, Linkerd, Istio, etc.,
Authentication and Authorization become a complicated service in itself given every service need to make sure enterprise security standards are being followed. There are a couple of great articles I have read around these and would be of interest to you as well.