I was reading this.

The “computer machine” as our base unit of work is a shitty unit.

What I typically want is

1. – Agility and flexibility
2. – Performance and scale
3. – Business continuity and taking a resource pricing point of view for dev, test, staging and DR.
4. – Business and security best practices baked into infrastructure

You can do agility and flexibility with virtual machines. But that’s it.

Virtual “machines” suffer from the same fundamental problems as “physical machines”.

1) VMs still take up space just like PMs and the space they take up is additive. A machine is a machine. Whether logical or physical. You cannot do business continuity, dev and test for the cost of production. It’s normal to figure out what a piece of software needs for production and then buy 20x all at once that to account for everything one might need. This is for an application that will not need to scale beyond the initial deployment and it’s clear to see why one would end up at 5% utilization on average. VMs are not in line with the idea of having accessible software fully utilize a server.

2) Performance and scale can not, will not and are not a unique feature of a pure VM approach. They can’t be. No more than a square peg’s inability to fit into a round hole. The same wall that you hit with physical machines, you will hit it with virtual machines. Except. You. will. hit. it. sooner. It you’re not hitting it, you’re not big enough, so maybe don’t worry about it: you’re likely just concerned about agility and flexibility.

You don’t buy CDN services by the “VM”. We need to move what we’re doing with compute to a utility around a transaction, around the usage of a specific resource. Everything else needs to be minimized.

To be clear about the problem and to leave you with some food for thought. I can take two racks of servers with two 48-port non-blocking 10 Gbps at the top of each, and then write a piece of software that will saturate the lines between these racks.

Can someone name a web property in the world that does more than a Tbps?

Can someone name one that gets close and only uses 20 servers for it’s application tier?

We have massive inefficiencies in our software stacks and hardware has really really really really outpaced what software can deliver. And the solution is what? More layers of software abstractions? More black boxes from an instrumentation point of view? Odd.

But familiar.

I was on a panel last week talking about the role of infrastructure and “The Cloud” in online gaming (and I’m talking “fun” games, like Farmville, not online gambling).

One of the questions was “What do you think about cloud interoperability and standards?”.

To which I asked, “What do you mean?”

“Well, what do you think about API standards and the like?”

To which I replied, “Completely uninteresting.”

Now I know that at first read, it sounds like I’m saying to forget “standards” and to forget “interoperability”, but I’m not. It’s just that most of the current conversations about it are uninteresting. And uninteresting in the sense that I’m not convinced there is even customer pain, I’m not convinced that having to tool around different APIs that only currently accomplish provisioning is that difficult (remember the great thing about it is generally that it takes <30 minutes to understand how to do things and get going). In the case of virtualization, many use libvirt and that’s what you generally do in programming: interoperability comes in the form of a library or middleware generated by producers and real users and not design by committee. I expect to see more of these types of projects emerge.

Beside the fact that one’s application shouldn’t have to be aware that it’s no longer in your datacenter and it’s now “in the cloud”, I’m not even sure what most of the current standardization discussions (many seem focused around provisioning APIs or things like “trust” and “integrity”) would enable start-ups, tool vendor adoption, ISV adoption and an “ecosystem” to emerge in the grand scheme of things. I don’t think that these are the main problems that limit adoption.

And what are the real problems where interoperability and standardization is important? I think in data mobility and transparency.

Data mobility?

Let’s only talk about mobility at the VM level. If I create an AMI at Amazon Web Services and push it into S3, I can use that AMI to provision new systems on EC2, but for the life of me, I can’t find the ability to export that AMI as a complete bootable image so that I can run it on a local system capable of booting other Xen images. If you have a reference for this, please send it my way.

The same goes for Joyent Accelerators. We don’t make this easy to do. We should.

Transparancy?

Now this is where I think things get good. And where standard data exchanges around what our “cloud” is doing and whether it has the capacity to accomplish what a customer needs it to. In a previous post, I said

The hallmark of this “Cloud Computing” needs to be complete transparency, instrumentability and while making it certain that applications just work, the interesting aspects of future APIs aren’t provisioning and self-management of machine images, it’s about stating policies and being able to make decisions that matter to my business.

The power of this is that it would actually enable customers to get the best price at the best times, know that they’re moving an application workload to somewhere that will actually accomplish it and it is required for there to be the computing equivalent to the energy spot market.

I’d like to hear from our readers to please. What are the current “standardization” efforts that you thing are going well and might be interesting? Any realistic ones? Which ones are boiling the ocean?

In my weekly reading of posts around this mighty collection of tubes, pipes and cans connected by shoestrings, the thing most call The Internets™, I came across “Why we moved away from “the cloud” to a “real” server”  from the fellows at Boxed Ice. They have a server metrics and monitoring service named Server Density.  Their exodus from a small VPS to collection of VPSs (What is the plural anyway? If Virtual Private Server is VPS, then Virtual Private Servers is VPSs?) is typical of a service that’s starting out and doesn’t have the in-house expertise and capital yet to go out and start building everything yourself (which is fine, that’s not a value statement, I’m simply saying that it’s a common path to go shared hosting to VPS to Managed Hosting to entirely DIY).

What I don’t like is the title. They moved from “the cloud” to the “real”.

To be exact, it was easier for them to get a “box” from a managed hosting provider with an NFS or iSCSI mount then it is to take the additional effort in configuring and managed EC2 images and the Elastic Block Store (EBS). They “would have had to build our own infrastructure management system” in order to get Amazon Web Services to do exactly what they wanted.

That’s entirely correct. A precise title would therefore be “Why we moved from two VPSs to some servers at Rackspace instead of getting into the morass of managing EBS plus EC2 and probably spend more money while we’re at it”.

