If you want the full gory details, check out the .NET Services team blog post here. What follows below are some of the things that I think are most crucial to understand both for new developers and for developers unfortunate enough to be in a position of having to migrate a lot of code. Quite possibly the single most important thing to note is this:
If you bought a book on Windows Azure that has already been released or will be released within the next month or two, it is out of date and completely irrelevant. PDC (along with the changes I'm going to outline below) will substantially change all of the Azure offerings.
I've trimmed a little bit because some of the breaking changes are fairly minor and don't have too much impact on developers. Here is the list:
- Portal address change. This is an easy enough fix and a simple find-and-replace if you've got any code that uses that portal address.
- Solution region migration. Some solutions when migrated to the new version of .NET Services might end up hosted in a different geographical region than before. This isn't all that big of a deal (for most of us).
- Queues Are Being Removed. This is huge. In the current version of .NET Services, you can use queues as a way of sending reliable, durable messages between the cloud and on-premise applications without the other endpoint being physically connected. This is a huge change. A new concept called Message Buffers are being introduced. I don't have all that much information on them but it looks as though the message buffers are essentially transient queues. You send a message to a buffer and it'll hang out in the buffer while the other end steadily pulls messages out of the buffer. A key point they make is that if you're looking for durable, reliable, persisted messages between service bus endpoints, you might want to look at using Azure Storage. As painful as it is to see queues go, I think this is a good move. Azure storage already has Queues, and they are robust and powerful. If the reason you were using Queues was to keep from overloading an endpoint with too many messages, the message buffer is your new tool of choice. If you were using Queues so that you could send messages while the polling end was offline, then you're probably going to need to concoct something involving an Azure Storage queue.
- Routers Are Being Removed. This is also huge, though slightly less huge than queues. The router concept never really "gelled" with me to begin with - I couldn't quite figure out how best to use it. Now that they're being removed and there will be some samples on how to do things like load balancing and targeted delivery, architectural decisions in this area should become easier to make.
- Relay Bindings are now secure (HTTPS) by default. You can override this behavior but there's very little reason to do so unless you are specifically trying to get your security information stolen.
- Service Namespace. Now instead of the solution name being the hostname of your *.servicebus.windows.net server, you will be able to choose something called the service namespace and have that be the hostname prefix, e.g. (namespace).servicebus.windows.net. This has low impact but is actually very useful.
- TransportClientCredentialType is being limited. Transport client credentials can no longer include X509 certificates, username/password combinations, or CardSpace cards.
- TcpRelayConnectionMode.Direct will be removed. This bugs me a little bit because way WAY back when Azure was first unveiled to the public, I remembered talking to someone who said that we'd be able to use the service bus to establish direct connections between two peers both of whom were behind firewalls. This is no longer a possibility, but I can see the reasoning behind it and, quite frankly, my particular use case for this feature was really niche-y.
- Service publishing feed now matches transport. This is handy and makes things a little more straightforward. For those who don't know, a service publishing feed is basically an Atom feed that shows all of the endpoints on your service bus service that have indicated they want their presence known publicly. In other words, I could hit the service publishing feed and get a list of all connected endpoints. That one ability is ridiculously powerful and is not getting nearly enough hype for the number of scenarios it enables.
- WSHttpRelayBinding has been removed. I'm not gonna miss this one bit as I never used it.
- WS2007FederationHttpRelayBinding removed. Again, not gonna miss it.
- Solution credentials replaced with issuer credentials in Access Control Service. This one is also quite big. Today, you can use a username/password combo, an X509 cert, or a CardSpace card to request tokens from the STS. As of Thursday, you're going to need an issuer credential (issuer key and issuer name). In addition, we're going to have to upload X509 certs to the portal to allow for SAML token requests. I will probably be doing a blog post on this once I get more information because this one is totally game changing and will halt development workflow as it stands now and totally change it after Thursday.
-
WS-Trust STS replaced with Web Resource Authorization Protocol (WRAP) STS
- Yes, I made this one gigantic. Why? Ding dong the witch is dead! The wicked witch is dead! WRAP is RESTful people. WS-Trust is EVIL people. Enjoy. We've all just been given a shiny cupcake with a frosting of awesome on top. - Access Control Service data will not be migrated. This means if you're one of those crazy early adopters and you've already written a complete app on the existing ACS - get your data backed up and saved somewhere now. It will be deleted on Thursday morning!
- Access Control Management Portal is being replaced with a command-line tool. I know some of you might be thinking, dammit! But I see this as a good thing. It's an absolute pain in the ass to stop what I'm doing and click through 8 billion links (including the 500,000,000,000,000 redirects involved with a Windows Live ID login) just to go tweak some small setting. I could probably take 20 minutes to rig up a couple .cmd files to do regular ACM tasks that are specific to my app and be done with it. This is going to be a big productivity gain, even though we lose some flashy web-based GUI.
Here's the bottom line:
Windows Azure (including Azure Storage, SQL Azure, and .NET Services) is maturing. It is moving away from being an experiment and moving toward a product that can sustain regular income and regular usage and the 90% customer usage scenarios. As a result, they're going to break changes and add features and shut off lame or ineffective or almost-never-used features.