My friends at Standing Cloud have closed another $3 million financing from us (Foundry Group) and Avalon Ventures. They’ve also added a long time friend, co-investor, and amazing entrepreneur Will Herman to the board.

Standing Cloud is a great example how one of our funding strategies plays out. We are the seed investors and have been working closely with the company since inception. They’ve built an incredibly deep product around a very specific aspect of the broad Cloud computing ecosystem. When they started, much of Cloud computing was total noise and marketing baloney. While there’s still plenty of that in the system, many of the products and services are maturing and the particular segment Standing Cloud has gone after has suddenly become incredibly important to a large number of hosting, managed services, and cloud providers (often the same thing) not named Amazon. Specifically:

Standing Cloud provides a seamless application layer for cloud providers, making application deployment and management fast, simple and hassle-free for their customers. Standing Cloud’s standard application catalog includes 100 open-source and commercial applications; its Platform-as-as-Service (PaaS) capabilities support multiple programming languages, including Rails, PHP, Java and Python, and a wide range of cloud service providers and orchestration software systems.

If you are a hosting, managed service provider, or building a cloud service (public or private), you have three choices. The first is to ignore this stuff (dumb). The second is to try to build it all yourself and keep pace with Amazon (good luck). The third is to use Standing Cloud.

If you want an intro, just email me and ask.

As most nerds know, Skynet gained self-awareness last week and decided as its first act to mess with Amazon Web Services, creating havoc for anyone that wanted to check-in on the Internet to their current physical location. In hindsight Skynet eventually figured out this was a bad call on its part as it actually wants to know where every human is at any given time. However, Skynet is still trying to get broader adoption of Xbox Live machines, so the Sony Playstation Network appears to still be down.

After all the obvious “oh my god, AWS is down” articles followed by the “see – I told you the cloud wouldn’t work” articles, some thoughtful analysis and suggestions have started to appear. Over the weekend, Dave Jilk, the CEO of Standing Cloud (I’m on the board) asked if I was going to write something about this and – if not – did I want him to write a guest post for me. Since I’ve used my weekend excess of creative energy building a Thing-O-Matic 3D Printer in an effort to show the machines that I come in peace, I quickly took him up on his offer.

Following are Dave’s thoughts on learning the right lessons from the Amazon outage.

Much has already been written about the recent Amazon Web Services outage that has caused problems for a few high-profile companies. Nevertheless, at Standing Cloud we live and breathe the infrastructure-as-a-service (IaaS) world every day, so I thought I might have something useful to add to the discussion.  In particular, some media and naysayers are emphasizing the wrong lessons to be learned from this incident.

Wrong lesson #1: The infrastructure cloud is either not ready for prime time, or never will be.

Those who say this simply do not understand what the infrastructure cloud is. At bottom, it is just a way to provision virtual servers in a data center without human involvement. It is not news to anyone who uses them that virtual servers are individually less reliable than physical servers; furthermore, those virtual servers run on physical servers inside a physical data center. All physical data centers have glitches and downtime, and this is not the first time Amazon has had an outage, although it is the most severe.

What is true is that the infrastructure cloud is not and never will be ready to be used exactly like a traditional physical data center that is under your control. But that is obvious after a moment’s reflection. So when you see someone claiming that the Amazon outage shows that the cloud is not ready, they are just waving an ignorance flag.

Wrong lesson #2: Amazon is not to be trusted.

On the contrary, the AWS cloud has been highly reliable on the whole. They take downtime seriously and given the volume of usage and the amount of time they have been running it (since 2006), it is not surprising that they would eventually have a major outage of some sort. Enterprises have data center downtime, and back in the day when startups had to build their own, so did they. Some data centers are run better than others, but they all have outages.

What is of more concern are rumors I have heard that Amazon does not actually use AWS for Amazon.com.  That doesn’t affect the quality of their cloud product directly, but given that they have lured customers with the claim that they do use it, this does impact our trust in relation to their marketing integrity. Presumably we will eventually find out the truth on that score. In any case, this issue is not related to the outage itself.

Having put the wrong lessons to rest, here are some positive lessons that put the nature of this outage into perspective, and help you take advantage of IaaS in the right way and at the right time.

