It is not Cloud first or API first but Strategy first. API Management Strategy in Multicloud Environments

[STALANKI]

Introduction

API(S) are the backbone of an organization digital transformation that provides a powerful mechanism to connect apps, social channels, systems and things.

It offers great flexibility to integrate various vendor specific application SAAS products but API management may get very tricky and over complicated especially if organization has a multi cloud environment and it may loose the steam quickly if we don't pick the right integration strategy that works for the organization.

As the organizations are being hustled into cloud for IT to drive operation effeciency and innovation,they are procuring cloud applications from different vendors to avoid lock in to single vendor. It means that we have different vendors providing their standard API(S) and integration to vendor specific applications via their own API management and IPAAS products.

The cloud transformation projects are also run in parallel for different applications Ex: SAP, AWS, Microsoft and there is a danger that each project will choose their own strategies and tools creating a spaghetti of brittle connections between cloud apps and on-premise if they don't have centralized vendor neutral integration roadmap for an organization derailing the very objective of the digital transformation i.e  agility and exposing application services via open API(S) .

This blog provides different API management strategy solution options for organizations to evaluate and pick the right approach that suits the organization.

If you are interested to know whether SAP API management and SAP Process Orchestration can co-exist then please check out this blog from me.

If you are interested to know whether  SAP API management and SAP Open Connectors can co-exist the please check out this blog from me.

Integration & Cloud Terminologies

Before we evaluate API strategic options for an organization, the integration architects first need to familarize with the below terminologies from wikipedia:

SaaS-Software as a service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as "on-demand software".

Platform as a Service (PaaS) or Application Platform as a Service (aPaaS) or platform-based service is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app

IaaS -Infrastructure as a service (IaaS) is a form of cloud computing that provides virtualized computing resources over the internet. IaaS is one of the three main categories of cloud computing services, alongside software as a service (SaaS) and platform as a service (PaaS).

iPaaS - Integration platform as a service (iPaaS) is a set of automated tools for connecting software applications that are deployed in different environments. iPaaS is often used by large business-to-business (B2B) enterprises that need to integrate on-premises applications and data with cloud applications and data. It is used for connecting different backend systems in a multi-cloud systems when we need to orchestrate and transform data between various data centres and feed into microservices.

Kubernetes - It has a number of features. It can be thought of as:

• a container platform


• a microservices platform


• a portable cloud platform and a lot more.

Kubernetes provides a container-centric management environment. It orchestrates computing, networking, and storage infrastructure on behalf of user workloads.

API Management Platform –It is provides a full lifecycle API management platform to design that enables API providers to design, secure, deploy, monitor, and scale microservice APIs. It sits in-line with runtime API traffic and enforces a set of out-of-the-box API policies, including key validation, quota management, transformation, authorization, and access control. API providers use the customizable developer portal to enable developers to consume APIs easily and securely, and to measure API performance and usage.

API Gateway Containers- It is usually a part of API Management Platform and is generally a  single server that can be deployed as container gateway on different clouds as an entry point to a cloud that manages client connections to all systems in the data centre that is deployed on cloud. It sits in data centres or near to on-premise systems. A policy enforcement point, a central point to implement horizontally applicable logging, rate limiting, security, and access policies.

Future IT Landscape

IT application landscape in future can be broadly divided into following components and organizations will be moving towards this model in future some day:

Model	Example Usecase
SAAS applications deployed on same vendor specific public cloud	SAP Hybris Marketing on SAP Public Cloud
SAAS applications deployed on same vendor specific private cloud	SAP S/4 HANA Extended, SAP Hybris Marketing on dedicated infrastructure
SAAS applications deployed on different vendor specific public cloud	SAP Hybris Marketing on AWS
SAAS applications deployed on different vendor specific public cloud	SAP Hybris Marketing on Azure Private Cloud
Applications hosted on same vendor IAAS/PAAS providers	S4 HANA Anyprem Hana Enterprise Private Cloud
Applications hosted on different vendor IAAS/PAAS providers	S4 HANA Anyprem Azure Cloud
Applications hosted on IT consulting IAAS/PAAS data centers	SAP BW hosted in Accenture data center
Applications hosted on organization network i.e pure on-premise	Legacy Applications that can't be moved to IAAS/PAAS providers

API Management Components in Containers

It is assumed that we will be using a true Open API management platform  isn't locked down in deployment and offers flexibility to deploy different API Management components as containers on different clouds i.e API gateways can be installed as containers on different cloud service providers like AWS/SAP/Azure/Google which can register itself to central API management platform of an organization i.e a true API management product built for multicloud.

API Management Strategy

This section provides different API management strategic options to integrate applications in the future IT landscape for organizations to evaluate and pick the right strategy that fits their IT cloud strategy.

Centralized API Management + iPAAS with distributed API Gateway Containers - Option 1

• A centralised API management platform is used for discovering, designing , monetizing, documenting and deploying internal and external API(S) in a consistent format across organization.


• API container gateways are deployed on various clouds to reduce the network latency and to ensure data movement to external applications is kept to minimal by keeping API(S) closer to source system via light weight API gateways deployed on docking containers on each cloud centre.


• Centralized iPAAS layer is used when we need to orchestrate and transform data or event based high volume messaging from multiple on-premise and cloud systems.

Centralized External API Management with distributed internal API Management + iPaas  - Option 2

• A centralized external API management platform is used for discovering, designing , monetizing, documenting and deploying external API(S) i.e. public facing in a consistent format across organization.


