There are a variety of notions to how cloud computing is defined. I tend to think that what this really boils down to is the ability to procure hardware or services that you wouldn’t normally have access to in a physical sense. Rather than buying 20 new servers, you can spin them up on-demand, and also dump them whenever you want. It’s the “utility” or “pay-as-you-go” model.
I don’t see any difference between spinning up one server to run some prototypes, or spinning up 100 to crunch through a huge data set. People seem to be getting caught up in the notion that unless you are doing some sort of parallel processing with lots of nodes, you aren’t doing “cloud computing”. I disagree.
I also don’t believe that virtualization is necessarily the same as cloud computing. To me, virtualization means that you’re essentially splitting up fixed resources you already have into smaller chunks for other people to use. This is your accounting and human resources departments sharing space on the same machine, but keeping them logically partitioned. Providers are now selling virtualization under the cloud label. But if I have to buy (or rent) 20 physical machines to virtualize into slices, then I’m still committed to 20 machines. If I need more or fewer resources, I may need to work through a contract or serve out a lease term. It’s no longer pay-as-you-go, it’s a major expenditure.
Software as a Service
I love the software as a service model. I like having someone else running a database or mail service so that I don’t have to hire a team or own the plant to support it. With the service being off-site, I don’t have to worry about local disasters (though be sure to watch out for providers without their own SLA or disaster recovery plans). Our clients are again becoming thin. Laptops will have fewer and fewer local applications installed, and simply access various online applications and databases.
Again, pay as you go.
Additionally, fewer staff to manage services in-house. This means you won’t/can’t strangle your sysadmin when hosted email goes down for six hours. That can be a good or a bad thing, depending on how you look at it.
The best part about this model, though, is that you focus your own resources on what you’re best at. Does an online marketing agency need to know how to administer an Exchange server? Or should that be outsourced to a company that has the expertise to run mail for over a hundred other companies?
Cloud != Scale
This seems like a typical misconception: If I build my application on a cloud computing platform, then it will automatically scale. Environments like EC2 provide the ability to scale your application horizontally. Your application, however, still needs to be able to benefit from horizontal scaling. If you can only handle 5 concurrent users per node, then adding more boxes isn’t going to get you to 10,000 users very quickly. This seems obvious, but many people are still missing this point.
I don’t think there are many case studies yet of companies with applications “in the cloud” who also have suffered large amounts of traffic. And when we do see more of these applications, they will tend to have been built by early adopters who are probably experts in their fields. These cloud services are not yet open and approachable enough so that you have your average developer poking around and building applications that have the DNA for failure. Google has done a good job with promoting AppEngine using videos and hack-a-thons.
Decent architecture is always going to be foundational for scale. Your application has to benefit from the availability of additional nodes.
Redundancy and Planning for Failure
Amazon gets a lot of heat when S3 goes down, or when Gmail is unavailable. This is all a lot of finger pointing, especially by people have not started using cloud services — The “I told you so” crowd. Truth be told, the day after the recent S3 outage, my company had an application that was offline for nearly the same amount of time as S3’s outage. Are we any better? No.
It’s incredibly important to have a failover option for your own application. Before I left Heavy, we designed our storage on S3 so that it could be replicated to physical disks that we have at RackSpace. When S3 went out, we just flipped over to the physical disks. Eventually there will be a time when we don’t have enough disk to store what we keep at S3. That doesn’t mean that it can’t be replicated to another cloud storage service.
Consider having a backup hosting service in place, either physical or using another cloud provider. Your physical service could be provided by a managed hosting provider, or on some other dedicated hardware outside of your own office. You don’t need to own your own servers for a backup solution.
If you don’t have much money to spend on physical machines to host your fully operating site or application, think about how you can reduce the site to a version that can be hosted on a minimal number of servers. Can you maintain a read-only backup? Can you host a backup of your most popular content (i.e. the top 5%), and temporarily turn off access to the rest of the site?
Abstraction Layers
Something that I have talked a lot about, but haven’t had enough time to spend building, is a good abstraction layer on top of cloud storage. Everyone seems to have slightly different APIs. On the other hand, about 85% of the features overlap from provider to provider. Why not write an abstraction layer to handle the 85% and use multiple services? This could probably work pretty well for flipping back and forth between (or replicating amongst) various cloud storage services like S3, CloudFS, Nirvanix, and also physical disks.
I don’t know many details about SimpleDB and AppEngine’s datastore, but it seems to me that you may be able to apply this 85% rule to those as well. You could probably even treat MySQL and PostgreSQL the same way. You couldn’t use all of the joins and transactions you normally would want to use, but then again, writing an application specifically for cloud computing platforms seems to be a different sort of animal. We’ve basically been doing the same thing for years with the so-called database abstraction layers. You can say that you’ve got a layer that allows you to flip from one database engine to another, but chances are, you have some engine-specific code that you’ve been using that doesn’t translate well.
Porting an Application to EC2
I ported an application at Heavy that ran on physical machines we had available at RackSpace onto EC2. How much effort did it take for the application developers? Almost none. We didn’t buy into using SimpleDB — we just ran MySQL on EC2 instances. We split our team so that we had a couple of us building a few tools for managing our EC2 instances, and the other developers went about their business building a web application that could run on a standard LAMP stack. Additionally, if EC2 ever goes out of commission, we have the code and databases backed. They can easily be deployed to physical machines.
It’s worth saying this again… I ported an application from physical machines to the cloud. This application was not written for a specific cloud service. We were very concerned about lock-in from the beginning.
Conclusions
What did we gain by hosting our application on EC2? Initially nothing. We had the physical machines to run the application. But as our traffic increases, we can fire up new instances on demand. If traffic drops off, so does out monthly bill. It’s variable cost web hosting.
Does hosting your application on EC2 solve scaling problems? No. If you can’t improve performance of your application by adding additional servers, then there are bottlenecks to solve. Running your service on the cloud doesn’t mean it scales.
Furthermore, the cloud is not self-healing. In other words, it doesn’t automatically monitor your application and grow your infrastructure. That doesn’t mean, however, that you can’t build your application to do this. Read Don MacAskill’s SkyNet posting (http://blogs.smugmug.com/don/2008/06/03/skynet-lives-aka-ec2-smugmug/) to get some idea of how that can work.
