Although I have been privy over the years to see behind the veil at Redmond, I will be focusing primarily on the externally visible actions of Microsoft and how the industry has reacted on average – specifically in the enterprise space, where I spend most of my time.

What managers are concerned about

When there will be problem with this technology, who will support us?
How will that change when the author of the technology moves on or loses interest?
How long can we expect to be using this technology?
How long will it take to learn it? When will we recoup our investment?

Traditionally, for companies on the Microsoft platform, choosing Microsoft as their primary technology vendor has been the safe bet. As a large company, Microsoft can afford to employ support engineers. These engineers are different from the ones who wrote the technology to begin with. Also, Microsoft has 10 year support guarantees. As a result, companies expected to use the technology for at least that long. With their size, Microsoft also had the ability to create copious amounts of documentation easing learning.

To turn the common phrase, nobody got fired for choosing Microsoft.

Open source seemed like risky business, at the time.

What changed?

It started with the Composite Application Block – CAB.

This technology was put out by the Patterns and Practices (P&P) group at Microsoft. After it came out, the gears of big marketing machines at Microsoft got to work, telling the industry about this great new thing at conferences, and the Microsoft Consulting Services (MCS) folks started using it with clients. CIOs at large companies sent developers to training on CAB by the dozen.

And then CAB was dead. Sorry. Microsoft prefers the word “done” to dead.
Just like Don Box said that COM wasn’t dead, it was done.

“What about that 10 year support thing?”, asked the CIOs (among many others).

You don’t understand, said Microsoft. You see, P&P are not a product group in Microsoft. They don’t have the resources to provide that kind of support. And the rest of the company isn’t obliged to support what they put out – since they’re not a product group.

You could literally hear the collective jaw of the Microsoft part of the industry drop.

This wasn’t supposed to happen (like housing prices in the US).

And then came .NET 3.0, and things seemed to go back to normal.

There were lots of wonderful things that came with it – like LINQ, and…

Linq to Sql

This was BIG.
Finally – after ObjectSpaces was promised at PDC ‘03 and later shelved, then WinFS (same story), it had arrived.
The object-relational mapper (ORM) from Microsoft.

The marketing machine went into high gear – it was the v3 promise. Linq2Sql (L2S) came from a product group. This was serious. It was shown at conferences and user groups all over the world. Developers were sent to be trained on it.

And then Entity Framework (EF) was announced – and L2S was done.

CIOs were rubbing their eyes in disbelief. “But this is from a product group – you have to support it, right?”

Well, said Microsoft, yes. We will support it with our support org. It’s just that we won’t continue to develop new features for it in the product org. We actually have a different sub-org that will be working on EF and they’re under a different division (SQL Server) than the sub-org that made L2S.

Jaws were hitting the pavement. All that investment erased. Just like that. It turns out that support without active development doesn’t mean very much, no matter how many support engineers are involved.

But the industry picked itself back up, and got back to work on the new foundational pieces that came with .NET 3.0. If Microsoft is calling it “Foundation”, that must mean they’re committed to it.

And then came Workflow Foundation

Workflow Foundation (WF) was a dream-come-true. At last, Model-Driven Development (MDD) had come to the Microsoft platform. Drag-and-drop on a whole new level. Imagine the reuse. Imagine the maintainability. Programming at higher levels of abstraction. A marketers dream. This was the culmination of previous efforts of Whitehorse in VS2005 and the Software Factories Initiative – or so we were told.

And then came .NET 3.5 – and the new WF wasn’t backwards compatible with the old one.
And then it happened again with .NET 3.5 SP1, and again with 4.0 (no more state machine – no wait, it’s back again, but not in the box).

All those companies that had long-running workflows in production needed to manually migrate them each time.

But this had become old news to the folks using Microsoft in the enterprise.
With Microsoft – you really can’t be sure any more.

What about open source?

Well, it was beginning to look more and more stable in comparison.
Especially the larger, more established projects. Those with active development.
Log4Net. NHibernate. Castle. etc.

