...step up as well. People will be building in a high degree of redundancy into their network provision, and that will become as important as everything else.
If you're entrusting your line of business to the cloud, you need to make sure not only the back-end is as resilient and as scalable as you need, but equally that network resilience needs to be there as well. There will be an increase in the strength of service-level provisions of network operators as well.
What else can businesses do to ensure against cloud failures?
One thing is to understand where the points of weakness or the points of concentration are and obviously, when you are architecting an application, to design as something that is going to be delivered by the cloud.
One of the aspects of our approach is that customers can use a programming model that is familiar to them in .Net, and the extensions that you can provide to make it Azure-aware are the thing to focus on.
Are private Azure clouds going to be feasible?
One of the benefits of the cloud approach is that multi-tenancy provides the kinds of economies that you can deliver back to customers. If you go from that to a dedicated cloud, you get some technology advantages when it comes to scalability and provisioning, but you're not taking advantage of multi-tenancy.
'Private cloud' is one of those terms that is used a lot, but there isn't a standard definition for it. Virtualisation from the server level upwards gives you a high degree of abstraction and privacy, and that's where the real economies come in.
But it depends on the level of abstraction you want to achieve. You can get right to the point where you've got your own datacentre running your own cloud. What you get there is the elasticity within the capacity you've got, but you do lose a lot of the economies because you still have to own all the infrastructure.
There's no doubt there will be a market for that kind of service, but it's really a question of where you want that abstraction point that creates your private cloud — and you can have it in multiple places.
What is Microsoft doing to address the issue of interoperability between Azure and other cloud services and on-premise applications?
What we've tried to do when it comes to the Azure service is that you architect applications in the same way as you would if you were just doing an in-house client-server application, for instance. When it comes to, say, SQL Azure, the database types and so on, the way you deal with the database is just the same as you would if it were in-house.
There is no doubt there will be a need to interoperate between different cloud services, and that is something we're fully committed to cooperating with. In the future, there will be the need to have the ability to, say, imbed a web service that is hosted on another cloud system.
The key question is whether there are new standards to be defined or whether the standards we have now are good enough, because what you're getting in the cloud is something that's very similar to what you would get with a standard approach. But either way, that's something that we're fully committed to participating in.
Do you have any suggestions for people who may be taking their first steps into the cloud and into Azure in particular?
I would definitely suggest taking a fairly simple existing application that's targeting the .Net framework and just to put it up there. The work involved to move it to a cloud structure is fairly trivial for a competent programmer.
That experience is very useful for organisations, not just because of the experience of how it operates when it's in the cloud, but the whole way you get it there — the various staging and testing.
One of our design goals with Azure is that you don't need to re-learn too much, so you can use the languages, frameworks and databases that you're familiar with. The great thing right now is that it's free, and so the opportunity is there now for people to dabble with it and just get comfortable with it.
