Q&A: Azure evangelist tackles cloud doubts
As Microsoft spells out the first service terms and pricing for its Azure development and hosting platform, ZDNet UK spoke to Mark Taylor, the company's director of developer and platform evangelism.
We quizzed Taylor about issues ranging from risk and resilience to private clouds and interoperability.
Microsoft's Mark Taylor
(Credit: ZDNet UK)
Q: When Azure becomes available in November, what will Microsoft be doing to convince people it is worth taking up?
Taylor: Since last November, we have been running our CTP [Community Technology Preview] program, which provides the ability to use Azure without paying for it. That will remain free until November when we go into commercial mode. Organizations can put applications up there and see how it goes. Many thousands worldwide are trying before they buy.
From November, the beauty of the pay-as-you-go model is that organizations can put up applications without having to make a substantial upfront commitment. As they get a better sense of their predicted volumes, they can move to a more formal arrangement.
Once the full Microsoft marketing muscle gets behind Azure to push uptake, what sort of provisions will you have in place to cope with surges in demand, if a service suddenly proves unexpectedly popular?
Taylor: The architecture we've built out so far has a vast amount of redundancy in it, and we're confident we can deliver against our service levels for the predicted volumes that we have come up with. We've got an aggressive program to continue to expand in terms of data centers and the capability within data centers.
A big chunk of the data center we have in Dublin looks like a loading dock from a supermarket. We have the ability to reverse containers in -- the power and the taps are there -- and they just become part of the data center. The ability to scale very rapidly without having to build new facilities has been a real core part of the data center strategy. The cost and agility we can take from that approach will serve us very well.
In your Azure service-level agreements (SLAs), you're offering credits against failure to meet certain uptime thresholds -- effectively credits to compensate for a customer's potential loss of business. How do think those guarantees match up to the risks that businesses are taking in moving to the cloud?
Taylor: If you have a failure, it depends where the failure is. We provide the platform, the storage, the connectivity. A failure within an application, for instance, would have a similar consequence if it was running in a traditional infrastructure.
The cloud industry is a new one. As we evolve, as we learn, as we understand -- and this is an industry-wide issue -- what the right kind of commercial arrangements are, then I'm quite sure our SLAs along with all the others will evolve to accommodate that.
This is a new industry and a new approach to IT, and we are all learning. I'd be amazed if we don't see an evolution in terms of resilience and geographic location of data.
In the same way, I imagine we'll continue to evolve the contractual offerings, service levels and pricing models that we're coming out with initially. Competition will always drive that, as will pragmatic experience.
What can you do to reassure people, especially when the link between the customer and Azure may not be in your hands?
Taylor: That's a very good point. The network between the cloud and the end user becomes a point of failure like everything else. What will happen -- we're seeing it now with organizations such as Akamai and Limelight with streaming -- with the increased dependency on public networks, we'll see the network operators 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?
Taylor: 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?
Taylor: 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. Virtualization 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 data center 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?
Taylor: 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?
Taylor: 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 organizations, 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 relearn 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.
Toby Wolpe of ZDNet UK reported from London.
"In your Azure service-level agreements (SLAs), you're offering credits against failure to meet certain uptime thresholds..."
IMHO, you should have asked him specifically to spell out the diffs between "scheduled downtime" (e.g. patch reboots), and "accidental downtime".
Microsoft once touted "five nines", but was only able to do it because they never counted the mandatory reboots against the availability figure. They didn't bother to inform the public about that little fudge-job (they discounted them as "scheduled downtimes" and therefore marked them exempt from the auditing... you really had to dig down to find that out).
I mean, if you're a talking head out touting SLAs, then how about not glossing over the gritty parts for those of us who have to live with the results, eh?
Matt Rogers @ Microsoft
twitter.com/mattrogerstx
I am curious - will this be noted in the contracts as well? (at least insofar as spelling out what defines scheduled downtime vs. the unexpected in the SLA?)
- by BernardManouvrier July 23, 2009 10:14 AM PDT
- I can?t fully agree with Mark on the notion that in a dedicated cloud environment you?re not taking advantage of multi-tenancy. If you create a dedicated cloud, it?s mostly because you want to provide a shared environment to several different business units within a company. The driver is cost reduction, and multi-tenancy fulfills its role in this context. So even if you?re not reducing costs as much as in a ?public? cloud approach, the resulting cost effectiveness is still very attractive.
- Like this Reply to this comment
-
(5 Comments)Bernard Manouvrier
Chief Architect
Axway