Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.

By Anthony Stevens

This is the third post in a series I’m doing at Seattle 2.0 on the key elements of the “tech” in “tech startup”.   Previous posts on source control and continuous integration, were developer-centric; this post, on the use of cloud computing by startups, is more strategic in nature.

Let’s start by talking about what we mean when we refer to the “cloud” in “cloud computing”.  “Cloud” is a term that is so overloaded as to become almost meaningless – every vendor has its own take on what the cloud is, what it comprises, and why you should go there.

One very simple definition of “the cloud” is: software running on hardware that you don’t own.  That’s an extremely broad definition, but it gets to one of the fundamental benefits of cloud computing: hardware independence.  Using this definition, my dedicated servers running at Softlayer in their Dallas data center could be considered as cloud resources.  I have no idea what hardware they use, nor do I particularly care.  They run Windows Server 2008, and I have full control over the operating system.

Another, slightly different definition of the cloud is: software services provided to you on demand over the internet.  This could be raw computing resources (Amazon EC2); storage resources (Amazon SimpleDB, Microsoft SQL Azure, Dropbox); or web resources (Google App Engine, Rackspace Cloud).  This definition also encompasses – and supercedes – older descriptions of SaaS, or “Software as a Service”, which referred to applications delivered on demand.  The new cloud definition is about both applications as well as raw computing and storage resources upon which you can build your own applications.

In this second definition, I still no longer care about hardware, but I also (in theory) don’t much care about the operating system as well.  If you’re building applications on top of someone else’s stack, that’s mostly an ephemera; if you’re merely using someone else’s resources, you don’t.  For example, I have no idea what operating system(s) that Twilio, my favorite telephony-services provider, sits on top of.  And I don’t care.  I use their API and that’s about it. The definite trend is to allow cloud consumers to virtualize the OS as another swappable element of the tech stack.

Let’s shift gears and talk about you, the Startup Entrepreneur, and why you should care about the cloud.

First and foremost, you want to keep your cash and not spend it on highly-depreciable hardware assets.  Buy your own servers?  That died in the ‘90s, along with grunge rock and Netscape.

Second, you want to let somebody else worry about the plumbing.  By “plumbing”, I really mean anything that is not your core competency.  If you’re an online market research firm providing insights to Fortune 500 companies about consumer sentiment, your core competency is not the physical storage of data, or the provisioning and scaling of your websites to meet unexpected demand.  There are firms out there for whom these sorts of things *are* their core competency.  They can do it 100x better and 100x cheaper than you, for a theoretical advantage of 10,000x. Leverage their offerings.

Third, you want to only pay for what you need.  As a young startup with twelve unique visitors a day, you don’t want to pay for a series of eight-processor monster servers with an attached storage-area network and a clustered database server that can scale out to serve 100,000 uniques an hour.  Six months from now, when you’ve been TechCrunched and Scobleized and Oprah-fied and what-have-you, you *do* want to pay for those resources (on the theory that those visitors are generating cash – you do have a revenue model, right?).  Cloud computing can allow you to scale as you need to, and you only pay for what you use.

Fourth, and most subtly: this approach, where you tie together best-of-breed computing resources and then plug your application on top of them, forces you (in a good way) to design your application with a minimum number of assumptions about dependencies; and where you have dependencies, you have to explicitly acknowledge them.  In the bad old days, your developers would build a webpage that assumed the XML file “abc.xml” was available on the local web server in physical directory /usr/content/foo/bar/abc.xml, and when you built out a second server you’d realize, abruptly, that the storage assumption didn’t hold for more than one server.  With cloud computing, you build in the notion of federation from the start and make fewer silent assumptions, which means more robust, more error-free, more scalable applications.  Call this a virtue of cloud computing architecture, as opposed to a tangible dollar benefit.  But it’s still valuable, and I would argue extremely so.

What are the risks and gotchas associated with cloud computing?

First, avoid the fallacy of infinite portability.  Sure, a Python app written for Google App Engine may have some portability to a different host running Python; but it’s nowhere near 100% and if you’re going into the cloud with portability as your goal, think long and hard about it.  In my mind, portability, especially for web-based applications, is a golden turd; it looks shiny from a distance but stinks when you’re up close.  See also: unfounded fears of vendor lock-in, which is a separate blog post.

Second, understand your risks.  You may no longer need to understand the arcana of database backups, but you do need to start reading and understanding service level agreements, and adjust your approach based on how much risk your startup can stomach.  Downtime is one big concern.  Another huge risk has to do with the inadvertent loss or exposure of your data; for some startups, particularly ones dealing with payments or sensitive personal information, a lot of your thinking will go into security and vendor provisions for the storage and transmission of your data.

Third, cloud computing does not mean you’re free from concerns about infrastructure: it just lowers and shifts the burden.  Instead of hosting, patching, backups, and networking, your tech folks are now going to need to be focused on monitoring, auditing, and instrumentation.  This is a good thing.  It’s also a different skill set.

Fourth, there is no silver bullet.  Everyone’s services go down from time to time, even giants like Amazon; there is no zero-risk proposition in cloud computing.  Your explicit tradeoff is this: for much less money and much less required expertise, I am going to have to absorb some additional incremental risk.  Are you running an online pacemaker-checking service for whom any downtime means people die?  Are you launching people into space? Cloud computing, circa 2010, may not be for you.

Interested to hear your take on cloud computing; what works, what doesn’t, and how much cloud is just right for startups.  See you in the comments!

Like what you're reading? Subscribe to GeekWire's free newsletters to catch every headline

Job Listings on GeekWork

Find more jobs on GeekWork. Employers, post a job here.