The Help Desk will be going away.

It’s important to understand the meaning of the term “Help Desk”. I don’t just mean people who sit around all day with headsets, answering phone calls. It turns out there are a *lot* of people employed in IT whose job it is to just keep the lights on. Vendors, Integration specialists, Sysadmins, and the guy whose entire job it is to  click the right button to clear the printer queue. Entire countries have devoted a lot of resources to greasing the gears of computers. They all work in a Helpdesk somehow.

CTO’s and CIO’s are starting to appreciate that their function at a company isn’t about technology implementation – it’s about how technology can help their business. Who cares if your OS is running Windows or Linux if all you need is a Word processor (and Solitaire). It’s become totally irrelevant.

What matters is the applications that are delivered to the end user; everything else is just implementation dogma. The people doing these implementations are Help Desks too, they’re just a few degrees removed from the end-user and prefer snazzier titles like ‘Application Services Engineer.’

It’s gonna take awhile. The PC will be around for a long time and people still need to type. But as we shift to tiny, integrated, crash-proof devices we need help desks less and less. The intuitive nature of the computer will suggest that it’s no longer important to be adept at using them. Not only that, but as we cycle through generations of people, the technical citizens will supplant the technical immigrants

There are quite a few issues with the transparency of costs in the cloud computing space. This includes no transparency into the cost of electricity, and where that electricity is coming from. To date, there is no public database of electricity markets, datacenters, and hosting providers which lists how much carbon per kWh of electricity is being output. In ICT this is a massive issue, because of the sheer amount of energy our industry consumes.

“Information and Communication Technology (ICT) is both a problem and a potential solution in the war against climate change. Currently, computers are responsible for more greenhouse gas emissions than airlines. Greenhouse gas is growing exponentially and we expect that ICT will produce double the emissions of the airline industry within five years with no end in site. ICT can provide a solution to climate change by reducing carbon emmission in the world through telecommuting and other means.”

Here in British Columbia we get most of our electricity from renewable hydro-electric power. Hydro-Electric is one of the lowest forms of reliable low carbon output electricity generation available. It goes without saying that providing computing services using energy generated this way would mean less CO2 / kWh but also less CO2 per compute cycle.

We need several things to make this happen

1) Start measuring how much power ICT is using on a per server / component basis
2) Develop resources that track carbon output per kWh in different states & provinces and provide that information as a service
3) Determine where your computing resources are located and track on a per machine level the amount of carbon being output
4) Calculate how much carbon you’re using.

Those are pretty audacious goals, but I think we really need to start keeping track of carbon output for power. By tying that into the different services we use on a regular basis, we can make carbon part of the social and actual cost of using services. Hopefully that will help buy us enough time and money to develop the carbon neutral power solutions we desperately need.

Popular wisdom suggests that this would mean we get to save something; We conserve energy because were powering less servers.

It turns out the opposite is true.

Jevons Paradox explains the effect that technological progress has on reducing prices of a resource, only to increase the actual consumption of that resource. Typically this applied a lot to the Oil industry, and its a rather well understood phenomenon, but the same thing applies to Network and Computing infrastructure.

Bandwidth is perhaps the easiest example of Jevons Paradox. Back when a couple megs of throughput cost you $1500 a month, you would find ways to reduce and conserve that bandwidth as much as possible. Technology has progressed to the point where some lucky individuals can get a LAN quality connection for as little as $30 dollars. It’s obvious that the cost for bandwidth has dropped through the floor. While that kind of progress should lead to greater efficiencies, it simply doesn’t work out that way. We dont conserve those pipes – we just use more of them.

Elastic Demand for Work: A doubling of fuel efficiency more than doubles the amount of work demanded, increasing the amount of fuel used. Jevons Paradox occurs

