Pipes, clouds and scarcity

Pipes, clouds and scarcity

Summary: Why does Microsoft call its cloud computing platform Azure? After all, a blue sky doesn't actually have any clouds in.

TOPICS: Windows

Why does Microsoft call its cloud computing platform Azure? After all, a blue sky doesn't actually have any clouds in. Is the name a hint that Microsoft thinks the cloud is a fad that will soon get blown away by the harsh winds of reality?

There are some stiff breezes whistling past the fluffy enthusiasm of some cloud proponents, but what Azure really implies is that Microsoft isn't building a cloud; it's building the sky that clouds will live in. Azure is a container for clouds. Or as Amitabh Srivastava, the senior VP for Azure (and the technical fellow who built Azure with Dave Cutler) told us, "The way we view the cloud is as a massive distributed computer that is spread across the globe. It consists of commodity machines, load balancers, switches all made available as a service. We want to build an OS that manages this massive infrastructure and makes it available. We have two goals with Azure. First, by managing IT efficiently you can drive operating expenditure and capital expenditure down. And by masking all the complexity, you can provide a rich set of abstractions developers can build on."

Of course, being from Microsoft he went on to say that "we view the cloud as an extension of existing IT" but that's fair enough. There's a limited number of businesses who would get on better by throwing all their software away and putting everything in the cloud, because the cloud - and the bandwidth that connects you to it - is nowhere near advanced enough to be mistaken for magic.

You could put everything into the cloud, but then your data and apps are limited to the speed and reliability of your connection. (And if you think have the perfect 24x7x365 network at high speed and low cost, we have a bridge we'd like to sell you, Gmail).You can duplicate things into the cloud, but then you're paying for standby systems; worth it if you need it, but not for everyone. You can move things into the cloud as you need them, but remember you're in a race between demand and bandwidth - and how do you know when you need to move?

Working with the cloud isn't like working with your everyday applications. Building successful cloud solutions means thinking very carefully about the architecture of your applications and just how they can take advantage of the flexibility and scalability of the cloud. Not surprisingly the tools you need are already here - in the shape of that old friend, the Service Oriented Architecture.

It makes a lot of sense, too. SOA is all about tightly defined software components that use well-constructed grammars and fixed APIs. You can change what you like inside a component - as long as it never changes the way it communicates with the rest of the components in your application. SOA is an ideal way of approaching the cloud - breaking applications down in to a soup of Lego pieces. Need two thousand blue blocks suddenly? Just take your standard blue block and replicate it across the cloud.

There is one requirement here: automated management. You need software that can build and manage the routing between components on the fly - as well as factories that can create and destroy application components as they're required. These aren't tasks for the IT pro - they're tools that need to monitor the current and predicted state of a business process, and then make appropriate changes to the deployed service components and the messaging architecture so that users always get the performance and the experience they want.

Automating these processes isn't easy, but that's what Azure and any successor OSes are for. Microsoft Research made some interesting announcements this week, around two new research operating systems, Barrelfish and Helios. We couldn't help but be reminded of the original Helios, a rather fine British OS developed for the parallel processing world of the INMOS Transputer. Perihelion's OS could scale to arbitrary number of transputer nodes, managing jobs and the messages between them. Taking that approach to the cloud makes a lot of sense, where applications are broken down into basic elements that replicate key pieces of a business process - and can be replicated as required to meet spikes in demand. And that's pretty much what MSR's Helios does. We're not looking at a desktop OS (unless it's a desktop running on Intel's multicore Larabee), we're looking at an OS that can scale and manage a cloud service across the many cores of an entire data centre.

Azure is the sky; will future OSes like Helios be the place where we build and navigate our own clouds?

Simon & Mary

Topic: Windows

Simon Bisson

About Simon Bisson

Simon Bisson is a freelance technology journalist. He specialises in architecture and enterprise IT. He ran one of the UK's first national ISPs and moved to writing around the time of the collapse of the first dotcom boom. He still writes code.

Mary Branscombe

About Mary Branscombe

Mary Branscombe is a freelance tech journalist. Mary has been a technology writer for nearly two decades, covering everything from early versions of Windows and Office to the first smartphones, the arrival of the web and most things inbetween.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


1 comment
Log in or register to join the discussion
  • Pipes, clouds and scarcity

    That really puts it into perspective for me Simon.... nice post. I can imagine using the 7 style library system to keep everything in view (well sort of).

    I would like to think that all the heavy, sometimes semi-automated configuration and settings data could have an almost hologhraphic and mesh like existence synchronised accross computers/servers/devices etc. Criucaly though, it would be most important to have access to this data through machines that belong to me, or that I could control.

    I've slowly been backing up files and software set ups in the most basic and easy to get to grips with part of the cloud, and that's by zipping up and using the live sky drive, or now much more importantly using <a href="https://www.mesh.com/welcome/default.aspx">live mesh</a>.

    Would want a great big pipe though, so far I would contemplate storing just some larger files up there. But moving stuff around, deleting etc, would depend on very good conections, although I'm sure the developers will bring us some cool desktop clients for quickly flicking switches and setting some pretty large movment into motion.

    As for Software As a Service, I've been testing a web based tv/audio/office/browse within cloud/type presentation based GUI.

    Upload speeds are of great concern because this system is designed to work by uploading from your desktop and running from a remote server.

    It held together quite well, but I was left wondering about all that idle desktop horse power. Maybe the way these things run can be more interchangable between server and unused horse power on the ground.

    roger andre