Monday, April 27, 2009

The Cloud - Not a Panacea

Everyone loves The Cloud. I mean, why not? There's no hardware to own, no storage systems to maintain, no networking hardware to deal with, it's infinitely scalable to the billionth degree; it's perfect!

Ok, so no one gushes about it that much (do they?). It has its notable benefits, but they aren't quite as obvious or simple as people sometimes make them out to be.

The crux of the issue is simple; simply moving traditional services, applications, or systems to a cloud-like environment yields little. Traditional systems with no knowledge of a cloud (or grid, or virtualized infrastructure, or...) environment can't take advantage of the dynamicity that it offers. Many systems (and arguably, people) don't understand what the true benefits of the cloud are.

A Common Cloud Case

Let's take a concrete - and common - example: an RDBMS on the cloud. I'll talk specifically about MySQL because it's on the tip of my tongue, but it will apply to many similar systems.

So there you are, running MySQL on Amazon EC2 on your Linux distro of choice. That was easy enough. You cron a nightly export to S3. You've taken advantage of some of the shared resources and that is good, to be sure. You can use EBS for large volumes. You lose some performance, but you can afford to get a larger instance so maybe you can increase some of the buffers and keep more in memory. Depending on your situation, it may all work out in the end. We won't get into the nuances of exactly what computational resources you get because it's damn near impossible to measure accurately and consistently. Let's call it a wash.

Perhaps the most important part of this is that you can easily set up one or more replicas. That's pretty damn nice.

That's a lot. The problem is that there isn't much one couldn't do in a traditional data center. Sure, something like EC2 can help jumpstart a start up - which is great - but for medium sized and larger companies, this isn't a concern. The question is what does the cloud do that the traditional data center (and approach) does not? The cloud is dynamic and on demand for a reason and this isn't it.

What the Cloud Does Well

Applications that natively and intrinsically know about the cloud and its properties and can actually react to changing conditions are the true candidates for cloud computing. For instance, stateless web serving is something that can take advantage of this kind of environment (with some additional functionality). The reasoning here is simple: with some simple measuring of load and knowledge of capacity, additional web server instances can be forked off and run, independently. These additional web servers (or their IPs) could be added to an external load balancing system to make them available to the public. There's no significant dependency here. Content to be served by the additional web servers can be made available with little fanfare and, provided you have enough resources, additional connections can be made to resources such as relational databases, caching servers like memcached, and so forth.

That's, of course, not the native case I mentioned. That's an adaption of a traditional service to the cloud using an orchestration process or resource manager, of sorts. The best case for the cloud are applications where change of the infrastructure is built in. People tend to easily go to places like map / reduce frameworks where jobs are self contained or transport state with them. Not to trivialize that case, but it's not everyday you find the perfect fit for such a model. Many times, you find hybrids where map / reduce jobs (a computation layer) requires access to a data grid (the storage layer) which limits your flexibility and ability to deal with changing conditions. In that case, it's usually not desirable to repartition or shift your data storage based on load (although you can repopulate caches based on load and network expansion). Maybe you don't care about data affinity because the footprint is small or access is infrequent, but with massive data stores or logically partitioned data, this is prohibitively expensive.

I'm not sure I have a good conclusion to this. What I'm driving at is that, while the cloud and dynamic infrastructure is a blessing, don't think of it as a panacea. Do the cost breakdown and consider what portions of your systems make sense in such an environment. Many times, running a traditional system where dynamic setup / teardown of nodes isn't feasible, on a platform like EC2, will wind up being more expensive after a year or so given even light usage. It's a buzzy topic and everyone wants to be on the cloud. Remember that the fastest way to kill something in the eyes of business is to push it for the wrong reasons or in the wrong situations.

Friday, April 17, 2009

We're Hiring!

We at Conductor are looking for Java developers to join our engineering team here in New York City, NY, US. Please take a look at the position details and submit your resume if you fit the bill. Make sure you indicate where you heard about the position (no, I don't get a referral bonus if people come from my blog. Unless someone from our HR department is reading this - then I want my bonus).

We're very interested in people who have real world experience building large scale, highly available, distributed, performant, applications in Java with Spring. Love of open source and / or technology in general is a huge plus. Knowledge of a language like Python, Ruby, Groovy, or Javascript is also good. Experience building data mining or analysis applications is good for bonus points. Come work with us. Trust me, it's a good place to be!

A reminder: None of this is sponsored, reviewed, or endorsed by my employer. Please see the Careers section of the Conductor corporate website for details.