In my mind, I keep envisioning Scott McNealy lounging next to a pool, sipping drinks from glasses with those little umbrellas in them and feeling smugly vindicated about his vision of where computing was headed. If you don’t remember, McNealy was the CEO of Sun Microsystems (the creators of Java) who, in the late 90s and early 2000s, effectively argued for a future populated by thin clients and big servers when he famously stated that the “Network is the Computer”. Today, apart from some higher-end work-stations needed by some developers and content creators, McNealy’s vision of the future has largely been realized. In fact, the only question that still seems unanswered at this point is who will own the servers that handle the world’s computing needs.
Why the Cloud Matters to Vendors and Cloud Providers
It should go without saying that the main reason that the cloud is being pushed so vocally by Microsoft, Amazon, Rackspace, and other vendors is because these businesses have very strong, vested financial interests in organizations using the cloud. Yes, there are very tangible and powerful benefits to consumers who use the cloud under the correct circumstances, but those benefits are still tempered by the benefits enjoyed by vendors. Succinctly stated, Microsoft (for example) is happy to push Azure because Azure is great for Microsoft’s balance sheet.
Consequently, it irks me a bit that the tech press at large seems so feverishly intent on pushing the benefits of the cloud without paying more attention to where all the money goes and what all of this portends in the long-term for our industry in general. In other words, if the likes of Microsoft, a company that has long depended upon IT pros and hosting companies as allies in selling Microsoft wares, is now effectively competing with those same IT pros, why aren’t more IT publications focusing on how short-sighted it is to push everything into the cloud?
A Question of Architecture: Scale Up vs. Scale Out
A bigger concern that I rarely see addressed in most pro-cloud articles promulgated by the IT press is the fact that not all solutions are an easy or obvious fit with the cloud. For example, as a SQL Server Consultant, I regularly talk to clients who are interested in moving their SQL Servers (and other workloads) into the cloud. However, the problem that many IT pros don’t seem to grasp is that the cloud was designed to take advantage of lower-end, highly-distributed scale-out computing platforms—whereas things like SQL Server tend to be de facto architected as scale-up solutions. Stated differently, databases typically need to serve as a single, authoritative, master repository for data. As that data grows with the application, the host that handles this workload typically needs to scale-up—meaning you need to throw more hardware at it—in order to keep things moving and working efficiently.
To scale workloads out, instead of up, you need to spread operations across multiple hosts so that each host, working more or less in isolation, tackles its own piece of the puzzle, such that the addition of new hosts equates to more work being done concurrently. Traditionally, databases aren’t very well suited to such forms of partitioning.
Granted, there are options for addressing scale-out needs when it comes to databases. Sharding, for example, partitions data across multiple hosts and then typically uses some form of routing to ensure that clients are mapped to specialized hosts that can handle their needs. Likewise, many NoSQL solutions use eventual consistency to (in overly-simplified terms) give each host its own copy of the data and then let those hosts work behind the scenes to keep changes more or less intact and up-to-date across all hosts. The problem with eventual consistency, however, is that it’s horribly unsuited toward most financial and truly transactional operations, simply because it can be so ruthlessly gamed and exploited.
A Question of Cost: The Cloud is Optimized for Scale-Out
In turn, this vulnerability means that organizations that want to simply port their solutions into the cloud—without making the necessary architectural changes—are left with app and web servers that are a perfect fit for the scale-out nature of the cloud, but the database servers don't fit—like a square peg in a round hole. The only problem is, everything hangs on that square peg. Consequently, organizations that want to push their scale-up databases into the cloud are left needing the larger or even the largest compute-instances of Virtual Machines available to them, which creates with three major problems. First and foremost is the fact that larger compute instances cost significantly more than their lower-powered cousins. Second, a primary benefit of the cloud is scalability—but if you’re already on the biggest instance and can’t scale-out, then you’ve lost the benefit of scalability, meaning you’re a round peg in a square hole. Third, and probably the most damning problem, is the fact that even if organizations pay for the most expensive compute-instances available, those high-cost hosts commonly don’t pack enough power to keep high-end database workloads running as needed.
Yes, it is possible to tune or even optimize cloud hosts to be able to handle a wide variety of relational database management system (RDBMS) workloads. Typically, this involves bolstering the IO subsystems, so that they can keep up with the high demands of database workloads. These optimizations, however, routinely come at a significant additional cost. The end result, then, of these many attempts to put decent-sized relational databases in the cloud ends up being a significant, recurring, monthly cost that still doesn’t create much, if any, benefit from actually being in the cloud. To put that into a more tangible perspective, I’ve seen scenarios where databases instances that I consider small cost around $2,000–$3,000 per month on cloud hardware and still struggle to keep up. Moving those workloads to traditional hosting companies would result in costs closer to $500 per month and the traditional hardware would run circles around the cloud hardware that too many people magically equate with scalability and unbridled power.
Use the Cloud, Ignore the Hype
Ultimately, the cloud is a service or tool like any other. It’s not a magical panacea for all things technical. Some workloads are a great fit, while other workloads might end up being more expensive to host in the cloud than they would be when hosting locally with your own hardware or a similar solution. Of course, some workloads should simply never be hosted in the cloud.
So, when it comes to the cloud, figure out what works, do your homework and learn about the trade-offs, and then leverage the cloud where it works. But, please, ignore the hype.