The same thing is happening in utility computing.The cost of computing is quickly becoming too cheap for us to save any energy, or to force us to squeeze more out of a system. While at layerboom we build advanced systems that can generate more revenue per physical server, the end result for utility operators is that they will sell more units. For them, this is a totally acceptable solution (and I wont complain either!). However, it has some dire implications for energy usage and conservation. Most of this infrastructure is running 24×7. Idle or not.

In North America, the infrastruture required to run the internet consumes about 10% of our electricity. Do our Data Centers need to get bigger? Or do we really need to start figuring out how to not only make these pieces of infrastructure more efficient, but find a way to ensure those efficiencies at least counter the growth in the system?

At a conference I attended awhile ago we broke off into several teams to discuss what we thought cloud computing was. This was doomed for failure, but what I noticed and what seemed to be lost on everyone in the crowd was that everyone came up with an answer that solved the problems they have to deal with in their profession, day after day. We didn’t come up with a magical definition, and this exercise has since become kind of a pastime at Cloudcamps / Conference, etc because nobody has ever come up with a good answer, and nobody ever will.

Until we stop thinking about the Cloud as a product, and start thinking about it as a concept, we’re all wasting precious time

It’s time for me to append my opinion to what is already a littered landscape of ontology. Honestly this is the best thing I’ve ever heard someone say about cloud computing, and it didn’t come from an engineer, the marketing department, a blogger, a techie, a social media consultant, or someone on twitter. It came from a Barista at my local Starbucks. She asked what I did, and I told her, and she was more curious about what it meant, so I begrudgingly went into a few details and she quickly replied back with “So it’s just easy”.

That’s it. It’s just Easy.
Cloud Computing is Easy.

Easy is why Joyent is great – You get a powerful system and signing up is quick, simple and Elegant.

Easy is why Amazon is kicking everyones ass. You can get 100′s of virtual machines crunching away at your data by running a single command.

Easy is why platforms and services that do Billing, Advertising, Customer Feedback, Authentication, Store your Data and Backup your Files are successful. Because it took the effort of a small group of people to build something that could be re-used over and over and over again by the masses, made so easy that having a credit card is the hardest part.

I recently asked people on Twitter “if they couldn’t call their magic “Cloud Computing” for one day, what would they call it”. The purpose was to make people think about it for one second. What do you ACTUALLY do. You don’t actually build cloud computing environments do you? No. Do you build hosting environments? Do you host software? Do you build or run platforms? Do you do anything like this? If you can tell me what you do without using the word “Cloud” then we can have a discussion, and if the power you provide can be made as easy as clicking a button or including a library, then maybe, MAYBE, you’ll have the right to wrestle it back.

There are economic concepts that dictate how you use services and hosting on the internet.

Do tell.

Computing is really cheap. Think about all the email that Gmail handles in a day. It’s so cheap that advertising can pay for it. But the “Network is the computer” after all, so we have to think about what it takes to get that information in and our of these clusters of cheap computing, and that’s the rub. Amazon charges $0.17/gig to get your data out of EC2, which is equivalent to almost two hours of their cheapest computing instance. This is a good scenario if the task you send to your cheap compute cluster can be defined in a very small package, and yields a relatively small result but typical web services and applications don’t work this way. The point is: Its cheaper to move the computing than it is to move the data.

So what?

This all clicked for me when I messed around with Freebases development environment, “Acre”. Acre is great. It lets you create, edit, and host your applications through a browser. Not only had I been messing around with Acre, but I’d also been toying with the idea of using Freebase as a mechanism for validating and normalizing data. The problem is asking Freebase for a bunch of information on say, “every city on the planet” is pretty expensive. Not only do you incurr a network transfer cost, but you then have to process the information. Not exactly ideal. But what if I could pose a question to an application running at Freebase? What if, instead of pulling out all the information about every movie and creating your own Freebase-based IMDB, you could host it right next to the data source. You get all the benefits of transferring the ‘heavy stuff’ over the WAN, and the browser gets the good stuff, but only when it asks for it.

