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.

One of the huge advantages of the cloud is its ability to cut the time to market for new ideas, creating more agile enterprises.   While rapid provisioning and access to a larger set of resources than you might otherwise have contributes to this, the biggest win comes from realizing that the cloud eliminates the need to think linearly.

Over the last 10 years or so, software development methodologies have evolved from a "waterfall" analogy where design was followed by development then by test, then by deployment (to put it simply) to an agile, concurrent model where software releases became much smaller and all of the activities above happened at the same time.  So instead of:

design->develop->test->deploy

organizations realized that they can be much more customer responsive and get more done by developing software as follows, in which their team is broken up into smaller groups that work on multiple releases at once, speeding up release times by 4 (in this example):

design4->develop4->test4->deploy4

develop3->test3->deploy3->design7

test2->deploy2->design6->develop6

deploy1->design5>develop5->test5

However, the cloud allows you to apply this same discovery to your deployments, not just your development cycle.  What does this mean?   Well, for most growing internet enterprises, deployment isn't static: as their code evolves, so does their deployment architecture.   

Let's look at a little example.  We have a customer who is bringing their internet service from beta through ramp-up to large volumes.   As they do so, their deployment architecture has changed from single-instance MySQL to multi-instance MySQL to Mongo+MySQL and finally Mongo-only.   Here's how their IT staff laid out their IT architecture plans:

prototype MySQL -> test MySQL -> production MySQL -> prototype MySQLmulti
->test MySQLmulti -> production MySQLmulti -> prototype mongo -> test Mongo
-> production Mongo

If there were any problems in any of the prototyping or test phases for their deployment architecture, they'd run the risk of falling behind their code or the demands of their customer base and having a site meltdown or constraining their business.   But they don't need to think this way.

Even with a small team, they can simply develop each of the deployment architectures concurrently by creating a separate cloud instance for each one and making progress as their teams' knowledge base evolves, rather than being constrained by limited amounts and configurations of hardware for hosting the deployments.

prototype MySQL -> test MySQL -> production MySQL

                   |-->prototype MySQLmulti ->test MySQLmulti -> production MySQLmulti

                                  |-->prototype mongo -> test Mongo -> production Mongo

The organization has the option of trading off staffing for project schedule on the deployment phase, while avoiding any potential budget problems by using small cloud instances when needed to speed development of their deployments.   As a result, they no longer have to worry about being "taken by surprise" by a sudden hockey-stick in their usage that overwhelms their current-generation of deployment architecture.   And their IT operations staff no longer needs to worry about taking the blame for falling behind the market.

This applies equally well to testing new markets with mini-versions of new products, and whole host of other processes that used to be linear but can now be done in parallel, thanks the cloud.

Today, HP warned that cloud computing early adopters faced security risks.

But the timing and motivation for such a warning are suspect: the risk that HP is warning about is already present for for organizations that don't have an adequate security plan.  Where their infrastructure is - virtual, physical, cloud - is of little consequence if there is no application-dependent security plan in place.  Once the application-dependent plan is created, it must be adapted to the deployment strategy.  For example, at the simplest level, there must be a firewall in place to block unused ports, which will be a physical firewall for a physical deployment, or a virtual one coupled with vlan controls for a virtual or cloud deployment.

This is no different than the requirement that there be a business continuity plan available to ensure uptime.  During the failure at Amazon's East Coast datacenter two weeks ago, customers which had a business continuance plan in place barely noticed the outage, while those who had hoped that Amazon's services included solving their business continuance requirements were disappointed by a multiday outage.

So the risk of the cloud is really more that, with its point-and-click deployment ease, it can lull users into ignoring or avoiding their fundamental business-critical IT responsibilities, especially since avoiding these responsibilities can represent a large fraction of the cost savings they see from cloud deployment.   Because these security and in business continuance plans have to start with the application, the cloud-buying organization cannot expect an infrastructure or platform cloud vendor that they interact with purely through a self-service portal to "fix" their security and uptime exposure: they must either retain the IT expertise in-house to use the cloud properly, or find a managed cloud vendor that offers Virtual IT services as part of their management suite.

So in a sense, HP is belaboring the obvious: large enterprises already have enough IT expertise to use the cloud safely, and small enterprises are well warned not to ignore the risks of skipping business continuity and security planning.   A possible reason for HP's announcement is that HP is late to the cloud game.  While HP's competitors were fielding cloud services, HP was focusing on providing hardware and software to cloud vendors, and it still does not have a credible cloud offering, according to outsourcing experts.  And there's nothing wrong with that: HP makes fine hardware and software.  But this sounds more like a stalling tactic to me: "stay away from the cloud until we have a better solution to your security problems than our competitors!"

