Amazon
SharePoint in the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Pavan Pant, Director of Product Management
As customers continue their march to the cloud we have heard from a large number who want to use SharePoint Server in the cloud. Two major concerns that show up frequently are migration of existing custom deployments and data security.
These organizations have spent years customizing their SharePoint deployments so they work just right in their environment, and moving to the cloud is a daunting proposition. Consider a scenario where a customer has deployed SharePoint and each department has its own intranet and individual sites for employees – the proliferation of these sites across organizations and the customization required has created a situation where customers typically stay away from using the cloud for their existing SharePoint deployments and start from scratch in the cloud.
We’ve also heard from customers who already have SharePoint deployed in their data centers with sensitive content (e.g., PII information) and would love to take advantage of the elasticity the cloud has to offer but have security concerns about using the cloud. In a shared multi-tenant environment customer data needs to be protected from unauthorized access at all times, and must be off limits to cloud providers. This essentially means that customers need full disk and network encryption to protect their data while it is at rest and in motion.
CloudSwitch allows you to take your existing SharePoint deployments and run them the cloud without requiring any changes to your application or networking. In addition, all your data remains secure – we provide full network and disk encryption (including encryption of the boot partition) in the cloud to ensure that your content remains secure while in transit to the cloud and in the cloud itself. Most importantly, the disk encryption keys remain in your control as opposed to being stored and managed with the cloud provider.
One of our customers is a large health insurance company that has sensitive patient data and other information in their SharePoint content management system. Their primary goal was to offload their ongoing management of the SharePoint servers in their data center and use Amazon’s public cloud. This would allow them not only to lower their costs but also to take advantage of the elasticity offered by the public cloud. The configuration in their data center is a two-tier SharePoint deployment – one server runs SQL while the other runs both the SharePoint Content Server and the Front-End IIS server.
With CloudSwitch’s software in place in their internal VMware environment, this customer was able to migrate their existing SharePoint deployment to the cloud securely, simply and without any changes whatsoever (IP address, MAC address, network configurations, etc.). Their end users can access and use the SharePoint sites for content management exactly as they did in the data center. SharePoint administrators are able to add servers to the farm, cluster the SQL server and burst in the cloud as needed just as they would in the data center but with all their security needs being met. Also, with the “infinite” scalability of the cloud, they no longer need to worry about the time it takes to buy and install new storage. They can allocate new resources to their cloud SharePoint deployment in minutes.
In addition to all this, the customer can also continue using their Active Directory installation in the data center to control authentication and authorization to the SharePoint portal – again, all of this without installing any agents or software on servers in the customer’s data center or any agents for the customer’s servers in the cloud.
Leveraging the Cloud
I recently attended a cloud computing panel where one of the panelists was lamenting how SharePoint was never architected with the cloud in mind because cloud providers like Amazon impose networking and storage constraints (e.g., dynamic IP address and ephemeral storage) that SharePoint does not handle well. Some of the main reasons to deploy SharePoint in a multi-tenant environment are to consolidate resources and take advantage of the scale the cloud offers – by having multiple users in a single deployment that can take advantage of storage as you grow. Many enterprises have been shying away from using SharePoint in the cloud because of concerns around security, storage management and networking implications. That applies only if you think about the cloud as an opaque system where only the cloud provider can control networking, security and configuration. With CloudSwitch, all of the control is shifted back to the enterprise and the users can run their existing processes and applications. We do all the heavy lifting for you so you can move your SharePoint deployments to the cloud and get started today!
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.
Amazon's Outage: Winners and Losers
By John Considine
In case you haven’t heard, last week Amazon’s Web Services had an extended outage that affected a lot of cloud users and has created a big stir in the cloud computing community. Here is my take on the outage, what it means, and how it affected both us and our customers.
First, the outage – Amazon’s Elastic Block Storage (EBS) system failed in one “small” part of Amazon’s mammoth cloud. The easiest way to identify with this failing system is to think of it as the hard drive in your laptop or home computer dying. Almost everyone has experienced this frustrating failure and it is always a frightening event. Your hard disk contains all of the data and programs you know and love (as well as all of the complex configurations that few really understand) that are required to give your computer its identity and run properly. When it fails, you get that sinking feeling – what have I lost, do I have any backups, how long is it going to take me to get up and running again? If you are lucky, it’s actually something else that failed, and you can remove the disk drive and plug it into a new computer, or at least recover the data from it.
Well, that is what happened in Amazon – the service that provided disk drives to the virtual machines in the cloud had a failure. Thousands (or perhaps tens of thousands) of computers suddenly had their hard drives “die”, and the big question was (repeated over and over)– what have I lost, do I have any backups, how long is it going to take me to get running again? At a more pressing level the question becomes did Amazon lose our data, or just connectivity to that data? In some circles there is no distinction between the two, but for most people, it just like that laptop – can I get my stuff back, or do I have to start from scratch? The good news is that it appears that most, if not all, of the data was recovered from this failure – indicating that the failure was in connectivity or that the data protection scheme that Amazon has in place was good enough to recover the data from the failed systems (or both).
There were three startling revelations from this failure:
- Cloud storage can fail – Ok, so this should not be startling, but we have not seen a failure like this in Amazon before, and we took it for granted that Amazon had “protected” the data and systems. There are nice features like “snapshot to S3 storage” that let users make copies of their disks into Amazon’s well known and respected Simple Storage Service (S3). This feature made people feel safe about their backups – right up to the point that they could not access the snapshots during the failure.
- People were using this storage without knowing it – Amazon is using their own infrastructure to deliver their other services as evidenced by other features being degraded or un-available when the EBS system went down. Some have speculated that in addition to the RDS service and the new Elastic Beanstalk, that some core networking functions could have been affected.
- This storage failure apparently jumped across “data centers” - OK, so this is a big one; Amazon encouraged us to build applications for failures and after an outage early in 2008, they introduced the notion of Availability Zones. These zones were designed to be independent data centers (or at least on separate power supplies, different networks, and not sharing core services). This would allow companies deploying into Amazon to place servers and applications into different zones (or data centers) to account for the inevitable faults in one zone. The fact that this issue “spread” to more than one zone is a big deal - those who designed for failures using different zones in Amazon’s east region were surprised to find that they could not “recover” from this failure.
This outage is a major event in cloud computing – the leader in cloud computing had a failure, a service went down for an extended period of time, and lots of companies were impacted by the fault. Now everyone is looking for the winners and losers – those who survived this outage and those who didn’t. Those who continued operation with little or no disruption fall into three groups – 1) Those who were lucky, 2) Those who were not using the effected services, 3) Those who had designed for this level of failure.
Based on our experiences and much of what I have read, the majority of the success cases during this failure were related to luck and those who didn’t use the service. Keep in mind that Amazon is huge, and they have “regions” all over the world including East and West coast of the US, Singapore, Tokyo, and Ireland. Each of these regions has at least two availability zones. The failure was primarily focused on one zone within one region. This means that everything running in other zones and other regions remained up and running during this outage and thus the majority of deployments worldwide were unaffected. I have read a few blogs of major users that stated that they don’t use the EBS service and thus had little or no trouble during this outage.
So what is required to survive this kind of failure? Many would say new architectures and designs are required to deal with the inherent unreliability of the cloud. I believe that customers can keep the same techniques, architectures, and designs that have been developed over the last 30 or more years, and it is one of the cornerstones of the CloudSwitch strategy. We believe that it should be your choice on where to use new features and solutions, and where to use your traditional systems and processes, and it should be easy to blend the two.
To that end, some of our customers are using a technique that extends their environments into the cloud; using the cloud to pick up additional load on their systems. In this failure case, they were able to rely on their internal systems to continue their operations. In other cases, customers want to use their existing backup systems to create an independent copy of their critical data (either in a different region, or in their existing data center). With the cloud, they can bring up new systems utilizing their backups, and continue with operations. The CloudSwitch system allows them to bring up systems in different regions, or even different clouds in response to outages; our tight integration with the data center tools allows them to use their existing monitoring systems and adjust for problems encountered in the cloud through automation.
How did we do? We’re very heavy users of the cloud, and many of our servers in Amazon were not impacted. Of the few that were impacted by the outage, a few key systems were “switched” back to our data center, and a unfortunately a few went down. On the servers that went down, we had decided to use Amazon’s snapshot feature as the data protection mechanism; we felt this was sufficient for these applications, and therefore we did not bother to run more traditional backups (or data replication). Given what we have learned from this experience and from observing how the community dealt with this outage we will now review those decisions. In the end, we’ll have a few more traditionally protected systems, and a few less that rely solely on the cloud providers infrastructure for data protection.
The outage from Amazon severely impacted many businesses and has caused many others to question the wisdom of clouds. The reality is that public and private clouds are a fact in the compute landscape, the only question is how do we insure that we have adequate protection? The answer lies in the experience that we have gained over the past couple of decades in building robust systems – in other words: what’s old is new.
CloudFormation – Cool, But Who Is It For?
By John Considine
A few weeks ago Amazon released a new feature for Amazon Web Services (AWS) called CloudFormation. This allows a user to organize the process for provisioning and operating resources in the AWS environment and is an evolution of the AWS model of “some assembly required.” We have often viewed the features and functions within AWS as a box of parts, from which users are left to build their own creations. This model is highly biased towards developers, the kind of people who like to have a box of parts and are willing to put in the effort to build new and interesting creations from them.
CloudFormation allows a user to coordinate a number of features within Amazon’s environment, such as: launch a set of AMIs (virtual machine image w/ application), configure a security group (pseudo firewall), setup an ELB (Amazon’s version of a web load balancer), and configure CloudWatch monitoring and alarms. All of this can be managed from a template that describes each of these setup steps, and is written in easy-to-use JSON.
So this new feature is pretty cool, but after working with it for a while, I’ve been wondering who the target user is. If you are a developer that is interacting with AWS through their API, then you already have a method of coordinating the resources and services in Amazon. By definition, up to this point, you had no choice. But more than that, if you are programming to the API, you want to have control over the details of your deployment, and to be able to monitor the steps and process. The CloudFormation is an alternative to your current methods, but is not necessarily better – if you are using the APIs, you still have to monitor the progress and deal with faults during the CloudFormation process.
On the other side of the spectrum, there are the “enterprise-class” users who are looking for full configuration management of their deployments – they want to control the full lifecycle of their system and software deployments including change control of all of the components within the system. The CloudFormation solution is really a provisioning engine, and even at that, it leaves off the early and late parts of provisioning – the actual configuration of the base servers, and the “customization” aspects of running in Amazon. Configuration and customization include things like creating the base images, controlling the OS configuration (kernels, boot parameters, etc.), selecting device drivers for consistent integration and operation, adjusting for randomly-changing IP addresses in Amazon, configuring load balancing based on the notion of instance ID rather than IP address, etc. The actual construction of the application and the configuration of the OS is done outside of CloudFormation, with CloudFormation operating as a provisioning engine.
Given that the developers have the tools they need to coordinate the provisioning and the enterprises are looking for full configuration management, where does this leave the target market for CloudFormation? Clearly the Amazon console users that are interacting with Amazon through the AWS portal are best served by this new feature. CloudFormation gives these users a simple “portal” for provisioning and managing their cloud deployments – but it comes at the cost of programmatic access and integration with existing application lifecycle tools and processes. Console interaction drives cloud activity into its own silo, and fosters the concept of the cloud as being a separate, foreign, and independent environment.
So what does this feature mean for CloudSwitch customers? Not much really, since our customers are looking for tight integration with their existing systems and processes, and want to have end-to-end control over their virtual hardware, operating systems, and application configuration. While CloudFormation is designed to allow a user to coordinate a number of features and functions of AWS, the user still has to use the new and somewhat different components provided by AWS. For example: using AMIs for their VM images, limitations on the kernels, operating systems, and OS configurations, firewall and load balancing configurations that are non-standard, and behaviors in the deployment and operation that deviate from the expected behavior in the enterprise.
In the CloudSwitch model, if a user wants to configure a firewall, they use a full-featured firewall with full configurability, not an Amazon-specific version; if a user wants to monitor their applications, they use their existing tools and processes; and if a user wants to have full configuration management of their deployments, they can control every detail of their servers virtual hardware, operating systems, networking, and applications – and not conform to the restrictions of the cloud provider. As our customers know, CloudSwitch is about giving the enterprise full control over cloud configurations and processes, rather than coordinating the components that a cloud provider delivers.
IAAS and PAAS: Getting Closer all the Time
By John Considine
Happy New Year! In this first post of 2011, I’d like to explore one of the primary ways the cloud landscape is evolving. Two of the pillars of cloud computing, Infrastructure as a Service (IAAS) and Platform as a Service (PAAS), are showing some interesting trends as cloud providers adapt to meet the needs of their customers. Over the coming year, we may see these familiar models evolving into something new since the ideal solution for most enterprises is not one approach or the other but some combination of both.
Traditionally these two methods of cloud computing have been quite distinct. Infrastructure as a Service providers like Amazon EC2, Terremark, and Savvis promise to remove the burden of managing physical infrastructure — everything from server installation and support to network and storage infrastructure build-out and management. Platform as a Service offerings like Force.com, Google App engine, and Microsoft’s Azure provide these benefits of IAAS in addition to offloading management of the underlying system and application software. Operating system software, core services, and even high level application building blocks are managed by the provider, freeing users from worrying about things like patching, updates, core application configuration and management.
Many feel that IAAS does not go far enough to eliminate the unnecessary overhead of managing common software components. Significant effort is involved in managing operating system lifecycles and common software components, and the PAAS supporters are pushing for cloud computing to eliminate this wasteful effort.
PAAS also has its downsides, particularly transition costs and vendor lock-in. In order to transition your workloads into PAAS, you have to adopt and design for the specific offering that the PAAS provider has created. This creates the potential for vendor lock-in because your new applications are using the specific services built by your PAAS provider, and you are unlikely to find the same services from another vendor.
We have found that enterprises are using all forms of cloud computing, from SAAS offerings like Salesforce to PAAS offerings from Microsoft to IAAS from Amazon. Within any given enterprise, there are multiple groups, departments, and users that have specific problems and are seeking solutions wherever they can find them. For example, business users in the organization are turning to SAAS to solve their customer management and collaboration, while developers are building new solutions on the PAAS platforms to speed development, and IT ops teams are utilizing the rapid provisioning and scalability of IAAS to get their work done. It is perhaps the pressure to provider broader solutions for these organizations that is leading to some interesting changes in the services offered by IAAS and PAAS cloud providers.
From IAAS providers, we’re seeing a trend to offer more PAAS services. This is apparent in Amazon’s offerings as they add services such as Relational Database Service (RDS) and Elastic MapReduce (Hadoop) to their SimpleDB and Simple Queue Service (SQS). These higher level services extend beyond simple IAAS into the realm of PAAS since they are not plain virtual machines but full services managed by Amazon. They carry all the benefits and disadvantages of PAAS offerings, with the interesting characteristic of being integrated as part of the overall Amazon solutions.
At the same time, we are seeing a new offering from Microsoft on their Azure platform, the VM Role. This soon to be released offering from Microsoft extends the PAAS nature of Azure into the IAAS realm. Now the customer can control all aspects of instances in Azure including all OS configurations and settings. Of course, this carries the downsides of IAAS as well, in that the customer must now completely manage the OS and applications.
These two providers give us insight to how the market is evolving — IAAS and PAAS are converging as vendors in each space adopt characteristics of the other. This convergence makes a lot of sense since enterprises want just as much control as they really need and the ability to offload work to a provider whenever feasible. In cases where they need to control the entire environment, they want low-level control. This is good news for both providers as well as customers because providers can offer value-added services that are “sticky” for their customers, while different groups within a given enterprise can choose the level of service they want, from fully-managed to completely controllable, now perhaps from the same provider.
As IAAS and PAAS morph into a converged model, CloudSwitch provides the position independence and flexibility that allow enterprises to take advantage of this evolving market without having to adapt to each cloud provider. By making the entire application stack (or selected portions of it) completely portable, from low level infrastructure to high level application control, customers can run their applications where it makes sense, with the management capabilities they need. It’s all about giving customers the choices they want, without risk of lock-in.
Image Conversion and VM Imports in Amazon
By John Considine
Yesterday Amazon announced another important tool in their ongoing platform innovation for EC2 – the VM Import tool. This converter allows you to “bring your VMware images to the cloud.” As we’ve seen extensively at CloudSwitch, this is a primary use case for most enterprises – the ability to take images you’ve already built (likely in VMware) and migrate them into the cloud. It’s great to see Amazon continue to innovate around these gaps in their offering, as this continues to drive the overall market growth and enterprise adoption. But it’s important to understand what this means for enterprises as they begin to move their workloads.
Enterprises do not want large engineering projects to be required as a step to the cloud. They want solutions that “just work” and allow them to focus on their applications and business – NOT their VM’s. They also need their cloud-based resources to remain completely unmodified in terms of the application stack (down to the lowest level of operating system) because their fundamental goal is for all the business processes around the application to continue to run independent of location.
Here are some critical requirements for image migration that we address TODAY at CloudSwitch – that can’t be addressed by simple image conversion:
- Maintaining the fundamentals of your operating system:
- No changes to the content of your operating system or applications
- No changes to the system registry
- Full system security:
- Automatic encryption of all data and communications
- No disabling of anti-virus, intrusion detection, or other protection systems
- No enabling of remote services (e.g., RDP) that potentially expose your apps to attackers
- Simple, enterprise-standard management:
- Management of all VM attributes (e.g., VMX, OVF, vApp…)
- No additional software in your OS images
- No changes to internal processes for building and managing VM’s
- No re-architecting of your networking or storage configurations
- No dependence on a cloud provider for your operating system selection, upgrades and patches
So where does this position the new VM Import converter from Amazon? It’s an important step along a much larger process of making EC2 become “enterprise-class,” or at the least, “enterprise-viable.” What’s needed is for the partner ecosystem around EC2 to build out the missing elements based on a deep, long-standing knowledge of enterprise needs and processes. At CloudSwitch, given our intense focus on enterprise requirements and team of experts in enterprise complex systems and software, we believe there is a very high bar to truly meeting the needs of the enterprise in the cloud. Beyond the underlying physical security, compliance and legal/procurement processes that cloud providers must address to be widely adopted, there are “tactical” issues around things like image migration that turn out to be far more complex than you’d think at first glance.
The key understanding of true enterprise needs is this: even small changes at the VM level can have major implications for application deployment, management, security and compliance. Enterprises care deeply about these issues and don’t want to adapt their processes to the cloud – they want the cloud to adapt to their needs. The Amazon VMware converter broadens the platform for developers in the cloud – this is good for the entire cloud industry. But if you want to run your enterprise applications in the cloud securely and without any modification or changes to your internal processes then you need CloudSwitch.
AWS and Freedom of Speech?
By John McEleney
The blogosphere and twitter have been in overdrive the past couple of days with the removal of WikiLeaks from AWS. The reaction and condemnation of Amazon has been swift and often brutal – charging the company with censorship and cowardly behavior. Consider the announcement from WikiLeaks on Twitter:
“WikiLeaks servers at Amazon ousted. Free speech the land of the free — fine our $ are now spent to employ people in Europe.”
Even the New York Times is fanning the flame by suggesting that Amazon yielded to political pressure from Senator Lieberman: “WikiLeaks’ illegal, outrageous, and reckless acts have compromised our national security and put lives at risk around the world,” Mr. Lieberman said. “No responsible company – whether American or foreign – should assist WikiLeaks in its efforts to disseminate these stolen materials.”
It’s very clear that WikiLeaks violated their terms of service; in fact Amazon posted this announcement on their AWS site:
Amazon Web Services (AWS) rents computer infrastructure on a self-service basis. AWS does not pre-screen its customers, but it does have terms of service that must be followed. WikiLeaks was not following them. There were several parts they were violating. For example, our terms of service state that “you represent and warrant that you own or otherwise control all of the rights to the content…, that use of the content you supply does not violate this policy and will not cause injury to any person or entity.” It’s clear that WikiLeaks doesn’t own or otherwise control all the rights to this classified content.
I believe the decision by Amazon was neither censorship nor cowardly. If I had to choose a word to express the action taken, I would call it consistent. It is consistent with the agreement that end users accept when they use AWS. I applaud Amazon for taking this action. While there are valid arguments for both sides of the WikiLeaks issue, these are part of a much broader debate over the democratization of information enabled by the internet and the moral code that journalists in the print media have lived by for so many years. For Amazon, the issue is more specifically related to the nature of the WikiLeaks content.
Sometimes it is useful to examine this type of decision at a personal level. Imagine that tomorrow someone steals some of your own personal property and tries to sell it on eBay. Wouldn’t you expect eBay to respond to your request by removing the offending posting? That’s exactly what Amazon did – once alerted to the fact that WikiLeaks was using AWS to distribute material that did not belong to them, Amazon took the controversial, but proper step (consistent with their terms of usage) of discontinuing WikiLeaks’ service.
Conspiracy theorists will say that Obama and half the government called Jeff Bezos and demanded that he stop WikiLeaks or else… my guess is that the truth is that the AWS team simply looked at the material and made the decision to terminate their access because it violated their terms of usage.
This is plain and simple – no major conspiracy, no attack on freedom of speech, just consistent business practices – which is exactly what you and I should expect from a leading cloud provider.
Why Public Clouds Are Looking Hot (Again)
By Ellen Rubin
Seems like it was only yesterday when industry pundits were backing away from public clouds in favor of the safer, more big-vendor-compliant “private clouds.” After Amazon shook things up with its new paradigm for computing and storage clouds in 2007, and started to gain traction (along with Rackspace and other cloud providers) in 2008 and 2009 – 2010 so far has been in many ways a retreat from the forces of innovation and the emergence of much fear, uncertainty and doubt about the perils of the public cloud. But lately, I’m seeing the pendulum start to swing back in favor of public clouds, albeit with a twist.
Not surprisingly, private clouds look more familiar and comfortable to IT managers, big vendors and consulting/SI/service providers. They involve purchases of hardware, software and services through traditional enterprise procurement processes. They allow resources to stay behind the firewall under enterprise control. They fall within the existing legal, compliance and audit structures. With the addition of many flavors of “cloud in a box” offerings, they start to address the main issues that drove developers to the public clouds to begin with: self-service, provisioning on demand and the ability to get access to more scalable resources without requiring large upfront cap ex.
Public clouds have all the benefits that have been written about extensively (horizontal scaling, true on-demand capabilities, pure op ex, etc.). But for much of this year, the debate in the industry has been all about how worried everyone is about using public clouds (security, control, etc. etc.), and how uncertain they are about whether IaaS will really take off.
But there are some recent indications that the public cloud is hot again. A great study by Appirio speaks to growing industry comfort with public clouds and the likelihood that these will have a dominant place in IT infrastructure. At the Up2010 cloud event this week in San Francisco, Doug Hauger, GM of Microsoft’s Azure cloud, referred to this study extensively to make the point that public clouds are gaining credibility. James Staten of Forrester recently blogged about his predictions for 2011, including: “You will build a private cloud and it will fail.” His point is not to discredit private clouds as an approach but to remind companies beginning this process how incredibly hard it is to build a large, scalable, on-demand, multi-tenant cloud – even just for internal users.
Staten’s predictions make the case for how the cloud market has evolved in 2010, as enterprises planned their cloud strategies, implemented their pilots and defined their cloud architectures. Rather than seeing public clouds as “the other alternative” to private ones, enterprises and vendors have begun to view these as compatible strategies in a more sophisticated hybrid cloud model.
We’re huge fans of the hybrid model at CloudSwitch, and it’s great to see customers embracing public clouds as extensions of their private ones (as well as of their traditional virtualized data centers). The critical point about public clouds is that they allow testing, innovation and quick success or failure to happen in a low-cost way. This learning is imperative for the hybrid model, and public clouds are here now, today, working well and allowing enterprises to gain experience and log cloud mileage as they build out the rest of their cloud infrastructures. With CloudSwitch, these companies are now able to view the public cloud as a safe and seamless extension of their internal environment, in effect turning the public cloud into a “private” cloud as well.
"Cloud in a Box" Gets Boxed In
By John Considine
Just a week after our blog post on the telcos, we find another big company joining the cloud computing tsunami – Oracle’s announcement of its “cloud in a box” offering as well as new offerings of Oracle software running on Amazon’s EC2.
For a company whose leader shunned the term “cloud” last year, this is a lot of cloud announcements in one week. Oracle’s new Exalogic Elastic Cloud is perhaps the first 
“cloud in a box” solution that is actually delivered in a box (of hardware). Unlike the offerings we have seen from Eucalyptus, Nimbula, Azure, and VMware, the Exalogic product contains the control software as well as the hardware components to make a virtualized resource pool. The other vendors have focused on delivering a software solution that can be combined with the users’ choice of servers, storage, and networking gear to build a cloud.
Oracle, powered by Sun’s server and system technology, has decided to deliver a complete cloud solution that contains up to 360 CPU cores, 2.8TB of RAM, and 40TB of storage in a single rack of equipment. This big box is reportedly priced at just over $1M. Oracle’s motivation for this box is to deliver on the promise of building an entire stack of both hardware and software that has been engineered to work together to deliver better performance, reliability, and scale. Overall, the Exalogic system has impressive performance characteristics and may be a great solution for data center consolidation, but…
Placing the term “Elastic” in the name of this offering is stretching the accepted definition of the term as it relates to cloud computing. The Exalogic server is a contained set of resources that is purchased, operated, and maintained as part of the enterprise infrastructure. You can scale your applications up and down within this solution, but in the end, you are limited to the number of cores, amount or RAM, and size of the storage you purchased. While you can add more racks to the solution, you are stuck paying for the whole thing independent from what you really use – not exactly elastic or pay for only what you use. My only other problem with Exalogic is the range of supported operating systems – we like the Linux and Solaris support, but a quote from Rick Schultz of Oracle – “There is no demand for Windows at the moment” – makes me wonder who they are talking to. More than half the enterprise workloads CloudSwitch has deployed to the cloud are Windows-based; how can there be no demand for Windows in Exalogic?
The other interesting difference in the Exalogic solution as compared to the big (public) cloud offerings is the design center for the hardware. Clouds like Amazon and Google were developed around “stripped down” servers to act as generic compute components. The redundant components normally used to improve the reliability of a server are removed from the compute nodes to reduce the component cost, and software and other application-level techniques are used to make up for the fail-able components. Each of the servers in the Exalogic solution has redundant power supplies, 2 solid state disk drives, and redundant Infiniband controllers. This more expensive hardware allows the system to survive component failures with minimal disruption to the running applications – a traditional enterprise infrastructure design, with high reliability to support a lot of VM’s packed on a single piece of hardware.
The difference between the two approaches highlights the upcoming battle between architectures in the cloud – stripped down commodity servers versus highly available high-end servers as the basis for cloud computing. The early leader in this space is the commodity server approach because of the types of applications initially targeted to clouds – stateless horizontally scalable web applications. But as we start putting more core enterprise applications into the cloud, the HA architectures become more interesting, and thus we expect this architecture to gain ground. We see these architectures gaining ground already with clouds like Terremark, BlueLock, and Savvis.
The other announcement this week from Oracle is expanded support for running Oracle software in Amazon’s Elastic Compute Cloud. Oracle has provided templates (AMI’s) in Amazon for its database software since 2008, and this week they have expanded the number of applications they will support in Amazon to include Oracle E-Business Suite, Oracle's PeopleSoft Enterprise, Oracle's Siebel CRM, Oracle Fusion Middleware, Oracle Database, and Oracle Linux. In addition to expanding the software supported on AWS, Oracle has taken the step of “certifying” the software for operation in Amazon. This means that customers can now get support from both Oracle and AWS for those applications. Although Oracle’s lead cloud story seems to be about the Exalogic box, I believe that this announcement does more to advance cloud computing for enterprises. Support for these key Oracle products in Amazon’s cloud adds credibility to public cloud computing, as it allows enterprises to really use the cloud for their core applications. This is one of the areas that a cloud provider cannot fix, it is up to the software vendors to expand their horizons to embrace the cloud and Oracle is blazing the trail.
I think the only downside to the Oracle-Amazon announcement is the lack of integration with Oracle’s control software. The FAQ’s from Amazon and Oracle emphatically state that the management controls for Oracle deployments to the cloud is exclusively the Amazon console and tool set. This is a shame since we believe that seamless integration between the data center and the cloud is key to a successful enterprise cloud deployment; creating a disjointed environment just adds work with no value for the enterprise and ultimately leads to cloud lock-in. Our enterprise customers have told us consistently that they want a “single pane of glass” from which they can manage pools of resources both internal and external.
Finally, while I like the architecture of the Exalogic Elastic Cloud, and believe that it could form the basis of a new class of cloud computing offerings, it too may be missing a critical point. If an enterprise decides to deploy their private cloud on this technology, there is no connection or relationship between the applications deployed to the private cloud and those running in the public cloud. This, once again, highlights the importance of cloud federation – you will never break the cycle of buying more hardware and infrastructure if you don’t embrace technology that allows you to access the public clouds.
Where Are the Telcos?
By Ellen Rubin
This week’s Verizon announcement about their new CaaS offering for SMBs highlights a strange situation in the cloud computing market. While Amazon has been growing explosively and MSP/colo providers like Rackspace, Terremark and Savvis have rushed to embrace cloud in their business models, the telcos have been slow to enter the fray.
Telcos in many ways seem like the most likely players to lead and ultimately win in the land-grab of cloud computing. They’ve got the huge scale, geographic coverage, existing enterprise relationships and experience in service delivery that would appear to give them unfair advantage. As noted in the Verizon announcement and some recent blogs, telcos have a “unique opportunity to position cloud computing as an extension of their managed networking solutions (such as MPLS-based VPNs), by offering ‘on-net’ cloud computing capabilities backed up by end-to-end service-level agreements (SLAs).” In fact, the networking infrastructure and ability to offer dedicated and secure access is one of the telcos’ greatest strengths since it addresses some of the key concerns about cloud security and bandwidth.
So it’s worth considering why the telcos aren’t yet a dominant force in the industry. To a certain extent, it’s taken a couple of years for them to perceive the threat of Amazon et al to their core businesses. The response has been primarily a defensive one, as noted by IDC’s Melanie Posey: “Right now they’re concerned with, ‘If our existing customers want cloud in addition to the traditional hosting we’re offering them, we have to have something too or they’ll take that incremental business to somebody else.’” Marketing announcements and pricing model changes have so far been the fastest and lowest-cost response to this threat. For example, some telcos are now offering per-month pricing instead of the traditional annual or multi-year structures.
In parallel, the telcos are doing the heavy lifting required to build new cloud services. A lot of the real spending so far in the cloud market is being done by these players: buying new gear from the server, storage and networking vendors; installing new software and management tools from the hypervisor and service management players; designing new architectures with the help of consulting firms; leveraging existing infrastructures from Terremark, OpSource and others, etc. This all takes significant time and money.
While this investment is taking place, there’s relatively little to see in terms of live customer deployments. But in the meantime, the first-mover cloud providers and customer early adopters are moving full-speed to test and improve their offerings and cloud footprints. They’re shaping and defining cloud requirements and best practices based on real-life customer engagements. The risk for the telcos in being late to the party is that they’re not getting the customer insights first-hand and are missing the direct experience needed for successful scale-out and service delivery. Without this, they could end up delivering too little, too late. Still, given the size and projected growth of the cloud market opportunity, there’s no doubt it would be a mistake to count the telcos out.
