One of the largest barriers to cloud deployments is the actual or perceived lack of security in the shared infrustructure used to provide cloud services.   Companies seeking to create applications that meet PCI, HIPAA, or FIPS standards are struggling with the twin challenges of actually meeting the requirements as well as finding auditors that are well enough versed in cloud technology to assess whether those requirements are met by a proposed cloud deployment.   On the other side of the fence, vendors are lining up to provide checklist-decorated services of supposedly regulation-compliant infrastructure that dangles the prospect of guaranteed compliance simply by choosing their hosting/cloud solution.   It's a mess! 

At ENKI, what we've learned is that there are two basic considerations in meeting requirements for compliant cloud security: actually providing infrastructure that meets auditor's requirements AND providing our customers with security solutions that are simple, effective, and flexible enough so that they can tell their clients or end users that they are not just meeting the letter of the law but actually sure that the personally identifiable data is really safe.

Our most sophisticated security-conscious client, a HIPAA-compliant medical information processing service company, is headed by a CEO who explained to me that his major challenge is convincing his customers (medical clinics) that they can trust him, for which HIPAA and SSAE compliance simply wasn't good enough.   He knew that he needed to secure his software by design, and then make sure that all the client data was completely inaccessible both at rest and in motion.   To accomplish the latter, they have chosen High Cloud Security's data security product, which is going to be rolled out in their processing environments at ENKI.