This is why server-side javascript is perfect

Hosting Ruby, PHP, Python, etc is kind of a pain in the ass. Well its easier than it used to be but it could be a lot better. If I had to choose something relatively lightweight to interface to my data-source and create that rich browsing experience, you’d probably pick Javascript. My initial impression is that depending on your data-source, scaling it would be easy, too. Running computing close (as in LAN close) to the data-set means a few things

1. You can create cheaper mashups

2. You can eliminate all the cruft from your data before it gets sent over the wire

3. You can create nifty applications and ask them short questions that yield short answers but require huge amounts of data to determine

ZOMG How do I start?

You’ll have to learn javascript, and as a hosting or service operator you’ll have to choose an application for running it server-side. There are a few options. Trusty Wikipedia has a lengthy list of Server-side Javascript implementations. I’d recommend checking out the following:

Rhino

Spidermonkey

V8

AppJet

Jaxer

-Trevor

Take Amazon as an example. Amazon operates their environment as a bunch of different groups, each running different services within the same company. S3, EC2, Payment Services. They’re all independent, highly scalable functions, tied together in the application we call Amazon.com.

Companies and startups are starting to break this operational model open, and putting those individual functions online for everyone. They’re building services that do something really well – or rather that do one thing really really well. They’re companies that focus on a specific function or feature and are open enough so creative people can say “I’m going to take this, this, and this – mix it in a pot and voila!”.

Do you want to build your own Twitter? Find an SMS gateway, Cloud Computing Host and XMPP service provider.

Do you want to build an interesting RSS/ATOM service? Find an RSS aggregator service and pour on some glue – see what sticks.

It’s Feature as a Service world (to use an already overused description). Eventually cloud companies will realize that doing one thing really *really* well is tremendously valuable. Why does everyone have to build their own DNS service? Why does everyone have to build their own hosting system? What about Enterprise Storage, Authentication, SMS Gateways, Massively scalable XMPP services? How come I have to do that myself? Can 10,000 messages sent through a jabber server be worth a dollar? I think it can (maybe the math needs adjusting but you get my point). We’re all really just building a massive computer called the internet, only with each big trend we replace ‘The Internet’ with something else. First it was ‘The Web’, then it was ‘Web 2.0′, and now its ‘The Cloud’. The fact of the matter remains – the further along we go the more tightly knit the internet becomes, and that means that theres opportunity for programmable white label services to propel us further and faster.

Application Integration

Just like everyone thought WSDL would automagically make applications work together, people think the new ubiquitous ‘Cloud’ will make applications work together. Unless your application was designed from the beginning to talk to and operate with other cloud stacks, then you’re going to have an application integration issue on your hands. This is why behemoths like SAP exist. Everything is one universal and translatable data format, all controlled by one vendor. If you want to be able to move data, or integrate applications that run in different clouds, then you’re going to have to do it the old way. Sit down, translate the data yourself, and emulate it where you can’t. Cloud != Application / Data Babelfish

Eliminate Monitoring

Monitoring is either a dirty word or a multi-million dollar business depending on who you talk to. As a sysadmin for several high-availability environments, I can’t stress it enough. Building your application and environment to be redundant is always step number one, but it’s useless if you don’t know the state of your environment at all times – especially before and after changes. Environment monitoring is like Behaviour Driven Development (see rspec) for your application. You know what’s supposed to happen, and how things are supposed to look – and if something changes you find out about it. You still need this kind of functionality, and just putting your stuff in the cloud doesn’t make issues go away. Cloud != Perfectly Reliable Environment

Eliminate Lock-in

