Welcome!

@CloudExpo Authors: Liz McMillan, Zakia Bouachraoui, Yeshim Deniz, Pat Romanski, Elizabeth White

Related Topics: @CloudExpo, Microservices Expo, IBM Cloud

@CloudExpo: Blog Post

What's the Big Deal About Cloud APIs?

Federation and integration are why we need 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!

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at http://dustinamrhein.ulitzer.com. You can follow him on Twitter at http://twitter.com/damrhein.

CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.