So much is so great about the cloud that anyone who talks or writes about it is in danger of sounding like they are in the midst of some kind of religious rapture. Naysayers, on the other hand, are few and far between. The truth is that the cloud—by which most people mean the public cloud embodied in services provided by the likes of Amazon, Rackspace, GoGrid, and HP—is a tremendous opportunity that can benefit most kinds of organizations. It offers instant access and agility, infinite capacity and scalability, moderate costs, and the ability to “switch it on and switch it off.”
Still, anything that comes close to being “too-good-to-be-true” has to have some downsides. For example, it is important to remember that cloud providers have no incentive to help you keep your costs low. Switching on instances is easy, but it is most often manual and sometimes complicated to switch them off. Not only do you have to remember to stop machine instances that are not being used, but you also have to manually remove unnecessary snapshots and release unused elastic IP addresses among other things. Who knows how many rogue instances are out there in the cloud, conceived for a specific project and then more or less abandoned, but still steadily incurring charges?
That’s a problem in and of itself, but the even bigger downside of moving to the cloud is lock-in. Yes, lock-in—just like with the old proprietary operating systems offered by IBM, Novell, or Digital Equipment Corporation. Just like the “old days,” once you are seduced onto the platform of any given cloud provider, your days of freedom are numbered. You may get lots of benefits and you may even love the arrangement, but should you ever decide to go elsewhere or bring your data and applications “back home” to your own premises, it could be problematic.
That’s lock-in.
It’s not the kind of problem you’d initially expect to find in the cloud— the paragon of a more flexible and even democratic IT space. Lock-in is a particularly serious problem when applications are developed within and for a particular public cloud environment. Unless you deliberately avoided using vendor-specific features, the chances of moving your application elsewhere become practically nil.
It’s not that there isn’t a role for the cloud. The cloud is going to be central to more and more IT activities. However, as you build an architecture for your organization, it is critical to avoid one-way streets that can lead to dead ends. Although the public cloud often integrates standards, each cloud Infrastructure-as-a-Service (IaaS) vendor brings specific elements to the table, such as ease of use features that end up becoming layers of lock-in. Many of these features are common to multiple IaaS providers’ offerings, but the implementation details are platform specific and nonportable. And that’s where the problems lie.
Cloud vendor lock-in isn’t always quite as blatant or complete as, say, building an enterprise around Digital Equipment Corporation’s VMS was in the minicomputer era. Instead, the cloud usually acts as a giant sponge, happily absorbing whatever workloads you choose to offload. But “squeezing the sponge” to get your applications or data back from a given vendor isn’t so easy because the cost and complexity of migrating off of the cloud providers are so high. You need to be conscious and deliberate in the choices you make about the services you consume from your cloud provider.
One option to help avoid lock-in is to choose a platform stack that can be deployed anywhere: on premise, private or public cloud. This provides better control and tooling at every stage of a move to the cloud and also reduces the leverage that a cloud provider has over you. You can also avoid cloud lock-in through adoption of Platform-as-a-Service (PaaS) technology. PaaS facilitates the deployment of applications without incurring the cost and complexity of buying and managing hardware and software or of endless provisioning cycles. It is today’s version of middleware all bundled together and can be a critical “next step” for organizations as they move from on-premise to cloud. Many PaaS providers offer a private cloud option, which serves as an insulating layer that prevents cloud-vendor lock-in.
In the PaaS model, you can build functionality using the tools or libraries that are built in to the PaaS, as well as whatever is familiar from your own environment. And, critically, PaaS gives you the tools to control configuration and manage deployment, obviating dependence on most of the cloud-vendor specifics that lead to lock in.
There are many different PaaS vendors offering variations on this theme. Selecting from among them is beyond the scope of this article. However, if you are adopting PaaS to avoid cloud-vendor lock-in, you should make sure that your PaaS investment includes the ability to create, connect, and integrate applications and data and do so across a wide range of environments (another key way to prevent lock-in). In addition, PaaS should provide tools that are easy to use so that you are as productive as possible.
So, in considering a move to the cloud, make sure you are moving toward best practices and building or maintaining an architecture that is flexible. Consider these “rules of thumb”:
- Make sure you have controls in place so that you don’t consume more cloud resources than you need, especially if it is just because “someone forgot” to throttle back a cloud activity.
- Cloud is often but not always less expensive than on-premises. Be sure to have metrics in place and consider how you are evolving a given function. It might turn out that building your own capacity on premises or in a private cloud actually makes more sense financially.
- Look for approaches that are modular in nature and allow you to mix and match functionality to meet your needs, while only paying for what you use.
- Look at open source options. Open source can reduce your price of admission to mission-critical infrastructure. Open source offers direct access to the source code and those who wrote it—which can be a positive if you have sufficient in-house capability to make use of this information.
- Look at PaaS as a potential stepping stone that can help you chart a path to hybrid and cloud deployments.
Then, as you look to the cloud to add capacity, cut costs, streamline dev/test, or add new functionality, be sure to keep the blinders off.
As a famous writer once warned, “Those who cannot remember the past are condemned to repeat it.” We are on the cusp of a new, cloud-centric age in IT, but we should recall how unpleasant vendor lock-in was in the old proprietary era. The cloud should be your ally in moving to the future, not your enemy.
