I was reading an interesting blog post today called Will Dublin Replace BizTalk?
It got me thinking more about this and I wrote up the response below. I would love to hear other peoples comments and thoughts on this. I see a clear separation on when you would use BizTalk vs when you would use Dublin. I see a great story going forward with both technologies working together.
I welcome comments and feedback on this.
Comment on “Will Dublin Replace BizTalk?” blog post:
“I like your article on Dublin and BizTalk but wanted to comment on a few parts.
As someone who makes a living working with BizTalk Server my ears perk up when I hear “it is going away”. I heard this same kind of talk three years ago when Microsoft introduced Workflow in .Net 3.0. I for one was confused about how Workflow would fit in with BizTalk. And now, BizTalk is bigger and stronger than ever.
Why? Because it does a great job inside the enterprise for the scenarios it is designed to address such as system and application integration, connectivity, transformation, and monitoring, just to name a few.
What I see Dublin (and .Net 4.0) doing is taking some of the best features of BizTalk and making them accessible to other parts of the enterprise that might not have requirements that call for a full and robust Integration Server. With Dublin specifically, it is the management and monitory concepts from BizTalk that we can see inside the Dublin code from PDC.
Will there be scenarios that now make more sense in a Dublin environment than BizTalk? Of course. Will all scenarios fit into Dublin – not a chance.
Even today I hear the question, “Why would we pay for BizTalk?” And for some customers BizTalk is not the right answer. For those customers they will now have Dublin to look at rather than having to custom build a solution.
It often comes down to a cost to buy vs. cost to build analysis. On an individual project basis this sometimes becomes a difficult decision. When you think enterprise wide, typically the cost to buy a supportable product with a core set of features is the better answer. With BizTalk, you get adapters, high availability, robust development tools, EDI, RFID, flat file parsing, administration, BAM, etc. While some of these items are being moved further down into the stack, not all of them will be.
The buy vs. build analysis will become more difficult. I think that is a good thing. The end goal is to do more with less and to lower the cost for consistently delivering supportable and maintainable code that meets the requirements. I think Dublin (and .Net 4.0) helps us down that road. In my mind, I’ll always see a need for BizTalk and will continue to recommend it to my clients as a core component in the enterprise when it makes sense.
I do not foresee a world without BizTalk, but I am excited about the world with options that include BizTalk and Dublin.
If you are looking for more information on Dublin, I have a screen cast available (https://www.stephenwthomas.com/media/p/21919.aspx) and a high level visual review of Dublin (http://www.biztalkgurus.com/blogs/biztalk/archive/2008/11/10/first-look-screen-shots-of-windows-application-server-dublin.aspx) available on my web site.
Stephen W. Thomas
www.BizTalkGurus.com”
Thanks for the post, Stephen!
I agree for the most part – but I’ve only read and seen what I can online. I’ve not dug into the VPC yet and I hope that, and some labs + posts like yours, help me make up my own mind about it!
I think most organizations, if not all, need BizTalk (or something like it). They just might not realize it until they’ve invested so much into their custom implementations that it is difficult to change direction. Like you said, its looked at from a project by project (or even cost center) basis and not from an enterprise perspective. They wind up spending time building up that ‘application infrastructure’ that its difficult to get away.
Dublin makes this ‘BizTalk’ need even less obvious, and I think in the end, a somewhat of a harder sell for BizTalk. Some of the core features of BizTalk I *think* I’m seeing turning up in Dublin. So, if I get 80% of my needs met by Dublin, can I offset the other 20% with custom work v. BizTalk licenses?
Do you think that might be the question that comes up more often than not?
If so, I could see organizations erring on the side of caution and building their business processes ontop of Dublin instead of BizTalk and maybe relying on 3rd parties to fulfill their specific integration need (e.g. SAP adapter).
Good to hear from you Zach. Hope all is well back in Allen.
To your point, giving you that extra 20% of functionality is what makes it worth the price of the license. That might be the mapper, the easy of high availability, the adapters, RFID, EDI, whatever is bundled in the SKU that makes it worth it to you. This will vary by project, client, and organization.
You are right though, if people do not think enterprise wise Dublin may look more attractive. Again, I think it all depends on the scenario. For Enterprise Application and System Integration, I cannot picture a scenario that makes Dublin look better than BizTalk.
It is sometimes hard to generalize since every project if different.
I have a real word example of a Dublin scenario. We recently moved some .net 3.0 workflows into BizTalk because we did not have a scalable, supportable host. While these workflows work well in BizTalk, running them in a workflow host would have been acceptable given they are simple file processing logic, i.e. not integration and somewhat over kill for BizTalk. If we would have Dublin, we could have kept these in workflow and free up BizTalk processing for more critical integration task.
I look forward to hearing more about your thoughts of Dublin once you get to crack open the VPC.
Stephen W. Thomas
Thanks for the great article Stephen. Lets not forget SQL Server Integration Services here; if anything, that is a lot more like BizTalk in terms of “adapters” and mapping capabilities – but it has not replaced BizTalk, it has enhanced it by providing an alternative.
I think the same will be true for Dublin. However, there is a risk that Dublin will be viewed as the path of least resistance because it is just “there” and requires no additional license fee. Therefore companies may just add to it or buy in the individual components they need to mimic a counterpart BizTalk component rather than buy BizTalk.
I am really looking forward to Dublin as it is really going to enhance the kind of things I can do as a developer. I read that some of the features planned are “Powershell” activities – that would be so cool.
McGeeky
Post around "will Dublin replace BizTalk?". http://www.biztalkgurus.com/blogs/biztalk/archive
Post around "will Dublin replace BizTalk?". http://www.biztalkgurus.com/blogs/biztalk/archive
That is a great comparison around SQL Integration Services impact on BizTalk. Most clients I work with use BizTalk and SSIS together in the enterprise depending on those specific tasks they are doing. I think we will see the same with Dublin.
I can see the risk of someone using Dublin due to it is the path of least resistance. I think Microsoft and the community will have enough information available to help customer make an informed decision (not necessarily the %u201cright%u201d choice). I thought the same thing when Workflow 3.0 came out. I thought people would always go for the cheaper workflow solution and custom build missing pieces. While I am sure this has happened, I have not seen it.
Stephen W. Thomas
Hello, why is it easier to make biztalk high available than dublin. the persistance datbase is a SQL Server database exacly like MsgBox for biztalk, right. Would’nt we achive a high availiable platform creating a Passive/Active SQL Server cluster. Ok in biztalk you have the biztalk host cluster functionality but that equals running two instances of a Dublin Service and a failover-process.
For some customers the cost is the issue I dont know but running 2 cpu’s with biztalk and a couple of standard editions will land at over 250000$. I dont know the cost of using dublin instead. I don’t know just thinking.
The core difference in terms of high availability is the core publish and subscribe architecture of BizTalk. This allows for a simple central database with the easy ability to add new servers to the group. To join the group, you must use the central publish and subscript database.
In Dublin, it is not required to have a central database. Not everything needs to have persistence and setting up persistence is configuration. This changes the high availability storey. For scenarios that need persistence a BizTalk-Like scale out store will kind of exist and a SQL cluster will achieve HA. Remember though, we are not pub-sub. Without persistence, high availability may be as simple as a load balancer. The point is, it depends on the scenarios and you have the flexibility to set it up as you need to.
Dublin will be available as a download to Windows Server and other OS%u2019s. Thus, I do not think it will have a separate price. (i.e. it is included with windows). That will be a strong selling point verses a $25k per CPU license.
Your Thoughts?
Stephen W. Thomas
I’ve worked with BizTalk and WCF\WF since the beta builds (BTS 2004). I thought I’d add my 2 cents, these days I tend not to be too vocal on blogs etc.
I have just finished delivering a SOA Management Platform and Framework IIS 7.5\AppFabric\WCF 4.0 only took me 3 months which was nice. I did however write one of these 4 years ago when WCF was first released.
AppFabric is a Web Services & Workflow App Server not an Integration Toolset I think we all agree on that one. Both have their own niche.
Working with AppFabric I got the feeling that it could have been so much more, but hopefully the following features will be addressed soon (note no features are integration ones):
-Comprehensive Web Farm Management v1 is a single-node solution
-Proper Impact Analysis
-SOA Network Diagramming
-Out of the box Managed WS Discovery
-Proper Query Builder for the Monitoring DB the current one needs a lot of work IMO
-Service Virtualisation (Note talking to MS in Redmond & on the forums it seems clear the MSE feature set will be absorbed by AppFabric over time)
-More out of the box cross cutting concerns
-Dynamic loading of WCF behaviours at runtime
-Operation Behaviour configuration
That aside in the last two months I have seen 3 organisations choose this platform over BizTalk. Both were looked at as alternatives. From talking\listening to them I hear the following reasons:
-License cost (obviously)
-Developer cost they see .Net 4.0 as an easier cheaper skill set to acquire
-Operational cost
-Uncertainty where BTS is heading, view that AppFabric is the future
-Some it seemed to be the type of organisation: these guys said they didn’t require the robustness of BTS (they were Insurance, Ports)
-Some had the view that integration isn’t as big a issue as SOA in their businesses, they would use BTS if they needed an isolated integration app but services were enterprise wide
-One didn’t like the experience they had gotten from implementing BTS apps in their organisation in the past
Well those were the main ones. I was suprised when I asked “What about using BTS to decouple from your legacy apps?” the response was “we can do that with services”.
These are only 3 organisations but it’s interesting none the less. Looks like there’s a new kid on the block though.
Rob Addis
On the BizTalk RoadMap page: http://www.microsoft.com/biztalk/en/us/roadmap.aspx
The following feature of BizTalk 2010: “Easy use of mapper and LOB Adapters in WF Designer for AppFabric Applications”.
To me that means the direction MS is heading is to put BizTalks’ integration feature set into AppFabric = AppFabric will superseed BizTalk 2006.
Thoughts?