This post is a hoax, it was published on April Fool's Day.

One beautiful afternoon in March, I was onboard a Metra train on my way home from CohesiveFT’s offices in downtown Chicago. I was reading a book on my Kindle, and little did I know that I was about to find out something huge that may soon change the IT landscape forever.

Not too far from my seat was a gentleman playing Solitaire on his laptop (I know, I know, no one is perfect). It looked like he had a conference call to attend, but since he thought his Solitaire was more important, he put his phone on speakerphone and turned up the volume, having placed the phone on a seat next to him. I have been trying to ignore the call but it was so loud one couldn’t do much about it - volume was set that high, I am telling you.

The call turned out to be one between all 7 US major cloud computing providers and top Wall Street firms. Apparently, a similar call happened earlier that day between European cloud providers and London-based representatives of pretty much the same banks.

As you might have already guessed from the title of this post, they were discussing ability to resell cloud instances (in infrastructure-as-a-service context). While providers will focus on implementing the actual mechanism how an instance can be “reassigned” to another account, the role of banks here will be to turn this into a new class of commodity that can be traded. Essentially, cloud providers as a group were pitching a new asset class to the investment bankers and wanted them to make the market for this commodity.

Here is how they said it’s going to work from technical perspective.

Say you have an instance in the cloud. There will be an API call that would be an “offer” - you are saying you want to sell this instance at such-and-such price. Someone else may have an outstanding “bid” for a similar instance. When there is a match, a trade will be executed: your old instance is going to be terminated, bidder’s image will be placed exactly in the slot your instance used to occupy, and then bidder’s image will be started.

The key they emphasized was that it was not about customers buying capacity from various providers at dynamic prices. It was about customers’ ability to resell an instance to another customer. At any price a buyer would be willing to pay! Also, providers said that if they ever get a request for a lot of capacity while they can’t satisfy it quickly enough, they would be willing to buy back capacity from their own customers on the open market.

This is obviously huge! To read more, please see here.

Every disruptive change has its pioneers. Someone must be the first to think of it, someone must be the first to launch it, someone else could be the first to use it at scale. While most observers agree that Amazon Web Services are an undisputed pioneer of cloud computing on the supply side (i.e., among vendors and service providers), year 2010 saw the emergence of Netflix as one of the pioneers in the use of cloud computing by enterprises.

Nextflix, many say, is not a typical enterprise. Even though it’s a big company (employs more than 2,000 people according to its press kit) that is publicly traded on NASDAQ with current market capitalization of slightly over $11B, it’s relatively young (founded in 1997 according to Wikipedia), caters primarily to consumers and its IT is their business (as opposed to a typical enterprise where its IT supports its business - when Netflix was a DVD mailing company, its IT supported its business; as Netflix is transforming itself into a content streaming company, its IT is becoming its business).

Netflix has always been a bit geeky. Their recommendation algorithm has been their prized asset for some time. Also recall, for example, a competition they ran in 2006 offering a big reward to anybody who would develop a better one.

I started following Netflix’s cloud use in 2010. Netflix is a big operation, possibly even regarded by AWS as their “reference” customer. If you follow cloud computing, you couldn’t have missed it.

I watched several presentations given by Adrian Cockcroft (see his interview with Randy Bias) and subscribed to techblog.netflix.com. The latest post there is full of cloud wisdom of a cloud practitioner.

For example, we learn that Netflix went to cloud in search for high availability and agility was almost like a side effect. We learn that Netflix does not want to be a datacenter expert because they regard it as an accidental complexity. Being a consumer brand in a relatively new market segment, they did not want to worry about getting their capacity forecasts right.

If you look around the web, you will find that Netflix is running a Java application stack, which makes it close to many other enterprises out there. But the key components that sets them apart is their internal operations platform tailored for Amazon EC2 - from development to QA, to deployment, to monitoring, to trend analysis, to troubleshooting. (It’s important to realize that an “internal operations platform” is not only software - it’s also a set of processes, standard operating procedures, mind set and operations philosophy).

