June 18th, 2007


A little patch to flickr_upload

I like posting pictures to Flickr. FerEx, yesterday I posted a 132 pictures of Art Cars that I took yesterday at the Fremont Fair.

I do bulk posting with a little Perl tool called flickr_upload. Today, I tore into that code to see how it worked, and while doing so, added handling of some features that Flickr has added to their upload API. So it now handles overriding the set default "safety_level", "content_type", and "hidden" attributes of the uploading images.

I've sent my patch back to the maintainer registered in CPAN, but I've also put it online here.

What I had wanted to do was be able to override the default license. Flickr defaults images to "All rights reserved", but has the option of setting various Creative Commons licenses. Most of my photos on Flickr, I set to "Attribution-NonCommercial".

What is the Next Big Thing? (longish)

In a decade, on-demand virtualized utility computing will be an invisible utility, part of the vital infrastructure of the technological economy.

People will mostly have forgotten what an enormous pain in the ass provisioning computation was today. Today, we don't truly feel that pain, because it seems "normal", everyone has to suffer it together.

The situation right now is, if you have a delivery van, you have to make your own gasoline. And you have to hire and pay for your own mechanics. Seems stupid, doesn't it? It's amazing that there are any delivery vans at all …

Think of the internet itself, what it did to telecoms.

Twenty-five years ago, if you wanted a high speed data connection to a computer in San Francisco, it was a pain. You'd have to come up with a pile of money, and wait a couple of months, at best. Hardware would be dedicated and provisioned, and then finally you would have your connection. To only one place. That you had to pay (a lot for) every month, no matter how many bits you pushed into it. And you had to pay for more than your actual average use, for burst need capacity.

Today, if you want that same sort of connection, you click a hyperlink, or start a VPN. The data stream is virtualized, packetized, and handled by a dozen routers owned by half a dozen companies. It lasts only for the few seconds or minutes that you need it. When it's done, the underlying hardware has forgotten about it, and is carrying some completely different person's completely different data.

Today, do you need a billion teraops of computation? You do the same thing today that you did for datacom then. That is, spend a pile of money, rent or buy hardware and rackspace in a physical datacenter, wait the lead time for purchasing, installation, and provisioning. And then pay for it month to month, year to year. Including paying for the burst capacity you rarely use.

Look forward ten years. Do for computation what the IP router did for datacom. Applications, components, and and dev tools will be architected for dynamic horizontal and vertical scaling as matter of course. When you suddenly need that billion teraops, the utility computing grid will provide it on demand, runs your instances only as you need them, and when demands change, the underlying hardware goes to work running something completely different.

Owning your own big datacenter will be like owning a network of leased lines. You won't do it unless you really really have to, e.g. for legal mandates, or for massive capacity needs, or if you're the actual utility provider.

For everyone else, hardware is going to be a lot smaller, relative to the amount of computation that you do. And even for that hardware you do own, you're still going to run a dynamic virtualizing grid on top of it, just for your own sanity.

Right now, all the existent utility computing outfits are more or less in startup mode. And they are all currently walled gardens, they think. (This is important, but that is a topic for another essay.). But even already, despite being a fledgling industry, they are massively oversubscribed. Massive unmet demand attracts money looking for investment. That money is starting to pour in, and the capacity is going to appear, seemingly overnight. Everything is going to change. Again.

The best known name in the game right now is Amazon's AWS EC2. But there are at least three startups who've talked to just me so far. And the hot rumor is that MSN's datacenters are about to virtualize and sell access. And then there's Google …

Bah, you say. Who suddenly needs a billion teraops with no warning, anyway?

iLike did, only a few weeks ago. Their Facebook application caught the zeitgeist, hit critical mass, and their userbase and attendant demand soared orders of magnitude in days. They started with 2 servers. Suddenly their 40 reserve were consumed, and they had to beg, borrow, buy, and scrounge hundreds more. news article here.

Marc Andreessen recently wrote it up in his blog. But since Marc is a well-funded VC, looking for places where well-funded VCs are needed, he missed the point. His conclusion was that only companies backed with the money and connections of a well-funded VC will be able to survive and afford the sudden demand crunches / instant capacity buildouts that the next generation of tech companies face.

In his words:

unless you already have, or are prepared to quickly procure, a 100-500+ server infrastructure and everything associated with it — networking gear, storage gear, ISP interconnetions, monitoring systems, firewalls, load balancers, provisioning systems, etc. — and a killer operations team, launching a successful Facebook application may well be a self-defeating proposition.

This is a "success kills" scenario — the good news is you're successful, the bad news is you're flat on your back from what amounts to a self-inflicted denial of service attack, unless you have the money and time and knowledge to tackle the resulting scale challenges.

Will every Facebook application go through this?

No, of course not. The ones that nobody uses will not have this problem.

But the successful ones all will.

The implication is, in my view, quite clear — the Facebook Platform is primarily for use by either big companies, or venture-backed startups with the funding and capability to handle the slightly insane scale requirements. Individual developers are going to have a very hard time taking advantage of it in useful ways.

I disagree. (I'll leave it to krow to say "Bullshit!").

Instead, what is going to happen is that when a company suddenly needs 100x capacity, the application itself is going to ask the grid for more capacity, and get it. And when the CEO and the other staff comes in from their Memorial Day holiday, they will discover that they now work for a company that's 100x as big, which almost no pain on their part.

When that pain goes away and is forgotten, a whole pile of really cool applications are going to go online that we can barely imagine now. Things that we don't think of because the economics and financing don't work. Yet.

Here are a couple of immediately obvious ones:

  • Some little personal webserver contains a page that gets referenced by SlashDot, or BoingBoing, or Instapundit. Today, that server would get smashed. But instead, the grid-aware webservice provisions a http redirector and a dozen httpd instances, holds up under the load, and then a day later shrinks back down.
  • One person builds a networked game, or a SecondLife toy, that suddenly hits a wave of fashion. Fortunately, he build his server to be scalable and grid aware. Instead of a dozen users, he's serving a million users, without being smashed by either "success kills", or having sold his idea into slavery to the VCs. And when the fickle wave of celebrity passes, no hardware or capital funds get wasted.

This is big. This is important. In ten years it's going to have changed everything.