Cloud Feed

I’m Out of That Game

(1 votes, average: 5 out of 5)

 Loading ...

Greetings from Covelong Beach in Chennai, where I will be sitting for the next 6 hours or so. *

Reading Sam Johnston’s piece on the future of cloud computing, I came to a resolution:

I don’t care what the definition of “cloud computing” is.

First, we’re operating under an aspect of “you don’t predict the future, you build it.” Better to wait 5 years and ask what the definitions then, rather than spend the next 5 years fretting about it.

Second, definitions from the blogosphere and marketingland don’t solve enterprise and startup and consumer use cases. Taking a security example, saying “AWS is secure” or “AWS is not secure” or “AWS is HIPAA-compliant” is meaningless until it’s tied to a very specific problem/solution set. Secure against what, particularly?

The idea is that companies will have services which correspond neatly to the definitions, at which point your choices are simple and you happily start generating purchase orders, or reach for your credit card, as the case may be. But how will you tell from such a surface view which companies will actually meet your needs from the 85 others who will ultimately plaster their marketspeak with the appearence that they do the same thing as the companies that really can meet your needs?

The devil is in the details. Or the use cases, as it were.

In theory, the definition-forging process will help guide the way in the actual “building the future” process, but what I’ve seen so far has been far too muddy to be widely useful. It’s useful to give yourself something to talk about over hors d’oeurves at a cloud computing event, but after that…

PS…not an attack on Sam’s post…just got me thinking…although I perhaps didn’t like his use of monkey analogy…

* Note to self, the next time that a previously subdued spike in craving for American food breaks over the wall and you reach for the bag of otherwise not-so-tasty Lays potato chips in the minibar fridge, you may want to check the bag to see whether said comfort food was even made in the US, and not, oh, Village Channo, Patiala, Sangrur Road, Bhawanigarh, Distt. Sangrur, Punjab. Not that I could tell a taste difference, rather it’s a matter of principle perhaps akin to the Japanese banning rice imports.

A Heap of App Engine Reading

(No Ratings Yet)

 Loading ...

The ever-reliable highscalability.com has a whole evening’s worth of detailed reading about GAE piled into one place, including lots of reallllly interesting details on the difference between BigTable and RDBMS.

Google App Engine Analyzed In Light of the Historical Shift to Utility Power

(No Ratings Yet)

 Loading ...

This article is ancient history by blog standards, being from all the way back in April, but it gives a start at answering a question that was hot - but ultimately unanswered - at the recent San Francisco CloudCamp. In talking about how the enterprise adoption of cloud computing would depend in large part on how risks were addressed, shifted and mitigated, analogies were repeatedly drawn to past moves to “outsourcing something critical”. Examples ranged from the more recent shift from in-house to outsourced data centers, exemplified by Exodus Communications, to more ancient, classic tech shift examples such as utility power. However, the analysis that night didn’t quite get past the “Hmm, that’s an interesting point” stage. Kirkpatrick’s post takes the next step.

Botnets vs Clouds

(No Ratings Yet)

 Loading ...

The question is “Can cloud computing smite down evil zombie botnet armies?”

The answer, IMHO, is “No”.

For the blissfully uninitiated, botnets are overlay networks in which compromised hosts on the Internet are harnessed up to some master command server to order the botnet to attack targets on the Internet, e.g. enabling a distributed denial of service attack. It’s also a popular resource management tool to marshall hosts for use by spammers. Here’s a solid backgrounder on the subject.

The core research  idea - Self Cleansing Intrusion Tolerance - is an interesting security research topic. It starts from the premise that there will always be some attack that is more sophisticated than your defenses, so all hosts should eventually be assumed to be compromised over time, and restarted at some last know secure state. The “assume compromise” premise is realistic, if unpopular, and now we have modern tools which have caught up to the classic security good practice of “reinstall from a day 0 backup in the event of a security compromise”. With virtualization, there’s a ready means to return to day 0. SCIT takes this to an extreme, constantly reboot alternating slices of your virtual server farm, so that any malware has only a minimal time to work before it is removed in favor of a fresh install.

As an aside, such an approach would require having a way to know that a virtual host is not in the middle of servicing a user (human or otherwise) connection before shutting down, or the farm will have a built-in “flakiness” quotient in which a percentage of all user connections will be intentionally broken in the name of the greater good each hour, which is not such an elegant solution for routine use.

Nonetheless, the basic idea, of taking advantage of the built-in day 0 backup inherent in virtualization on a routine basis, is sound. Viewing it as a silver bullet against botnets and worms is not.

A hearty malware infestation is moving at a much faster rate than the 1 minute reboot cycle proposed. Some malware would simply reinfest a portion of, or even all of the same virtual servers every minute, with the remainder of the 60 second window being enough to launch outbound attacks. We’re talking generally about small programs performing complete operations in chunks of a few seconds or subseconds at a time.

Restarting might even be a boon for malware writers, since they can do some damage to other hosts and then know that their tracks will disappear in a minute. And an autoreboot pattern on a large virtual farm will be noticeable remotely, and then the botnet C&C software can be modified to a) flag the autorebooting hosts as such; b) perhaps have policy-based reinfection of same (if that’s even necessary, given the speed at which infestations can move); b) and policy might include selling botnet space in an autorebooting farm as a separate service at a different rate - “1000 forensics-proof temporal zombies for $49.95!”.

Computer installations all tend towards collecting cruft over time, with malware as a malicious and extreme form of cruft. Virtualization offers the convenient opportunity to periodically clean out the crap from a system, including the evil variants, so the general idea of regularly dropping back to a known good version is worth exploring. Its already being done on the client side in the world of thin clients. But the bots will adapt and propagate happily onward…

Erlang in the Cloud

(1 votes, average: 5 out of 5)

 Loading ...

There’s a lot of debate about how much can be abstracted away by “the cloud”, but on the other side there is always a concrete implementation to create a service. Here’s an interesting case study around a highly scalable consumer SAAS application -  Facebook’s Chat service. The article is a bit older (May), but it’s still timely, in showing how choice of implementation language matters in architecture. And Erlang is one of those programming languages that usually only comes up in rarefied telecom circles or when software engineers want to demonstrate that the feathers in their plume are brighter than others. Seeing it outside of its normal hiding places and showcased on a stage like Facebook is interesting in its own right.