We're not all going to the public cloud overnight. That’s why the hybrid cloud is a critical concept for enterprises. The idea of a hybrid cloud is that you keep your server farm and massive investment in VMware, Oracle, and whatever else you bought over the last 20 years or so and relocate some workloads to the public cloud. You’ll also create a private cloud with many of the same features of a public cloud. Meanwhile, you may have some apps that aren't going to make it to either a private cloud or public cloud.
The hybrid cloud lets you run your infrastructure locally, get some of the features of the cloud in terms of tenancy, provisioning, and scaling, and then be able to relocate an app to the public (or perhaps private) cloud when you're ready. In reality, some data or services may never make it up to the public cloud for regulatory, security, bandwidth, or cost reasons.
The incremental nature of the hybrid cloud also has real benefits, because it lets IT test the cloud waters carefully and even pull back if needed.
To get to the cloud—be it private or public—you need core services available, a workable strategy for what to move first and where, and what to leave behind.
The core services needed in a hybrid cloud
There are three types of core infrastructure services that must exist in both your on-premises datacenter and in the public cloud to make a hybrid cloud strategy work:
- Security and identity: You need a way for users to authenticate and be authorized to your applications both locally and in the cloud. This needs to be done in a centrally manageable way that doesn’t require each app to reinvent security.
- Search: You need to find things in both places. You also need a search solution that lets you find things across both environments while respecting security because you’re not trying to have your behind-the-firewall data find its way to the internet. (Disclosure: I work for Lucidworks, which provides a search solution.)
- Core data: There are databases in the cloud, of course. But not everything will be in an RDBMS; essential enterprise data without which none of your business apps can function also exists in apps and other repositories. You have some core data without which none of your business apps can survive. Some of that data is now in the cloud anyhow, with apps like Salesforce. However, you’ve got other data that you need to be in the cloud as well.
What to migrate to the public cloud
Generally, your applications don’t get moved to the cloud until they are updated; that is, when you have to invest in them again anyhow. To decide what is moved to the cloud when it is updated, you need to answer these questions:
- What will it cost to run? You may save money on equipment and management costs for apps migrated to the cloud. However, it is a myth that it is always cheaper in the cloud. If those servers are burning CPU cycles and outputting massive amounts of data for relatively few users 24/7, plus the app is never updated and you’re not really expanding it, it is hard to imagine a scenario where it is cheaper in the cloud.
- What is the application’s architecture? An application built on modern web technologies is much easier to migrate than an app that uses, say, CORBA. Older architectures didn’t anticipate the cloud, so you essentially have to rewrite older apps from scratch to make them cloud-capable.
- Do you have team support? if the development team and infrastructure team don’t support the move, you gave a very difficult obstacle—and a very likely failure.
- What are the regulatory issues? If you’re required to comply with regulations or require various certifications, you need to make sure the cloud infrastructure will let you do so. Those requirements can get very complex in the cloud: Is the app and/or data in a country allowed by regulations? Does your cloud vendor have the right certifications? Can an app in the cloud even meet those requirements?
- What are the dependencies? Are all your application dependencies available from the cloud?
- How will your data be found? If you move your data to the cloud, will anyone be able to find it? How will you publicize it locally? How can it be found and augmented with internal data?
By the way, these same considerations apply to migrating to a so-called private cloud, which is an on-premises datacenter that uses many of the same technologies and architectures as a public cloud. In some cases, such as around regulatory compliance and application dependencies, these issues are easier to address when migrating to a private cloud. But you also have to secure, manage, evolve, and operate that private cloud infrastructure yourself—it is still your datacenter, after all.
What to leave on your dedicated infrastructure
Some apps just ain’t going to a cloud, hybrid or not. For the long term, you may want to think about finding new applications or implementations. In the short term, you probably want to leave any application on-premises if it is:
- Really stable or static: You have an app that isn’t being updated, is still used, and is very stable. Maybe it isn’t time to rock the boat.
- Not webby: Your app is some kind of DCE monstrosity written in the early 1990s and does everything by fixed addresses. Maybe it is a 4GL desktop app that you use Terminal Services to get to. Any app using pre-web/pre-cloud architecture and technologies is difficult and expensive to migrate. Look elsewhere for migration candidates.
- Highly dependent: If your app depends on a lot of other stuff that isn’t already cloud-enabled, save it for later.