• Internal API(S) are exposed using vendor specific API management platforms depending on which vendor application services we are exposing.


• Vendor specific iPAAS layers are used when we need to orchestrate and transform data from multiple on-premise and cloud systems depending on the on which vendor applications we are integrating.. Ex : SAP API/CPI Management is used for integrating SAP cloud apps, AWS API Management/AWS Elastic Bean Stack for integrating AWS apps.

 

Distributed API Management & IPAAS  Platform for Public Cloud Apps & Out of box API(S) – Option3 

• A distributed public cloud native API management/IPAAS platform  is used for discovering, designing , monetizing, documenting and deploying  integrations between public cloud apps via standard API(S) or standard IFLOWS/API(S) in a consistent format across organization.


• Centralized API management platform/iPAAS is used when we are integrating private cloud apps with on-premise systems or developing custom integration flows/API(S) that are not provided out of the box.  Ex : SAP API/CPI Management is used for integrating different SAP public cloud apps or customizing out of box API(S), AWS API Management/AWS Elastic Bean Stack for integrating AWS apps using out ofthe  box AWS packages, Centralized API management/IPAAS for building custom integrations between cloud and on-premise apps .

Option Comparision Matrix

The table below provides the comparision between the 3 options described in above section.

Feature	Option 1 (Simple API Landscape, Low Opex Costs)	Option 2 (High Complex API Landscape, High Opex Costs)	Option3 (Medium Complex  API Landscape, Medium Opex Costs)
Infrastructure Costs	Infrastructure costs are low as compared to Option 2 as we are using one API Management Platform	Infrastructure costs are more as compared to Option 1 as we are using API Management Platform for each cloud vendor.	Lesser Infrastructure costs compared to Option 2 as we are using centralised API management/iPAAS for exposing on-premise and private cloud apps and different platforms to expose public cloud integration apps or standard API(S).
Licensing Costs	Licensing costs are low as compared to Option 2 as we are using one API Management Platform	Licensing costs are more as compared to Option 1 as we are using API Management Platform for each cloud vendor	Lesser Licensing costs compared to Option 2 as we are using centralised API management/iPAAS for exposing on-premise and private cloud integration apps and different platforms to expose public cloud integration apps or standard API(S).
Agility	Option 1 is more agile as we don’t need to connect different API management and iPAAS Platforms.	Option 2 is less agile as we need to connect different API management and iPAAS Platforms.	Option 3 is more agile compared to Option 2 as we are using centralised API management/iPAAS platforms for exposing custom  on-premise and private cloud integration apps  and different platforms to expose public cloud integration apps or standard API(S).
Development Efforts i.e. Costs	Less effort compared to Option 1 as we are deploying light weight API gateway services from same vendor across clouds and data centres and developing using centralized API/Ipaas platforms.	More effort compared to Option 1 as we are developing using different vendor specific API/Ipaas platforms.	Medium effort compared to Option 2 as we are as we are using centralised API management for exposing custom on-premise and private cloud integration apps and different platforms to expose public cloud integration apps or standard API(S).
IT Integration Architecture Complexity	Less Complex as we have less hops and Integration Layers and hence the integration design is simple.	More Complex as we have more hops and Integration Layers and hence integration design can be very complicated .	Medium Complex compared to Option 2 as we are as we are using centralised API management for exposing on-premise and private cloud integration apps and different platforms to expose public cloud integration apps or standard API(S).
Digital Innovation time to Market	Less time to market as it is relatively easier to develop and test using centralized API Management/iPAAS platform	Longer time to market as it will be complex to develop on different API Management/Ipaas platforms. The co-ordination of different teams and testing of interfaces will become complex impeding the timelines.	Average time to market compared to Option 2 as we are as we are using centralised API management for exposing on-premise and private cloud integration apps and different platforms to expose public cloud integration apps. The co-ordination of different teams is only required for certain business scenarios i.e. different platforms to expose public cloud integration apps or standard API(S).
API Development Consistency	API’S are developed consistently across organization as we are using a single platform irrespective of what applications we are integrating.	API’s can be developed inconsistently across organization as we are using different platforms depending on type of applications we are integrating.	API’s are developed consistently than Option 2 as we are using centralised API management/iPAAS for exposing on-premise and private cloud apps and different platforms to expose public cloud integration apps or standard API(S).
Standard Native Cloud API(S)/Integration Flows	High Effort is required as the Catalog of API(S)for each cloud native vendor may not be fully available on chosen central API management vendor.	No Effort is required as the Catalog of API(S)for each cloud native vendor is available on API/iPAAS platforms as we are using cloud vendor specific API/iPAAS  management platforms for public cloud and out of the box integration scenarios.	Medium Effort is required as the Catalog of API(S)for each cloud native vendor is available on API/iPAAS platforms as we are using cloud vendor specific API/iPAAS  management platforms for public cloud and out of the box integration scenarios.
Support Team Skills	API Support Teams will only need skills for one API Management/iPAAS Platform and hence TCO is low compared to Option 2.	API Support Teams need skills for different API Management/iPAAS Platforms and hence TCO is high compared to Option 1.	API Support Teams still need different skills but the API support teams for public cloud apps can be very lean as we are using centralised API management for exposing custom on-premise and private cloud integration apps and hence number of API(S) exposed via public cloud can be minimal i.e. we only use different platforms to expose public cloud integration apps or standard API(S).