There was also the fact that most enterprises were heterogeneous anyway – doing both Java and .NET development. Open source tools and frameworks were common in the Java space, politically greasing the wheels for .NET OSS in those organization.

Boasting features and capabilities several years ahead of what was coming out of Microsoft, more companies gave them a chance, and were pleasantly surprised. And the virtuous cycle of OSS gained speed. With more use, they become even more stable and got even more features, driving yet more use. Blog posts about them bloomed all over the web. User group presentations were given. At a presentation I gave at TechEd Europe 2006, I used NHibernate in my demo.

OSS had crossed the chasm. No, not everybody used it, or knew of it, but a critical mass of the industry had grown to depend on it.

Microsoft’s actions over the years had done more for OSS adoption than I think many would have imagined.

On Pub/Sub, Messaging, and SOA

Interestingly enough, when the first version of WCF was still in the oven (then called Indigo) there were discussions on whether it would support publish/subscribe messaging. Here we are, 3 versions later, and still no pub/sub, but the discussions continue

Message brokers were always important for enterprises in the Java space – IBM MQ; Tibco RV; Sonic; companies were paying millions for this stuff. Microsoft had MSMQ – finally at v3 with XP and Server 2003, but still with insignificant penetration to the market. BizTalk did have a good run, though, but not so much as a message broker, more as an integration and orchestration engine, unfortunately coming late to the Enterprise Application Integration (EAI) party.

Later, the SQL Server guys came with Service Broker – messaging in the database. But you could see that their heart wasn’t in it. The API was clunky. It still didn’t have pub/sub. There was no binding available for WCF.

After some time making noise in the SOA space with Oslo, that changed as well. Oslo is now Sql Server Modeling.

I imagine that some of the adoption pick-up with NServiceBus can be attributed to the vacuum Microsoft left behind when exiting the messaging/pub-sub/soa space. The way NServiceBus aligns with the principles found in the corresponding Java technologies makes it very palatable to enterprises working with both platforms.

The fact that there’s active development, a vibrant and growing community, and even training available definitely contribute as well.

In closing

I don’t fault Microsoft for any of this. There are a million things that they could have done. Choosing to do one thing means choosing not to do many others. The decisions they made were done with the best intentions. Hindsight is 20/20 of-course.

And that’s just it – we do need to take a look back.

If you’re a manager making a technology related decision, or are working with managers in those positions, knowing the history of today’s technology can give you a more accurate representation of the risk involved in each choice. Also, understanding the vector that Microsoft has decided to take in various areas is critical, especially if you find out that your architectural choices aren’t quite aligned with some of those vectors.

In this post, I’ve tried not to take a stance on whether a certain approach (ORM, Pub/Sub, etc) is good or bad, or even getting into which cases it’s appropriate or not – just to describe Microsoft’s externally visible behavior in that space.

I hope that this short history lesson can help your organization make the right technology decisions in the future for its specific context. Your comments and thoughts are most welcome, as always.

The question of how web-based (or 3rd party) consumers can work with pub/sub based services comes up a lot.

Many developers are used to implementing web services exposing methods on them like GetAllCustomers.

When moving to pub/sub and other more loosely coupled messaging patterns, developers look to implement the same pattern, opting for something like duplex GetCustomersRequest and GetCustomersResponse. The reasoning is simple and straightforward – it is difficult to push data over the web to consumers.

However, there are still ways to disconnect the preparation of the data from its usage thus gaining many of the advantages of pub/sub.

By employing REST principles and modelling our customer list as an explicit resource, web-based consumers would simply perform regular HTTP GET operations on the URI to get the list of customers.

The resource itself could be a simple XML file – it wouldn’t need to be dynamic at all.

You can get all the scalability benefits of pub/sub for web based consumers. All you need is a bit of REST

The previously hand-drawn distributed system concepts map has already surfaced a couple of diagrams on scalability and performance.

I’m now making the full interactive environment available.

[For any class, by clicking on the '+' beside 'Advanced', you can see all the diagrams in which it takes part]

This is an ongoing, huge undertaking and your comments and suggestions are not only welcome, but absolutely necessary to take this to the next level.

Get Integrated Simplicity.