Right lesson #1: Amazon is not infallible, and the cloud is not magic.

This is just the flip side of the “wrong lessons” discussed above. If you thought that Amazon would have 100% uptime, or that the infrastructure cloud somehow eliminates concerns about downtime, then you need to look closer at what it really is and how it works. It’s just a way to deploy somewhat less reliable servers, quickly and without human intervention. That’s all.  Amazon (and other providers) will have more outages, and cloud servers will fail both individually and en masse.

Your application and deployment architecture may not be ready for this. However, I would claim that if it is not, you are assuming that your own data center operators are infallible. The architectural changes required to accommodate the public IaaS cloud are a good idea even if you never move the application there. That’s why smart enterprises have been virtualizing their infrastructure, building private clouds, and migrating their applications to operate in that environment. It’s not just a more efficient use of hardware resources, it also increases the resiliency of the application.

Right lesson #2: Amazon is not the only IaaS provider, and your application should be able to run on more than one.

This requires a bias alert: cloud portability is one of the things Standing Cloud enables for the applications it manages. If you build/deploy/manage an application using our system, it will be able to run on many different cloud providers, and you can move it easily and quickly.

We built this capability, though, because we believed that it was important for risk mitigation. As I have already pointed out, no data center is infallible and outages are inevitable.  Further, It is not enough to have access to multiple data centers – the Amazon outage, though focused on one data center, created cascading effects (due to volume) in its other data centers. This, too, was predictable.

Given the inevitability of outages, how can one avoid downtime?  My answer is that an application should be able to run on more than one, or many, different public cloud services.  This answer has several implications:

• You should avoid reliance on unique features of a particular IaaS provider if they affect your application architecture. Amazon has built a number of features that other providers do not have, and if you are committed to Amazon they make it very easy to be “locked in.” There are two ways to handle this: first, use a least-common-denominator approach; second, find a substitution for each such feature on a “secondary” service.
• Your system deployment must be automated. If it is not automated, it is likely that it will take you longer to re-deploy the application (either in a different data center or on a different cloud service) than it will take for the provider to bring their service back up. As we have seen, that can take days. I discuss automation more below.
• Your data store must be accessible from outside your primary cloud provider. This is the most difficult problem, and how you accomplish it depends greatly on the nature of your data store. However, backups and redundancy are the key considerations (as usual!). All data must be in more than one place, and you need to have a way to fail over gracefully. As the Amazon outage has shown, a “highly reliable” system like their EBS (Elastic Block Storage) is still not reliable enough to avoid downtime.

Right lesson #3: Cloud deployments must be automated and should take cloud server reliability characteristics into account.

Even though I have seen it many times, I am still taken aback when I talk to a startup that has used Amazon just like a traditional data center using traditional methods.  Their sysadmins go into the Amazon console, fire up some servers, manually configure the deployment architecture (often using Amazon features that save them time but lock them in), and hope for the best.  Oh, they might burn an AMI and save it on S3, in case the server dies (which only works as long as nothing changes).  If they need to scale up, they manually add another server and manually add it to the load balancer queue.

This type of usage treats IaaS as mostly a financing alternative. It’s a way to avoid buying capital equipment and conserving financial resources when you do not know how much computing infrastructure you will need. Even the fact that you can change your infrastructure resources rapidly really just boils down to not having to buy and provision those resources in advance. This benefit is a big one for capital-efficient lean startups, but on the whole the approach is risky and suboptimal. The Amazon outage illustrates this: companies that used this approach were stuck during the outage, but at another level they are still stuck with Amazon because their server configurations are implicit.

Instead, the best practice for deploying applications – in the cloud but also anywhere, is by automating the deployment process. There should be no manual steps in the deployment process. Although this can be done using scripts, even better is to use a tool like Chef, Puppet, or cfEngine to take advantage of abstractions in the process. Or use RightScale, Kaavo, CA Applogic, or similar tools to not only automate but organize your deployment process. If your application uses a standard N-tier architecture, you can potentially use Standing Cloud without having to build any automation scripts at all.

