Nearly every company can find benefits in public cloud services, but most cannot justify a private cloud. Many...
enterprises have virtualized data centers, but see no need to go further. These enterprises run mission-critical applications on dedicated servers, where they're likely to stay. Hybrid cloud computing seems like a possibility, but the private cloud portion remains an obstacle. So, what if companies could create a hybrid cloud without that private cloud commitment? It's possible -- and easier than you'd think.
One barrier to hybrid cloud adoption has been private cloud use. A traditional hybrid cloud is a combination of public cloud services and a private cloud with orchestration and automation between the two. However, some companies are using cloud-friendly integration to combine public cloud application components with components that remain in the data center. And DevOps has made this possible.
Installing any application, particularly hybrid cloud apps, traditionally breaks into two phases: deployment and integration. In the deployment phase, copies of the application's components are installed where they will run. The integration phase connects components to one another and to application users. And while the deployment phase changes when you adopt the cloud -- public or private -- integration remains the same. You can reduce the turmoil of hybrid cloud adoption by leaving your on-premises data center resources in house.
DevOps saves the day
IT departments typically turn to flexible DevOps tools for app deployment -- in and out of the cloud. Tools like Chef and Puppet accommodate a variety of cloud management systems, which allows administrators to select the best public cloud services. But it's often overlooked that these tools both deploy and integrate application components; deployment doesn't have to be in the cloud. With DevOps, it's less important for the private cloud portion of a hybrid cloud application to actually reside in the private cloud.
DevOps enables businesses to take advantage of all the public cloud's benefits without changing internal IT practices to adopt a private cloud. There are three benefits to doing so:
- Many mission-critical applications are difficult to migrate to the cloud (even private cloud) for two reasons. First, the software was designed for dedicated server use. Second, the application's performance and stability requirements are best met with dedicated server and storage resources. Hybridizing these applications without moving core components to a private cloud offers cloud benefits to a whole new set of apps.
- Applications that run on older software platforms may be difficult to migrate to a private cloud. The business case for hybrid cloud is improved when these apps can simply run as they are.
- To run a private cloud, an organization needs tools and skills that most don't possess. Additionally, your company may not have enough IT staff or skills to create an efficient private cloud resource pool. Hybridizing public cloud services with internal non-cloud components can eliminate this.
Hybrid cloud computing minus private: How-to
To take advantage of a hybrid cloud without a private cloud commitment, look at the application workflow to determine which of its components can move to the public cloud. Generally, those components will be the front-end applications. Therefore, you'll need to develop cloud deployment practices for these apps.
The second step is to separate the application component deployment process from the component and user integration processes using workflows. The goal of deployment, from a hybridization perspective, is to create a set of directory entries that allow components to be located. In the same terms, the goal of integration is to thread connections through these directory entries to move information. It's crucial not to mix the two or you'll have to redo all your application lifecycle management (ALM) practices and tool decisions each time you make a change with your cloud provider or internal IT platform.
The biggest problem for hybridizing internal non-cloud components with public cloud services is elastically moving components across the cloud boundary on-demand or in failover scenarios. Don't plan to cloud-host something that you're not allowed to run in the public cloud for internal security or compliance reasons. Deal with the reliability, availability and scalability of the app components that need to run internally in other ways.
When you can cloudburst an on-premises application component, remember the principle of separating integration from deployment in DevOps and ALM practices. Component deployment differs depending on where it's hosted, but integration is the same if you've ensured both cloud and non-cloud deployments leave a trail of directory entries that represent each deployed component. Integration only works on these; as long as both cloud and non-cloud deployments result in the same integration directory entries, you can use the same practices and tools to perform the integration.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Re-defining the true meaning of hybrid cloud
Five hybrid cloud management questions
What to avoid with your DevOps strategy