I admit, it’s a longer, more awkward title but it doesn’t use a generic term for what is a pretty specific complaint.

I want to make really clear at this point that I think they’re entirely right, and everyone in the “cloud industry” should think to themselves “Am I writing the correct software that would make such commentary a thing of the past?”.

What then is the cloud? And really why did the “cloud” fail them at this stage in the game?

In my opinion, “Cloud computing” is a software movement.

Software requires a hardware platform, and the hardware platform must be scalable, robust and able to either directly handle a workload or be a valid part of partitioning that workload. At Joyent, we’re pushing our physical nodes to the point where they’re simply not normal for most people: base systems with 0.25 to 0.5 TBs of RAM, more spindles than a textile factory and multiple low latency, 10 Gbps out of the back (looking back to 6 years ago, it’s amazing what you can get nowadays for about the same price) . These then become the transistors on the Datacenter Motherboard, and just like how on a current “real” server, many of the components are abstracted away from us (we deal with a “server” and an “operating system”), those of use writing “Cloud Software” need to abstract away all the components of a datacenter and have everyone deal with telling the “cloud” what they want to accomplish. Taking desired performance and security into account, the ultimate API or customer interaction is “I want you to do X for me”.

What is X? Some examples,

“I want this site to be available 99.99% of the time to 99.99% of my end users. How much is that?”

“I have this type of data, it needs to be N+1 redundant, writes have to happen within 400 ms and reads within 100ms 99.99% of the time. How much is that?”

I could go one with a series of functional use cases like this where the user of a “cloud” is asking to do exactly what we typically want an entire infrastructure to do (not defining the primitives etc), where the user is telling the cloud how important something is to them and where the user is asking for an economic value/cost to be associated with it.

The “How much is that?” should always return a value that is cheaper than “real” and cheaper than DIY.

That’s something that’s different.

That’s something that’s an improvement on the current state of computing. It’s not a horizontal re-tooling of the current state of affairs.

That’s something that would take us closer and closer to providing products to growing companies like Boxed Ice where they start out really small on the “cloud” and seamlessly scale to a global scale when they need it, and the “cloud” becomes “real”.

I’m moderating the first panel of the day at Om’s Structure09 conference today.

If you’re at the conference please make sure you say “Hi”.

I was on a panel at Enterprise 2.0 yesterday about “Cloud Computing” providers and wanted to take the entire definite of “what is cloud computing?” from a different perspective.

As a consumer, I fundamentally want the entire technology stack for an application to

1. Just work
2. Just scale
3. Just tell me everything

Just works means that I tell an infrastructure that I want my application to have user experience X 99.99% of the time to 99.99% of the my users, and what I want back from that query is a dollar amount. I’ll then make a decision about what I can afford.

Just scales means that I can go from zero to millions of users, one geographical site to twenty geographical sites, and one continent to four continents without a rewrite/rearchitecting.

Just tells me everything means that an API and data source is not only about provisioning machine images or the like, it can be queried for real time and time series data about everything. It let’s me make decisions around latencies and nothing ever just happened for no reason.

When you think about what it would take for these things to come to fruition, it starts to feel like a real step forward in the industry. It’s the collection of these things (in existence or development) that I don’t mind giving a new term to.

A little over a year ago Joyent was identified in a Forrester report as one of ten “Cloud Computing” companies to watch. The report was really the beginning of “Cloud Computing” being applied to those of us doing infrastructure and I think marks the point in time when the term really began to appear in marketing materials.

Our inclusion on that list was notable because we were the only privately held company on the list that operates their own server farms and develops their own software stack to instantiate and manage it all.

Since then it’s been cloud cloud cloud cloud cloud cloud cloud cloud and I recall the first time I noticed it showing up as an adjective, I overheard someone actually ask “Is your application cloudy yet?”.

Does one really want a “cloudy” application?

Our premise here has always been that an application should “Just Work” and when it does not, then we should have the means to quickly figure out why and correct it. Importantly, one should be able to figure out the issue(s) within the context of the entire architecture.

The general “gut feeling” though is that something is changing in our industry, and I would say that like how “the network” was flattened, standardized and made into a utility, what people are talking about as cloud computing is the next wave of making data and compute available as utilities or even if entirely owned, one conceptualizes and runs it as a utility. Well that’s part of it. For now, we’re all just calling it Cloud Computing.

Like anything that is a utility, there are initial concerns that fundamentally boil down to trust.

Trust does not emerge from things that are cloudy (opaque). It emerges from complete transparency and the ability to determine what’s is happening or has happened. Trust comes from letting an infrastructure know what’s important to you. I want to query an infrastructure with “This application needs to be available within 1 second to 99.99% of my users 99.99% of the time. How much is that and can you do it?” or perhaps “This 246GB of data you’re about to handle is ‘level 3’ data in our privacy policies. How much is that and can you do it?”.

The hallmark of this “Cloud Computing” needs to be complete transparency, instrumentability and while making it certain that applications just work, the interesting aspects of future APIs aren’t provisioning and self-management of machine images, it’s about stating policies and being able to make decisions that matter to my business.

Rod and I also held several interviews at the show – including Tim O’Reilly, Kevin Marks, Steve Gillmore, Dan Farber, and Rafe Needleman trying to get public opinion on ‘What is Cloud Computing’. We will be posting that video shortly as there is some good stuff in there.

Disclosure: That handsome fella interviewing him happens to be my husband, Chris Heuer, whose agency produced the Blogtropolus bloggers lounge at at the Web 2.0 Expo.