And here is the point of this post (finally!). Netflix essentially has built an enterprise-friendly world-class PaaS for Java. They probably built it without thinking of selling it as a standalone product to other enterprises one day, but I would like to ask - why not? If the world's biggest web retail operation managed to build a hosting business, why can't one of the world's geekiest enterprises build an IT ops platform business as well?

Think about it - Netflix Web Services, Java application hosting, for enterprise by enterprise…

Can’t say for sure if it will happen or when but my gut feel is that it will happen eventually, and if not Netflix then some other cloud customer will enter application hosting (PaaS) business with a platform originally developed for internal needs.

Netflix folks, are you reading this?

Since November 2010, I have been running Jekyll to power this blog. Before Jekyll, I was on self-hosted Wordpress, which could explain some of my decisions around how I organize my posts because I didn’t want to break any existing links.

You can find some interesting resources on Jekyll that I collected while building this site at http://www.delicious.com/dsamovskiy/jekyll.

If you are reading this post via RSS, you can find all code snippets below at https://gist.github.com/852008 or open this post in a browser. As of the time of this writing, I use Jekyll 0.7.0.

Categories

I define categories for each post in its YAML Front Matter.

My category layout uses category_name as parameter which I can access as page.category_name. For example, all posts in current category are going to be in site.categories.[page.category_name].

And here is a plugin that I use to generate each category’s main page from an empty one called “category.html” (instead of explicitly having a separate page for each category):

Post Counts by Category

In my templates I use site.sorted_categories as a list of categories sorted by the number of posts in each category in descending order:

And here is a plugin that I use to build this list:

Related Posts

For each post I build a list of related posts as N most recent posts in the same categories. Here is how I populate post.related:

I am not a formally trained economist. I am a software engineer, and economics (and economics in IT in particular) is merely a hobby of mine.

I have now seen many mentions of Jevons paradox in the context of cloud computing. Initially, when I first learned about it, it sounded interesting and exciting, just as any proposition that on the surface defies common sense and explains something fundamental in one’s area of professional interest. But as I read how other people apply Jevons paradox in their lines of thinking, I realized that it’s not as clear cut as one might imagine.

What is Jevons Paradox?

While you can read the entire paper here, Jevons paradox in short states that “improvements in fuel efficiency tend to increase, rather than decrease, fuel use” (both link and interpretation are from Wikipedia).

Let me first outline a hypothetical scenario in cloud computing domain where a phenomenon similar to the one described by Jevons could be observed.

Imagine you are developing a model that can predict future spot prices in Amazon EC2. To be able to obtain results with 50% confidence level, your model needs to run for 5 hours on 100 cloud instances (500 machine-hours in total).
 
Now imagine that due to enhanced orchestration and coordination between various parallel tasks of your model, you no longer need to run all 100 instances for the entire duration - you can stop and start instances on demand at the right times such that your overall model now takes only 220 machine-hours. In other words, you switched to more efficient use of the resource (compute instances).
 
Looking at significant savings, you start contemplating whether to improve the results by increasing desired confidence level, which will obviously increase the amount of computation and hence will drive up the number of required machine hours.

Predict the future vs Explain the past

The last paragraph above is what’s known as rebound effect. If you choose not to require higher confidence level, your rebound effect is 0. It means that you fully realized all savings made possible by increased efficiency of your use of resources. This case is not Jevons paradox.

If you choose to require say 60% confidence level and it leads to 300 machine-hours, you still realized some savings (500 machine-hours vs 300), just not as much as you would have realized had you stayed with 50% level. This case is not Jevons paradox either.

Furthermore, if you choose to require 80% confidence level which happens to lead to your enhanced model requiring 500 machine-hours, your overall spend will remain the same (500 vs 500). Also not Jevons paradox.

