Here’s a question – do we really care about SOAP or REST any longer? With the advent of cloud and the increased focus on the rapidly changing software consumption model, it seems like Enterprises should come full circle back to API. What do I mean by API in this context? Yes, it’s a programming interface, but as I’ll argue in this post, it’s a generalized programming interface accessible over HTTP. I’m not talking about a .NET DLL or Java RMI interface here.
General interfaces can be implemented in a few ways and the specific implementation (while important) is no longer the salient aspect. Instead, the goal for an Enterprise is how to manage such an API, how to secure it, how to scale it and make it work for the business.
API management, then, is about securing, managing and auditing an increasingly important Enterprise I/O point, one that has enormous potential to connect and expand the Enterprise to new customers through all manner of technology including smart-phone applications, browsers, middleware, legacy applications and just about anything that can talk HTTP.
I also think that this focus on API management is historically connected to SOA and services. Here is how I think we got there:
- First, behind the firewall “SOA” brought low-cost, HTTP-based standard SOAP APIs into the Enterprise mindshare. Rather than thinking in terms of RMI, we can think in a platform independent way and expose interfaces outside the Enterprise.
- Then, Web 2.0 trends and the REST hype coupled with the use of the “WS-* complexity backlash” (new term!) brought REST APIs into the Enterprise mindshare, but Enterprises continued to use SOAP because REST lacked a coherent security model
- Next, the cloud consumption model begins to emerge and software service providers such as Salesforce.com and Amazon want thriving developer communities. Unmarred by any previous history, they offer both SOAP and REST APIs (aka ‘query’ APIs).
If we compose these previous events they lead to a conclusion that moves the discussion from SOA to Services to APIs. I will argue that what Enterprises care about is how to manage API connectivity outside their organization and leave it up to the technology providers to not only make the piping work, but also make it secure, reliable, cheap, scalable, standards-based and compliant. At Intel, we have the concept of a service gateway or enforcement point specifically for this.
From what we’ve seen, there are three conceptual usage models centered on three actors: Enterprise, Service Provider, and Consumer.
The Enterprise is a traditional enterprise normally thought of as one that exposes services to other enterprises for some B2B transaction. Service providers are the term I use to describe a software service provider such as Salesforce.com or Amazon, which expose different types of services (IaaS, PaaS, or SaaS), and Consumers can be end-consumers with a smart-phone, a developer, or thick client.
API Management Use Cases
The three use cases are:
- Enterprise Edge Security – Here the enterprise wants to securely expose services to business partners, with a focus on authentication, auditing, and perimeter security for B2B transactions. A variation on this case is a set of enterprise services exposed to customers, consumed through a tablet or smart-phone. Here is a conceptual picture of the use case with a gateway shown as a control point for the API
- API Security – Here the service provider wants to securely expose services to customers and developers, with a focus on quality of service enforcement, authentication and API mediation
- Hybrid Cloud Gateway – This category has three important sub-usage models:
- Data Gateway – Here the enterprise wants to securely utilize a service provider like Amazon, Microsoft or Google as for additional platform-level services such as queuing and storage. Here the focus is on quality of service enforcement, data protection (encryption/tokenization), authentication and attack prevention
- Control Gateway – Here the enterprise wants to securely utilize a service provider like Amazon EC2 or Rackspace to as a way to spin-up and spin-down additional server capacity and enforce authentication, authorization and quality of service enforcement on access to external, hosted virtual machine instances.
- Hosted Edge Security – Here the enterprise deploys a service at a cloud service provider and needs Enterprise class security on the exposed API. Focus is on authentication, attack protection, secure migration and policy consistency between the service provider and Enterprise.
The hybrid cloud use cases are shown in the following diagram.
Use case (a) is the conceptual deployment for a control or gateway gateway and use case (b) is the case where an Enterprise is beginning to externally host their infrastructure on a cloud service provider. Here, the gateway is augmenting the API management capabilities provided by the cloud service provider and allowing policies to migrate from the Enterprise to the cloud.
It should be emphasized that there are many, many variations to case (b). Sometimes, the applications themselves are created using the cloud service provider’s own infrastructure, such as Microsoft Azure or Google Apps engine (PaaS). In other cases (depicted in the diagram), it’s Enterprise middleware or other systems migrated to the cloud and hosted (IaaS) with a requirement for Enterprise security policies.
It’s also clear that some of these variations are more speculative than others – it’s an open question whether Enterprises will be willing to risk migrating their core information systems and business processing to the cloud. This is really the big question on everyone’s mind – how much can Enterprises risk today and what can they do to minimize this risk? We think that a service gateway can help minimize this risk, but the Enterprise must place a high degree of trust in the cloud service provider.
These are the three cases that we’ve come across. Notice that the issue of API type is really not at the forefront – any of these could be done with a SOAP/XML, REST/XML or REST/JSON implementation style. What is needed is a way to control and secure these exposed APIs – which is the topic of API management.
I’d love to get comments on this idea and especially new usage models. In some upcoming blogs I’ll be expanding on these and then trying to get into specific details.