The other day I met with a group of Boston start-up CTOs to share ideas on technology and team building. Typically these discussions veer into helping each other with technical challenges scaling SaaS software. Of all the companies present, we’re all pushing the envelope with big data, large subscriber bases, and managing lots of cloud infrastructure. Many great ideas were exchanged, but one major theme resonated: The cloud may not be the best place for every kind of software stack. The group represents many different use cases; big data archiving, analytics, social networking for niche audiences, video encoding, application performance analysis, Advertising sales networks, and others.
To understand how we got to this place today, let’s step into the time machine elevator and press the button for “Year 2008.” Down, down we go and the doors open to “the cloud” (and specifically Amazon Web Services) just coming onto the tech scene. All of a sudden software architects and developers could control their own infrastructure (and not have to hassle with hardware sales reps or CFO’s and their purchase orders.) We technologists, myself included, with big ideas “projected” our hopes and dreams onto the cloud as the panacea solution for all our infrastructure needs. We understood for the most part utilizing the cloud would require new ways of thinking about software architectures. We also had “real world” time-to-market pressures to get our service running quickly and start to prove out business viability. The cloud has tremendous potential to help accomplish great things, but used incorrectly, the cloud could cause a lot of (financial, technical stability) harm.
In the “gold rush” to the cloud we (the nascent start-ups pioneering in the cloud) were all learning at relatively the same time the same “lessons.” How and when to scale, how to analyze costs and efficiencies, the need for different kinds of monitoring and alerting, how to deploy software updates to a cloud-based environment, the list goes on. Many lessons learned, and the theme of mastering the cloud tilted more toward “let’s figure out how to “game the cloud.” Because there’s no reason to use the cloud unless you can make the economics work, and to make the economics work requires a mind set to “game the cloud;” process more data & transactions at least cost. Easy to write, but very technically challenging and rewarding to pull off.
Back to the CTO group conversations and the point of this blog post. Multiple times I heard examples of companies realizing their project may not be the best use case for the positive attributes of cloud computing. In some examples, the cloud was the perfect place to start their project, prove an idea, and quickly engage with the customer audience. But as a web service needs to scale, the cloud’s performance and economic quotients become an impedance mismatch with the needs of the start-up. A scenario heard a few times was this: Start at Amazon, encounter a cost or scaling road block, move to dedicated, and then finally adopt a hybrid dedicated / cloud scenario. The dedicated hosters are showing more flexibility to “look” like cloud providers with frictionless ticketing systems and quick response times to fix failing hardware.
Scaling in the “pure cloud” was either too expensive, too complicated, or (yikes) both. These are painful lessons to learn in real-time while performing in front of a live audience. For those that realized the cloud was not the best long-term strategy the alternative was dedicated hosting or a hybrid approach of cloud and dedicated. The good news is the cloud is iterating quickly, and every six to nine months new advances in CPU, networking, and storage offer more flexibility to make the cloud a better match for more use cases.
As I write this, Summer 2011, the cloud is not the most cost-effective infrastructure for a steady-state workload. A web application that has static infrastructure needs will not find an economic advantage to using the cloud. If all you need is 20 CPUs and there is no “bursty-ness” to the workload, then a traditional dedicated hosting facility is the best scenario. The cloud is also not the best place if the application needs guaranteed minimum performance requirements for networking or disk I/O. The cloud is awesome if workloads are variable, or if the software stack is designed to use spot nodes and reserved instances (more on these in a future blog post.)
The Sonian Archive project is a very good use case match for today’s cloud capabilities. Data flows from on-premises to the cloud, and once in the cloud on-demand CPU is used to process the data pipeline. Lot’s of quality S3 storage is used to store data, and spot nodes process the data with excellent price per performance ratios.
An example project that is not a good use case for the cloud is one that requires very intense computational, disk and networking I/O. A 2 year old dedicated multi-core CPU will out perform a cloud CPU every time when measured by these performance criteria.
Summary:
Determining if the cloud is the appropriate hosting environment requires a dispassionate understanding of your application’s compute and storage requirements and a mindset not to force a square peg in a round hole. Otherwise your application will not scale and probably cost too much to operate.
