Today was again a very exciting day at one of our customers (despite the Monday). As an integration architect I am currently working on the next-gen integration architecture in which cloud strategy is a very crucial part (among APIs, Microservices, Data Virtualization etc.). All concepts and technologies in the new world are closely related to each other (or even depending on each other), but for a smooth cloud transition and a flexible target architecture an API Management Platform is simply a must-have and plays a significant role!
In my last blogpost I already pointed out that I like to see an API Gateway & Management Platform as the successor of the traditional Enterprise Service Bus and (web) APIs as the new unit of integration logic. Being an abstraction layer on top of backend applications (holding all organizational assets and data source) it creates a single point of entry for developers (both internal and external) by hiding all implementation logic and even location of the private API. The only coupling that exists is the one that exists between the API consumers and the functional API definition (or Swagger documentation, does it ring any bells?). Implementation logic or location of the private API is not relevant for the API consumer which is fully agnostic to what is behind the public API. So this means that when we move the private API from an on-premises location towards a cloud environment or even rewrite the API that there shouldn’t be any impact on the API consumers as long as the functional API definition doesn’t changes (does it ring any bells?). This is similar to the use of a service contract (WSDL definition) in a traditional service-oriented architecture (SOA).
API Consumer -> Functional API Specification (Swagger documentation) -> API Management-> Private API (either on-premises or cloud)
Having said that, the following visual representation (based on 3scale API Management and NGINX as API Gateway) shows a simple situation in which a data store holding publicity available data is moved to a cloud environment. The cloud delivery model (IaaS, PaaS, SaaS) is not very relevant in this example. We see that the functionality was first exposed as an internal RESTful API (1). After the cloud transition of the data store we see a RESTful API (2) being fully compliant with the original functional API definition (or Swagger documentation):
This transition can be performed on-the-fly by simply adjusting and reloading the configuration in NGINX without any downtime.
This example obviously assumes that an API Gateway & Management Platform is already in place and broadly used (which is not always the case). But at the same time it also makes clear that the power of an API Gateway & Management Platform can be leveraged not only for the desired target architecture but also for the road towards it by enabling a smooth cloud transition.