Automating an application deployment in the cloud is a best practice with numerous benefits, including:

• Free redundancy. Instead of having an idle redundant data center (whether cloud or otherwise), you can simply re-deploy your application in another data center or cloud service using on-demand resources.  Some of the resources (e.g., a replicated data store) might need to be available at all times, but most of the deployment can be fired up only when it is needed.
• Rapid scalability. In theory you can get this using Amazon’s auto-scaling features, Elastic Beanstalk, and the like.  But these require access to AMIs that are stored on S3 or EBS.  We’ve learned our lesson about that, right? Instead, build a general purpose scalability approach that takes advantage of the on-demand resources but keeps it under your control.
• Server failover can be treated just like scalability. Virtual servers fail more frequently than physical servers, and when they do, there is less ability to recover them. Consequently, a good automation procedure treats scalability and failover the same way – just bring up a new server.
• Maintainability. A server configuration that is created manually and saved to a “golden image” has numerous problems. Only the person who built it knows what is there, and if that person leaves or goes on vacation, it can be very time consuming to reverse-engineer it. Even that person will eventually forget, and if there are several generations of manual configuration changes (boot the golden image, start making changes, create a new golden image), possibly by different people, you are now locked into that image. All these issues become apparent when you need to upgrade O/S versions or change to a new O/S distribution. In contrast, a fully automated deployment is not only a functional process with the benefits mentioned above, it also serves as documentation.

In summary, let the Amazon Web Services outage be a wake-up call… not to fear the IaaS cloud, but to know it, use it properly, and take advantage of its full possibilities.

Standing Cloud, which makes it easy to deploy and run apps in the cloud, recently closed a $3m financing led by Rich Levandov at Avalon Ventures. Rich and I have known each other and worked together since the mid-1990′s and more recently have invested together in NewsGator and Zynga.

Rich has spend a lot of time in the clouds lately, including his investment in Cloudkick which was acquired yesterday by Rackspace.  He got excited about Standing Cloud and their mission to “reimagine hosting” in the context of cloud computing.   Shared hosting was a great idea back in 1999 but most users of Web apps today require more control over upgrades, better access to backups, ability to move applications across cloud providers, and extremely high reliability.  In addition, deploying apps on most cloud providers continues to be unnecessarily complicated.

There are a huge number of solution providers out in the world who are specialists in any of the more than 70 open-source apps that Standing Cloud supports. For them, Standing Cloud is a simple way to deploy multiple instances of a single app across all of their clients, retain a high degree of flexibility and control over the apps, and not ever have to worry about hosting. These are folks who are helping businesses launch and maintain not only websites but the software they use to run and manage their business.

This week, Standing Cloud launched the Standing Cloud Partner Program for these customers.  Becoming a partner includes free hosting for one instance of a single application for one year, volume pricing, and a listing of their services in the Standing Cloud Application Network, launched last week, which is gearing up to be the go-to place for end users and solution providers around Web apps. The program is designed to help grow the business of service providers who customize, support, and deploy online applications, ranging from CMS systems like Drupal, WordPress and Plone, CRM systems like vTiger and SugarCRM, and other business tools like Status.Net, and OpenVBX.

If you’re a solution provider looking for a better way to manage apps for your clients, you can sign up at Standing Cloud.  And if you want to see how easy it is to set up any of over 70 open source apps in under five minutes, just select an app and click on “Use It Now.”

Last Thursday, my good friends at Standing Cloud (we are investors) got a nice (and their first) write up in TechCrunch titled Standing Cloud Gives You One-Click App Installs Across Multiple Hosting Providers. I’m proud of the Standing Cloud team as they’ve resisted all the cloud hype and just stayed heads down and built out some really cool stuff that they are now rolling out.  I tuned into the TechCrunch article and scanned the comments and lo and behold, Standing Cloud seemed to have a giant issue being called out – namely the font of their logo.

Who knew that Papyrus was so hated by TechCrunch readers? Who knew there was a Papyrus Watch website for font offenders? All I could think of was that the Standing Cloud font was better than the old Feld Technologies font, which was in Bauhaus.

