What’s the big deal about cloud APIs?

APIs for cloud are important. Based on the number of writings, conference sessions, and Twitter blasts endorsing the cloud API movement, I think this is something on which we can all agree. However, I sometimes get the feeling that we just accept the fact that the API movement is important without really stopping to ask a very basic question: ‘Why are APIs for cloud important?’

Now, if you asked this question to a room full of people at say, a cloud conference, you are undoubtedly going to get some amount of variance in the answers. I would wager a guess that the terms automation and devops appear in the conversation. There is little doubt that APIs for cloud solutions lay the foundation for higher levels of automation, something almost every company needs. Similarly, you cannot deny that the cloud API movement has been a significant driver behind the devops (aka “infrastructure as code”) craze that one cannot help but notice today. That said, the real value of APIs for cloud is more significant than either enhanced automation or devops. The real value of the API movement is that it can help companies embarking on cloud overcome the biggest, sometimes underappreciated challenge in cloud implementation today: federation.

Consider that you are a company considering adopting cloud services to augment what you already have on-premise. Perhaps you are looking at providing some services, such as CRM, via the SaaS model. In addition, you want to augment the capacity of your in-house testing lab with a public IaaS provider. Having seen scenarios like this unfold many, many times in the enterprise, I can say with a fair degree of confidence that one of the very first problems you will encounter is one of coherency in management and operations. In other words, you will need to address issues like how you manage employee access to these services, how you inventory the cloud services, how you manage the health of those cloud services, how you integrate data across these services, and many more.

At that point you have two options, you can either implement one off service management systems for each domain within which you consume services. Obviously, this is untenable even in our simple example, as you would end up with separate management systems for on-premise, SaaS, and IaaS services. The second option is to take a federated approach to service management, and this is of course what you want. It’s what everyone wants. Users want to bring the management of services (regardless of the service consumption model) under a single domain. It is all about coherency… and sanity of course.

Federation is nice, but it is really a conceptual sort of thing. Integration is what provides the mechanics or underpinnings of federation. To say that we, as an industry, have overloaded the term integration is a severe understatement, but just think about it in the context of our simple scenario. If you want a federated approach to consuming services on-premise, via SaaS, and via public IaaS, you are going to look at integration from multiple angles:

Service request integration: This covers the need to integrate your current on-premise provisioning system to be able to talk to your public IaaS provider.

Service management integration: This covers the need to integrate things like monitoring, authentication, and authorization approaches for all services regardless of domain.

Service runtime integration: This covers the need for things like data integration across on-premise and off-premise systems. For instance, you may need to integrate data stored in an on-premise customer database with the CRM system you consume via SaaS.

You could go on and on with the different facets of integration as well as the different considerations for each of those topics. The bottom line is that there are many integration points to address when companies embark on cloud. Remember, that except in rare cases, companies are not starting with a green field, and they do not want a fragmented approach.

Okay, so how does this all tie back to APIs? Well, if you agree that federation is good, and you agree that integration is the underpinning of federation, then I say you must see the value of APIs. Meaningful integration is largely dependent on APIs to be able to provision cloud services, manage cloud services, monitor cloud services, secure cloud services, etc. It is really the only way to make it work.

Going forward, I think the question will be how many APIs do we need for common services. For instance, do we really need a plethora of different APIs for what is essentially IaaS functionality? Of course we don’t. All that really does is make it hard on providers to write solutions that enable federated service management across a number of different domains and providers. While you may think I am complaining on behalf of vendors, remember if it hurts the vendors, it hurts the consumer. They end up with less choice or solutions that only tackle half of their problems.

Cloud APIs are good, and I am glad to see such healthy interest and work in the area. Having said that, I think we need to streamline much of this work. We need to be pushing standardization into many of these APIs. As an industry, we need to stop competing on the API. This is not good for vendors and more importantly, it is definitely not good for consumers. Let’s all settle on some APIs and go head to head on implementation and value-add!