moving to the cloud
You're Ready to Move to the Cloud. Now What?
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy The CloudSwitch Team
In our many discussions with enterprises of all sizes and industries, we’ve seen that the majority are starting to include the cloud in their overall IT computing strategies. The benefits of fast provisioning and pay-on-demand are extremely compelling. At the same time, it can be daunting to figure out that first step into the cloud.
We are working closely with companies as they evaluate the cloud, making it easy and secure for them to get started. According to one of our customers, with CloudSwitch they could deploy and measure the real results of running a “lab on demand” in the cloud for internal users in the same time it normally takes just to write a position paper on the cloud for their board.
To help organizations move beyond “Now what?” we have developed a “Starter Kit” that provides best practices and simple steps for a successful move to the cloud. We’ve created the content based on our experience of working with customers during the past year, covering their most frequently asked questions, including:
- Which application(s) should I move to the cloud first?
- How hard is it to move existing applications to the cloud vs creating new ones?
- What are the advantages and disadvantages of private, public and hybrid clouds?
At CloudSwitch, we’re not just simplifying the way enterprises run applications in the cloud – we’re also simplifying their experiences taking that first step into the cloud.
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.
Security vs. Compliance in the Cloud
Security is always top of mind for CIOs and CSOs when considering a cloud deployment. An earlier post described the main security challenges companies face in moving applications to the cloud and how CloudSwitch technology simplifies the process. In this post, I’d like to dig a little deeper into cloud security and the standards used to determine compliance.
To codify data security and privacy protection, the industry turns to auditable standards, most notably SAS 70 as well as PCI, HIPAA and ISO 27002. Each one comes with controls in a variety of categories that govern operation of a cloud provider’s data center as well as the applications you want to put there. But what does compliance really mean? For example, is SAS 70 type II good enough for your requirements, or do you need PCI? How can your company evaluate the different security claims and make a sound decision?
SAS 70 (Types I and II)
SAS 70 is a well-known auditing standard that features prominently in many compliance discussions. It encompasses a variety of controls in different categories (physical security, application security, security policies and processes, etc.). SAS 70 is not a specific set of standards; instead service organizations such as cloud providers are responsible for choosing their own controls and the goals those controls intend to achieve. With SAS 70 Type I, an independent auditor evaluates the controls and issues an opinion, while the more coveted Type II is based on at least six months of active data. Accordingly, many providers will state that they are in compliance with Type I, and Type II evaluation is underway.
SAS 70 has some wiggle room, and you have to dig a little deeper to determine what the certification really involves. The savvy cloud customer will want to know not just whether a cloud is SAS 70 Type II compliant, but what controls they selected in order to get there. This is a question that people normally don’t ask, and under SAS 70 guidelines, service providers have no obligation to tell you. Thus, the level of transparency varies. Some providers may be quite willing to share their audit report describing their controls, objectives and methods. Others will explain that the information is confidential and delivering it would expose company secrets. Or some types of control information may be freely available and others off-limits.
PCI (and Its HIPAA Component)
A second major security standard in cloud computing is PCI. As the security standard for Mastercard and Visa, PCI has a known set of required controls, making it inherently more stringent than SAS 70 where controls are determined by the service provider. The inference is that PCI has stronger security than SAS 70 (and can command higher pricing). However this is not cast in stone—it depends on the SAS 70 controls that the service provider has chosen. Due to the more rigid compliance requirements PCI branding is usually harder to achieve than SAS 70. HIPAA is a subset of PCI, which means that if a cloud is PCI compliant, HIPAA compliance comes with it.
Compliance Building Blocks
Regardless of which standard is used, achieving compliance to run an application in a cloud involves building blocks, with the cloud provider’s physical infrastructure providing the foundation. Infrastructure controls include obvious things like protecting the facility from natural disasters, assuring reliable electrical power (such as backup distribution systems) in the event of outages, and backing up data in the event of a hardware failure. They also include controls governing the cloud provider’s processes and policies such as employee authorization to access the data center and how internal security reviews are performed and reported.
Sitting on top of the infrastructure controls is a separate set of application controls. Multiple levels of security are required, for example, the transport media must be secure and data must be encrypted once it leaves the data center with encryption keys under enterprise control. An application might meet SAS 70 or other standards within a company’s data center but not when it’s moved to a cloud because of exposures that may exist there or along the way. Likewise, a SAS 70 TII application in the cloud may not meet the controls if moved back to the enterprise datacenter, and could require a re-audit.
Deploying to the Cloud
There is a difference between compliance standards and what a company needs to feel secure. For data and applications that have regulatory requirements, compliance standards and audits are mandatory. For these types of applications, we’re still in the very early days for cloud computing—let’s face it, no company is going to put critical regulated applications into the cloud without the ability to conduct complete end-to-end audits. However, even for applications that do not require compliance, enterprises want to know that their data and applications are protected. Achieving security in these environments is where CloudSwitch is focused.
Cloud computing creates a division of responsibility between the cloud provider and the cloud customer. While the cloud provider needs to address infrastructure operation and protection, the customer is responsible for ensuring compliance for their application, and ultimately the overall solution. The central idea here is keep the controls separated between the cloud provider infrastructure and the customer application. If the controls mix, where for example the cloud provider has access to stored data, then things get very complicated. When this occurs, you have to worry about who in the cloud provider’s organization has access to your data, how and when they can access it, and how this access is audited and controlled. If the provider is opaque, then you can’t know. Even if the cloud provider is more transparent in their access polices, you have to evaluate those controls against your standards and potentially have to adjust your own controls in response. Further, you have to adjust to all changes in the cloud provider’s processes over time.
By keeping your systems isolated from the cloud provider’s infrastructure, you can minimize this mixing of controls. Placing protection mechanisms into your resources in the cloud can assure that data moving across the cloud provider’s networks and all data stored in their systems is encrypted. Combined with external key storage and management, your applications can be separated from the cloud provider’s infrastructure. This still requires that the cloud provider run its data center with proper physical security, power management, etc, but can greatly enhance the application level security that the enterprise needs. Finally, this separation can simplify the process of achieving compliance at the application level when running in the cloud. This isolation layer can address a number of the data protection controls by providing a uniform and repeatable process for encrypting data.
The days of cloud computing are just beginning, but with the right combination of cloud providers and additional technologies, it’s not too early to start doing real work in the cloud and to reap the benefits of this new computing paradigm. Our early customers are doing it, and so can you.
Five Things to Do Before Moving to the Cloud
Before moving an enterprise application to the cloud, you need to be sure that your expectations are realistic and your objectives match what the cloud can deliver. In this post, I’d like to share what we’ve learned from working with our beta customers, from their initial exploration of cloud possibilities to going live with a specific application they’ve migrated to the cloud. The following steps can help guide the thought process when considering a cloud deployment, and provide a starting point for moving forward.
1. Determine your cloud objectives. What are you trying to accomplish? Is the cloud a solution for reducing costs, faster provisioning, data center consolidation, all of the above? Sometimes all goals align, where the cloud allows you to save money, be more responsive and avoid huge infrastructure investments all at the same time. But it may not be possible to realize all the benefits for a given organization or use case. For example, if there’s extra capacity in your data center there may be no obvious consolidation advantage to putting an application in the cloud. However, there could be other issues at play that justify the move, such as high operating costs or an infrastructure that makes it difficult for users to get the support they need.
2. Pick an application that makes sense. For example, how much latency is acceptable to users? The laws of physics slow things down over the Internet and network performance will vary, so if you need millisecond response the cloud may not work for your application. How critical is the application? You may not want to put an application in the cloud upon which the business depends even if infrastructure limitations (scaling, support, response time, etc.) make it seem like an attractive option. Get your feet wet before diving in -- a safer approach might be to start with a low-risk, back office (not-strategic) application before setting your sights on more ambitious targets.
3. Involve the CSO/risk management team from the beginning. The cloud, perhaps even more than other technology shifts, has raised red flags about security since your applications and data will potentially be moving outside of the enterprise firewall. Engage your company’s security experts and decision makers from the beginning to understand their perspective and address their concerns directly. Get them involved in the discussion early so they’ll understand why the cloud is important to the business and how you want to use it. Give them a chance to review their security concerns with potential vendors before you sign up.
4. Decide which cloud(s) are acceptable. Finding a cloud that’s best suited to your needs is as critical as identifying the right target applications. Cloud offerings vary widely—in their APIs, configurations, storage infrastructure, networking options, pricing structures and SLAs. Some of the variables will be essential for your requirements, while others are simply nice to haves. The process is like evaluating any other technology offering, except the environment is probably new and unfamiliar. You may want assistance from a partner with cloud expertise who can help you qualify the various cloud options to make sure you make the right choice.
5. Create a sandbox where people can experiment. All of the different user groups should be able to see how a cloud-based application compares to a traditional one. Give business users, administrators and developers a chance to evaluate the benefits of the cloud from their perspective, as well as the limitations. Application experts can use the sandbox to run functionality and performance testing on the application in the cloud to see how it behaves compared to the traditional environment, and if any differences are acceptable.
Get Your Hands Dirty
Once you’ve done the necessary due-diligence, you’re ready to get started with beta testing and proof-of-concept pilots with vendors. In an area as hyped as the cloud there’s really no better way to learn than hands-on, and these basic best practices will help lay the foundation for a successful cloud strategy. CloudSwitch can help address the security concerns and make it “point-and-click” easy to move to the cloud, using your existing management tools and applications.
