Cloud Computing
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.
Is Encryption the Solution to Cloud Computing Security and Privacy?
By Guest Blogger Erik Heels, Partner at Clock Tower Law Group, experts in patent law
Wikipedia defines "cloud computing" as "the logical computational resources (data, software) accessible via a computer network (through WAN or Internet etc.), rather than from a local computer. Managing local computers is hard: there are security issues, computer lifecycle issues, accessibility issues. Cloud computing, ideally, is easy: set it and forget it, access your data from anywhere, outsource your IT headaches to your service provider. To end users, whether individuals or companies, "the cloud" is an abstraction, a computing environment that can expand to suit users' needs.
What's The Problem?
One problem with cloud computing is that both cloud computing providers and law enforcement agencies can access your files, usually more easily than if your stored the files on your own computer.
Also, security breaches, like the much-publicized Dropbox security breach, during which all Dropbox accounts were accessible to all users without any password protection, can occur in the cloud.
For users, it is important to know whether your data is secure, who can access it, and what happens when there is a security breach.
For service providers, it is important to comply with both US and non-US laws including (1) data retention laws, which are ostensibly designed to help law enforcement entities do their job and (2) data disclosure laws, which are ostensibly deigned to help users know when their private information has been compromised.
Is Encryption The Answer?
Most cloud computing providers (1) authenticate (e.g. transfer usernames and password) via secure connections and (2) transfer (e.g. via HTTPS) data securely to/from their servers (so-called "data on the wire"), but, as far as I can tell, none (3) encrypts stored data (so-called "data at rest") automatically.
So if you want your data to be secure in the cloud, then consider encrypting the stored data. And don't store your encryption keys on the same server! It is unclear whether a cloud computing provider could be compelled by law enforcement agencies to decrypt data that (1) it has encrypted or that (2) users have encrypted, but if the provider has the keys, decryption is at least possible.
I have used and abandoned both Microsoft's Encrypting File System (EFS) and Apple's FileVault for encrypting data on my desktop computers. But desktop encryption is painfully slow! Perhaps cloud computing providers can leverage the power of their data centers to make the performance hit of encryption-decryption imperceptible to the user. That would be cool. And would make the benefits of cloud computing greatly outweigh the risks.
Here are three security questions you should ask of your cloud computing provider:
- Data on the Wire. Are files transferred to/from cloud servers encrypted by default?
- Data at Rest. Are files stored on cloud servers encrypted by default?
- Data Retention. If files on cloud servers are encrypted and there is a request from law enforcement to decrypt the data, then what do you do? Bonus question: What if you have the key(s)?
I searched for answers to these questions for four cloud computing providers (sourced in part from TechTarget's list of top cloud computing providers and Wikipedia's list of cloud computing providers) that are popular with small businesses like mine:
Simple Google searches of these providers' websites provided more questions than answers on the topic of encryption:
- search Amazon.com for encryption
- search Google.com for encryption
- search Apple.com for encryption
- search Dropbox.com for encryption
Cloud service providers need to do a much better job of communicating what is and what is not secure about their offerings. For example, I would characterize Dropbox's security page as misleading at best:
"Your files are actually safer while stored in your Dropbox than on your computer in some cases. We use the same secure methods as banks and the military.... Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so). But that’s the rare exception, not the rule."
Just because your files are transferred securely to Dropbox does not mean they are stored in an encrypted format on Dropbox's servers. And it is the "rare exception" that is, or should be, the concern of users.
For More Information
- International Association of Privacy Professionals: Ten Steps Every Organization Should Take To Address Global Data Security Breach Notification Requirements. I would add "11. Get insurance" and "12" Get a good lawyer."
- Electronic Frontier Foundation (EFF): Surveillance Self-Defense. What can the government legally do to spy on your computer data and communications? And what can you legally do to protect yourself against such spying?
- Electronic Frontier Foundation: Mandatory Data Retention. Regarding controversial laws that require Internet Service Providers (ISPs) to collect and store records documenting the online activities of users.
- PrivacyLawCompliance.com. Law firm specializing in helping Massachusetts companies comply with privacy laws.
- ZDNet: Microsoft Admits Patriot Act Allows Access To EU-Based Cloud Data
- Centre for Commercial Law Studies (CCLS) at Queen Mary, University of London: 'Personal Data' In The UK, Anonymisation, and Encryption
Summary
As more individuals and companies move their computer files and computer applications from local client computers (over which they have a great deal of control) to remote server computers (over which they have limited control), security becomes a bigger concern - both for users and for service providers.
Erik J. Heels is an MIT engineer; trademark, domain name, and patent lawyer; Red Sox fan; and music lover. He blogs about technology, law, baseball, and rock 'n' roll at ErikJHeels.com. His law firm, Clock Tower Law Group, represents cool companies such as CloudSwitch.
Cloud Wars Heat Up
By John Considine
Last week I wrote about the Cloud.com acquisition and what it means for Citrix, Rackspace, OpenStack and the industry. Next, I’d like to dig into the VMware announcement about their cloud infrastructure suite. Citrix clearly wanted to announce their news just prior to VMware’s, and for a good reason – Citrix is hitting VMware in a weak spot of their cloud strategy. It’s pretty clear that VMware is not getting the vCloud adoption they were anticipating from service providers and even enterprises.
In Paul Maritz’s presentation, he mentioned that VMware “…has been working closely with service providers because you need the same stacks on both sides [the private cloud and public cloud] to be able to ‘slide’ applications to the cloud…and back again.” At CloudSwitch we are dedicated to the notion that you don’t have to have identical infrastructure stacks between the data center and the cloud. You have to expect that what a cloud provider chooses will not necessarily be the same as what the enterprise has chosen, or that they will work together in lock-step. VMware seems committed to the strategy that they will provide the complete solution on both sides of the cloud, and that all parties will work together to stay coordinated. This is very different from Citrix’s positioning around more open and heterogeneous solutions.
Citrix and VMware have been competing in the virtualization space for years with a battle of features (mostly Citrix catching up with VMware and trying to gain share in the enterprise virtualization market), but the scope of the competition has been growing thanks to cloud computing. Cloud computing expands the server virtualization fight from hypervisor features to integrated stacks for deploying/managing infrastructure. The hypervisors remain important, but the new frontier contains everything from core networking to storage management, to large scale deployments to self-service IT. In this new battle, Citrix has some real strength in networking (Netscaler, etc.) and application delivery, and with their Cloud.com acquisition, they are capturing some proven orchestration technologies.
VMware is investing huge resources to expand their cloud offerings (Maritz claims a million man hours). Their focus is on adding features to their hypervisor and layers to their stack (vSphere+vCenter SRM+vCenter Operations+vShield+vCloud Director). They have lots of expertise in this area and direct interaction with enterprise customers and requirements. On the service provider side, they are dependent on feedback from VMware-based partners to provide input and learn how to build and run large-scale infrastructure clouds. We’ll have to see how this approach plays out vs. Citrix’s CloudStack.
In the end, this competition is great for all of us as well as for CloudSwitch specifically. The competition in the cloud space will continue to drive innovation, new features, and simplification of deployment for this great new platform called cloud computing. CloudSwitch is all about choice and giving enterprises control and flexibility in their cloud architectures. As the world of cloud computing evolves, we love to see different options, technologies, and capabilities – because a world filled with different cloud choices needs a CloudSwitch to connect all of the pieces.
Buying the Cloud
By John Considine
Here we are on July 12, mid-summer when you think most people are wondering about going to the beach in 90 degree weather, and instead we have big cloud news. Early this morning we were greeted with the announcement that Citrix is buying Cloud.com for more than $200M. After the initial congratulations to Sheng and the team at Cloud.com, the twitter-sphere and blogosphere went wild with thoughts and deal analysis. At the same time, everyone was waiting to hear what VMware was going to say in their “Cloud Infrastructure Launch” webcast.
I’ll start with some thoughts on the Cloud.com acquisition. Rather than go into the rationale and size of the deal, I’d like to focus on what this acquisition means to Citrix, OpenStack, and Rackspace.
It’s clear that Citrix has been a major supporter of OpenStack and that support makes sense since it’s a great way to compete against VMware. OpenStack is shaping up to be the answer to the closed source solutions being developed by VMware for building both public and private clouds. It’s also clear that Citrix needed a boost to gain traction and credibility in the market for producing cloud infrastructure. They have a good hypervisor and are busy building out more features, tools, and performance – but cloud infrastructure is a lot more than hypervisor + new features.
Enter the Cloud.com guys. They know how to build clouds, and already have traction with service providers and enterprises alike. They have proved that they know how to make a cloud scale – and this is not as easy as it sounds. Keep in mind that building clouds is more complicated than standing up virtualized clusters and running standard tools; there are complex networking, storage, and workload placement problems, not to mention versioning, maintenance, and operations.
So this is clearly a good thing for Citrix, and on the face of it, a good thing for Cloud.com – but what about OpenStack? The bigger question here is: what does this really mean for the OpenStack community? Is this a case of Citrix providing the enterprise/supported version of OpenStack as RedHat does for Linux? Will we see a set of capabilities delivered by Citrix that are built on OpenStack, but that are exclusive to Citrix’s CloudStack? Will OpenStack be increasingly driven by Citrix’s needs and integration with Xen (versus other hypervisors)?
If Citrix remains committed to its stated direction of providing the software for clouds (rather than building a cloud themselves), they are in a great position to capitalize on OpenStack. Rackspace, on the other hand, has a more complicated opportunity with OpenStack. They created the idea and built the community, but they are limited by the fact that they are themselves a cloud provider, so it would be hard for them to sell and support OpenStack software to other cloud providers and vendors. That leaves the door open for someone else to step in and become the enterprise software vendor for OpenStack. Clearly Citrix has been targeting this, and the addition of Cloud.com adds the full software stack and knowhow for building and deploying a cloud.
And in other news...VMware announced its Cloud Infrastructure suite today. Given that the VMware announcement was previously scheduled, I can only conclude that Citrix picked today to overlap with their announcement. These two announcements occurring on this sleepy mid-July date point to high activity in the cloud space, and the coming wars around who is going to provide the cloud infrastructure for both service providers and the enterprise. This may become a battle of closed source solutions from VMware and open source solutions from Citrix (and OpenStack)… I’ll write more about the VMware announcement in my next blog, but the battle between Citrix and VMware is definitely heating up.
Cloud Brokers Make the Cloud Fit for Enterprise Requirements
By Ellen Rubin
Sometimes it’s fun to look back at your predictions to remember what you were thinking at the time and see how accurate you turned out to be. Based on some recent conversations, I decided to revisit one of our early blog posts from 2009, where we were envisioning the direction this industry would take and the role our technology would play in it.
That post, Dynamic Cloud Fitting — the Future in Automated Cloud Management, described a world where workloads would move automatically to the right environment to meet a customer’s business and technical requirements. It also explored how an entity called a “cloud broker” (initially defined by Gartner in 2009) would provide the technology and expertise to achieve that goal.
Fast forward to 2011. The idea of workloads being redirecting on the fly across different clouds for real-time optimized cost/performance is still a vision for the distant future – both because the technology is not yet available and also because customers have shown little interest to date. However the main concept of a cloud broker “fitting” a workload to a cloud environment based on technical and business requirements turns out to be very important to customers, and is already possible today. By providing an intermediation layer spanning multiple clouds, cloud broker software from companies like CloudSwitch can provide a range of capabilities beyond the scope of an individual cloud provider or service.
In terms of cloud “fitting,” what customers want is the ability to set parameters on a number of dimensions in order to control usage and optimize workload performance. These parameters include (but are certainly not limited to):
- Which cloud services they want to make available (and for which users)
- Which geographic locations (regions, zones, data centers)
- Cost limitations – per hour, based on quotas, etc.
- Maximum latency that can be tolerated
- Virtual machine requirements for CPU, memory, etc.
- Maximum provisioning time that is acceptable
- Minimum SLA required for reasonable availability
What’s clear is that cloud broker software must incorporate an algorithmic approach to mapping the requirements of the enterprise, user groups, individual users, and specific workloads against the possible cloud services that have been enabled. This is a non-trivial process and is based on capturing and tracking a mix of inputs from administrators and users, as well as real-time data from the virtual machines, networks, and cloud providers. Think of this as being somewhat similar to recommendation engines on websites like kayak.com that help “fit” travelers’ requirements and preferences against available flights. Only in this case, the “flights” are instances that can be provided by one or more cloud provider or by internal virtualized resources.
Another important aspect for the cloud broker software is to implement the “fitting” algorithm in the context of a role-based access control (RBAC) system. Think of this in terms of layers of enterprise controls and permissions that guide users’ options for self-service access to cloud resources. For example, a global administrator may set up the initial constraints based on which cloud services are available for the entire enterprise, while a business unit administrator may have more narrow limits for her users based on quotas, geographic constraints for certain teams, etc. – and the final end-user just wants to get his work done quickly and cost-effectively without worrying about any of this.
One point we didn’t foresee in our original blog post on cloud fitting was how the cloud broker’s role would expand. In addition to on-boarding applications into the cloud, customers now look to cloud brokers to fill important gaps in areas that cloud providers either don’t want to deliver (such as multi-cloud capability) or that are hard to deliver because of architectural limitations.
Security is a good example of the latter, where the shared environment of the cloud makes it hard to give individual customers control over encryption and key management, something that enterprises frequently require to get CSO sign-off. Extension of network configurations into the cloud with full configurability is also challenging for most cloud providers, since their network architectures are by definition fairly “flattened” and limited in options like multiple sub-nets (unless the customer is willing to pay for a dedicated network setup). This is another area where cloud brokers can help bridge the gap between what enterprise users need and what multiple cloud providers can deliver.
So the role of a cloud broker turns out to be evolving and growing broader over time, and no doubt will continue to do so. There’s a broad consensus that the broker’s role is important — not just here at CloudSwitch, but also among industry analysts like Gartner, other technology vendors, and our enterprise customers. The key insight is that cloud brokers allow enterprises to extend their control over their applications and data into the cloud. This ability to put control in the hands of the customer is what matters the most.
Enterprise Cloud Summit at Interop: A Moment in the Cloud
By John Considine
Despite scheduling the first of day conference to start on Mother’s Day, there was a good turnout for the Enterprise Cloud Summit in Las Vegas this week. The presentations covered everything from how public clouds “work” to the future of private clouds. Sessions were brief and moved quickly, which kept things interesting, but at times felt a bit rushed for the speakers – as I can attest to after delivering a 15-minute talk on deploying enterprise applications in public clouds.
As you might expect from an Interop crowd, the audience was loaded with people who consider their primary job “IT,” and surprisingly very few who were active programmers; a sure sign that although the developers started the cloud trend, core IT is now getting in on the game. The audience reminded me that we are still in the early days of cloud computing, and the clever organization of the summit by Alistair Croll and team helped highlight this.
By mixing “under the covers with the cloud provider” sessions and real-life case studies with panels debating the various forms and futures of cloud computing, the audience got a full dose of the hopes and dreams of the cloud as well as the nitty-gritty of what is (and is not) working today; often one right after another. An amusing example – a panel debating the “private cloud = false cloud” taking positions on whether private clouds are real or just virtualization, followed a little later by Zynga talking about how successful their private cloud is…
My takeaways from the summit: The audience and speakers represented a true reflection of where the whole industry is on the transition to cloud computing. If you want to find reasons to delay and avoid the cloud, it is easy to debate and find use cases where it doesn’t make sense. However, if you want to embrace this transformative platform shift and take advantage of the clouds, there are plenty success stories, people, and products to help you get there.
Planning for Outages in the Cloud
By Dave Armlin, Director of Customer Support at CloudSwitch
The Amazon US East outage of just over a week ago was an eye-opener for many people. Here at CloudSwitch it validated what we know about best practices for using the cloud. Not surprisingly, these reflect traditional IT processes and systems that enterprises know are needed to protect data and ensure that applications remain available to users.
From an enterprise support perspective, I’m very happy about the variety of options we have to protect and backup data, scale and shrink application capacity, and bring applications on and off-line. It’s also easier than ever to make sure that you don’t have all of your “eggs in one basket” due to public clouds and products like CloudSwitch.
CloudSwitch was designed to bridge the worlds of the data center and public cloud, making it extremely easy and safe to move virtual machines into the cloud over an encrypted tunnel onto encrypted storage. You can also deploy multiple copies of your virtual machines to different availability zones, regions, or even clouds. Because CloudSwitch acts as a layer-2 bridge between the data center and cloud, virtual machines in the cloud are able to seamlessly access the data center and visa-versa, allowing data and applications to live in either the data center or the cloud. This provides some great opportunities to continue to use your existing IT management tools while taking advantage of cloud storage and cloud compute power in powerful new ways.
We encourage our customers to make full use of the opportunities that CloudSwitch enables:
- Deploy virtual machines to multiple availability zones, regions and/or clouds.
- Clone existing virtual machines or create hot “point in time” snapshots.
- Continue to utilize traditional backup methods.
- Employ traditional file system and/or database replication and load balancing to make your applications as available as possible.
- Automate scripted deployments and life cycle actions on virtual machines.
When reviewing DR strategies with customers, we recommend the following approach:
- Review all applications and associated virtual machines and prioritize them to determine the appropriate DR strategy.
- Review and test monitoring of each application to ensure that you can detect and be alerted to application failures as quickly as possible.
- Eliminate single points of failure for critical applications by providing multiple points of presence in the cloud.
- If you are using replication technology to keep copies of virtual machines in sync, ensure that you have appropriate alerts in place to detect synchronization failures.
- Determine if failover and failback must be automated or manual processes.
- If load balancing is required, weigh the options and limitations of the different load balancers. Amazon’s ELB for instance can balance across availability zones but not regions.
- For lower priority systems that don’t require HA, consider scheduled automated clones/snapshots or traditional backups or both.
Eating Our Own Dogfood
In our own internal operations, we’ve deployed www.cloudswitch.com to both Amazon’s US-East Region and US-West as well as Terremark’s Enterprise cloud. We utilize an open source file system synchronizer to keep these copies in sync. This application also has an automated backup process that backs up data to Amazon S3.
CloudSwitch’s web portal for download/activation and support consists of database and application servers which are deployed to multiple regions within Amazon utilizing database (master-slave) replication.
As our CTO John Considine noted in last week’s blog post, we and our customers had a range of experiences during the Amazon outage, which only reinforced the importance of planning and implementing the procedures outlined above. In some cases, we relied too heavily on snapshots for some of our internal systems, and recognized after the fact that we needed a careful DR review and prioritization of the many applications we have running in the cloud.
Any DR/HA plan should be routinely validated. We’ve taken this recent event as a good opportunity to do this internally and have been working with our customers to remind them of the options that are available to them with CloudSwitch to protect data and make systems more resilient.
In-Path WAN Optimization for your Cloud Deployments with CloudSwitch and Riverbed
By Pavan Pant
As our enterprise customers embrace the cloud, we’ve been hearing a growing demand to help them optimize enterprise network connectivity as they scale their cloud deployments. At CloudSwitch, we’ve been thinking about the issue of network optimization for quite some time now and working with partners like Riverbed to tackle network performance in the cloud.
Today we are pleased to announce our support for Riverbed’s Cloud Steelhead® to help customers optimize their hybrid cloud deployments. Many of our existing customers have already invested in Riverbed infrastructure in their data centers, and want to extend these trusted resources into the cloud. The primary drivers for WAN optimization in hybrid cloud architectures are twofold:
- Improving network performance between data centers and the cloud for better end-user experience
- Reducing bandwidth between the data center and the cloud, thereby reducing cloud costs
In a hybrid model the public cloud acts as a remote data center, making infrastructure resources available to distributed teams of users, but requiring connectivity back to corporate data center resources. Riverbed’s WAN optimization technology can reduce bandwidth requirements and accelerate a number of applications and protocols including Windows file shares, NFS servers and Oracle forms. Riverbed’s innovations in data compression, de-duplication, and other techniques enable much more efficient data movement between customer data centers and the cloud, while freeing up bandwidth for other applications. In our testing we have seen anywhere from a 5 to 100x improvement in your application’s performance, and 60-80% reduction in bandwidth costs.
Simple and Secure Deployment in the Cloud
Our joint solution allows customers to easily select Riverbed’s Cloud Steelhead from CloudSwitch’s network library and launch it unmodified in the Amazon EC2 and Terremark clouds. The user can simply select the cloud networks they would like to optimize, and the Riverbed appliances will take it from there – automatically selecting the network traffic and applications to optimize.
Once Riverbed’s Cloud Steelhead is running in the cloud on CloudSwitch’s isolation technology, customers simply enable automatic peering through Riverbed’s user interface. This ensures that network traffic is optimized as soon as servers in the data center try to communicate with servers in the cloud or vice-versa. In addition, CloudSwitch ensures that all communication and data are automatically encrypted so that your extension of infrastructure into the cloud is always protected, end to end.
CloudSwitch allows Cloud Steelhead to be deployed in-path so that all network traffic on the optimized LAN for your servers in the cloud runs through Cloud Steelhead. This allows the WAN optimizer to accelerate cloud traffic automatically without requiring any additional modifications (no agent installations, no drivers, no changes) to your servers in the cloud. This is the unique advantage CloudSwitch offers– simplicity, security, and the ability to offer WAN optimization with full configurability and control by the enterprise.
Our mission at CloudSwitch has always been to make it easy and secure for customers to launch virtual machines in the cloud. Last year, we enabled public IP access to cloud resources by adding an open-source firewall to our network appliances library. As we learn more from our customers about their requirements, we continue to build our library of partner offerings, demonstrating the strength of our platform and our ability to act as a cloud gateway. We’re excited to support Riverbed’s Cloud Steelhead and are hard at work integrating with market-leading firewalls, load balancers, storage appliances and other devices. Our software lets joint customers easily deploy these virtual appliances in the cloud with secure, in-path configurations to enable much more efficient data movement and scalability in the cloud.
To learn more about how enterprise customers are optimizing the cloud today, please join our upcoming webinar with Riverbed, “Optimizing Your WAN Connectivity for Hybrid Cloud Deployments.”
What to Look for in a Cloud Gateway
Part 2 of a 2-Part Series
By Ellen Rubin
The last post explored why more and more enterprises and technology vendors are making the adoption of a cloud gateway a top priority. This post focuses on the capabilities that all stakeholders should look for.
So what exactly is a cloud gateway? A cloud gateway is technology that extends the enterprise data center or private cloud out to external clouds. It’s a core component of the hybrid model, and when it’s well-architected, it brings simplicity, flexibility, and control to cloud computing. By shielding users and IT departments from the complexity of cloud deployments, the gateway makes applications portable across different cloud architectures, platforms and even different hypervisors. It provides cloud users with easy access to the widest range of resources and services available, and gives technology vendors a platform for delivering high-value services to on-premise and cloud environments. It’s also a platform for innovation around new capabilities that now become available in the hybrid cloud model.
Here’s what a well-designed cloud gateway needs to do:
- Guarantee security: Data needs to be encrypted end to end, from inside the corporate firewall, across the Internet, and within the cloud infrastructure. Encryption keys need to be under enterprise control at all times, and off-limits to everyone else. The cloud becomes an integral part of the enterprise IT environment with data at rest and network communications protected from both the cloud provider and 3rd parties at all times.
- Extend enterprise networking: Every enterprise has a unique network infrastructure for connecting its servers and applications — things like addressing schemes, topology, identity and directory services, and network equipment (firewalls, routers, and switches). Cloud providers have completely different network architectures to support their multi-tenant operations. The gateway needs to enable enterprises to match their current network topologies when they are using the cloud, and have the ability to bridge specific network segments (or LANs) to the cloud in a simple and automated fashion – including both layer-2 (Ethernet) and layer-3 (Internet Protocol) connectivity.
- Deliver enterprise-class network appliances: As more and more network vendors introduce their own cloud versions, customers want to be able to leverage what they already have on-premise and use trusted vendor products for their cloud deployments. These enterprises have made significant investments in the management and operation of these appliances. A cloud gateway should enable the use of these trusted vendors across the various cloud offerings available to allow the enterprise to leverage policies, configurations, and expertise when extending into the cloud.
- Integrate with data center infrastructure: A gateway should be able to tie into existing virtualization infrastructure to allow users to seamlessly combine the cloud deployments with on-premise applications and infrastructure. The gateway should be able to interact with different virtualization technologies (VMware, Xen Server, Hyper-V, KVM) to give enterprises the broadest scope and flexibility in cloud deployments as they evolve their virtualization and cloud strategies.
- Provide seamless visibility and control: The gateway should allow users and administrators to monitor and manage applications running in a cloud as if they were running locally, using existing tools and polices in a single, integrated environment. Cloud resources should appear as part of the corporate infrastructure, with external pools of capacity appearing alongside internal ones.
- Protect roles and access: Dedicated individuals or teams are usually responsible for setting up enterprise networking, storage, virtual machines, applications, monitoring, etc. In the wild west of the cloud, with the paradigm shift towards self-service provisioning and management, these responsibilities fall on the end user — typically the developer or business user as they access cloud resources. These users are often unaware of corporate policies or configurations, and are unsure how to address these requirements. The cloud gateway should preserve the multi-role capabilities required for enterprise control, allowing rules to be created and enforced while letting users access cloud resources on demand.
- Span disparate cloud architectures: All the requirements mentioned above need to span multiple clouds, with their different APIs, hypervisors, storage architectures, etc. The gateway needs to give users access to the widest range of choices so they can take advantage of all the cloud has to offer. The gateway must be designed with a deep understanding of different cloud providers’ capabilities and differences, so it can deliver optimal services and the best price/performance to meet customers’ specific requirements.
A Platform for Innovation
Beyond meeting the needs of customers and vendors today, the gateway is a platform for innovation that opens the door to a new generation of capabilities. The cloud gateway sits at the nexus of new technologies – it ties into the virtualization infrastructure within the data center, tightly integrates into the network infrastructure, and connects with multiple external clouds. The ability to interact with all these key components enables new services and solutions. Here are a few examples:
- Cloud brokerage: Workloads can be moved to the right environment based on business and technical requirements. Users can examine a menu of available clouds and choose the ones that provide the best combination of pricing, QoS, provider flexibility, or other criteria.
- Geographically distributed applications: The cloud provides the freedom to place workloads around the world. The gateway allows simplified network management, multi-cloud support (the ability to choose clouds nearest your consumers), and central control for resource management.
- Data management: The gateway is in a key position for managing data and workload distribution. With ties into both the data center and target clouds, the gateway can facilitate data movement, replication, remote access, and security of data.
- Enhanced security: With access to enterprise resources as well as control of distributed networking and compute resources, the gateway is an ideal place for delivering new security models – including remote access, distributed policies, and advanced virus protection.
The concept of a cloud gateway is capturing mindshare across the cloud industry –from enterprise customers to technology vendors and service providers. It’s a key enabler for their cloud strategies, and they’re eagerly looking for ways to take advantage of it, to meet current requirements and introduce some new paradigms in enterprise computing.
