3rd-Generation API Management: From Proxies to Micro-Gateways

Businesses today understand that, in order to remain competitive in a market dominated by digital disruptors[i], they must innovate and gain business agility and speed. To this end, organizations of all sizes are adopting cloud (SaaS, PaaS, IaaS)[ii] not only as the means to reduce TCO, but also as a vehicle to achieve digital transformation and customer centricity.

However, moving to cloud does not mean one cloud. Research suggests that organizations are opting for multi-cloud strategies[iii] as opposed to putting all their eggs in a single cloud vendor's basket. This best-of-breed approach to cloud adoption means that on-premises monolithic system(s)[iv] (e.g., an ERP) and other on-premises applications are re-implemented in the cloud as discrete SaaS applications and integrated or extended with PaaS.

Figure 1 - Cloud transformation

For those on-premises applications that either don't have a cloud equivalent or simply don't address the desired requirements, many organizations are also opting for application development in the cloud.[v] Microservices architectures[vi] have become predominant as an architectural style for implementing such cloud-native applications. To do this, a monolith is broken down into smaller pieces -- each representing a business capability -- and then implemented as a fully decoupled service (microservice),[vii] typically in PaaS.

Figure 2 - Cloud native application development

As cloud adoption continues, information inevitably becomes more and more federated, not only across many different SaaS and PaaS applications (from different vendors), but also across many on-premises systems.

In order to achieve digital transformation, an organization must first either adapt or enhance its existing (on-premises) IT systems or attempt to replace them with modern ones (probably in the cloud), so products and services can be offered digitally via multiple channels (web, mobile apps, kiosks, partner online stores, bots, etc.).

Digital transformation makes co-workers more productive by enabling them to execute business processes whilst on the move through a seamless journey delivered by different device interactions.

It also enhances an organization's partner ecosystem by giving them on-demand access to relevant business data and providing the means to execute business transactions electronically.

However, none of the above are possible if access to core business information assets is not availableÑand with information becoming federated, access can be a big problem.

Integration platform as a service (iPaaS)[viii] solutions address this issue. Their selling point is their ability to connect to any cloud and/or on-premises system and deliver the access required. A robust iPaaS platform should be capable of connecting to any cloud and/or on-premises application to deliver seamless access to information via RESTful Application Programming Interfaces (otherwise known as Web APIs[ix]).

The use of APIs as the means to deliver standard, consistent and secured access to information enables multi-channel applications to consume the assets they need when they need them.

Figure 3 - iPaaS solution with API management capabilities

However, unless the iPaaS solution delivers robust, 3rd-generation API platform capabilities, it will struggle to address the aforementioned needs. An API has to be as close as possible to the source of information. If it's not, issues like slow responses due to network latency and exposure to other network issues (i.e., unplanned outages) may arise. If information is distributed across multiple clouds and on-premises systems, so must the APIs.

3rd-Generation API Platform

As cloud adoption takes place and information becomes geographically distributed, getting access becomes even more important. Establishing VPNs to provide connectivity soon becomes impractical. In many cases, it won't solve the problem anyway, because SaaS vendors won't give direct access to their databases -- instead, APIs will be provided as the only means to access information.

It is at this point that 2nd-generation API platforms (basically ESBs and/or XML appliances enhanced with API management capabilities) fall short of capability and struggle to satisfy modern requirements derived from cloud adoption and digital transformation.

Figure 4 - 3rd-generation APIs everywhere

As illustrated in Figure 4, in order to deliver the capabilities needed for cloud adoption and digital transformation initiatives to succeed, a more sophisticated 3rd-generation API platform, is required -- one that doesn't have the technical baggage of monolithic architectures and therefore:

