X
Tech

Pipes, clouds and scarcity

Why does Microsoft call its cloud computing platform Azure? After all, a blue sky doesn't actually have any clouds in.
Written by Simon Bisson, Contributor and  Mary Branscombe, Contributor

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

Editorial standards