virtual machines
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.
Do VMs Still Matter in the Cloud?
By John Considine
There’s a long running debate about the true role of Virtual Machines (VMs) in cloud computing. In talking with CTOs at the large vendors as well as the “Clouderati” over the last two years, there seems to be the desire to eliminate the VM from cloud computing. A colleague of mine, Simeon Simeonov, wrote a blog a couple of weeks ago that made the case for eliminating the VM. While the argument is appealing, and there is growing support for the idea, I’d like to argue that there are compelling reasons to keep the Virtual Machine as the core of cloud computing.
Virtual Machines encompass “virtual hardware” and very real operating systems. VMs drive the economics and flexibility of the cloud by allowing complete servers to be created on-demand and in many cases share the same physical hardware. The virtual machines provide a complete environment for applications to run – just like they would on their own individual server, including both the hardware and operating system.
Sim and other cloud evangelists would like to see applications developed independent of the underlying operating systems and hardware. Implied in this argument is that developers shouldn’t be constrained anymore by an “outdated” VM construct, but should design from scratch for the cloud and its horizontal scalability. This reminds me of early conversations I had when we were just starting CloudSwitch that went something like: “If you just design your applications to be stateless, fault tolerant, and horizontally scalable, then you can run them in the cloud.” The message seemed to be that if you do all of the work to make your applications cloud-like, they will run great in the cloud. The motivation is cost savings, flexibility, and almost infinite scalability, and the cost is redesigning everything around the limitations and architectures offered by the cloud providers.
But why should we require everyone to adapt to the cloud instead of adapting the cloud to the users? Amazon’s EC2 was the very first “public cloud” and it was designed with some really strange attributes that were driven from a combination of technology choices and a web-centric view of the world. We ended up with notions of “ephemeral storage” and effectively random IP address assignment as well as being told that the servers can and will fail without notice or remediation. These properties would never work in an enterprise datacenter; I can’t imagine anyone proposing them, much less a company implementing them.
But somehow, and this is what disruption is really about, it was OK for Amazon to offer this because the users would adjust to the limitations. The process began with customers selecting web based applications to be put in the cloud. Then a number of startups formed to make this new computing environment easier to use; methods of communicating the changing addresses, ways to persist storage, methods of monitoring and restarting resources in the cloud, and much more.
As cloud computing continued to evolve, the clouds started offering “better” features. Amazon introduced persistent block storage (EBS) to provide “normal” storage, VPC to allow for better IP address management, and a host of other features that allow for more than just web applications to run in the cloud. In this same timeframe a number of cloud providers entered the market with features and functions that were more closely aligned with “traditional” computing architectures.
The obvious question is what is driving these “improvements”? Clearly the early clouds had captured developers and web applications without these capabilities – just look at the number of startups using the cloud (pretty much all of them). I’d assert that the enterprise customers are driving the more recent cloud feature sets – since the enterprise has both serious problems and serious money to spend. If this is true, then we can project forward on the likely path both the clouds and the enterprises will follow.
This brings us back to the role of the Virtual Machine. Enterprises have learned over the years that details matter in complex systems. Even though we want to move towards application development that doesn’t touch the hardware or operating systems objects, we must recognize that there is important work done at this level – hardware control, the creation and management of sockets, memory management, file system access, etc. No matter how abstract the applications become, there is some form of an operating system that works with these low level constructs. Further, changes at the operating system level can affect the whole system – think Windows automatic updates, Linux YUM updates, new packages or kernel patches have caused whole systems to fail; this is the reason that enterprises tightly control these updates. This means in turn that the enterprise needs to have control of their operating systems if they want to use their software and management policies, and the way that you control your operating system in the cloud is with VMs.
Enterprise requirements are driving the evolution and adoption of the cloud and this will make the use of VMs even more important than it has been to date. Cloud providers know that enterprise customers are critical to their own success and will make sure that they deliver a cloud model that feels familiar and controllable to enterprise IT and developers.