I recently met with their executive team (they're in Mountain View, like us) and was impressed with the product.  The architecture behind their system is to provide a storage republishing engine that handles all encryption, keeping unencrypted data completely out of the cloud storage infrastructure, while republishing a secured block or file based storage to the client VMs.   This not only secures the customer's data, but also the VM itself and its swap space - everywhere that an image of the secured data might reside, even temporarily, including backups.   In addition, they offer a key separate key management server with role-based access that can be locally or remotely hosted, allowing keys to be managed without the necessity of logging in and providing them to the application before it can run.  Key management can be entrusted to the cloud service provider, a third part, or even handled by the clients themselves.  While there is no 100% secure way of storing a key (who has the key to where the key is stored?) this solution allows you to choose who you'll trust with your keys, without having to manage them manually.   It completely eliminates carrying around printed keys, USB key storage sticks, or other ad-hoc solutions.   The one remaining challenge - securing the link from the VM to another to storage - is addressed by having an in-VM version of their storage publisher software.   With this method, any operations that the cloud service provider applies to the protected data do not expose any priveleged information - even moving the VM from one datacenter to another.

Because of ENKI's "everyting is virtual" approach to infrastructure, High Cloud Security's services are easy to deploy, and no restriction is placed on the flexibility of their key management: we can run it, you can run it, or you can have a third party run it. You can also use the storage republisher VM entirely for your private application, kept within a VLAN, so that no element of your cloud infrastructure shares unprotected data with another customer, which meets even the most stringent storage privacy requirements.

Please contact us to talk over your compliance requirements and how our virtual private cloud / virtual colocation architecture combined with High Cloud Security can make meeting your compliance requirments a snap.

In the last 10 days, ENKI experienced two downtimes that seriously impacted some of our customers.  What was common to the two failures is that they were due to unavoidable single points of failure in ENKI's infrastructure, points of failure that we had no control over.  ENKI, like all top-tier cloud providers (and colo/datacenter providers) has taken painstaking care to remove all possible single points of failure in its infrastructure, from the power coming into the datacenter to the servers that run our customer's applications.   In fact, ENKI has redundant power, cooling, security, storage, networking equipment, bandwidth links and service providers, servers, and interconnect.  At first blush, it looks like nothing can fail without a backup system taking over.

However, there are still single points of failure lurking in the modern datacenter.  And there is precious little that service providers can do about it.   Customers CAN do something about it, and I'll get to that later.   The source of those single points of failure is software.  Not the customer's software (though that is the most common cause of downtime) but rather software that is used to provide the cloud services.  And when it fails, it is the service provider's worst nightmare: watching the customers at whose side you've labored to help them grow their businesses, suffering terribly while there is little you can do besides working with your vendors to figure out a way to work around the defective software.

Eight days ago, one of our Juniper routers failed due to a known bug which was incorrectly categorized by Juniper as "noncritical" but caused a router to go down, and at the same time not informing the paired redundant router that a failure had occurred.  So no failover occurred and as a result one of ENKI's datacenters was cut off from the internet.   Lest you think this is a rare problem, just Google "Amazon router bug" and you'll find a few similar occurrences that have taken down Amazon's services.   The search works with other major providers as well.   They all rely on software that is inside hardware provided by major networking vendors; and that software is not perfect - as no software is.  Because of the nature of the failure we expereinced, the problem looked like a bandwidth provider issue, since our "failed" router was still active and passing some traffic.  It took a long time to diagnose and repair.  It was awful.

Today, ENKI experienced another problem in which our VMWare hypervisor and manager (VSphere) crashed in one of our clusters, rendering some customers' machines unusable.   VMWare confirmed that this is an as-yet unrepaired bug.  Even worse, to reset VCenter, VMWare recommended every server in the cluster be restarted so that all the v-switches would be reinitialized, which caused each customer in the cluster to experience a short downtime.   Our VCenter management nodes are redundant, the databases under them redundant, and of course our servers are redundant.  But if the software fails to recognize its own failures as an event that it has to respond to, the failure will go unaddressed.    This kind of failure is similar to the storage infrastructure failure that Amazon experienced a year ago, in which data was lost, or the Rackspace failure of two years ago.  VMWare is the premiere virtualization system on the planet and well ahead of its competition - but not perfect.   Today's downtime for the worst affected customers continued even after VMWare was fixed, since the crash stimulated a bug in our Oracle SAN causing it to make the LUNs open at the time of the crash unusable.   Oracle had no idea how to repair the problem, and we finally failed over to the backup SAN - against their recommendation - to fix the problem.  Once again, it was awful.  

So despite our best efforts, we - ENKI and other cloud or colocation service providers - cannot in good honesty guarantee 100% uptime, or even anticipate all failures because of the software bugs lurking in our management systems and datacenter hardware.  We could warrantee against them, but that wouldn't stop it from happening, and even worse it would give our customers a false sense of security!  In general, the industry's record is pretty good, and ENKI's record better than average.  But despite our best efforts, we are not immune to failures because at the end of the day, every provider relies on software that represents a single point of failure.  This will probably be the case for a long time, especially due to the rapid pace of innovation in cloud, networking, and storage software, which introduces bugs.

What can cloud customers do if they need more reliability than service providers can offer?   Many customers react to downtimes like this by considering building their own infrastructure.  However, it will rely on the same technologies that the service providers use, and will be subject to the same failures - not to mention that the customer has to incur tremendous costs to go it alone and often can't afford the high-availability storage and networking that service providers use.   And another strategy - moving to another services provider - seems like it will fix any recurring problems, but only until the next service provider encounters a bug.   

There are two solutions customers can implement.  The first is to make their software as restartable as possible.  Suppose one of your servers goes down, taking the application with it.  Then, the cloud management system restarts it (assuming you don't have ephemeral instances like those in Amazon.)  Will your application come up?   If not, you'll have a downtime much longer than the time your server was down.  It pays to test the restartability of your servers before they fail.  The downtimes experienced by many popular websites after a major outage have generally been 2-10x the length of the outage due to restartability issues.

The next and even more effective solution is diversifying critical applications across clusters.    Every cloud provider or colo provider provisions their systems in "clusters", sometimes called "availability zones" or other terms. These clusters generally have separate storage and networking (though in the case of Amazon, what we saw last year was that storage was shared across the entire datacenter, crossing availability zones.)   By placing active/active or active/standby application deployments in different clusters, you can get the redundancy that allows you to keep running past any single point of failure, since it's highly unlikely that even the same piece of software will fail at the same time in an unrelated infrastructure cluster.   WIth clusters hosted in the same location, the second copy of your app will easily be able to keep up with the primary one.   Over a longer distance, you will need to make provisions for handling delays in concurrency.  The unfortunate side effect of this approach is cost, but still less than it would take to build two physical infrastructure locations from scratch.   It also may require adapting or changing your software to allow for active/active or active/passive site pairing, and even potentially adding some global load balancing to use both sites at once.   Whether you're hosted at ENKI, Amazon, or in your own infrstructure, this is the only way you can get past the reliability barrier of 3.5-4 nines that today's infrastructure tops out at.

If you're contemplating deploying a high availability application, please contact us to talk about how we can assist you with it.

While the debate about what Cloud computing really is rages on with respect to IaaS (infrastructure as a service) or PaaS (platform as a service), the actual architectures behind these types of cloud have coalesced into two basic types: dedicated server slices, and fully abstracted computing resources.

The earliest and largest cloud services including Amazon and Rackspace are all based on dedicated server slices.   The basic idea is to provide a server with RAM/CPU, disk, and network connection much like the colocated leased dedicated servers that dominated web hosting 10 years ago.    For former hosting providers or colo providers going into the cloud market, this type of service is the easiest to understand and develop.  These types of clouds are often sold as a menu of fixed-size instances since they're trying to pack servers optimally, and often do not include solid performance guarantees or persistence guarantees since the provider has limited control over what happens on the servers. The user is never completely isolated from limititions of or problems on the server.   Dedicated server slice clouds often offer additional off-instance storage to compensate for the instance ephemerality (the possibility that the instance may disappear at any time.)

However, the theoretical basis for cloud is bins of resources comprising compute, storage, and networking, with the flexibility to allocate nearly any amount from each bin to create a custom computing environment.   Providers who implement this type of cloud "abstract" the resources from the underlying hardware that provides them and the user need not know anything about it.  This is more technically challenging, but can offer much better performance and flexibility.   Providers that do this include ENKI as well as Terremark, iLand and others, often using VMWare as the technological basis.  The hardware architecture consists of often diskless servers with a centralized SAN or NAS.   Often these providers will sell instance sizes that are fully customizable, persistent instances (since the instance is held on the SAN) and offer guarantees of performance since they can control the three bins of resources.

Which is better?   Typically dedicated server slices are less expensive, since lower-end server and disk systems can be used, as well as avoiding the expense of high-performance networking and pricey SANs.  Howeer, performance and reliability can be issues.    Fully abstracted resources offer the possibility of better performance guarantees (depending on the overallocation decisions the provider has made) and better reliability due to the instances' freedom from sitting on an individual server, but at potentially higher prices.

The table below summarizes the differences between the two architectures.

Various recent user surveys and performance measurements done on cloud computing systems show great variability over time as well as between services, which affects both the perceived reliability of the system and the effective price paid for cloud computing.   The root cause of this performance variation is overallocation of resources.  This blog entry will explore what overallocation is and how to minimize its effects.

First of all, let's remember that cloud computing's biggest pluses - savings and scalability - come from the fact that customers are accessing shared resources.   Because resources are shared, any bottlenecks in the system will affect all users' performance when the system is stressed.   Studies done at the University of Adelaide showed that Amazon's performance can vary by up to 10x over the course of the day, possibly due to demands on the EBS system, or simply overtaxing the gigabit ethernet connections on the individual servers.

Let's look at how this affects pricing.  For example, let's assume that you are paying $0.10/hr for a cloud instance.  If you log in (linux) you can use the 'top' command to see the I/O latency, shown as iowait.   Perhaps it's 10%.  this would mean that your instance is spending 10% of its time waiting for the network, and effectively you are paying $0.11/hr for one promised unit of the instance's performance.   However at 3pm, when all the schoolkids come home and get on multiplayer games, the iowait now jumps to 90% (yes, our customers have measured this.)  Now, you are paying $1.00/hr for the instance's promised performance.  Perhaps you don't need that performance, but if you do, then you have to compensate by buying 9 more instances, and you will indeed be paying $1.00/hr.

The example above covered unintentional (or at least unplanned) network overallocation but the other three resources that cloud vendors sell - storage, CPU, and RAM memory - can also be overallocated.   Like network bandwidth, storage can be overallocated simply by placing too many demands on the centralized storage system or local disk (depending on the cloud architecture - see my blog on cloud architecture.)  The network and storage overallocations are hard for the vendor to address rapidly because they would require hardware changes.  However, depending on the hypervisor the vendor chooses, both CPU and RAM can  be intentionally overallocated for a variety of purposes, usually associated with reducing costs and/or reducing pricing.

Here's how this works.    If it supports overallocation, the hypervisor allows setting two allocation parameters, a "limit" or maximum size of the resource, and a "reservation" or minimum size.  When a new instance is allocated, it is given the reservation amount, and then as it needs more, its usage can grow up to the limit.    This allows many more instances to be allocated - actually over-allocated - on a server, than would actually fit based on the promised instance sizes (the limits).   Until the instance actually needs more resources, it operates the same way as if it were not overallocated.  But when it asks for more resources, the hypervisor has two choices: deny them (which can cause the software to crash or operate very slowly) or move the instance to another server that has the resources available.    Moving the instance (or "motioning" it as some vendors like to say) causes congestion on the network and uses up CPU resources, resulting in slower performance for instances on the respective machines.   And since both deciding that the move is necessary (generally monitoring a prolonged resource shortage) and doing the moving the takes time, there is a delay between when the resources are needed and when they are available, which may affect some applications, especially those that experience peaky loads.

Despite its shortcomings, overallocation is common practice among cloud providers, and is likely responsible for some of the extremely low prices that some providers offer.   Whether that overallocation is intentional or the result of overtaxed resource bottlenecks like networking or SAN controllers, performance can vary widely between cloud providers based on hardware design and overallocation policies, yet these policies affect performance in complex ways and are rarely if ever documented by the provider.

How do you avoid suffering the penalties of low performance and excessive cost per unit of usable resources that overallocation can cause?   If you choose a cloud provider based on price,  you will likely be suffering from overallocation, which requires that you set up an auto-scaling capability in  your software as well as the cloud management system, so that additional instances can be allocated automatically as the load exceeds the available resources, in order to keep performance constant.   While this may address performance issues, it will not solve the problem if cost per usable unit of compute.    It can also lead to some very complex architectures, which I have seen deployed in Amazon to get around its widely varying performance.  In the end you may not see any cost savings from such workarounds since they inevitably have a cost of implementation and operation.   

The alternative is to choose a provider that does not intentionally overallocate resources, and addresses performance bottlenecks aggressively.    

Dell is asserting that cloud computing is raising the danger of vendor lock-in, which the IT industry has been successfully trying to reduce, by "shoehorning" proprietary technology into private clouds.

Well, nothing has really changed: buyer beware still rules the day!

The whole point of virtualization - the core enabler of cloud computing - is to separate hardware architecture from implementation.  Yet there are many cloud solutions that are proprietary.  And it's not limited to private clouds: Amazon, GoGrid, OpSource and others have "innovations" like hardware firewalls, proprietary hypervisors, and unique storage architectures that lock applications into their clouds.   The solution is to go back to basics: stick with hardware that supports standards (like NFS), use a an off-the-shelf hypervisor (paid or free), and implement architectural elements that used to require dedicated hardware (like firewalls and load balancers) with software (paid or free.)  Then, you can replace the underlying hardware (in the case of private clouds) OR cloud provider and keep running.   This isn't rocket science: you do have to swear off the goodies that any single cloud vendor touts as a you-can't-do-without requirement... but it also sets you free of lock-in.

At ENKI we have tried to avoid proprietary technologies that impact our customers' implementations.  Yes, we have branded firewalls and we use Infiniband,  the new wave in datacenter interconnect, as well as other non-standard technologies.  But from our customers' perspective, they are not visible or do not put requirements onto their deployments.   We've avoided exposing our hardware firewalls to our customers since that dependence would prevent moving to another cloud.  We've hidden Infiniband and our SSD-backed storage behind industry-standard NFS.   And so on.   And we always use standard hypervisors (VMWare and soon KVM) since we ourselves learned the hard way that applications stuck in a proprietary hypervisor (like our older cloud technology, Applogic, which has a custom version of Xen) are difficult to support or move around.   

As a result, our customers - for our public or our private cloud services - know that they can easily change providers, hardware architectures, geographies as their business requires, while still enjoying the superior performance and service that ENKI offers.

James Urquhart asks, "Can any cloud catch Amazon Web Services?"

His answer: It's nearly impossible though it may happen eventually.

I couldn't disagree more with this analysis. Certainly, within a limited scope, Amazon shall remain dominant because of the reasons you listed. However, if Amazon were "all that", they would have captured a significant portion of the overall IT market by now, not just early adopters and developers. There are plenty of ways other companies can and will be able to compete with Amazon because as you pointed out, being the market leader pigeonholes you, and because Amazon's continuing and somewhat bizarre focus on an academically pure cloud product rather than a customer-oriented one. The points on which competitors may compete, just for starters, include...
- performance. Amazon's underlying architecture isn't performance-oriented, in part because of pricing
- price. Believe it or not, they're making a large markup on the service which can be undercut
- relationship Being closer to your customers than a web-based vending machine gets them to both spend more and be happier with the service
- flexibility. Hybrid private/public clouds, special-purpose hardware (yes, despite virtualization, hardware has an impact on applications!), custom IT solutions, etc. are all making money for a lot of MSPs, but the Amazon cloud model doesn't allow for them
- reliability. Need I say more? There are plenty of different reliability/price points available for entering the cloud market.
- technology. Amazon's combination of server-for-hire with distributed storage isn't the only way to implement cloud. Ask VMWare. The other alternatives offer advantages that other service providers can exploit.
- market segmentation. Amazon has done little to address the low and high ends of the cloud market, despite inking some large deals. We've won a number of important deals from Amazon because their price point, use model, or instance inventory weren't targeted at the particular customer.
There are many more differentiators, but suffice it to say that the world would be a boring place indeed and cloud would be facing a much longer adoption cycle if Amazon were the only provider, just it would if Amazon didn't exist.

This week's VMWorld conference was a bit of a surprise to me.   Held in Las Vegas, the expo was considerably smaller than previous years in San Francisco perhaps due to lower marketing budgets (or higher costs of attendance) since vendor's booths were smaller and less ambitious than in previous years.    But what was more interesting was the limited commercial focus of the event: provisioning.  This year's exhibitor focus was on getting VMs into the cloud with a wealth of provisioning systems including VMWare's new version of VCloud Director and an updated VSphere suite, but also many third-party provisioning tools.  And with all that provisioning, lots of new storage and networking capability will be needed, so there are plenty of hardware vendors selling servers, storage, and network gear.  Storage, in particular, is taking a spotlight as public and private cloud providers are discovering that existing storage systems are not up to the task of serving up demands of a virtualized infrastructure loaded with a wide variety of applications.   And to a lesser degree there was a focus on managing increasing quantities of virtual machines and storage as both enterprises and cloud providers are seeing that "virtual sprawl" can turn into "cloud sprawl".

However what was more interesting was what was *missing*: innovation about what to do with all those VMs once they were deployed.   The problem of provisioning is essentially solved; lots of software exists to allow users to create new VMs on demand (even if it's still basically Beta software!).   Lots of hardware exists to facilitate that.   There are still horrific problems with scalability that only the largest cloud providers have by and large solved, but it is now only a matter of time until they are solved.   There's lots of innovation in storage and networking coming to market to solve them.  However, making those VMs useful is still an open field.

This issue is the one that I believe will define the next year of  progress in Cloud Computing.   The fundamental need of cloud users is to run applications with acceptable performance and uptime, and very low management effort.   This is where the next wave of innovation will be focused.  These products will improve productivity for all concerned.  From the user's point of view, this will look like an evolution of VM provisioning into platform-as-a-service, with much greater options available for deploying applications rather than just empty or "golden" VMs.   For the cloud provider - internal or public - it will look like tools that make it easier to get customers what they want quickly, and keep them running without downtime.   In particular, the current PaaS offerings - highly integrated but very inflexible and suffering vendor lock-in - will be replaced with a more flexible set of tools that provision customers' VMs and multi-VM applications based on templates managed by vendors, but customized by the end-customer.   In addition, as familiarity with application deployment and management in the cloud builds within the industry, cloud frameworks and management tools will offer standard options for application-dependent auto-scaling, disaster recovery, version updating, and failure response.
While this will be a many-year journey, I think the challenges that will be faced by cloud users and providers alike as enterprises start to move more mission-critical applications into the cloud will drive significant innovation and move the level of cloud services ever closer to true Virtual IT.   On the other hand, reports from the field are that larger enterprises are still struggling with virtualization and not moving to the cloud as fast as the analysts are reporting - so they too are looking for more useful, integrated cloud services... in other words, Virtual IT.  Since this is ENKI's vision, you can count on us being there with best-in-breed tools, a continued emphasis on a rich relationship with our customers, and some surprises that we're working on to help our customers make the most of their virtual infrastructure.

In his recent blog post, "Don't dismiss cloud computing hype; creative fog is what makes cloud work", Kevin Fogarty of ITWorld asserts that cloud hype is actually beneficial since it stimulates innovation and adoption by driving providers to stretch capabilities and customers to try new things (a short paraphrase.)   While this would be completely true in an academic environment in which some new theory or knowledge domain was being debated and developed, there are negative consequences in the real world for both providers and customers of cloud.

Being on the frontlines of delivering cloud as a managed cloud service provider, I feel compelled to take the customers' side in this.  Sure, we as a provider have benefited from the hype, because it has brought us customers who thought we were the El Dorado of IT services, a land in which your every IT wish would come true (or at least the wishes made possible by all the hype.)  However he makes the implicit point in his article that the hype is good because potential cloud customers are too well-considered and conservative to fall for it, so it really benefits the cloud ecosystem by fostering innovation.   My experience is that such customers are few and far between - even IT management in larger enterprises often is squeezed and troubled enough by their current situation that they will grasp at solutions that might seem like hype to those more well-considered, and cloud buyers at smaller enterprises and especially entrepreneurs often think the hype is all completely real.  This puts us - as an infrastructure and platform cloud provider - in the position of having to compete with imaginary products like cloud services that are up 100% of the time.  Sure, it drives our innovation to achieve that service level, but what do we say to someone who thinks it's currently possible for any random cloud deployment?   In our case, we choose to educate as part of our sales process, even if the education process disappoints the customer or we find that they are best served by going elsewhere.

So it makes me wonder what happens to cloud customers who believed the hype and chose a provider that didn't bother to tell them that it was hype.  The results can't be pretty, as we saw a few months ago when Amazon had a data center failure that only surprised those who believed the hype, rather than reading Amazon's actual service level agreement.  So there lies the danger of the hype: it serves both the clients and the providers of cloud by building a shared delusion that allows them to achieve their business aims - until that delusion is pierced by reality.
This is very much the same situation as the '90s in which large enterprise suites were sold (and still are) with the hype that they will actually make the client company successful, instead of the all-too-common result of entrapping it in an endless miasma of deployment headaches.  There was substance behind enterprise suites, and they didn't fade, but they did disappoint large numbers of buyers who are now being experimented on by SaaS companies instead, though this time around the challenges are different, resulting more from integration issues than configuration issues.

As the holder of my customer's IT responsibilities, we take them very seriously and are looking - much like the much-maligned IT departments Kevin compares cloud to - to reduce their risks and eliminate the effects of the ecosystem of experimentation that he is praising.   Analysts are always talking about the watershed that will get large enterprises and those that think like them to move important parts of their IT to the cloud: perhaps it is realizing that cloud vendors aren't going to experiment on them with hyped features that will help them cross the chasm.

I just spent 3 days at the HostingCon conference in San Diego.   For a cloud service provider, it was pretty eye-opening to for the first time, see the entire ecosystem for hosters as opposed to the pure enterprise-cloud world that we normally work with.   What is amazing is that the bulk of the revenue from Hosting/Bulk Hosting/Shared Hosting still comes from individual servers running unvirtualized CPanel/Plesk or other control panels.   Many of the booths at the show offered add-ins or enhancements to CPanel to allow it to deliver more robust services, including better security, reporting, and load management.   There was even one vendor who offered a clustered CPanel setup promising high performance.  However, the dominance of control panels is being challenged by companies like OnApp, which offers an environment of easy virtual machine deployment with a control-panel like interface and hoster-friendly setup.

There were also a number of vendors showing SaaS services that complement traditional hosting.  Cloud Flare and a few other security-as-a-service offerings that replace hardware firewalls (including web application firewalls) seem to be showing promise at reducing the cost of security and DDOS mitigation.  Cloud Flare offers caching for javascript and images on DNS-optimized points of presence, essentially making it a CDN as well.   There were also some monitoring and billing vendors and third-party PCI certification companies, which reflected the increasing sophistication of both hosting companies and their customers.

A few hardware vendors came to show off their latest wares.   SuperMicro and Dell now offer mini-blades of up to 12 1-socket servers plus disk in a single 2U chassis.   DataOn showed a drawer-style JBOD system similar to Sun's old "thumper" system, with very high density.  AmpliData has an object storage system with high performance and lower power density.

What was missing from the show was any kind of "real" enterprise-style cloud product, offering virtual private datacenters and management capabilities based on hierarchical customer entities.   It appears that both hosters and their customers are still happy with the traditional hosting model, leaving cloud computing to upmarket and vertical-market ecosystems.

This meant that I didn't really have a compatible language to describe to people I met what it is that ENKI does.    I finally came upon the idea to use old (hosting-age) terminology to describe the new generation of cloud services that ENKI offers:

dedicated server -> virtual dedicated server

colocation -> virtual colocation  (a customer-managed virtual private datacenter)

IT services -> virtual IT services (provider managed production IT in the cloud)

With this Rosetta Stone based on the concept of virtualization, I was able to get some good conversations going with hosters about the similarities and differences in our products and approaches, and how we could serve our customers better.   In particular, many cloud customers start with hosting and/or VPS services (especially as they prototype their websites), necessitating a strong cross-pollination of hosting and cloud vendors and services in order to better serve the market and avoid the customer disasters that Amazon experienced a couple months ago.

In addition, I saw that our private cloud deployment service, PrimaSys, based on our Computing Utility, is a good match for hosting providers looking to move into the cloud world, since it offers turnkey VPS provisioning, while also allowing whole applications to be deployed with a single click.

Today I received an email from the Cloud Connect conference soliciting sponsorship.  It began with the eye-opening comment, "Clouds are designed to fail - they're made of transient, unreliable components."  It then goes on to say that at the conference, an analyst will lead a discussion about architecting applications to work around expected failure.

But I'd like to go back and examine the opening comment.  Are clouds really designed to fail?   If you are a cloud aficionado as I am, you have been keeping tabs on Amazon's EC2 since it was created, and you'd know that the statement is correct about EC2.   Amazon approached the cloud from a very academic perspective, in which - much like a RAID array - the components are assumed to be failure prone and the only thing that can be guaranteed is the service as a whole (even across multiple datacenters) and that it is the users' responsibility to architect their application deployment around this principle.   So it was no surprise to me when a datacenter-wide failure in EC2 brought down many of its customers.  

However, Amazon isn't the only cloud out there, and it isn't even defining what cloud is or supposed to be anymore, even if it has a dominant market share.  EC2's low reliability, low performance, and fend-for-yourself management aren't suitable to many (and I would argue most) cloud customers, and other vendors - including ENKI - have stepped in to offer alternatives.  In fact, ENKI's cloud offerings have always been designed to recover from failure automatically because we know our customers are often not interested or capable of figuring out how to work around built-in failure modes.   Just looking out at the available technologies for building public or private clouds, CA's Applogic and VMWare have offered automatic failover for a long time, and newer offerings from smaller vendors are starting to offer it as well.

Now, I'll be the first to say that all systems have failure modes and there is no cloud or hosting solution that can offer 100% uptime - despite optimistic advertisements to the contrary.  Disks fail, servers fail, SANs fail, networks fail.  It's inevitable.  However, customers of clouds which have self-healing infrastructure have a choice: accept the vendor's guaranteed per-server/service uptime level as their base infrastructure reliability, or architect a more highly redundant deployment that can build on that base level.   For many, the 99.975% to 99.99% uptime that we guarantee at the operating system level is more than adequate for their business, especially considering that the bulk of their downtime is usually due to software issues.  On the other hand, customers of clouds guarantees only at the aggregate service level and not at the operating system/VM level do not have a choice: they must factor unbounded downtime into their systems architecture planning.  And that requires skilled, experienced IT staff and developers, as well as increased complexity and cost for redundant cloud instances

All clouds will fail, but the ones designed to stay up will offer a very different customer experience from the ones that are designed to fail.