it
Legacy Apps Make the Case for the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John Considine
We often talk about CloudSwitch moving legacy applications to the cloud in a simple and secure way; this raises the question of what exactly we mean by “legacy.” To be more specific, we mean a broad range of apps—including third-party, custom and customized off-the-shelf applications—basically any application that has been developed in your current environment without specific design for a cloud.
It turns out that these existing applications are very important in cloud computing. When we started building CloudSwitch, we were focused on the hybrid cloud computing model; that is, some components must stay in the data center and other applications and functions can move to the cloud. However, it became apparent that “stretching” applications between the data center and cloud only works for certain types of deployments due to the added latency between the data center and the cloud. For this reason, we recommend moving as much of a multi-tier application to the cloud as you can. This allows the application to continue to run with low latencies between the different components. Sounds obvious, but this is where a whole new set of problems arise, and it’s what causes people to start talking about the challenges of moving legacy applications to the cloud.
In order to operate a multi-tier application in the cloud, you need to be able to control the application(s), infrastructure, and operating system, including things like a database tier, middleware, and custom applications. This also means that you have to “cloudify” each of these components. Suddenly you are looking at a lot of work, and potentially facing failure because some of those tiers can’t be modified to run in the cloud.
We saw a great example of this when Microsoft’s Azure service first launched. The initial release of Azure allowed application developers to build .NET applications and run them seamlessly on their local machines or in the Azure cloud. However, people trying to use this cloud usually had other applications/databases/etc. that were part of their solution, and there was no way to run these in Azure. This meant that there were a lot of things that could not be moved to Azure since “stretching” the application caused unacceptable latency and there was no way to connect the Azure deployment to the data center-side applications. Microsoft has since expanded the capabilities of Azure, but there are still many types of applications and services that cannot run in their environment.
Given all the challenges, why is it worth bothering to move legacy applications to the cloud? For most enterprises (as opposed to new ventures and SMBs), legacy apps by definition occupy the majority of the existing IT footprint, far more than newer applications, let alone those designed specifically to run in a cloud. In many of the companies we’ve worked with, legacy apps are well over 75% of the data center footprint, and they’re constantly expanding and creating needs for more capacity. Legacy apps tie up internal processing and storage resources, sometimes continually, sometimes in a “spiky” way to meet occasional massive needs. Their demand for computing power is usually growing (or skyrocketing), and contending with other applications. The enterprise then has to make tough choices about whether to buy more equipment or put up with degraded performance.
By providing access to virtually unlimited resources on demand, the cloud can bring a new level of elasticity and efficiency to a company’s IT environment. Legacy apps are often the best candidates for moving to the cloud, especially in cases where they’re infrequently used, or only need to scale for new releases or for seasonal/marketing-driven events. One of the best use cases for the cloud so far is the ability to offload this type of resource-consuming set of apps to a lower-cost cloud infrastructure, freeing IT to focus limited internal resources where they’re needed most.
The Hidden Costs of Internal Clouds
By Ellen Rubin
A public cloud can provide access to computing resources that many companies would otherwise never be able to afford. The arguments for the cloud are well-known by now, but remain compelling—no up-front costs, virtually unlimited computing power on demand, and highly efficient pricing where customers pay only for resources used. There’s also less pressure on corporate IT departments that are charged with managing the infrastructure and budgeting for new equipment to keep up with demand.
But concerns about security and loss of control in public clouds have led to an alternative model—the internal cloud—that replicates the cloud environment inside the corporate firewall. Within these boundaries, enterprise users can provision computing resources as needed, using the cloud’s self-service capabilities while leveraging data center services. Internal clouds are often referred to as private clouds, but since private clouds can also be found in external environments, the “internal” designation is a more precise term for what we’re talking about here. (RightScale's blog post provides helpful definitions of the different cloud variants.)
With servers, applications and data within the enterprise walls, internal clouds can provide many of the benefits of cloud computing without the potential risks when the computing environment is provided by a third party. Unfortunately, the economics of internal clouds makes them inherently less efficient than the public cloud, especially as new technology makes the public cloud safer and more reliable. Here are some of the reasons why:
- Infrastructure costs: Deploying an internal cloud requires building out the infrastructure to support the needs of all enterprise users. In addition to acquiring the necessary hardware and software, this includes things like configuring the network, allocating storage, paying the electric bill, and providing square footage for the equipment. Plus, all of this infrastructure has to be managed and supported on an ongoing basis.
- Over-provisioning: Just as with traditional IT infrastructure, anticipating resource requirements for an internal cloud is difficult since applications run at varying usage levels. Some applications consume resources fairly steadily while others require occasional bursts of massive computing power. Companies may have no choice but to over-provision, where some equipment sits idle most of the time in order to have resources available for peak periods. (Meeting these short-term usage needs is one example where the elasticity of public clouds really pays off.)
- Building the management plane: As Jon Brodkin points out, building an internal cloud is about more than just virtualization. One of the key benefits of cloud computing is the self-service aspect, where users can access resources as needed via a self-service portal, which then execute in the cloud automatically without administrator intervention. Building this control plane is another substantial step when implementing an internal cloud.
For all of these reasons, the internal cloud carries a cost overhead compared to leveraging the resources and self-service framework already provided by public clouds. Ironically, much the same protection and control offered by internal clouds is becoming increasingly available in an external public environment. So enterprises may find that a public cloud may provide a more cost-effective home for many (or even most) of their applications.
Internal clouds can make sense for the most business-critical requirements or those that need specialized hardware or have regulatory compliance issues. Focusing internal resources on these types of applications would greatly reduce the investment required to build, sustain and grow enterprise infrastructures. While some applications may always need to run internally, many companies have dozens of others that could run more cost-effectively today in a public cloud, providing computing power on demand along with required security, agility and scalability.
At CloudSwitch, we provide technology that allows companies to take full advantage of the resources and savings that the public cloud has to offer, while integrating seamlessly with their internal environments. Applications deploy automatically, are free from lock-in, and stay tied into internal data center services. In short, the enterprise gets the protection and control formerly found only behind the firewall, and can combine the best of internal and external cloud offerings with maximum agility and value.
