Recent Posts
Private Clouds: Old Wine in a New Bottle
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John McEleney
I recently read a Bank of America Merrill Lynch report about cloud computing, and they described private clouds as "old wine in a new bottle." I think they nailed it!
The report points out that a typical private cloud set-up looks much the same as the infrastructure components currently found in a corporate data center, with virtualization added to the mix. While the virtualization provides somewhat better server utilization, the elasticity and efficiency available in the public cloud has private clouds beat by a mile.
In short, the term "private cloud" is usually just a buzzword for virtualized internal environments that have been around for years. By replicating existing data center architectures, they also recreate the same cost and maintenance issues that cloud computing aims to alleviate.
Despite their limitations, there is still a lot of industry talk about creating internal private clouds using equipment running inside a company’s data center. So why do people consider building private clouds anyway?
To answer this question, you have to step back and examine some of the fundamental reasons why people are looking to cloud computing:
- The current infrastructure is not flexible enough to meet business needs
- Users of IT services have to wait too long to get access to additional computing resources
- CFOs and CIOs are tightening budgets, and they prefer operational expenses (tied directly to business performance) vs. capital expenses (allocated to business units)
In every case, the public cloud option outperforms the private cloud. Let’s examine each point:
- Flexibility – the ability to access essentially unlimited computing resources as you need them provides the ultimate level of flexibility. The scale of a public cloud like Amazon’s EC2 cannot possibly be replicated by a single enterprise. And that’s just one cloud – there are many others, allowing you to choose a range of providers according to your needs.
- Timeframes – to gain immediate access to public cloud compute resources, you only need an active account (and of course the appropriate corporate credentials). With a private cloud, users have to wait until the IT department completes the build out of the private cloud infrastructure. They are essentially subject to the same procurement and deployment challenges that had them looking at the public cloud in the first place.
- Budgets – everyone knows that the economic environment has brought a new level of scrutiny on expenses. In particular, capital budgets have been slashed. Approving millions of dollars (at least) to acquire, maintain and scale a private cloud sufficient for enterprise needs is becoming harder and harder to justify — especially when the "pay as you go" approach of public clouds is much more cost-effective.
There are many legitimate concerns that people have with the public cloud, including security, application migration and vendor lock-in. It is for these reasons and more that we created CloudSwitch. We’ve eliminated these previous barriers, so enterprises can take immediate advantage of the elasticity and economies of scale available in multi-tenant public clouds. Our technology is available now, and combines end-to-end security with point-and-click simplicity to revolutionize the way organizations deploy and manage their applications in public clouds.
Sir Isaac Newton may not have dreamed about clouds, but his first Law of Motion, "a body at rest tends to stay at rest", has been a good harbinger of cloud adoption until now. It is fair to expect that people will grasp for private clouds simply because it’s more comfortable (it’s the status quo). However, the rationale for public cloud adoption is so compelling that a majority of organizations will choose to embrace the likes of Amazon, Terremark, and other clouds. As adoption increases, private clouds will be used only for select applications, thus requiring far fewer resources than they currently demand. We’re also seeing the emergence of “hybrid” clouds that allow customers to toggle compute workloads between private and public clouds on an as-needed basis.
In the end, we will have new wine and it will be in a new bottle. With CloudSwitch technology, 2010 is shaping up to be a great vintage.
What Cloud APIs Show Us About the Emerging Cloud Market
By John Considine
While there is no “official” definition of cloud computing, I believe programmatic access to virtually unlimited network, compute, and storage resources is an essential characteristic. Even though many users access cloud computing through consoles and third-party applications, the foundation of a cloud is a solid Application Programming Interface (API).
Since CloudSwitch works with many cloud providers, we have the opportunity to interact with a variety of cloud APIs—both active and soon-to-be-released versions. After working closely with both the APIs and those implementing them, I’d like to share some impressions:
- Despite all the discussion about standards, clouds are still very different. The important takeaway here is that cloud APIs have to cover a lot more than start/stop/delete a server, and once the API crosses into provisioning the infrastructure (network ranges, storage capacity, geography, accounts, etc.), things get more interesting.
- A cloud requires a very strong infrastructure to work properly. For public clouds, the infrastructure needs to be good enough to sell to others. If you know what to look for, key elements of the cloud API can inform you about the infrastructure, what tradeoffs the cloud provider has made, and the impact for end users (More on this later.)
- The cloud capabilities, and thus the APIs, are evolving fast. We see new API calls and expansion of existing functions as cloud providers add new features and capabilities. At the same time, we are talking with cloud providers about services that are coming soon and what form their API is likely to take. This is a great place to leverage the experience and work of companies like CloudSwitch to integrate the new capabilities into a coherent data model, and keep up with the changes.
An API can give a good indication of what is going on inside the cloud, particularly when you look at the functions beyond simple virtual machine control. I like to look at the network and storage APIs to understand how the cloud is built. For instance, in Amazon, the base network design is that each virtual server receives both a public and private IP addresses. The addresses are assigned from a pool based on where your machine ends up within their infrastructure so that the cloud provider can route network traffic to your servers. In Amazon, the base network design gives each machine both a public and private IP address, which are assigned from a pool based on where your machine ends up within their infrastructure. However, even though you get two IP addresses, the public one is actually just routed (or more accurately NAT’ed) to the private address. In Amazon, you only have a single network interface to your server, which is a simple and scalable architecture for the cloud provider to support, but will cause problems for applications that require at least two NICs (like some cluster applications).
An interesting contrast to this design is found in Terremark’s cloud offering. Like Amazon, IP addresses are defined by the provider so they can route traffic to your servers, but instead of the generic pool of addresses used by Amazon, Terremark allocates a range for your use when you first sign up. The good side of this approach is better control of the assignment of networking addresses; the bad side is potential scaling issues since you only have a limited number of addresses to work with. In addition, you can assign up to four NIC’s to each server in Terremark’s Enterprise cloud, which lets you create more complex network topologies and support applications that require multiple networks for proper operation.
Just when you thought this all makes sense, you have to take into account that in the Terremark model, servers only have internal addresses. Unlike Amazon, there is no default public NAT address for each server. Rather, Terremark has created a front-end load balancer that can be used to connect a public IP address to a specified set of servers by protocol and port. For each protocol and port you want to connect to your server, you must first create an “Internet Service” (in Terremark language) that defines a public IP/Port/Protocol and then assign a server and port to the Service, this creating a connection. Since this is a load balancer, you can add more than one server to each public IP/Port/Protocol group. Now that we have opened the discussion on load balancers, I have to mention that Amazon has a load balancer function as well. And while it is not required to connect public addresses to your cloud servers, it does support connecting multiple servers to a single public IP address.
The key point is that the APIs and the feature sets they define tell a story about the capabilities and design of a cloud infrastructure. Decisions made at the infrastructure level—like network address allocation, virtual device support, and load balancers—will impact the end user features, flexibility, and scalability of the whole service. When considering what cloud environment is best for your applications, you need to look down to the API level to understand how the cloud providers’ infrastructure decisions will impact your deployments.
Building a cloud is clearly complicated—but it provides an unbelievably powerful resource when it’s done right. Cloud providers choose key components and a base architecture for their service which results in clouds with different “sweet spots”. With CloudSwitch, you can span these different clouds and put the right application in the right environment.
Cloud Computing Compliance: Exploring Data Security in the Cloud
By Guest Author, David Mortman
David Mortman, Director of Operations and Security at C3 and former CISO at Siebel Systems, has a proven track record in leading security teams and setting security strategy at several companies, including C3, Siebel Systems, Network Associates, Securosis and Echelon One. David is a regular presenter at RSA and Black Hat and has also presented at SOURCE Boston, Information Security Decisions and the CSO World Congress.
Amid an ever-increasing bevy of regulations that enterprises need to worry about -- from SOX and PCI DSS to HIPAA/HITECH and the FTC's Red Flags Rules -- and a growing number of cloud service providers to choose from, enterprises have a lot of options and a lot of questions to consider concerning cloud computing compliance.
While migrating services to the cloud may provide many benefits, it does not absolve an enterprise of certain responsibilities. Most notably, the enterprise is still required to remain compliant with the assorted regulations and laws that it would fall under had it retained that service inside the company.
In some cases, as with PCI DSS, there is definite potential to reduce a company's compliance scope by outsourcing certain services. Most notably, by wholesale outsourcing the credit card processing to a third-party provider, an organization's PCI scope will be significantly smaller (though not go away completely). With the FTC's Red Flags Rules, however, that is not the case, as the FTC has mandated that any outsourcing must entail equivalent or better security than the enterprise would have implemented internally.
As you start to investigate moving services to the cloud, it's important to ask several cloud computing compliance questions:
- Does this data that will be moving to the cloud fall under any compliance-related regulations or requirements? This includes data such as Personally Identifiable Information (PII), Personal Health Information (PHI), or corporate finance-related information.
- If the answer to question one is yes, which regulations does it fall under and what controls are necessary?
- Can the cloud provider actually offer the identified or equivalent controls that your organization's data requires?
- Does the cloud provider have the necessary policies, processes and procedures to properly maintain those controls?
- Does the provider have appropriate disaster recovery and business continuity processes to meet your organization's business needs?
- What happens if the cloud provider goes bankrupt? Can the enterprise's data be sold to a creditor or at auction as a provider's asset?
- Should I decide to change providers, is there an easy way to export my data in a useable format?
- Is the provider willing to alter its default terms of service in order to guarantee or provide service level agreements (SLAs) around questions 3-7?
That last question is particularly important, as many cloud providers refuse to use anything other than their default contract language. As a result, they have effectively eliminated themselves from being potential providers of compliance data-related services. Several of the compliance regulations, most notably HIPAA/HITECH and the FTC Red Flags Rules, specifically mandate that an enterprise must have contracts with its service providers mandating appropriate controls, processes and procedures in accordance with each regulation's guidelines.
Similarly, if the providers can't meet the requirements of questions 3-7, they should also be eliminated from contention for your company's business. Lack of ability to meet requirements is a problem especially when it comes to PCI DSS and HIPAA/HITECH. Thus, you will quickly find that your options for cloud service providers are limited -- at least in the short term -- though rumor has it that several of the larger cloud providers are working on retooling their systems to meet these compliance needs. There are a handful of cloud providers on the healthcare side that have built applications specifically to meet the needs of the healthcare industry, but I have not yet seen any security evaluations of these applications to determine their effectiveness.
In the meantime, I recommend passing the above questions to providers that you're evaluating, much like you would pass them a request for information (RFI )for any other outsourcing project, and then choose the provider that can best meet your needs.
Alternately, if none can, investigate ways of removing or obfuscating the relevant data (such as hashing or encrypting information prior to moving it to the cloud), so your organization can still get the business benefits of the cloud.
Hear more from David Mortman in this recorded CloudSwitch webinar:
Title: “How to Secure the Public Cloud for the Enterprise: Making the Public Cloud Work Like a Private Cloud”
WATCH ON DEMAND >
