enterprise cloud computing
What If You Could Provision in the Cloud Using Your Existing Data Center Tools?
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInWhat if you could use your incumbent data center bare metal provisioning tools to create application instances in the cloud?
Today you may be using familiar tools in your data center to build out new application stacks successfully, such as Microsoft ADS or RIS, Kickstart or Autoyast, HP Opsware or BMC BladeLogic, or Altiris. You may have also made a significant additional investment in front-ending these provisioning tools with an in-house developed provisioning portal, or orchestrating these tools with a workflow or Runbook automation tool.
These tools and processes require a significant investment in their deployment and in the authoring and configuration knowledge that is embedded within them. But, as flexible as these tools are in reliably building configurations, they are not usable as-is with compute resources in the cloud. Consider Amazon EC2, for example. How will you get their Xen paravirt network device to PXE broadcast, or route that back to your on premise DHCP/TFTP infrastructure? Till now, the answer is that you can’t.
So, you are faced with having to use another siloed provisioning tool that is designed and built for use with your chosen cloud provider. You need to retrain staff. Reprogram configuration scripts. Maintain parallel systems that are basically doing the same thing.
It’s hard to argue that it’s worth doing all this, outside of the compelling premise that you REALLY want to be able to turn on something for 2 hours, and pay 15 or 16 cents for the use, and then turn it off. The power of that flexibility has been the motivating force behind organizations going against the grain and adopting a separate and purpose-built cloud provisioning tool to take advantage of the elasticity and flexibility of cloud-based servers.
But what if you didn’t have to make that choice? What if you could treat cloud servers EXACTLY as if they were new bare metal blade servers that had come off the loading dock, been racked and stacked, powered on, and started PXE broadcasting? Today, you can import a list of MAC addresses off your asset sheets for these newly powered-on servers into your incumbent bare metal provisioning tool of choice, and start throwing your J2EE stacks onto these servers.
CloudSwitch is committed to the proposition that you can have your cake and eat it too. You can create as many blank servers as you want, using any combination of instances sizes to customize the cores, memory, storage, network, and compute capacity that you need to provision an application stack. The blank servers can be interrogated for generated MACs. You can plug those into your bare metal provisioning systems, just like the good old days when you could go over and see the lights flash for your new server in its rack, and get ILO console access.
Turn them on, let them PXE boot, and let them provision your stack. Use them as long as you need them and throw it away. You won’t have to retire the equipment or plan a server upgrade. Your cloud provider will take care of that for you. You won’t have to change a thing. Everything you have in place will still work. Transparently.
Isn’t that just a basically better idea?
__________________________________________________________________________________
Vote for CloudSwitch! Watch our video and cast your vote on Cloud Connect LaunchPad. Help CloudSwitch advance to the finals.
Cloud Federation and the Intercloud
Last week’s post explored federation in the cloud, allowing enterprises to move workloads seamlessly across internal and external clouds according to business and application requirements. Advances in federation are good news for companies considering a move to the cloud since deployments no longer need to be custom projects and applications no longer have to be tightly coupled to a particular cloud.
To follow up, there’s been lots of discussion recently about the concept of the “Intercloud,” a direction for cloud computing that is closely related to federation and ties in with much of our work at CloudSwitch. A term introduced by Cisco, the Intercloud refers to a mesh of clouds that are interconnected based on open standards to provide a universal environment for cloud computing. Like the name suggests, it’s similar to the Internet model, where everything is federated in a ubiquitous, multiple-provider infrastructure.
The primary difference between the Intercloud and federation is that the Intercloud is based on future standards and open interfaces, while federation uses a vendor version of the control plane. With the Intercloud vision, all clouds will have a common understanding of how applications should be deployed. Eventually workloads submitted to a cloud will include enough of a definition (resources, security, service level, geo-location, etc.) that the cloud is able to process the request and deploy the application. This will create the true utility model, where all the requirements are met by the definition and the application can execute “as is” in any cloud with the resources to support it.
What shape the Intercloud will take and what standards will emerge to make it work are part of an ongoing debate. Some industry watchers believe it will happen sooner than later. Others believe that discussion of the Intercloud is premature, wary that embracing standards too quickly will hold back innovation, and therefore the Intercloud will remain only a vision for the foreseeable future. When these debates will be resolved is anyone’s guess, but major progress in cloud integration is already underway, so there’s no need for enterprises to put their cloud plans on hold.
At CloudSwitch, we believe that the Intercloud is likely to emerge organically as the result of continuing innovations throughout the cloud ecosystem. Federation is one of the prerequisites toward that goal, providing ongoing improvements in cloud interoperability aimed at giving enterprises many new options from which to choose. The ability to federate identity, access and dataset migration is also one of the key requirements for Intercloud activity. This interoperability at the infrastructure level has to work transparently in order to launch applications into the cloud environment and manage the integration.
The benefits of the Intercloud are in many ways already a practical reality. A significant part of the Intercloud vision can be achieved with a strong federation technology that provides a gateway between different clouds and the internal data center. Users and their companies can avoid lock-in and run workloads in the environment that best matches their needs, based on cost, performance, security, compliance, geography, latency, etc. In short, some of the most important Intercloud goals can be achieved using technology already coming to market.
Holiday Presents from the Cloud
As the year winds down, there are a few things I have come to expect: holiday parties, snow, and new features from cloud providers. This year exceeded all of my expectations, starting with a note in early December from our friends at Terremark letting us know that they have fixed their Windows pricing for cloud servers. Until this upgrade, if you started a Windows server in their cloud, you had to pay for a whole month of Windows licensing ($30-$100 depending on the version) no matter how much you used the server. This was rather un-cloudlike, where we want to only pay for what we use. With this new feature, running Windows in Terremark’s cloud only costs a few cents per hour (Linux cost + 20%).
Then came the snow—I live in New Hampshire, and on December 9th we received a foot of new snow to really get the season going. The very next day, Amazon made a big flurry of announcements—support for Windows 2008, the ability to boot from EBS, and the new US region US-West1.
Each of these features means big things for Amazon and for cloud users. First, support for Windows 2008 is a longstanding request from Amazon users. I think that Amazon was held back from supporting W2K8 because of the design of their boot volumes, which needed to be copied out of S3 into the local storage instance in order to boot the operating system. As the boot volume grows, the amount of resources consumed and the boot time of the servers grows significantly, withW2K8 requiring more than 10GB by default. In order to support W2K8, Amazon required another technology advance to make it possible—booting from EBS snapshots.
Perhaps the biggest problem enterprise users had with Amazon was the lack of persistent storage for boot volumes. Amazon has now created a way for users to build persistent boot volumes, coming up to parity with competitors on this feature. Sure, it’s a little different from how enterprises normally think about storage and configure boot volumes, but the ability to use EBS volumes for booting eliminates the window for data loss that most users had to contend with in the original boot methods. (This feature is not huge for CloudSwitch customers because we have always supported booting from EBS as part of our products; however, we can take advantage of this feature to improve boot times for servers in Amazon.)
Another major Amazon announcement is the new west coast region. Many of CloudSwitch’s early customers (not to mention our own development activities) are based on the east coast, so EC2’s primary location has been a good fit for us. Things only improved with the introduction of the Europe region since we have seen a lot of interest for European resources for both locality and compliance reasons. However, for west coast customers, having to hop across the whole country to access your cloud resources was less than ideal. Now these companies have local resources to target, but more important, this ongoing expansion shows that the public cloud is doing well. The addition of US-WEST1 and the soon-to-open Asia region reflect just how quickly the public cloud is growing and how hard Amazon is driving it.
The news from Amazon comes on top of what was already an outstanding year for cloud computing with major announcements from many key players, including: IBM software running in the cloud, new VMware-based public clouds, reduced pricing for servers and storage in the cloud, and Microsoft’s Azure gaining momentum. Each of the cloud providers is growing and maturing its cloud offerings, and we are reaching a tipping point where there are multiple clouds with sufficient features to support enterprise workloads. Get ready for 2010—it’s going to be an exciting year as large-scale enterprise cloud computing takes off.
Making Cloud Computing Secure for the Enterprise
For cloud computing to gain traction in the enterprise, IT and security executives need to be certain that their company’s applications and data are safe. But when security is partly out of enterprise control, it becomes impossible to know if sensitive information has been accessed or compromised.
Today, using a public cloud means moving from an internal environment where a company has complete control of data and processes to an environment where that control belongs to someone else, and is often opaque. Within the cloud, applications run in a multi-tenant virtual environment, sharing physical machines with other customers. Companies considering moving an application to a cloud have legitimate concerns about data being compromised or stolen, including unauthorized access by cloud administrators, exposure in the internet or rogue employees using the cloud to corrupt or leak sensitive information.
One solution is to keep sensitive data within the corporate data center and put the other application tiers in the public cloud. While this approach works well for some use case scenarios, the latency impact of the “reach back” into the data center can be unacceptable for many applications and users. The other option is to move the entire application to the cloud – including the database tier – for better performance and scalability, but this exposes the application to new potential threats such as those mentioned above.
Encryption is a well-known approach to addressing these types of security threats. For protection in the cloud, the enterprise would need to encrypt all data and communications. While it’s not that difficult to add encryption software initially to the application environment, the new configuration requires ongoing management and maintenance. And in order to run the application in the cloud, the enterprise needs to deliver the encryption keys to the cloud to decrypt the data, creating additional security risks by exposing the keys in the operating environment. In the worst case, poor configuration can expose the corporate data center to threats from the cloud.
In developing our security model at CloudSwitch, we worked closely with CSOs and security teams at several large enterprises to understand their requirements. As a result, our architecture addresses three areas of protection required to make cloud computing secure for the enterprise:
- In the data center: Role-based access control protects data and processes from unauthorized access.
- In the Internet: Connections are authenticated and data is encrypted to prevent data in transit from being exposed or compromised.
- In the public cloud: Data is encrypted with keys under enterprise control, and can never be accessed by the cloud provider or unauthorized users.
The CloudSwitch security strategy is a key part of our vision to make the cloud a seamless extension of the corporate data center. Using CloudSwitch technology, companies can move applications and data to a cloud without modification, and back to the data center as needed. Companies can also select the right cloud for a specific application, based on security and compliance levels as well as service offerings and pricing structures. Only with control of applications and data at all times can enterprises take full advantage of cloud resources without sacrificing the security required by customers, internal users, regulators and other stakeholders.
Reality Check at the Cloud Expo
The talk at the Cloud Computing Expo this week in Santa Clara was all about enterprise cloud adoption. Is it real? Is it already happening? If so, who’s doing it, which applications are they running and which clouds are being tested?
To a large extent, cloud computing is a victim of its own somewhat out-of-control hype cycle. Since so much has been written and discussed about the cloud in 2009, there is now a growing impatience for actual results. The fact that 2000 people showed up at the Cloud Expo in Santa Clara this week (double the number from last year’s show) suggests that at the very least, interest in enterprise cloud computing remains very real, and the need for practical solutions and use cases is growing more urgent.
There was a growing concensus about a number of issues:
1. The hybrid model of on-prem data centers combined with the use of public clouds and cloud offerings from managed service providers is emerging as the new model for enterprise computing. Enterprise users would like to keep some applications behind the firewall (within an internal cloud or more traditional environment) and put others in the right cloud environment outside the data center.
2. The first applications to move to the cloud are development and test environments, business continuity solutions (“poor man’s DR,” not full active-active scenarios) and web applications. These are more easily separable from other applications and infrastructure within the data center, and tend to be lower risk for moving off-prem.
3. Major hurdles for enterprise cloud adoption remain the same as last year: security, loss of control, lack of integration with the enterprise data center and fear of cloud lock-in. The lock-in concerns have become more pointed as new cloud offerings come into the market beyond Amazon. (As an aside, Rackspace had a strong presence at the show, but surprisingly, Amazon, Terremark, Savvis, Microsoft and other providers were noticeably absent. Many Asian companies appear to be gearing up for new cloud offerings in 2010.)
Beyond these broad areas of agreement, the sessions at the show revealed very little new information about enterprise success stories. In some ways, it was surprising that there wasn’t more visible progress across the industry this year. However, what we’ve learned from our own enterprise experiences is that in 2009, a lot of groundwork is being laid by both cloud providers as well as enterprise IT to prepare for cloud deployments in 2010.
As we’ve geared up for our private beta (started this week and running through the end of the year), we’ve learned from CIOs and heads of IT that they first want to do some “cloud exploration” to validate the experience for admins and users in terms of ROI, functionality and performance. They start by putting a small number of servers into the cloud to see what works and what breaks. They need buy-in from security and risk management to start putting applications and data outside the firewall. They are building TCO and ROI cases to review with legal and finance as they get cloud budgets approved for 2010. For their part, the cloud providers are deeply engaged with POCs and test environments for enterprise users, and are learning what’s missing from their offerings. It seems clear that by the next Cloud Computing Expo in April, we’ll be seeing the results of all this work in some strong case studies by enterprise adopters.
Moving to the Cloud: Key Considerations for Cloud Networking
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
Every enterprise has a unique network infrastructure for accessing servers and allowing applications to communicate between components. Various layers support the management of network addressing, deliver critical services, and ensure security. The infrastructure includes specific addressing (sub-nets), address services like DHCP/DNS, identity and directory services like LDAP, and firewalls and routing rules – all reflecting the specific requirements and evolution of the given enterprise.
Clouds are not different from the enterprise in this respect; they have unique networking infrastructures that support complex and flexible multi-tenant environments. Remember that the cloud providers have to control their networking so that they can route traffic within their infrastructure. More important, their design is completely different from your enterprise networking architecture, design, and addressing. This is not a problem if you’re doing something stand-alone in the cloud because you don’t care what the network structure is as long as you can access it over the internet. However, if you want to extend your existing networks and use your existing applications, there are serious discontinuities that have to be addressed.
First, you have to deal with addressing. The typical cloud provider will assign you a block of addresses as part of your cloud account. For example, Flexiscale and GoGrid essentially give you get a block of assigned addresses that you can attach to the servers you create. In some cases these are external addresses (meaning that they are public addresses that can be accessed from the internet), while in others, they are internal. In either case, they are not assigned as part of your addressing. This means that even if you manage to connect these resources to your data center, you need to build new routes and alter your services to allow these “foreign” addresses into your system. Amazon originally took a different approach by providing a dynamic system where an address is assigned every time a server is started. This made it hard to build multi-tier applications, requiring developers to design systems able to pass changing address information between application components. The new VPC offering partially solves this problem for connecting to the Amazon cloud, although some key challenges remain. Other cloud providers are investigating similar networking capabilities.
The next major issue with networking in the cloud is data protection. In your data center, there is a secure perimeter defined and developed by your IT organization that is comprised of firewalls, rules, and systems to create a protected environment for your internal applications. This is important because most applications need to communicate over ports and services that are not well protected and certainly not safe for general internet access. Since applications are developed for the protected environment of the data center, it can be dangerous to move them unmodified into the cloud. Under normal circumstances, the application owner or developer has to build protection on a per-server basis and enact corporate protection policies.
The loss of control of the infrastructure mentioned earlier has additional implications – in most clouds you can’t control the physical interface level. That is, in addition to assigned IP addresses, you get MAC addresses assigned to you as well. These addresses can change every time a server is started which means that the identity of the server (and associated IP addresses) cannot be based on this familiar attribute.
All of these networking issues are at play whenever enterprise applications require the support of your data center infrastructure – things like identity services, naming services, and access to internal databases and other resources. Because of this, your cloud resources need a way to connect to your data center, of which the easiest approach is a VPN. In building this solution, you need to design for routing to the cloud and provide a method for cloud applications to “reach back” to the applications and services running in your data center. Ideally, this connection would allow Layer-2 connectivity because a number of services require this level to function properly.
To wrap up this segment, networking, like storage, is a very important part of your IT infrastructure, and the cloud adds a number of interesting new variables to the design and operation of your data center environment. What’s needed is a well-constructed architecture and a good understanding of the limitations imposed by the cloud if you want to integrate successfully with the public clouds. Today, this can be a major barrier to cloud adoption since enterprises are understandably reluctant to re-architect their network environments or become knowledgeable about the complexities of each cloud provider’s underlying infrastructure. When designing your cloud strategy, make sure to select a migration path that addresses these issues and protects you from costly engineering projects and cloud risks.
Next: Key Considerations for Cloud Management
Moving to the Cloud: Key Considerations for Cloud Storage
This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.
The true challenges in storage and data management in the cloud result from the diverse and often unfamiliar processes and infrastructures offered by the cloud providers, including: new provisioning methods, storage properties, data population and transfer, and systems for data management (snapshots, clones, replication, backup). The cloud providers define the relationship between servers and storage and often impose constraints on everything from allocation size limits to the ways in which storage is managed. These are just some of the things you’ll want to consider as you start to think about integrating cloud computing into your existing IT environments.
I’d like to focus in detail on the complexity and variability of cloud provisioning and storage properties. There are different models for storage in existing compute clouds, with the most common being an “inclusive” storage model. In this model, each server comes with a certain amount of storage attached to it. The storage is a fixed capacity that is provisioned when you create the server from the pre-existing templates.
For example, Rackspace gives you disk space that is proportional to the memory (RAM) size you select. The smallest memory/disk combination is 256MB of memory with 10GB of disk. With each doubling of memory, the disk space is also doubled until you get to roughly 16GB of memory and 640GB of disk. With the new Terremark vCloud Express, you get a system disk that is predefined for each “template” server you select. For a standard Linux distribution, you get a 10GB system disk, for Windows 2K3 you get a 20GB disk and for W2K8, you get a 40GB disk. Terremark’s vCloud Express allows you to add additional storage as new disks, while others (like Rackspace) allow to “resize” your servers and storage to create a new server with a larger disk and copy your data into it.
Amazon offers several distinct types of storage within EC2. The default storage you get with each server you create in the cloud is called “ephemeral” storage. You then have the option of allocating and attaching Elastic Block Storage (EBS), and there is also an object store system called Simple Storage Service (S3). Ephemeral and EBS are standard “block storage” devices – meaning they are viewed and used as disks attached to your server (/dev/sdg in Linux, D: in Windows) while S3 requires an API or other tools to integrate with your systems. The good part about the EC2 storage offerings is that you have some powerful options as you build for the cloud; the hard part is mapping the proper resources to your applications and integrating this with your existing processes. Specifically, the base storage is ephemeral, which means that if you power-off the server, or it has a hard fault, all the data on that storage is lost. This means that everything on these drives (boot parameters, application updates, user data, logs, etc.) is subject to loss when you power off the machine. There are several methods of handling this situation: 1) Build your servers every time you start them from a formula or other sources such that you don’t depend on the base storage being persistent; 2) Use Amazon or third party tool sets to periodically “bundle” your servers into S3 (effectively taking a snapshot of the server); or 3) Attach EBS storage to your image and store your important data on persistent storage.
Turning to granularity, we find a wide range in the units or increments of available storage in the various cloud providers. There is the “included” storage mentioned above that is often based on the size of the server and the requested OS type. To add storage, we find cloud providers (such as Amazon) allowing 1GB increments up to 1TB, and others (like Flexiscale) allowing only fixed increments of 50GB/100GB/250GB. For Rackspace, you can resize both the server and storage according to the defined fixed ratios, but these are bound to memory and CPU so there is no independent scaling of storage. The bare-metal cloud provider NewServers allows iSCSI storage to be attached to your servers in 250GB increments. In the cloud these varied increments really matter, because you are paying by the GB/month and if you need just a little more storage, you could end up having to purchase 10x more storage than you need, or having to pay for more memory and compute than you need.
The conclusion we can draw is that there are numerous storage configuration options in the cloud, and these options become linked to the server “flavors” defined by individual cloud providers. Because you don’t have the same control or even mechanisms in the cloud as you do in the local data center, the manner in which you allocate, populate and manage data in the cloud will be different. The work you do to understand and map your applications’ requirements into cloud-based storage requires changing your processes to match those of the cloud, and often this work is cloud-specific.
Beyond configuration issues, of course, there are many other concerns. For example, with data management, you have to determine how you will get your data into the system, how to grow your systems and how to protect your data. Right now most clouds use template servers that you have to build up from a pre-installed base operating system using update mechanisms and then re-installing the application components. As for protecting your data, there are also many cloud-specific options available – from RAID-protected EBS in Amazon, to data snapshots and cloning, to backup services offered by companies like Rackspace.
The bottom line is that cloud storage can be simultaneously simple and complex – just like cloud computing in general. It’s simple to use if you just want to try something new; complex if you want to integrate cloud storage into your existing processes and infrastructures.
Next: Networking in the Cloud
RSS Feed