There are probably no public cloud providers or prospective providers that believe their customers will not demand...
hybrid cloud integration. Nearly all enterprise cloud users expect to create hybrid environments between their private data centers and the public cloud, and a careful analysis of cloud usage even among small and medium-sized businesses suggests some hybrid strategy is likely. Many businesses also plan to use multiple cloud providers, a forecast that becomes more likely as the level of cloud adoption rises from infrastructure through platforms and up to software.
But how much support is there, really, for customers looking for hybrid cloud services? One reason that's difficult to determine is that it's not at all easy to decide what support such a customer would need. In fact, a cloud provider that wants to support hybrid cloud customers may have only one path to success: Follow the application.
Providers need to look at all these phases of the application lifecycle to support hybrid cloud services.
In today's market, there are two uses of hybrid cloud that introduce complexity. At the simple end of this spectrum is a static, cooperative relationship between a cloud-hosted component of an application and a data center component. At the complex end is the cloud-bursting application that requires the public cloud to pick up work as the load on a data center application increases, risking performance degradation. The best way to prepare for hybridization is to address these scenarios -- as well as the hybrid applications in between -- by using application lifecycle management as the requirements driver.
Broadly speaking, the application lifecycle sequence is develop/purchase, deploy, integrate and manage. Most cloud services offer management interfaces that focus on the deployment phase, but this is only a small piece of the hybrid cloud customer's needs. Providers need to look at all these phases to support hybrid cloud services, and hybrid cloud use is likely the key to the largest segment of the cloud opportunity.
Hybrid cloud services: App components need directories
What an application needs in order to run and be connected among its components is typically set when the application is developed. Componentization is the result of segmenting applications into separate units that are then integrated into a workflow that supports its users. A cloud provider is offering a set of components when it offers Software as a Service (SaaS), so SaaS providers must define the way their components are linked to others to create hybrid applications. This starts with good documentation on the application programming interfaces (APIs) and a specific mechanism -- that is, a directory -- for registering components as they are installed.
It's important for providers to remember here that if they establish a directory of their SaaS components, they'll have to provide a mechanism for users to add their own self-hosted components as well. Without that mechanism, providers will not have a complete map of components available for integration later.
Deployment is the process of committing resources to each of the application components, and the critical question is what resources are actually needed. All applications and components deployed in the cloud must have an associated set of rules to ensure that the correct resources are allocated. There are two ways this can be done today: by providing a directory of requirements that are then used by the cloud management system, or by providing what's called a DevOps script or model that describes the actual deployment process as an ordered series of steps. A cloud provider has to expect to support both.
In both cases, it's necessary to have a complete inventory of the parameters needed to guide resource selection during cloud deployment. For DevOps, the critical question is the way in which the management interfaces in the cloud are accessed. Unfortunately, a number of popular DevOps tools exist, including Chef, Puppet, Juju and Salt. Providers should look at each and ensure they have clear instructions (and tools, where appropriate) to integrate these with the provider's cloud APIs. It's also very helpful to have DevOps maps and scripts available for deploying popular applications on cloud platforms, along with instructions on how to modify those maps and scripts for hybrid cloud use.
More hybrid cloud strategies for providers
Is SDN the answer to hybrid cloud networking problems?
Why it's imperative to educate customers on hybrid cloud
Virtual data center services offer another path to hybrid cloud
In the integration area, the key requirement is to be able to access a common directory to find application components when they've been cloud-deployed. This is largely an addressing issue, meaning that the mechanisms will vary depending on how addresses are assigned to cloud and data center components. Directory mechanisms (including DNS and UDDI) or "elastic addresses" like those Amazon uses help link cloud components that might be deployed anywhere with other components to exchange work. Many DevOps tools support integration as well as deployment, and it may be valuable to focus support on those tools to encourage hybrid cloud users to adopt them.
You can view what some users and providers call "platform services" or "Web services" as an extension to integration. An operator that offers either Platform as a Service or Infrastructure as a Service can also provide a component of functionality -- ranging from Database as a Service (DBaaS) to content caching and delivery -- that may be integrated with user applications in the cloud or the customer's data center. Many cloud providers see these platform services as a means of increasing their average revenue per user and accelerating cloud adoption, but they can complicate the whole application lifecycle if the provider doesn't properly educate customers.
DBaaS is perhaps the best example of this. A terabyte-sized cloud storage system might be accessible from a hybrid application and an on-premises data center component using standard per-block I/O, but the access costs and network demands would be significant, not to mention the effects on performance. If the provider offered a "query" service in which a SQL query was instead sent to a cloud database, only the query request and results are exchanged over the network. It can be a significant boost to cloud adoption for mission-critical applications, but taking advantage of it would require hybrid cloud customers to structure their applications to send queries rather than issue block I/O commands. That means providing application guidance even at the development/purchase point of the lifecycle.
All mission-critical enterprise applications today are not going to require hybrid cloud services, and without those applications, the opportunity space for cloud computing shrinks considerably. Support the hybrid cloud customer well and you'll have the best possible cloud revenue stream and highest profits.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.