Q&A
Cloud Connector
Microsoft's Robert Wahbe on Azure and S+S applications.
Now that Microsoft has rolled out its cloud-computing strategy, the company is hoping developers will start to explore the Azure Services Platform and think about how to build applications that live in the Software plus Services (S+S) world.
A key evangelist on that front is Robert Wahbe, corporate vice president of Microsoft's Connected Systems Division. Wahbe runs the company's engineering teams that are charged with delivering its Web services and modeling platforms. The editors of
RDN sat down with Wahbe at the recent Microsoft Professional Developers Conference (PDC) to discuss Azure and what impact it will have on the Microsoft developer ecosystem.
 |
"You can take Visual Studio and .NET Framework and build an ASP.NET app, and you can decide to deploy that locally, or you can decide to deploy that to Windows Azure." |
| Robert Wahbe, Corporate Vice President, Connected Systems Division, Microsoft |
To what extent is Windows Azure based on Hyper-V and to what extent are we looking at a whole new set of technologies?
Windows Azure is a natural evolution of our platform. We think it's going to have a long-term radical impact with customers, partners and developers, but it's a natural evolution. It takes what we have today -- from the phone to the desktop to the server -- and brings that to the cloud. It's built foundationally on top of Windows Server 2008 and .NET Framework. We have millions of developers on top of Visual Studio and on top of .NET Framework, and they can take the vast majority of their skill set and build apps the way they have been today. They can deploy those on the premises.
So you're saying developers can write to the Windows cloud, aka Azure apps, and they'll run on Windows Server on-premises? That logic can be redeployed to Azure?
The key thing -- and Ray [Ozzie, Microsoft's chief software architect] did mention this [during his PDC keynote] -- right now, many applications aren't built with the scale-out in mind from the beginning. The notion of stateless front-ends being able to scale out, both across the data center and across data centers requires that you make sure you have the right architectural model. Microsoft will be trying hard to make sure we have the patterns and practices available to developers to get those models [so that they] can be brought onto the premises. As you write your applications in a scale-out model from the premises, they can be brought into Windows Azure.
The example we showed was a situation where you can take Visual Studio and .NET Framework and build an ASP.NET app, and you can decide to deploy that locally, or you can decide to deploy that to Windows Azure. The only thing you have to do when you go to Windows Azure is to specify some additional metadata. So you have to specify how many instances am I going to run on, and what kind of SLA am I looking for -- that kind of metadata. Then Windows Azure can take that and implement that correctly.
How do they specify that metadata?
Right now -- to the core -- it's in an .XML file. That's a great example of an executable model, and Windows Azure understands that model to its toes. So it's a model, and it delivers that. You can write those models in 'Oslo' using the DSL written in 'M,' targeting Windows Azure in those models.
So there's a natural fit here for applications developed in Oslo?
Yes, because Oslo is about helping you write applications more productively. You can write any kind of application, including cloud. You can also write server applications and client applications. But we're definitely working hard on the models for the cloud as well.
What challenges might be awaiting dev shops? What sort of skills do they need to either discover or refine as they move to a services-aware, cloud-aware application?
You've got to take a lot of your skill set, a lot of your practices -- whether it be the development methodology you use around ALM, using TFS [Team Foundation Server] -- a lot of that just carries forward. Because at the end of the day, you're writing code, and you're deploying that code. Windows Azure provides a new deployment target at a fundamental level, so there's a lot that's similar.
A couple of things are new. There are a lot of new services that developers are going to need to learn in order to see if they make sense on their solutions. One example: If you were going to hook up two businesses together with some sort of business-to-business messaging application, we have a lot of technology that makes that easy -- Windows Communication Foundation, these kinds of things. But now you need to ask yourself: 'Does it make sense for me to use the Azure platform and the service bus, which is a part of .NET services?' And you're going have to learn what the pros and cons are if you're adding it to your solutions. That provides you with an out-of-the-box, Internet-scale, pub-sub solution that traverses firewalls. That's very compelling.
On the other side, you also need to start thinking about some new issues. You might be in a regulated industry where there are certain requirements on how the data is transmitted, what the encryption is, what the political jurisdictions are ... those kinds of things. As you're thinking about incorporating the cloud into your solutions, you're going to need to take those things into account. This is one of the drivers for why a platform is S+S. Every developer has a unique set of needs, and they need to choose differently between how much they're doing in the cloud and how much they're doing on the premises. So depending on regulatory, compliance, whatever assets they have and their scale requirements, it may be an opportunity to learn something new.
Are we looking at plug-ins to Visual Studio or new development interfaces to service-enable some of these things? Are we bringing more development resources to the table?
You're going to see some very natural extensions of what's in Visual Studio today. For example, you'll see new project types. I wouldn't call that a new tool ... I'd call it a fairly natural extension to the existing tools. You'll see new properties in the property descriptions of solutions. So you can say things like: 'How much scale-out do I want? Do I want this to run in multiple data centers?' Those kinds of things. If you look at the portals for Windows Azure and the Azure Services Platform, there are new kinds of tools that are great for IT pros to look at utilization, to look at what the load is on their applications ... those kinds of things.
What can we expect in terms of Oslo uptake and some of the stuff that developers are going to have to grasp as they start developing into the Azure space?
We want to get bits into the hands of developers as early as we possibly can. We don't take the attitude that we're going to wait until we're basically close to shipping, and then spring it on people. We want to get a CTP [community technology preview] out early and engage in that conversation. Now we can get this thing out broadly, get the feedback, and I think for me, that's the most powerful way to develop a platform. If you're going to build a platform in a vacuum, it's very hard to get it right. You need to have developers pounding on it, telling you what you're doing right and what you're doing wrong.
Given the uncertain time frame of Azure, are some of your rivals like Amazon and Google gaining a lot of early share? How will you deal with the competitive landscape?
The place to start with Amazon is [that] they're a partner. So they've licensed Windows, they've licensed SQL, and we have shared partners. What Amazon is doing, like traditional hosters, is they're taking a lot of the complexity out for our mutual customers around hardware. The heavy lifting that a developer has to do to take that and then build a scale-out service in the cloud and across data centers -- that's left to the developer.
We have base compute and base storage, which is the foundation of everything we're doing with Windows Azure, but then we have these higher-level services like the database in the cloud. We have these user services for photos, contacts and blogs, and these kinds of things with the live services. We have Internet-scale building-block services with .NET services, and we'll be rolling out CRM Services and SharePoint Services. We have these higher-level things so that now developers can stand on the backs of thousands of engineering years as they're building the solution. They don't have to build an Internet-scale pub-sub system. They don't have to have a new way to do social networking and contacts. They don't have to have reporting services that they have to build up themselves.
Google is a very limited offering. It's a single programming language. It's a particular part of the Web application. You can't do the back-end processing. You don't have a full database back there. You don't have a lot of the things you might need to build an end-to-end application. You can't even take too long to respond to the Web request or they'll shut you down. It's a hobby.
Obviously you have the Microsoft-hosted monoliths in play here. Will an enterprise be able to host their own cloud? Will there be third-party partners doing that as well?
I want to be very clear on this. We built Azure on top of Windows Server and on top of .NET Framework. As we learn, we're going to take that innovation and bring it back to Windows Server. And then as we innovate in Windows Server, we'll bring that back to Azure. And we absolutely support the choice, depending on whether it's your data center, your cloud, your personal enterprise cloud or the Microsoft Azure cloud. But the way you'll get your cloud is that you'll buy Windows Server, you'll buy SQL Server, you'll buy the existing premises platform, and we'll continue to move that innovation ilaterally.
But in terms of the actual physical hosting of machines, if I'm an enterprise and I want to provide these cloud-based Azure services to my users or business partners, I can have my own private cloud?
With Windows Server, not with Azure. The Azure Services Platform, SQL Services, Live Services -- those are hosted exclusively in the Microsoft data center. You get at them on Microsoft's platform and other platforms, because they're all exposed on Internet standards.
Other platforms meaning?
Other operating systems, other computing platforms, other hosters that are exposed to Internet standards -- REST, SOAP and XML.
So only Microsoft will be hosting Azure?
Only Microsoft is hosting Azure, but anybody can host our core app platform, which is Windows Server and SQL Server. And again, the innovations are going to flow in both directions. We're going to innovate in Windows Server -- that will move up to Azure -- and we'll innovate in Azure.
We talk about the cost of computing, but what impact will all this have on the cost of development and the management of development processes?
We think we're removing complexities out of all layers of the stack by doing this in the cloud for you. For example, we'll automatically do all of the configuration so you can get load-balancing across all of your instances. We'll make sure that the data is replicated both for efficiency and also for reliability, both across an individual data center and across multiple data centers. So we think that by doing that, you can now focus much more on what your app is and less on all that application infrastructure. My guess is that, to the extent that the cloud is appropriate, it will make it much simpler for you to build your applications as a developer, and then you can also use premises as well.
What's your advice for preparation now going though 2010?
I think the call to action is to start engaging in a conversation about the cloud and about Azure. Download the SDKs, get free accounts, start playing with it, start giving us feedback. That way we can make sure that what we deliver is what [development managers] need. Number two is to start thinking about what's appropriate for a hosted solution, and what's appropriate for premises. Start getting those kinds of development practices in place, so as these roll out, there's an easier way to take advantage of the new services. It's new patterns and practices -- new best practices.