Legacy Apps
Top 5 Questions Asked by CloudSwitch Customers
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Dave Armlin, Director of Customer Support
New CloudSwitch customers and prospects are coming up to speed every week and there are a number of questions that show up frequently enough that I thought it would be helpful to cover them in a blog. When we work with customers, our goal is to make their experience getting started in the cloud fast and easy, and to make sure they feel comfortable with the ongoing simplicity and security of the CloudSwitch model.
Here are their top 5 questions:
1. How do I move applications to the cloud?
CloudSwitch literally makes moving an application to the cloud a simple drag-and-drop operation. A virtual machine (or group of VMs) is selected from a VM location (vCenter,ESX machine, or CIFS share) in the CloudSwitch user interface, the target public cloud region/zone/location is selected, and the machine is moved over a secure tunnel to the cloud. Storage for the virtual machine in the cloud is automatically allocated and encrypted, and keys are kept under the customer’s control.
Virtual machines that are moved to the cloud retain their MAC and IP addresses, since the CloudSwitch appliance acts as a layer-2 bridge allowing these machines to appear as if they are running in the data center behind your firewall.
2. What applications should I move to the cloud?
A wide variety of apps are good candidates to be moved to the cloud. As Ellen Rubin blogged about recently, legacy applications are certainly great candidates for offloading from your internal data centers. Web servers and web applications like SharePoint, .NET, J2EE/SOA, Drupal, Wordpress, Wikis, corporate intranets, or batch processing applications are all good candidates as well.
When selecting applications for the cloud, you need to be aware of latency between the data center and the cloud. Latency is a function of physical distance between the data center and the cloud region you’ve selected. For instance, a data center on the East Coast in the US should see around 20ms latency between the various public cloud regions on the East Coast.
Select applications and place them in closest proximity to the virtual machines and data center services that are accessed most by these applications. For instance, a web application that utilizes a database heavily may perform best if the web tier and the database are both deployed to the same cloud and region. A web application that utilizes a database infrequently and caches results may perform well with the database in the data center and the web tier in the cloud.
3. What changes to my network do I have to make to use CloudSwitch?
Minimal. Outbound port 443 to the Internet has to be opened for the CloudSwitch appliance to create a secure encrypted connection to the cloud. This is outbound traffic only, nothing inbound. There are no changes to your network configurations.
The CloudSwitch appliance requires promiscuous mode and forged transmits set to “Allow” on the Virtual Switch or Port Group for the network adapter assigned to CloudSwitch in your virtual environment. For more information, check out this blog article on networking and ESX.
4. Can I get a virtual physical console to my machine in the cloud?
Yes. CloudSwitch provides a virtual console accessible from the CloudSwitch user interface via a browser that allows you to interact with the base system to make network changes or other tasks one might perform at a physical console. Access to this console can be secured to specific users or groups using Role-Based Access Controls (RBAC) in the CloudSwitch user interface.
5. Can I allow traffic from the Internet reach my machines in the cloud directly as opposed to going through my corporate firewall?
Yes, CloudSwitch supplies a cloud firewall that allows you to assign a public IP to a virtual machine and control access to VMs in the cloud from the Internet. Pavan Pant, our Director of Product Management, blogged about this a while back. You have full configurability for permissions/access to all cloud resources through this firewall.
The Trouble with Legacy Apps
By Ellen Rubin
Last week, I was on a panel at the CompTIA Breakaway conference in DC, with Scott Crenshaw from RedHat and Ron Culler from Secure Designs. Scott made an interesting comment about the three types of applications out there: (1) new apps that are being architected from scratch for the cloud; (2) legacy apps that are being re-architected for the cloud; and (3) everything else. It was a useful framework for our discussion about cloud migration and security, but it also made me think a bit about the issue of legacy apps and why these remain so controversial for the cloud industry.
If I had a dime for every panel discussion that led to a heated debate around whether or not to re-architect for the cloud… I think the heat around this issue reflects some underlying confusion about how to handle all those “annoying” legacy apps. It’s an area of particular interest to us here at CloudSwitch, so I’d like to share our thoughts and hopefully generate some additional productive discussion in the industry.
Let’s start with (1) new apps. High-profile customer stories from companies like Netflix are creating momentum around the idea of building enterprise apps – even mission-critical ones – to run specifically in the cloud. Of course, start-ups and SMB’s have been doing this for years, since they quickly realized that the cloud provides a low-capital way to get their businesses started and frees them from long-term expensive contracts with hosters and colos. But the idea of building greenfield enterprise apps that take advantage of the cloud’s agility & scalability is only slowly gaining traction.
This is due to several concerns of enterprise stakeholders. While individual developers love the idea of coding directly for the cool new platform of the cloud (without fighting corporate IT for access to servers), corporate IT often feels threatened by a new process/platform that may make them less relevant or able to set policies and standards. Corporate IT also recognizes that as the cloud apps go into production, all the serious issues around reliability, performance and integration will fall on them and may be extremely complex and difficult to manage. Security and networking teams have the expected concerns about changes to existing policies and access, and overall loss of control. And all groups share a fear of cloud lock-in since you’ve essentially built your app to run in a specific cloud.
Next there’s (2) teaching old legacy apps new tricks by re-architecting them for the cloud. This is appealing because it allows enterprises to move off outdated (and often costly) OS’s and hardware. It also allows the app to get true benefit from the scalability, geographic distribution and rapid provisioning of the cloud—and to run better in an environment where server performance and availability can be highly variable. Traditional legacy apps are often limited to scaling up vs out, and have requirements for network and storage configurations that may not exist in the cloud.
So why not re-architect? Most of the legacy apps we see at enterprise customers are either non-mission-critical (tier II, III) or less frequently used, with occasional bursts during peak periods. It’s not always economical to re-architect these or to spend precious developer resources on building/testing/supporting the new apps. Plus, the apps themselves may have some inherent limitations due to the age of their architectures (think SAP, SAS, Oracle Apps, etc. – apps that were designed long before the cloud gained attention, and that may not behave well if re-architected or may pose licensing challenges).
And finally, there’s (3) the “everything else” category – legacy apps that include all sorts of custom apps designed for specific purposes and business uses that may or may not still be important to the enterprise. You’d be amazed at how many of these there are. A typical F1000 enterprise can have hundred or even thousands of apps, and very few are mission-critical or worth the effort to re-architect. But there they are, sitting in your data center, still important for some particular group or maybe for compliance reasons, so you don’t want to get rid of them, either. The cloud is a great place to relocate these apps, and provides options for closer geographic proximity to the actual users, as well as the cost benefits of shutting down apps when not in use.
I find that among the “clouderati” there’s often a lack of interest in this last category of apps, mainly because they’re not very sexy or high profile. Enterprises, on the other hand, are pretty interested in them since they represent a large plurality (if not majority) of the apps that need to be considered in a broader cloud strategy. Also, since by definition these are not the critical apps that the enterprise depends on, they’re the easiest to try first in the cloud to show a low-risk success story to potential cloud users.
Large cloud providers and cloud enablement vendors are starting to take greater notice of legacy apps (both the kinds that should be re-architected as well as those that should be left alone). Amazon’s VPC strategy and VM migration tool reflect a growing recognition of legacy app requirements, as does VMware’s vCloud Director strategy, and Citrix’s CloudStack/CloudBridge. The industry as a whole has begun to focus on making it easier to migrate legacy apps and keeping them integrated with the enterprise environment they rely on.
This is good news for enterprise customers, and no surprise to us at CloudSwitch, where legacy apps have always been part of the vision. We believe that unless legacy apps can be safely and seamlessly run in any cloud environment with full enterprise control, enterprises will hold off adopting cloud in a major way. For every Netflix out there, there are hundreds of enterprises that will not build apps specifically for the cloud, or will only do this for a tiny percent of their application portfolios. And regardless of which category of app we’re discussing, you still need these apps to tie into enterprise management/monitoring systems, data, networking and security. Legacy apps are the proving ground for the cloud’s enterprise-readiness and maturity, and the industry should embrace this challenge head-on.
What IT Managers Should Learn from Public Clouds
By Ellen Rubin
Corporate computing is going through a fundamental shift — moving to a world that’s largely cloud-based, self-service, and highly virtual with shared resources. Rather than go through their IT departments like they have for decades, users will simply specify how many cloud servers they need and for how long, and provision their own resources with a few mouse clicks. I recently read an interesting post by Rodrigo Flores, observing that the growing acceptance of public clouds is also changing the role of corporate IT departments, and they’ll have to either adapt or die. I’d like to make a few suggestions about how they can adapt.
First of all, they need to face reality. IT is driven by the need for agility, elasticity and cost-efficiency, and that can be provided most effectively in the public cloud. A year or two ago, most pundits were saying that large-scale adoption was inevitable — now the transition is well underway. Individual users and departments are already making inroads into the cloud to take advantage of agility not available internally. In many cases they’re not waiting for permission or help from corporate IT— they’re moving ahead on their own.
The growing emergence of public clouds creates an alternative to the traditional data center, while lowering the costs of infrastructure services. As cloud computing takes hold, the impact can prove unsettling for corporate IT departments that find themselves increasingly evaluated against the fast service and flexibility provided by public clouds. How will corporate IT departments fit in? How can they maintain their relevance when users can simply go to the cloud and get the servers they need immediately, often with better service than is available internally?
Rather than viewing public clouds as a competitive threat, corporate IT should embrace cloud computing and recognize their new role — serving as a trusted broker for the resources that users need, whether in a public cloud or internally depending on where the application belongs. Corporate IT becomes a much more agile organization, leveraging public clouds and internal clouds within an integrated framework, and IT professionals providing the front-facing infrastructure and support services that make it work.
But corporate IT still has much to learn about how to design and support this new environment, with virtualization being only the first step. To gain this expertise, they need to look to the public cloud — Amazon, Terremark, Savvis, Rackspace, Microsoft, etc. The infrastructure and processes that cloud providers have created at tremendous effort and cost can provide a guide for how corporate IT departments are going to operate in the very near future. It’s an idea that hasn’t yet received much attention from industry observers, but we’ve been hearing it a lot lately from our customers, particularly those thinking strategically about the cloud.
Thus, corporate IT has another incentive (in case they needed one) to take the lead in moving their companies to public clouds. As they plan their own agile environments for internal users, public clouds are where they’ll learn the best practices needed to make it work:
- Building the self-service portal: Corporate IT will need to make self-service for computing resources as simple and robust as it is in the public clouds.
- Managing a multi-tenant environment: Cloud providers deliver rapid provisioning at low cost by supporting large numbers of users on a shared infrastructure. Corporate IT will need to replicate this environment, while providing mechanisms that allow applications to be moved out to a public cloud or back again.
- Scaling efficiently: Cloud providers use several different scaling techniques and policies to keep up with growing demands, and corporate IT can learn a great deal from them about how to make trade-offs and automate wherever possible.
To sum up, corporate IT should look to public clouds as their most valuable resource — often far more agile, elastic, and cost-effective than internal resources. They’re where many enterprise applications (perhaps the majority) will soon run. In addition to their inherent advantages, public clouds also have much to teach. The lessons will come in handy as IT departments discover their new strategic role as champions of a more agile corporate computing environment. CloudSwitch technology makes that new world much easier to build and manage, so corporate IT can drive innovation without losing the security and control they need.
Legacy Apps Make the Case for the Cloud
By 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.
Legacy Apps: The Next Frontier in the Cloud
Although cloud computing momentum continues to build and scarcely a day goes by without a new cloud announcement or study, there’s been little real enterprise adoption and almost no meaningful case studies. In part, that’s because early cloud providers and vendors were focused on developers and technology start-ups when they designed their offerings, and larger, more established organizations were rarely on their radar screen. While start-ups can easily embrace new technologies and architectures, enterprises have far more constraints and have been largely limited to “tire kicking” the cloud with small applications that aren’t particularly meaningful for the business.
Cloud computing is now entering a new stage as CIOs and IT managers recognize that cloud computing is going to become an integral part of the enterprise computing environment. For it to be strategic as opposed to experimental, they need to know that the cloud can integrate with their existing data center infrastructure and incorporate the legacy applications that reside there. That’s where the major pain points, complexity, and costs have always been, and where the cloud can potentially offer its greatest returns. In our discussions with CIOs, we hear this theme over and over.
Legacy apps cover the entire installed base of applications running on a company’s internal infrastructure. They include everything from highly-used apps that are optimized for particular hardware to older versions of apps that must be maintained for specific customers as well as test and development environments, and apps used for internal purposes such as training. The true enterprise payoff for cloud computing will come from the ability to offload a wide range of legacy apps that don’t need to run in the data center to a cloud environment where they can be managed more cost-effectively. Not all legacy apps will make sense to move to the cloud initially (or perhaps ever), so the trick will be to select the right ones.
As Bernard Golden points out, the conundrum is that while putting legacy apps into the cloud can provide huge value for the enterprise, it’s also where the biggest hurdles lie. While a new application designed specifically for a cloud can usually be rolled out fairly easily, legacy apps come with a whole new set of challenges. Many of today’s cloud offerings were built for serving up web apps and Amazon-type storefronts, and have attributes that were not originally designed with the enterprise in mind (non-standard storage, isolated networking, and multi-tenancy are some examples). The result is lots of manual re-configuring, complex engineering, and trial and error before the enterprise application is able to run in the cloud. And once the app is in the cloud, it’s completely separate from the existing management tools and policies, and potentially locked-in to the cloud for which it has been re-architected. This lack of fast, incredibly simple ways to migrate legacy apps to the cloud and back without modification is one of the major factors holding back enterprise cloud adoption today.
CloudSwitch is focused on eliminating the barriers to moving legacy apps to the cloud. We believe applications should be able to run in the cloud “as is”, without worrying about the technical hurdles that today makes cloud deployments complex, time-consuming and expensive. We’re excited to be part of the “next frontier” in cloud adoption, working closely with enterprise customers and cloud providers.
