As a Sales lead for NGINX at F5, I often interact with customers that are using more than one API management framework. One customer I spoke with has five at last count! Why is this? There can be many reasons, but one situation we come across again and again is that as customers are transforming their applications from monolithic architectures to more microservices‑based architectures, they’re finding that their traditional API management framework no longer satisfies all their requirements.
Before we examine the ways these traditional frameworks are no longer adequate, let’s take a look back at how we got to where we are today…
The Evolution of Software Integration Architecture
During the early 2000s we saw a growing requirement for an integration layer able to connect various front‑end services to various backend services such as mainframes, message queues, and datastores. Middleware tools solved these integration challenges with protocol and message transformation, greatly reducing the complexity of connecting to backend systems. These middleware tools became known as an enterprise service bus (ESB) and over time began to offer additional functionality such as authentication, authorization, and auditing capabilities. To connect and integrate internal business functions APIs, ESB vendors created APIs that typically used SOAP message protocols and XML‑formatted data. Over time the ESB became a critical infrastructure component for many organizations, which consequently tended to treat ESB like a “pet” in their infrastructure.
Organizations were forced to rethink their business strategies and infrastructure models as Internet traffic grew exponentially and consumers began to consume services in new ways – a prominent example being the use of mobile devices for shopping, Internet banking, and social media. Time-to-market became a key business driver for many organizations, inspiring lines of business to look for more agile ways to bring new products and services to market. I am sure we have all heard the maxim that it is no longer large companies that eat small ones, but fast ones that eat slow ones!
The evolution of mobile devices as well as the adoption of modern web frameworks led developers to adopt more modern web frameworks and to replace SOAP/XML APIs with newer, lighter‑weight REST APIs and JSON‑formatted data. APIs have now become such an instrumental way for our devices and applications to communicate that in 2019 Akamai found that 83% of web traffic is API calls. As ESB became less relevant to the “digital natives” adopting new technologies, ESB vendors tried to hold on to market share by offering API functionality with both legacy SOAP and more modern REST web services. This resulted in a quick win for the ESB vendors, but the market was still moving at a rapid pace towards the microservices era.
Many of the API management frameworks that exist on the market today started life as ESBs. They were built long before the public cloud became mainstream, and predate the rapid adoption of microservices and methodologies such as DevOps and CI/CD tooling. So now we can understand why organizations today are finding that traditional API management frameworks no longer satisfy all their requirements. Simply put, it is because these frameworks were implemented when customers were not building distributed, microservices‑based architectures that often run inside of Kubernetes clusters, in both public and private cloud environments.
#blog #opinion #api management