After last week's meltdown at Amazon, a lot of people (including me) are talking about what needs to change in cloud computing to provide users with a greater degree of confidence in cloud and the vendors that provide it.   So far, I have focused on the customers of cloud as having a great deal of influence over the levels of service they experience, since ultimately they have the power whether it is in how they use the service or which provider they choose.  The more informed they are, the better the cloud ecosystem will perform.

However, there is a major problem with this approach (nothing's simple, right?)  Customers can relatively easily inform themselves (or hire employees, consultants, or professional services) to help them make the best use of cloud services.  However, what they cannot easily do is find out all the limitations, gotchas, constraints, tradeoffs, and misrepresentations that cloud vendors suffer from, much like the colo and hosting vendors have for over a decade.   For example, Amazon is essentially a "black box" so even a very IT-literate customer can't effectively engineer around their limitations.   And Amazon has a very supportable position in not releasing all its secrets to the world for fear of losing its competitive edge.  This obfuscation in the name of protection of intellectual property and market position goes well beyond Amazon, however.  Based on my experiences, every cloud vendor and managed services provider also is part of this conspiracy of silence.  And amazingly, what I hear from investors and analysts about problems with various cloud technologies is not published on the internet or spoken of in conferences.  There are many reasons for this, not the least of which are gag clauses that equipment and software vendors write into their contracts.

For example, here at ENKI we use a number of branded products and technologies to provide our services.    The sales/service/evaluation contracts we signed with these vendors specifically prevent us from sharing lists of bugs, performance analyses, or other damaging information about their products with the public.   Again, it's quite reasonable that vendors we do business with be protected from incorrect or malicious information or misinformation about their products.  However, if their products have serious flaws - something that is going to be universally true about anything that is new or changing rapidly - then our customers have a right to know the risks they are taking with using those products in our services.  But we have no way to let them know except to call them individually.   Our only choice is to stop or avoid using the vendor's product, which is something we have done a few times in our history.  We can't even announce why we are discontinuing the use of the product, according to most of our contracts.

Every day, I see ENKI's competitors touting this or that product or technology, many of which we have already discarded as fatally flawed from the perspective of reliability, security, or usability, yet we can not have an open discussion about them on a public forum (though we're happy to do so individually!)   And I think about the hapless customers signing up to use their services, only to face business-critical limitations later.   Just today I got three marketing emails in my inbox from competitors using software systems to provide cloud services that suffer from horrific bugs.

While all this secrecy is understandable, and for the moment legally correct and enforceable, it is a disservice to the cloud-using and cloud-selling community.   You can't really choose a technology based on only its positive features!  Let's face it: every piece of software and hardware has flaws, but the ones that persist still offer enough value to keep people using them.  This isn't just true of cloud, but many IT products, in particular large, expensive software systems (which I'll also have to let remain unnamed) suffer from long-running outstanding bugs and terrible service.   I only see two ways out of this dilemma: either something blows up as it did last week, or software/cloud/hardware vendors permit and encourage a more open dialog as many Web2.0 companies have bravely begun doing. 

What can you, the cloud/IT/software-buying public do about it?  Not a lot, but you can start by letting go of the expectation of perfection, which drives vendors to try to hide bugs and problems.   An easy way to do this is to look at your vendor from a relationship point of view: when the inevitable problems crop up, are they willing and capable of responding?    This is no more - and no less - than you'd expect from your own IT department, right?

All this secrecy puts us at ENKI in an uncomfortable bind, since our corporate values are based on openness and transparency as a means of honoring our customers.   So if you have questions about a cloud technology please contact me.  I'll be happy to share what I know.  But please, don't expect me to sign my name to it!

In my last blog article, I wrote about what had happened to cause so many customers at Amazon's EC2 service to go down last week.   Now, I'd like to share my observations and learnings about this event gleaned from running our own cloud computing service and practice.

I have written extensively in the past about how cloud services have not progressed to the point where companies can do without IT operations, despite the apparent ease of starting an instance in the cloud.   Unfortunately, this observation is at the root of the problems that Amazon's customers experienced last week.

Let's look at how cloud computing has turned traditional SaaS provisioning upside-down in the last few years.   Back when I worked at NetSuite, and at other companies before that, once an application was completed, a deployment organization was built to provide it reliably and capably to customers.   While the pyramid on the left below is a bit exaggerated, a mature organization providing a reliable SaaS offering would grow its customer base over time by expanding the in-house deployment (IT) group which managed its systems, and by buying and maintaining more and more hardware in expensive purpose-built datacenters.  This provided good to excellent reliability because the company built its IT group with expensive hard-to-find (especially during the dot com boom) experienced IT experts.