I laughed for a while, then laughed some more at several good natured emails between me, Dave Jilk (the Standing Cloud CEO), my partner Jason, my partner Seth, and Todd Vernon (Lijit’s CEO who is on the Standing Cloud board.)

Then Dave turned himself into Papyrus Watch and posted a comment about it in the TechCrunch comment stream:

“I failed to heed prior warnings about this issue and we will now have to pay our debt to society. In response to your comment and others, I have voluntarily turned myself in to the authorities at PapyrusWatch (http://www.papyruswatch.com), and we are already making plans to update the logo to something attractive and sensible. I hope you favor rehabilitation over punishment and would be willing to try the service, or at least read the article, despite our aesthetic transgression.”

Papyrus Watch did their part with a post titled The Story of Standing Cloud.  In it, Standing Cloud announced that they have put up the job of designing a new logo for Standing Cloud on 99designs for $395.  Please, no Bauhaus.

In March I wrote about Standing Cloud‘s public launch of a free service to test drive open source applications.  As reported today in TechCrunch, Standing Cloud has now launched it’s Business Edition, a service that enables users to also host applications on any of four cloud providers. As with the free edition, they have made it remarkably easy to get started: you register (including providing payment information), select your cloud provider and application, and go.  Currently, the easiest setup is with Rackspace, where Standing Cloud can automatically assign a billing account to you; this easy setup is coming soon for GoGrid and Amazon EC2.

In the Business Edition launch, the Standing Cloud service provides fast and simple installation, automated regular and manual backups and simple application monitoring.  Importantly, the backups can be restored to any cloud service, not just the one where you started.  You can also easily reboot the application if it seems troubled, upload text files (including templates or other customizations), and if you are so inclined, access the server command line through a terminal window that operates within your browser.  Through September 30, the only fees Standing Cloud is charging is for the server time and bandwidth usage; after that it will cost an additional $19.95/month for their service – which by then will include a number of additional features.

There are now more than fifty open source applications available in Standing Cloud – so they’ve organized them in a searchable list format. There is also no technical limitation requiring that the applications be open source, so if you are looking to promote or enable users to host your commercial application, send me an email and I’ll connect you with the right person at Standing Cloud.

My long time friend Alan Shimel has been blogging up a storm on Network World (if you want to hear any amusing story, ask him about the first time he met me.)  When Alan started writing his column for Network World he asked me for introductions to a bunch of our portfolio companies that were using open source.  Alan is a tough critic and calls it like he sees it so while I knew there was no guarantee that he’d go easy on the companies, I knew that Alan would do an even handed job of highlighting their strengths and weaknesses.  I also know that everyone I invest in values any kind of feedback – both good and bad – and they work especially hard to delight their customers so any kind of feedback will make them better.

Earlier today, Alan wrote an article on Standing Cloud titled Seeding the Cloud with Open Source, Standing Cloud Makes It Easy.  On Monday, Standing Cloud released their first version of their product (called the Trial Edition) which is a free version that lets you install and work with around 30 open source products on five different cloud service providers.  It’s the first step in a series of releases over the next two quarters that Standing Cloud has planned as they work create an environment where it is trivial to deploy and manage open source applications in the cloud.  Alan played around with Standing Cloud’s Trial Edition, totally understood what they are doing, and explained why the Trial Edition is interesting and where Standing Cloud is heading when they release their Community Edition at the end of April.

Alan’s also written several other articles about companies in our portfolio recently, including the open source work Gist has been doing with Twitter and a great review of the Pogoplug and how it uses open source.

I believe I’m one of the people that inspired Alan to start blogging a number of years ago.  Through his personal blog Ashimmy, the blog he writes for Network World titled Open Source Face and Fiction, and the blogging he does on security.exe (his company CISO Group’s blog), Alan is one of my must read technology bloggers.  And he’s often funny as hell, especially when he gets riled up.  Keep it up Alan!

Not long after I posted about Dave Jilk’s experience with the Pogoplug, he started using the phrase “Pogoplug Simple” to describe one of the goals of Standing Cloud.  The idea is that technology products should be so easy to set up and use that the experience is vaguely unsatisfying – you feel like you didn’t do anything.  Standing Cloud – a company we provided seed funding for last year - is launching publicly this week with its Trial Edition and I think they’ve managed to make cloud application management “Pogoplug Simple.”

The Trial Edition makes it easy to test drive any of about thirty different open source applications on any of several cloud server providers.  Register with your email address, log in, pick an application, click Install, and in about 30 seconds you’ll be up and running with a fully-functioning application accessible on the web.  You don’t need an Amazon EC2 or Rackspace account, as with “appliance” providers.  You don’t need to learn about “instances” and “images” and security groups.  You don’t need to know how to install and configure a web server or MySQL, or download, install and configure software code.  You don’t even need to configure the application itself – Standing Cloud plugs in default values for you.  And it’s free.

Like the Pogoplug, the Standing Cloud Trial Edition doesn’t do anything that a motivated IT professional couldn’t do another way.  It’s just a lot faster and easier.  But for someone who is *not* an IT professional, it removes some rather high barriers to both open source applications and cloud computing.

The Trial Edition is just the beginning for Standing Cloud.  Soon you will be able to host, manage, and scale applications with the same emphasis on simplicity.  Give it a try and give me feedback.

Standing Cloud, one of the Boulder-based companies we seed funded last year, is hiring a Java Developer.  They are a provider of software and services that facilitate deployment and management of application software, using on-demand cloud servers from providers such as Amazon Web Services, Rackspace Cloud, GoGrid, and others. 

The role is to build, maintain, and support client code that interacts with third party cloud services and virtualization APIs.  You’ll be deep in the weeds with the various emerging cloud services and part of a young team of eight other people.

If you are interested, send a resume to jobs@standingcloud.com. 

We made a seed investment at the end of last year in a company called Standing Cloud.  They are working on a set of application development and deployment tools for cloud computing that build on some of the ideas in the posts What Happened To The 4GL? and Clouditude.  They’ve spent the first quarter of 2009 testing out a series of hypotheses we had concerning issues with Cloud Computing as well as building an first release of their cloud deployment tool.

Things in cloud computing land are much worse than our hypotheses, which were already suitably cloudy.  Following is a simple example of a real issue that even a non-techie will be able to understand.

When starting cloud server instances via an API, it’s important to realize that the instance may become "available" from the perspective of the cloud provider system before all of its standard services are running.  In particular, if your automated process will connect to the instance via ssh or http, it will be at least a few seconds after the instance appears before the applicable service is available. This problem generally does not arise if you start servers manually, because by the time you see that it is running, copy the IP address or domain name, and type the command or browser URL to connect, the services are usually ready.  Possible solutions include:

• Wait a safe, predetermined amount of time.  This is the simplest, but obviously is not robust.
• Attempt to open a socket on the applicable port (e.g., 22 or 80), and do so in a loop, with a brief sleep between attempts.  These attempts will fail until the service starts, and you should have the loop time out after some period in case there is a deeper problem with the instance.
• In a similar loop, directly attempt to connect to the service.  Depending on the SSH API you are using, this may have additional overhead or abstraction that is better avoided, but it is robust and likely to work.

A related, but more insidious issue is that the sshd authentication services are not necessarily available as soon as sshd is available on the port.  Thus it is possible to connect to the service and have authentication fail, even though everything should be in order. A sufficient wait period or a loop is once again the solution.  However, if the loop wait period is not sufficient, you may attempt too many failed authentications and lock yourself out of the system.  Thus this approach has no fully robust solution aside from an empirically safe wait period either prior to authentication or in the loop wait.

Clearly these problems are tricky to diagnose if you are not aware of their idiosyncrasies.

A more robust but also more complex overall solution would be to incorporate a service on-board the instance that starts up at boot and checks the status of sshd from the inside, then makes an otherwise unused port available when the system is fully ready for connection and authentication. Of course, this requires that you can boot from a pre-configured image rather than a stock image, and it also requires that another port be open on the firewall.

The set of things like this is endless.  In addition, each cloud computing environment has different nuances and each stack configuration adds more complexity to the mix.  There are so many fun puns I that apply that I get giddy just thinking about all the storms ahead and the need for umbrellas.