Distributed cloud service is a growing phenomenon. It fills several roles, distributing data for use by distributed applications, for data protection, and for other reasons. We have been seeing an increase in the number of distributed applications. Non-distributed applications lack the resiliency that is required to work within a cloud, whereas distributed workloads add a certain amount of resiliency to an application. Depending on how they are architected, the lack or failure of one part of a distributed application won’t bring down the entire application. Use of multiple clouds ensures your eggs are not all in one basket, so to speak.
Does this mean that an application needs to be distributed to be a member of multiple clouds? In many ways, the answer is, “Yes, it does.” However, the application does not need to be specifically designed for distributed use; you can distribute across clouds using techniques such as meshed load balancers for a web application with sharded databases on the back end.
Why is this important?
To be a cloud, five items are required:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service.
Yet, none of these items provides state, resiliency, or even availability. All of them address service delivery, but not service creation. A cloud ends up providing just the basic building blocks of a service. What you put on top of the cloud is what matters. How you put an application on top of the cloud is based on that application’s needs for resiliency, data protection, and volume, and on its nature.
Migrating applications to the cloud is more than just moving virtual machines into the cloud; many tools, such as HotLink, CloudVelox, Veeam, and Zerto do this well enough. Migration is more about how those applications work within the cloud. It is about the connections between tools running within the VMs. Ultimately, it’s about applications and their attendant data. The intersection of data and application needs to be considered when moving to the cloud. To provide resiliency for an application using a cloud service, you may use multiple data centers within a cloud, or even multiple clouds. When you use multiple clouds, you end up with a hybrid cloud approach to your application.
So, migrating to the cloud takes a bit more work, and you need tools and an architecture to maintain the following:
- Network connections
- Network services
- External services
- Data protection
- Security
- Application management.
You also need a method by which to manage the performance of an application, perhaps by using new tools, or some old ones. Everything you choose to use, whether for security, data protection, or performance management, must work within multiple clouds and be hypervisor agnostic. Since we are virtualized, using tools under the virtual machine is what we do now for data protection and security. How these translate to the cloud is still being settled; one common administration question is whether or not we need clouds that only support our hypervisor.
You could go that route, and perhaps it would work—you never know what a cloud service provider will allow you to do until you ask. However, you may be unnecessarily limiting yourself to just one technology. Perhaps it is time to pick tools that you can use anywhere. This sounds like reversing direction, but as we move toward the cloud, the data interactions get more interesting, and they occur at layers we have to control and work within. If they occur outside our control, we do not know if we can trust the end result data.
Tools that work anywhere generally work as agents or on the wire, or they can be 100% cloud-based themselves. Some examples are New Relic, Splunk, CloudVelox, and HotLink. The real questions become, “What is it that we want to do? What tools exist, and how do they integrate into our chosen management platform?” Perhaps we’ll have to create mash-up NOC views using available APIs.
When you design an application for the cloud, whether it is just a single virtual machine or hundreds, you need to consider how to manage the agents required to do security, performance management, and other items. Companies including Intigua, Puppet, and others make programs that service this gap.
The long and short of it is that you cannot just move an application to the cloud and expect it to work without some help. You’ll need to figure out how much help is needed to deploy the application, and you’ll need to focus on minimizing the help and support needed after deployment. You’ll also want to archive the lessons learned from this process, so that the next time you migrate something to the cloud, that information is available to help do it correctly.
Managing applications in the cloud requires an architecture that can learn about the application during deployment, create a blueprint, and from there deploy the application as well as learn from any mistakes and update the blueprint. Is this built into your application today? Is it built into your cloud migration strategy?
What do you do today?