Oh boy I said a dirty word. If you write your application for AppEngine, then you’re using AppEngine until you refactor. Period. The AppDrop application lets you “run AppEngine on EC2″ but thats kind of masking the issue. AppDrop is just the AppEngine developer tools running in an AMI – it doesn’t do anything like emulate all the necessary infrastructure that makes AppEngine appealing in the first place and the authors acknowledge this. Don’t get me wrong – AppEngine is great. Its a highly abstracted environment for writing web applications, but it’s not appropriate for a lot of different services. If you want to be able to treat the cloud like you treat a “standard” machine -> LAMP stack then you should be aware of all these factors. Cloud != Universal Magical Computer

Eliminate Jobs

Sysadmins (and I can say this) are an odd bunch. Most of them treat their environments like children, rearing them to a specific age, but always keeping a watchful eye. Others tend to automate everything necessary in order to move on to the next best thing. The people that horde data, knowledge, useful tools, and expertise will fit right in to closed cultures, but if you want to make it in the new reality, you’re going to have to open your mind. The cloud isn’t going to make you obsolete unless you try stopping progress. If you didn’t have to worry about making system images and building back-ends all day think about all the other amazing things you could do! There are a slew of bad analogies I can use to drive this point home, but I’ll use the most cliche: Be a reed in the wind. If you’re clinging onto a job because you’re easily replaceable, then its just a matter of time. Learn a new skill. Cloud != Massive Layoffs

Great Scott! An aquaintance of mine just forwarded this to me today and my jaw dropped. A team working out of University of California, Santa Barbara led by Rich Wolski has reverse engineered the EC2 framework and (apparently) released it under a FreeBSD style license.

They gave a demo at the Open Source Grid and Cluster Conference, which was a paid conference (tsk tsk tsk)

From the website:

Overall, the goal of the EUCALYPTUS project is to foster community research and development of Elastic/Utility/Cloud service implementation technologies, resource allocation strategies, service level agreement (SLA) mechanisms and policies, and usage models. The current release is version 1.0 and it includes the following features:

• Interface compatibility with EC2
• Simple installation and deployment using Rocks cluster-management tools
• Simple set of extensible cloud allocation policies
• Overlay functionality requiring no modification to the target Linux environment
• Basic “Cloud Administrator” tools for system management and user accounting
• The ability to configure multiple clusters, each with private internal network addresses, into a single Cloud.

The initial version of EUCALYPTUS requires Xen to be installed on all nodes that can be allocated, but no modifications to the “dom0″ installation or to the hypervisor itself.

This is fantastic and *exactly* what the industry needs right now. In fact, it falls in line nicely with what we’re working on at LayerBoom. I’m extremely interested to see how this works. I’m actually booting it up as I type this.

[link] [link]

The Open Virtual Machine Format, or OVF is a proposed universal format that aims to create a secure, extensible method of describing and packaging virtual containers. Because the standard is open, it means any environment supporting the standard can import and export those virtual machines between different hypervisor platforms. The current OVF specification includes definitions ranging from virtual machine metadata and disk format, all the way to detailed hardware specifications and logical network information. It also provides an ability for the virtual machine itself to get information from the hypervisor host, meaning that if you’re creative you could create some really nifty automated integration and deployment tools.

If that doesn’t mean much to you, then consider this: Industry heavy-weights like Dell, HP, IBM, Microsoft, VMware, and XenSource all took part in drafting the specification. As far support tools go, VMware has published what appears to be the first OVF container creation tool, available here.

There IS a big problem with OVF right now, and a lot of bloggers and analysts out there are getting it wrong. OVF is not and does not define a new virtual disk format, simply a wrapper around them. This means that OVF support doesn’t enable you to drag and drop virtual machines between Xen and VMware. Some formats can be converted externally using tools, however most of the current techniques involve booting up a system, and running a migration tool to be able to convert the image – not exactly ideal. OVF does include the ability to describe your specification in an HREF, which means that you could publish your spec, and create a system that could modify containers on the fly.

If Vmware, Xen, and Parallels are technolgical islands, then OVF may one day be the bridge that will allow you to travel between them.

Update It looks like OVF will be announced formally at the Catalyst 2008 conference. More information here.