And only if you choose to go still higher with confidence level - say 90% - will you end up with your model taking more than 500 machine-hours, and in doing so you would end up with situation described by Jevons.

All in all, Jevons paradox is a special case of rebound effect, and there is absolutely nothing that can tell you in general case in advance how big the rebound effect is going to be. Hence, you can't tell in advance if a rebound effect will be big enough to turn into Jevons effect or not. Therefore, predicting in general case that cloud computing will not save you money because of Jevons paradox alone is logically inaccurate.

On the other hand, if you saw me going from 500 machine-hours for 50% confidence level to 700 machine-hours for 90% level, you could explain what happened to me as Jevons paradox. Post factum.

Macro vs Micro

Jevons formulated his statement on a macro level. Rebound effect is also usually studied on macro level. Macroecnomics focuses on economy as a whole - or, in other words, on a collection of individual entities (firms and households) each of which is guided by their own self-interest, independent of that of others.

What happens to a set of entities as a result of their independent actions taken cumulatively can’t tell us how a given individual household or firm will behave - that’s on micro level.

Automatically assuming that whatever happens on macro level happens to every participant on micro level is a fallacy of division.

Therefore, even if cloud computing will not lead to reduction in overall IT spend, saying that a given company can't lower its IT spend by going to the cloud because of Jevons paradox alone is inaccurate.

Further Reading

• http://www.eoearth.org/article/Rebound_effect
• http://www.eoearth.org/article/Jevons_paradox

Among numerous technical components that comprise an infrastructure-as-a-service cloud, there is one that usually draws most criticism and causes most annoyance. I am talking about the network. Too flat, too inflexible, too slow, too unpredictable - cloud network has been accused of being each and every one of these. And while some of the complaints could very well be valid at times, it is the cloud network that holds huge untapped potential for many big things in cloud computing.

While a network in each cloud may be designed differently, there are usually two important characteristics that all networks in all clouds share - they are super fast (LAN speeds within a single region) and they are multi-tenant.

The latter is the key. It’s true that multi-tenancy is often presented as a drawback or undesirable side effect - it significantly increases the risks of running one’s systems in the cloud and could negatively impact the throughput of one’s system because of noisy neighbors.

But let’s look at it from another perspective. Applications want to exchange data. (And by “application” here I mean any piece of software that runs in the cloud - webapp, data store, queueing system, data warehouse, traffic encryption service, etc). A webapp wants to receive user’s request, send a query to data store, and simultaneously send the visitor’s IP address to a geo-location service. Data store wants to send the response back to webapp and send query statistics (how long it took to run the query, how many records were returned, etc) to a monitoring system. Monitoring system wants to analyze and send alarms. And so on and so forth.

But what if the webapp in this scenario is run by one company, monitoring system is run by another company which specializes in monitoring, data store is run by data store specialist company? This used to be nearly impossible. From vendor’s standpoint, providing real-time support for data stores located at each client’s own network was extremely hard and costly. From customer’s standpoint, connecting from their datacenter to vendor’s system over Internet or private links could be prohibitively slow. In the cloud it becomes a piece of cake, primarily due to the very fast network between different cloud tenants.

Furthermore, in clouds like Amazon EC2 there is no real difference in network connectivity between 2 servers under the same account and 2 servers under different accounts (this covers both speed and bandwidth).

Cloud network to application data is what Internet Exchange Point is to Internet traffic.

What you used to need to have in your own network can now be easily outsourced to a specialist, without sacrificing connectivity speeds or bandwidth, if both of you host your systems in the same cloud region. This is huge.

Additionally, and for some potentially even more importantly, you now get an opportunity to interconnect with your customers, vendors and partners at LAN speeds, without having to spend a fortune - all you need is for everybody to get their systems (or at least points of presence) running in the cloud. The power of network effect!

George Reese predicted that 2011 would be a year of the network in the cloud. I fully subscribe to the idea that 2011 is going to be the year when cloud network is going to start playing a new and significantly expanded role.