• Can implement APIs anywhere (in any vendor's cloud or on-premises) without introducing an operations nightmare and huge costs
• Empowers communities of developers by letting them discover and subscribe to APIs via a self-service developer portal
• Delivers seamless tooling for end-to-end API development lifecycle and API-first so developers get the tools they need to design, create and test their APIs
• Gives information owners full visibility and control over their information by letting them decide how and by whom their assets are accessed
• Delivers strong security to protect information assets against all major threats (i.e., OWASP top 10)
• Is lightweight, appliance-less/ESB-less, and suitable for Microservice Architectures
• Is elastic (i.e., can scale easily)
• Is centrally managed regardless of the number of gateways, APIs and their location
• Makes meaningful use of statistics so operations data can be used to gain business insight and not just to monitor and troubleshoot
• Is subscription based, with no CPU-based licensing

The End of "Fat" Middleware

As monoliths are broken down into smaller pieces and re-implemented as discrete cloud applications either in SaaS or PaaS, the business logic and information contained in such monoliths also gets distributed. The tendency we saw in 1st- and 2nd-generation integration middleware to become bigger and bigger (with lots of logic in it) reverses for good, almost like a bubble that bursts[x].

Figure 5 - Logic distribution in 3rd generation

3rd-generation API platforms truly mark an inflection point for software architecture and software development; it is no longer possible to depict architectures in layers. It's a paradigm shift that is better appreciated by comparing the different architectures and how the information flows within them.

Figure 6 - 1st- and 2nd-generation API platforms architectures compared

API Capability Model

The following capability model identifies some of the capabilities expected of a 3rd-generation API platform. Although not all of the capabilities are core to the platform, related capabilities have been included because they're considered critical in order to have an end-to-end solution. The use of models such as this one is highly recommended as it provides a structured framework for deciding what technologies can be adopted to realize each capability.

Figure 7 - API capability model

As it can be noted from the diagram, API gateways play a central role, not only because they are the engines that run the APIs, but also because they are the point of entry to information assets and where policies are applied. If APIs are doorways to information, API gateways surely are the doors.

Although not explicitly shown in the model, there are some fundamental capabilities that set 3rd-generation API gateways apart from1st- and 2nd-generation ones:

• Lightweight: Non-monolithic, appliance-less, ESB-less. They should be lightweight and very easy to implement (anywhere) -- ideally, using containers.
• Self-sufficient: It should be their responsibility retrieve APIs, policies and even system patches from a central management unit.
• Microservice oriented: It should be possible to:
  • Be stateless. No state should be managed for any transaction.
  • Implement services in any language and or technology of choice.
  • Elastically scale gateways in or out based on different conditions.
  • Implement API load-balancers by integrating with registries (e.g., Consul, Eureka, etc.) and dynamically determining active service endpoints and routes intelligently.
  • Prevent developers from adding logic into the gateways by not providing capabilities that don't belong on a gateway.

Conclusion

3rd-generation API platforms are all about delivering capabilities that facilitate the adoption of modern architectures, which in turn enable businesses to innovate and deliver new products and offerings quicker and cheaper and therefore remain relevant and competitive.

For digital giants[xi] such as Google, LinkedIn or Amazon, this is old news. However, for the majority of organizations world-wide, the journey to cloud, digital transformation and customer centricity is only getting started.

The tendency of information/functionality to become federated will not stop here; analysts predict that by 2020 the number of connected devices will reach at least 21 billion.[xii] Businesses of all sorts will make use of Internet of Things technologies to engage more closely with their customers and partners to completely change the way interactions occur and how products and services are offered.

A 4th-generation platform, one that goes beyond the cloud and delivers management and connectivity capabilities to billions of internet-enabled devices, will therefore be required.

Figure 8 - 4th generation API platforms

References

• Who are the digital disruptors redefining entire industries? (2015, TechRadar)
• NIST definition of cloud (2011, National Institute of Standards and Technology)
• The future isn't cloud. It's multi-cloud (2017, Network World)
• Definition: Monolithic architecture (TechTarget WhatIs)
• Developing cloud applications in the new IT era (TechTarget)
• A word about Microservices and SOA (SOA4U Tech Blog)
• Open Modern Software Architecture (OMESA) GitHub Repository
• iPaaS: What is it exactly? (SOA4U Tech Blog))
• Representational state transfer (Wikipedia)

About the Author

Oracle ACE Director Luis Weir is Chief Architect with Capgemini UK PLC. He is a co-author of Oracle API Management 12c Implementation (2015, Packt) and Oracle SOA Governance 11g Implementation (2013, Packt) as well as numerous articles and white papers. Luis is also a frequent speaker at industry events including Oracle OpenWorld, and most recently at Oracle Code London on April 20, 2017. Luis holds an MS in Corporate Networks and Systems Integration from the Universitat Politecnica de Valencia (UPV) and a BS in Electronics Engineering from the Universidad Nueva Esparta.