Microsoft’s Strategy of “Framework First”, “Host Second”

I’ll say up front that this post is more of just thoughts in my head vs. any deep insight. 

It hit me on Friday (as a result of a discussion list I’m on) that many of the recent additions to Microsoft’s application platform portfolio are first released as frameworks, and only later are afforded a proper hosting environment.

We saw this a few years ago with Windows Workflow, and to a lesser extent, Windows Communication Foundation.  In both cases, nearly all demonstration showed a form of self-hosting, primarily because that was the most flexible development choice you had.  However, it was also the most work and least enterprise-ready choice you had.  With WCF, you could host in IIS, but it hardly provided any rich configuration or management of services.

Here in 2010, we finally get a legitimate host for both WCF and WF in the form of the Windows Server AppFabric (“Dublin”) environment.  This should make the story for WF and WCF significantly more compelling. But we’re in the midst of two new platform technologies from Microsoft that also have less than stellar “host” providers.  With the Windows Azure AppFabric Service Bus, you can host on-premise endpoints and enable a secure, cloud-based relay for external consumers.  Really great stuff.  But, so far, there is no fantastic story for hosting these Service Bus endpoints on-premise.  It’s my understanding that the IIS story is incomplete, so you either self-host it (Windows Service, etc) or even use something like BizTalk to host it. 

We also have StreamInsight about to come out.  This is Microsoft’s first foray into the Complex Event Processing space, and StreamInsight looks promising.  But in reality, you’re getting a toolkit and engine.  There’s no story (yet) around a centrally managed, load balanced, highly available enterprise server to host the engine and its queries.  Or at least I haven’t seen it.  Maybe I missed it.

I wonder what this will do to adoption of these two new technologies.  Most anyone will admit that uptake of WCF and WF has been slow (but steady), and that can’t be entirely attributed to the hosting story, but I’m sure in WF’s case, it didn’t help.

I can partially understand the Microsoft strategy here.  If the underlying technology isn’t fully baked, having a kick-ass host doesn’t help much.  But, you could also stagger the release of capabilities in exchange for having day-1 access to an enterprise-ready container.

Do you think that you’d be less likely to deploy StreamInsight or Azure Service Bus endpoints without a fully-functional vendor-provided hosting environment?

Share



Categories: Cloud, StreamInsight, WCF/WF, Windows Azure App Fabric

9 replies

  1. Nice post Richard. With regard to Service Bus, I heard Ron Jacobs on DotNetRocks indicating that there are some plans for bringing Service Bus on premise as well (sometime in the not too distant future) and I would surmise that Windows Server AppFabric would provide the host process as an alternative to the low end custom host or high(est) end Biztalk host. With the eventual addition of Server AppFabric hosting and Caching into Azure , the story would be better in terms of cross-premise solutions.

    Cheers,
    Benjy

    Cheers,
    benjy

  2. Richard, for StreamInsight we were expecting more a product than a framework. Based on what I saw and played with, it’s lacking tooling and hosting environments. Everything is there but would require a bit too much effort to make efficient use of it (at least for us).

    Chris

  3. Hi Richard,

    I think you have hit a good point, but I think from a business strategy perspective as much as some of us complain about it, its probably the right road for Microsoft to take.

    For example it WCF and WF were usable products where customers could get value from them without the host. It proves the concepts they offer and you get lots of feedback about the direction they need to go in, eg with WF there are significant changes in 4.0. I think if Microsoft had brought out a WF host before now they would have had the risk that it wasnt very good or that they needed to make big changes to it before WF became more established. This could have really affected the roadmap of WF and delayed WF 4.0.

    I dont think the story with WCF is quite the same as IIS has always been a good enough host.

    Another example of this could also be Oslo. The language/repository etc came out before the tools which would have really driven adoption such as a really good interface and people building applications around it. We know Oslo has kind of stalled and isnt the big deal it was a year or two ago so maybe the initial feedback on the “framework” showed it wasnt the right time to invest in and really push for the things that would drive adoption.

    All opinion based on observation and few concrete facts so happy to be shot down by anyone more knowledgable who disagrees

    Mike

    • The way I understand it, our strategy has always been about depth in the platform which consequently gives us a lot of reach and we then get ISV’s and partners to build the tooling and products on top of the platform/framework. Over time though as we see common use cases (and sometimes common tooling) emerge, those get added into the platform(and with the tooling its often the least common denominator otherwise we would end up cannibalising our own ecosystem.) This then has the effect of raising the bar for ISVs and partners. WF is a good example of this. No one is going to dare offer a commercial bare bones workflow anymore (such offerings were rampant pre-WF) when its already available for free (ok, WF4 is not bare bones anymore). With WCF (and especially WF+WCF) just hosting in WAS for non HTTP communication was a killer in terms of coding for all the management etc which necessitated Windows Server AppFabric.
      But of course, none of this actually helps a V1 adopter🙂 and I would have thought that with StreamInsight, taking on the CEP market necessitates a proper product not a framework so it is rather disappointing.

      Just my 2p,
      Benjy

  4. I believe that’s the right way to implement these technologies. For example, in BizTalk, the strong dependency on the host can be a major annoyance (slows down development/testing, reduces flexibility), so I’m glad to see newer frameworks being released without any dependency on the host. A good “side effect” of this strategy is that the framework is decoupled from the host “by design”.

    For example, first releasing WCF without a host allows integrating the technology into various hosting environments (BizTalk, IIS, Sharepoint, other proprietary solution-specific host). This is probably what allowed having WCF adapters for BizTalk in the first place. If WCF had first been released as a component of Dublin/AppFabric, I’m not sure it would have also been integrated into BizTalk.

    It’s true that it can slow down adoption of the technology, but:
    – it can still be used in projects that already have their own scalable/reliable hosting environments (or in projects that don’t need such an environment)

    – it can be integrated in various Microsoft technologies, instead of forcing each technology to reinvent its own communication/pub-sub/workflow/CEP/security/… implementation

    – once a full product with full hosting becomes available, it will be more mature, easier to work with, more testable, more flexible to be integrated into various solutions…. and therefore more likely to be recommended/selected as a solution

  5. Hi Richard,
    Very good points highlighted in the Post. For the exposing end points in the service bus for in-premises services you need to create a host – you can’t use IIS as host, as the App fabric service bus requires a connection to be initiated by both ends of the communication. The Windows Azure platform AppFabric Service Bus bindings do not support IIS/WAS activation at this time. Most common way is to host the service end point using windows service which Richard has already mentioned. Using BizTalk for hosting the service end point in service bus does not seem to be good value proposition, unless you already have biz talk already sitting in your environment.

    Regards
    Amol Gote (MSFT)

  6. Hi Richard,

    Regarding StreamInsight hosting, from what I understand, hosting model is very flexible and you can even host it on WCF. You could extend WCF to then use Windows server Appfabric on top of IIS. This will provide you with monitoring and persistence tools. You may even use Biztalk as a host for queries and data streams and use a client to trigger the queries.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: