With the recent flurry of everything-as-a-service blog posts, it was good to read Frank Dzubeck’s pragmatic article on The Industry Standard outlining five issues that should be considered upfront by anyone pondering using cloud computing to run their apps. Frank list covers the basics of security, performance and financial ROI, but he adds management and governance which most folks fail to realize are at least as important.

I would add one more question to Frank’s list, though. Potential users should also ensure that service is available in multiple data centers and preferably from multiple providers as well. This makes it easier to build for business continuity and to provide a responsive rich user interface to wide spread audiences.

John Foley wrote a short piece on InformationWeek covering 3tera as their Startup of the Week that’s worth a read.

Alistair Croll’s written another thought provoking piece on Gigaom, this time discussing how the cloud will force networking vendors to change over the next few years. Having spent more than a decade building networking companies this is a subject near to my heart and I think Alistair did a good job identifying the pressure points and two potential change vectors for networking providers; building virtual appliances and selling to the cloud vendors.

Virtual Appliances - Intelligent networking functions like firewalls, load balancers, traffic shapers, caches and intrusion detection won’t be purchased as physical devices by cloud computing users. Instead, they’ll adopt this functionality as virtual appliances and pay by the hour. Thus vendors can participate in the growth of cloud computing by repackaging their products and adjusting their pricing model.

Selling to Cloud Operators - IMHO, this shift will actually be harder for many vendors. Alistair identified a couple of issues, including commoditization caused by the purchasing power of large data center operators. However, there’s a more fundamental issue - cloud computing has very different networking requirements than traditional data centers. Traditional data centers have purpose built deployments for specific applications. You can literally walk through the data center, point at racks, and identify the application. Many of these applications have local networks within the rack and uplink into the data center backbone. In contrast, cloud data centers are built for scale from homogeneous resources. Rack after rack of servers. Any application has to be able to run anywhere. Thus, while traditional data center purchasing decisions have been based primarily on features,  cloud computing favors large, high performance, switches with relatively few features.

The shift won’t happen overnight, of course, but vendors that recognize the trend early will have the opportunity to build market share.

our CEO, Barry, is fond of saying that google isn’t just about search, it’s about scale. As if to punctuate his point for him, today google published a post about the 1 trillionth URL on the web, ” . . . our systems that process links on the web to find new content hit a milestone: 1 trillion (as in 1,000,000,000,000) unique URLs on the web at once!”

OK, you can call me a geek, but I really like CLI’s. It could be that they so seldom have serious UI issues the way GUI’s do. Or it could simply be nostalgia for the days when screen savers actually had a purpose. Either way, I had to smile when I first came across goosh, a shell like interface for google.

Now if google would just put the database on a floppy . . .

Willy Chiu, VP of High Performance Computing at IBM, wrote a cio.com article identifying five business trends propelling cloud computing. Among his observations is this gem “Cloud computing is tailor-made for bringing order out of chaos.” I couldn’t possibly have said it any better myself!

Nicholas Carr has an article in The Atlantic titled Is Google Making Us Stupid? that got me thinking over the weekend. I’ve noted before how Google’s ubiquitous nature can have unintended consequences, such as the de facto standardization of spelling and grammar. In his article Nick notes that the nature of searching for information is having profound impact on the way in which he and others read:

“. . . what the Net seems to be doing is chipping away my capacity for concentration and contemplation. My mind now expects to take in information the way the Net distributes it: in a swiftly moving stream of particles. Once I was a scuba diver in the sea of words. Now I zip along the surface like a guy on a Jet Ski.”

I’ve noticed this myself as well, a feeling that the Internet is condensing all information into Cliff’s Notes. In particular, this has been quite concerning in the blogosphere, where it often seems folks expect hard issues to be discussed and resolved as quickly as they can post. In a previous post on standards for cloud computing I cited a few threads where folks expected publication of specifications and standards as easily as posts to a blog. Of course, that simple isn’t possible, but I believe that the speed with which we access information online builds that expectation.

It appears that one unintended consequence of unhindered access to information is a sort of commoditization of thought. Information is simply so easy to come by that we tend to value it less. Worse, ideas and the effort to communicate them are discounted by the sheer volume of information that floods our senses at every waking moment.

As an example, when I was an undergrad some 25 years ago at CSUF, research was painful. I might spend hours scouring through microfiche, racks of books or the dreaded manual stack for the CDC Cyber mainframe trying to find information. Having unearthed what I was looking for, I was certain to write it down or copy it.  Today, however, I write down as little as possible. Written information is the first thing I lose. I also almost never copy of print information. Rather, I rely on my ability to search for it again. Google has become an integral part of my process for consuming information.

I can’t share Nick’s more pessimistic view of the situation though. Humans are resilient and have a way to adapting technology to their needs even if at first it appears the other way around. I, for instance, picked up an Amazon Kindle a couple months ago. Using the same technologies that can commoditize thought, the Kindle places entire books at my disposal even when I’m unconnected at 30,000 feet. Since getting it I’ve read two novels, three business books, a science book, and numerous magazines and newspapers. That would have been more than a year’s reading before. Plus, I’ve noted more young kids carrying books with them recently than laptops. They’ve got their phone for texting, and their iPod, but no laptop. Perhaps, the market is already pushing back.

Alex Handy at System Management News writes about Digg’s Kevin Rose and Ron Gorodetzky and how they are scaling Digg — see Digging His Way to Web Success.

With all the havoc about Twitter (if you spent the last few months on Mars, Google for it — there was even a post by Twitter’s founder describing what happened), it is refreshing to see someone who did it right and simple. The key point, I think, is that you have to start it simple — especially if you are a startup, you cannot and should not attempt to create the ultimate scalable system in version 1. Aside from this being impractical, it is also impossible for any system that’s actually interesting, because you don’t know which way your system will grow (trying to predict the future and plan for all possible cases is the surest way to never release anything).

Check out what Nati Shalom and Todd Hoff wrote about Twitter and scalability in a larger scope. Also, Todd Hoff’s excellent high scalability blog has a lot of useful info on how various big sites scaled, including Digg.

So how is this related to cloud computing: well, no matter how your application is deployed and operated, you still have do the architecture right for scaling: and not only in a static sense (a one time scalability design) but also in time, as your system grows and takes on different, usually unexpected directions to success. A good utility and/or cloud computing solution will help you in this: from offering ready made “best practices” stacks and solutions, to helping you build, debug, tune, monitor and operate your own particular architecture.

Onward and upward (or, for scalability freaks, outward!)

Being an entrepreneur is a risky business, and as such it certainly isn’t for the faint of heart. However, an email thread circling 3tera today shed a little light on one aspect of our character that I hadn’t seen before.

Tomorrow being the 4^th of July, the thread started out innocently enough wishing everyone a safe and enjoyable holiday. With each “reply all” though, the thread took on a new twist, talking more about fireworks and what we used to enjoy as kids. In the end the thread was about how to make explosions from safe-and-sane fireworks (or other items). In other words, how to break the law. Turns out more than a few folks had ways to make things go bang.

Of course, it isn’t surprising that a bunch of entrepreneurs are willing to take risks for fun. However, I wonder if it’s a requirement. Are all entrepreneurs rule breakers? Is that part of why we build companies instead of going to work for established firms? Is the excitement of seeing your system go live for the first time the same as watching that firework explode?

I’m no psychologist, but I think they are related. Accomplishing what others say “can’t be done” is exciting. And IMHO it is related to the elation of that exploding fire cracker you weren’t supposed to have. So as you’re celebrating tomorrow and hear the din of firecrackers, perhaps you’re listening to the job training of the next Steve Jobs or Bill Gates.

After 2 years+ of showing people how to run Wordpress on a grid, we finally bit the bullet and moved our own blog on Wordpress. On a grid, of course.

As advertised, the process was smooth and easy — the Wordpress famous 5 minute install worked on the standard LAMP cluster infrastructure from AppLogic. Five minutes flat (here’s how).

The rest of the two late nights on the weekend were dedicated, of course, to style sheets, plugins and porting the contents over. Much to my amazement, the process was way easier than I expected.

• The stylesheets (aka themes) in Wordpress are simple to set up, yet powerful — probably the easiest to set up among all the web apps I have used. (Of course, the word easy is cautiously applied to anything that has to do with CSS, but that wasn’t Wordpress’s fault; and, big thanks to Firebug!).
• The plugin model in Wordpress is install-by-file-copy (remember the old DOS days?) while still activation is from the GUI — simply brilliant combination.
• Pouring in the contents — 114 posts dating back to December 2005 — took a bit of work; the easiest way I found was through simulating Wordpress import: simple XML, only a few fields were really necessary, the rest Wordpress seemed to fill in itself (e.g., I set only the post_date and Wordpress autofilled the post_date_gmt; the only surprise was the post_status — must be set explicitly to publish; in hindsight, this could have been fixed with a single checkbox from the manage posts panel). Part of the time was, of course, spent reading some of the old posts — equal bits nostalgic and refreshing.

Overall, quite enjoyable. After the 4-conferences week (aka, the cloud computing conference week plus LTPact) and a lot of talking, talking and talking, it was great to get something done with my own two hands (and two keyboards). There is something really rewarding, in the sense of instant gratification, in putting up web applications and tailoring them to work exactly as you want them (PHP, while not the best language ever, is nearly the perfect instant gratification language, no offense to Ruby).

As a result, now all public facing infrastructure of 3Tera runs on the grid, as does almost all of our internal infrastructure. A shout out to the good folks at SiteKreator for taking our web site all the way to here — we are still running some personal sites on it and I will most definitely set up the first web site of my next startup there again.

Now, I wish our blog would become as popular as to deserve some of the more advanced infrastructure we have for LAMP applications — self-scaling based on load and remote replication. We’ll get there. In the meantime, to those who need such infrastructure today, it is easily available.