However, today a software startup or even a growing SaaS company can "forget" about worrying much about IT since it can be managed at the click of a mouse.   The eye-hand-mind cycle of selecting a server instance, clicking to get it started, and being rewarded with an apparently perfectly functioning system leads the user to think everything is perfect; that all eventualities have been handled.  Especially if that hand is that of a developer or other staff not experienced in production IT concerns.  As a result, the company's management allows resources to go into developing the application instead of the IT infrastructure.  So far, so good.

The problems with this approach appear when management thinks that Cloud infrastructure is its IT strategy and eliminates the "Deployment Strategy" layer of the traditional IT stack.  After all, why keep all those people around when you can just tell Amazon what to do on the web?  This has resulted in the deployment organization you see on the right, which looks really good to the developer-founders and their investors, since more resources go to developing the app and everyone saves money and keeps equity compared to doing things the traditional way.

Of course, cloud vendors have not been remiss in taking up this value proposition and selling it back to entrepreneurs, who in turn think that it is an IT strategy, when in fact it is merely a cloud sales strategy.  Cloud computing has literally turned IT "upside down", but as we saw last week, many of Amazon's customers didn't realize what the consequences could be.  WIthout anyone in their organizations thinking about application deployment management, they became vulnerable to failures, performance problems, and downtime due to release management issues.

The solution is simple - isn't it?   Just go back to the way things were (left pyramid) but replace the infrastructure with cloud.  In fact, this is what the more successful users of cloud - who of course you don't hear about since they haven't experienced disastrous failures - have done.  However, in talking to prospects and customers, this hybrid approach doesn't get them the savings they expected from cloud computing.   They may save 10%-30% on infrastructure, and they definitely reduce their time to market, but they still have a heavy burden of IT operations, resulting in net savings in the 10%-20% range that leaves them disappointed with cloud economics.

Instead what is wanting here is a more 21st century approach to building an IT strategy for your SaaS company, similar to the hardware-eliminating infrastructure cloud revolution.  This comes down to two using two approaches, which can be combined: outsourcing, and automation.

For the smaller company or entrepreneur who still needs access to the level of IT competence that will ensure successful deployments, outsourcing is a godsend.  There are an increasing number of break-fix operations services companies that will manage your applications in the cloud for you, though the number who will actually advise you and fully manage the deployment and ongoing maintenance are fewer.  This is why we introduced our PrimaCare service to complement our own cloud services, which is essentially an insurance policy on your deployment to keep it from failing and make it successful.  By outsourcing IT on a per-deployment/per-VM basis, IT consts can be controlled through the same on-demand and pay-per-use methods that made cloud computing successful.

The other tool available to the SaaS provider is automation.  Amazon's Cloud Formation is great, but doesn't automate business processes associated with managing the cloud.    While commercial solutions like RightScale or open-source tools like Puppet and Chef can help, there is as yet no fully automated cloud management workflow engine, though the up-and-coming Kaavo Imod system is very promising.  However, the first order of business is to determine what processes you use for code updates, platform updates, security management, backup, disaster recovery, etc.   While some of these processes look like something that might come from your cloud vendor, unless you determine what you need and then assess what the vendor provides, you will never know the holes that need to be plugged.  An operations services vendor like ENKI can assist you with professional services to guide you through process discovery for your critical processes and the best way to automate them.

The resulting deployment pyramid is a hybrid of the old-school and Web 2.0 models, in which the middle layer - focused on operations services - has been restored but modified to complement the cloud delivery model and deliver the capability and maturity model (CMM) that SaaS customers have come to expect from their providers:

If it sounds like I'm leaning heavily on outsourced services, it is because in general I've found that rapidly growing entrepreneurial companies don't have the resources to solve these problems on their own, and the recent Amazon meltdown underscores that observation.   While it's nice to be able to solve every problem yourself, it's clearly better to get them solved sooner than you would waiting until you've grown enough (or had enough bad experiences) to do so yourself.  If your organization can leverage the skills, processes, and staff of a mature IT organization, on-demand, why develop it yourself, especially if the costs are lower.   Outsourced operations services are considerably more expensive than not having any operations services in your deployment model - but quite a bit less expensive that going it alone or suffering a repeating series of downtime events.

These observations are confirmed by the reducation in downtime we have seen ENKI's operations services customers experience, typically adding another half-nine or more of reliablity to their deployments.