.Net Services: Microsoft's key to cloud security and Java interoperability

On April 1 Microsoft released what it dubbed the “M5” (Milestone 5) CTP (Community Technology Preview) beta of .Net Services. .Net Services are a set of

Burley Kawaskaki
Cloud
Microsoft-hosted developer tools for creating cloud-based and/or cloud-aware applications. Microsoft asserts that its cloud operating system, Azure, will be fully open, able to support any app built on any platform, via these .Net Services. Indeed, as part of Microsoft Subnet's "10 Questions For" series of Q&A interviews, Burley Kawasaki, director of developer platform product management, has gone one step further with a special message for Java Web developers. "We want Java developers to feel comfortable accessing our technology, without having to learn anything new - they can continue to leverage their existing skills and extend their existing Java apps," he said during the interview conducted on Friday. (In answer to Q4.)

This outreach comes during a time of heated debate over how cloud computing is to be different from development platforms of the past, open and interoperable from the get-go. Microsoft's competitors had banded together to create what they dubbed the Open Cloud Manifesto, leaving Microsoft out of their efforts. And today, Microsoft's longtime enterprise app rival, Oracle, has announced that it is buying Sun Microsystems for $7.4 billion.

[Note: why do you see an audio player? Click to hear the voice of Microsoft Subnet singing a song with lyrics written by Burley Kawasaki because we opened our mouth and lost a challenge, but you'll have to go to Page 3 to learn the how and why of it.]

Listen:

Microsoft Subnet: Q1: Microsoft has been promoting four major cloud initiatives: Windows Azure, SQL Services, .NET Services, and Live Services. Briefly, what's the difference between them and what is the one key thing for enterprise IT managers to understand about each?

Burley Kawasaki: All four of these are part of an overall effort to deliver the Azure Services Platform. Windows Azure is the "cloud OS", it provides the low-level resources like compute, storage, etc. On top of the cloud OS we also deliver building block services oriented at developers building apps - they can use these additional services either in a stand-alone fashion or in conjunction with Windows Azure. SQL Services provides cloud-based relational storage, Live Services provides cloud-based consumer services, etc

.NET Services is a set of hosted services that extend the existing .NET programming model to take advantage of some of the unique types of app scenarios that you can build targeting the cloud.

Microsoft Subnet: Q2: Under what circumstances would a company want to take existing .Net apps and convert them to cloud-based .Net services (instead of creating new services from scratch) and what's involved in doing that?

Burley Kawasaki: We actually think that most customers will start by taking their existing .NET apps and looking for extension opportunities - leave their existing investments in apps intact, but find ways to add new capabilities that leverage the cloud. This is part of the scenario that we address with .NET Services; we've added the additional capabilities in .NET Services to specifically make easier the challenges of providing "+" namely the "service bus" (for secure messaging across firewall from on-prem to the cloud), "access control" (to easily federate identity info across identity mechanisms), and "workflow" (to provide rules that help you route the messages as they flow across the service bus).

As part of the service bus, we provide access control capabilities that recognize also that you want to secure your messages as they cross firewall boundaries (between on and off prem), and also the ability to provide workflow that controls the flow of messages.

If you want to build new cloud apps that run in the cloud - you certainly can target that and we see a lot of Web 2.0 companies and ISVs that are doing that right now. But most traditional enterprise customers are thinking more carefully about how they extend their on-prem apps to the cloud.

To clarify, .NET is the common programming model across both on-prem and cloud. Literally the same .NET 3.5 framework is running both on-prem and in Windows Azure. .NET Services is a set of extensions - think additional pre-built patterns and capabilities - that address some of the unique challenges that developers often face when they build cloud apps.

Think of this somewhat like the old "MFC" (Microsoft Foundation Classes) of yesteryear that we provided to accelerate developers building apps. This all means that devs can take their existing skills in .NET development and apply them across into the cloud; we abstract away most of the additional considerations (e.g. crossing firewalls, long-running messaging, interop across org boundaries, etc.) that you would have to think about typically if your building a cloud app.

Microsoft Subnet: Q3: Can you give a specific example of how someone converted an existing .Net app to .Net Services, including how long it took - what's generally involved in terms of toolkit, other skills?

Burley Kawasaki: Sure, we've got one of our ISVs (S3Edge) who has done just this type of thing. They were an ISV in the manufacturing sector, had built a supply chain app for their on-prem suite. They wanted to take both their code and skills and be able to leverage this for the cloud. It was very straight-forward, they had prototypes of their cloud functionality up and running in a matter of days/weeks.

The key thing was that they were already used to building on .NET - specifically ASP.NET and WCF - so this was a programming model that was very simple for them to move and their skills also leveraged all of the right knowledge already. I should mention that S3Edge did not completely move all of their app modules - again, they targeted the ones where there was real business benefit to moving to the cloud. You have to do an analysis of where is the value - move the things that can exploit the benefit.

Microsoft Subnet: Q4: A Microsoft blogger who shall remain nameless recently said "Microsoft still isn’t offering up firm Java-for-the-cloud timetables or deliverable commitments at this point." And yet, a Java toolkit for .Net Services created by Schakra Inc., has already been released. What is Microsoft doing today for Java developers and what has been publicly promised for the future?

Burley Kawasaki: We want Java developers to feel comfortable accessing our technology, without having to learn anything new - they can continue to leverage their existing skills and extend their existing Java apps.

Most of our customers have a large investment in their on-prem apps that they are trying to leverage and extend. This includes Java, COBOL, .NET, etc. Anything you can imagine can be - and is - being used in the enterprise. So it's an important design principle for us that we have to be able to interoperate with the full heterogeneity of the enterprise.

This starts with support for the available Web services standards - things like both WS* based services, but also including RESTful services as well. If you've already adopted a standards-based approach you can access the cloud (via .NET Services) very readily. However, many customers are still moving to completely standards-based protocols - so we also provide other SDKs that give you access from various languages: Java, Ruby, .NET.. These are important to meet the developer where they are, and give them access via the language of their choice We also interop with other scenarios - a key one being interop of access control rules, such as connecting your existing identity store (Active Directory, Tivoli, Sun, etc.) so that you don't have to replicate this information. We can interoperate with this information via available standards like WS-Trust, WS-Federation, etc. We showed a great demo of this at MIX just a month ago, where we showed an app that was written on multiple clouds (Google App Engine running Python, integrating with .NET code running on Azure).

Microsoft Subnet: Q5: As you've mentioned, one of the flagship features of the new .Net Services CTP released in March is improved access control. Can you explain what's new about it and how this fits in the "Geneva" cloud identity platform?

Burley Kawasaki: Geneva is the codename for a set of the technologies we're releasing in the future, across both server (Geneva server) and framework (Geneva framework). We're complementary to those investments by also providing the 'cloud' component of this, completing the triangle. You as a developer can easily build "claims-aware" apps (using Geneva fx), easily connect/federate identity with your existing on-prem applications (using Geneva server), and if you want to connect over into the cloud (or across clouds) then .NET Services provides the cloud-based identity federation component.

We build .NET Services working very closely with the Geneva team, to apply the same claims-based identity model deeply across the technologies so that they work together very well.

Microsoft Subnet: Q6: A little over a year ago, we were all talking about Oslo and how it would have a modeling component that would ease .Net development. What's up with Oslo and has it materialized yet with .Net Services CTP?

Burley Kawasaki: We're very excited about the work that's going on with Oslo - we also just released another update to the CTP back in January, just a few months after the drop we did at PDC. Oslo is part of .NET development - I think of it as being one of the many advances that we continue to make to drive greater productivity for you if you're building .NET apps. Think about things like WPF, WF, WCF - all of these are examples of us driving higher productivity for you if you're building .NET apps. We see Oslo as providing a broad platform for building all types of apps, and helping give you greater productivity by applying metadata and model-driven techniques.

It turns out that one of the sweet spots of model-driven type development happens to be for the cloud - to really take advantage of the elasticity and scale that you can provide in the cloud, we use lots and lots of model-driven techniques under the covers in Azure. So it's only natural that we would apply our Oslo platform investments at some point to highlight the different types of cloud app scenarios that customers want to build. This is something we'll be talking more and more about throughout the year.

As you build on .NET - whether you build on-prem or in the cloud with Win Azure - you will over time increasingly apply these higher level productivity frameworks (including Oslo) as part of the way you build .NET apps.

Microsoft Subnet: Q7: We've already touched on this, but want to clarify, can you use .NET Services by itself and under what circumstances would an enterprise do so?

Burley Kawasaki: Absolutely, and many customers are. I alluded to this also in the demo we gave at MIX - we showed how you might want to run your app on Google's cloud, and simply use .NET Services as the way to connect your cloud app with existing applications. Another scenario we're seeing are more classic B2B scenario - I want to connect an on-prem app with those of my suppliers or trading partners, and use .NET Services to facilitate the easy and secure exchange of messaging.

In this last example there was no application logic running in the cloud - it was all on-prem - but with .NET services connecting the on-prem application logic.

Microsoft Subnet: Q8: If someone develops a .Net Services app and wants to share or sell it, what license can the programmer use to do so?

Burley Kawasaki: We've not yet announced any licensing terms, we're still getting feedback also from partners (both SIs and ISVs) on their requirements. Stay tuned. [Editor's Note: Microsoft has revealed some of its planned licenses for Azure.]

Microsoft Subnet: Q8: What's the business case and cost structure for moving .Net apps to the cloud? What kinds of fees should an enterprise expect to be charged and how will they be assessed?

Burley Kawasaki: These considerations are pretty much the same for anyone, so my answers here are not specific to MS. Generally enterprises are looking to change their cost structure from CAPEX (capital expenditures) to OPEX (operating expenditures), when they move to a pay-as-you-go model. They also typically are looking for ways to have greater elasticity of their infrastructure - by that I mean being able to add capacity very easily and quickly to accommodate spikes in traffic.

For customers it is something they will usually evaluate app by app. Some apps may never move to the cloud, they may decide to keep on prem for greater control, etc. Some apps they may move to the cloud for the above benefits. They will manage it like a portfolio, and we believe therefore that you need the ability to choose and move things back and forth as needs warrant it.

Microsoft Subnet: Q 9 Once a programmer develops the .Net Service for the cloud and launches it, what tools are (will be) available to manage it?

Burley Kawasaki: From a development perspective, all you need is already in Visual Studio - you can build apps using your existing tools, debug locally on your local machine, and then simply deploy into the cloud.

1 2 Page 1
Page 1 of 2
IT Salary Survey 2021: The results are in