by Dan Probert
I’ve been working with BizTalk for many, many years. From writing VB plugins for BizTalk 2000, using EDI Accelerators with BizTalk 2002, and then learning about new and seemingly mysterious patterns like sequential convoys and scatter-gather and correlation when BizTalk 2004 arrived.
BizTalk has always demanded a steep learning curve: my rule of thumb was to say that in order to be a good Integration Developer, you need experience in many different tools, technologies, and systems. How can I properly integrate BizTalk with SAP, unless I actually know how SAP works, and how you connect to it? Ideally I’ll have written or seen a BAPI or IDOC, and understand how SAP is deployed or configured. All of these thing make it easier to not only design an integration scenario, but to troubleshoot it when issues arise.
 |
In the early days of BizTalk 2004, we had the “Bloggers Guide to BizTalk” – a CHM (Compiled HTML Help) file produced by Alan Smith that collected all the known BizTalk blog posts into one file, that could be read offline |  |
| It was essential reading, as in those days information on how best to design scenarios, or fix issues, or even to install BizTalk was hard to come by. At the time, the books BizTalk Server 2004 Unleashed (SAMS, 2004, co-authored by fellow kiwi Scott Woodgate) and Professional BizTalk Server 2006 (Wrox, 2006, co-authored by Darren Jefford, Kevin Smith, and Ewan Fairweather) were nigh-on essential reading. |
 |
And then there was BizTalkGurus, started by Stephen W. Thomas in 2005: a website that syndicated content from BizTalk-related blogs all over the world, and which provided a forum for people to ask questions and have them answered by other members of the community.
In 2008, Microsoft Azure was unveiled at the Professional Developers Conference (PDC) in Los Angeles (although at the time it was described as “a version of Windows that runs over the internet” by CNET).
As I watched sessions at this year’s Integrate 2020 Remote conference, I realised how much has changed in that time, in terms of the technologies that make up the Cloud, and the new technologies we can use to deploy to either the cloud or on-premises, or even out on the “edge”.
And I was also struck by how in the midst of all this change, BizTalk has stayed somewhat static – true, there have been bolt-ons that enable cloud or hybrid scenarios, but a BizTalk App written in BizTalk 2020 would still be mostly understandable to a BizTalk Developer from 2004.
In some ways, BizTalk Developers have become the Mainframe Developers we used to make fun of (or so I understand ?) back in the early days of BizTalk – dinosaurs, clinging to outdated technology like CICS and COBOL, working on antiquated platforms. For those that contract to their companies, we might have a passing admiration for the day rates these old-timers could charge, whilst feeling sorry for them that they had to work with such old technology.
And yet, now I wonder if BizTalk Developers have become those dinosaurs, at least in part. As a contractor (at least here in the UK) you can be certain of getting a good rate if you’re an experienced BizTalk Developer, especially if you work for a large corporate that has a significant investment in BizTalk. And there is still a place for BizTalk for companies that still want their middleware on-premises, or who are wanting a hybrid solution without embracing the cloud entirely.
Suddenly we’re embracing a new Microsoft. We had 12 years to get our head around Microsoft Azure, and the increasingly agile and rapid-change announcements we see coming out of Redmond.
Now we’re in a situation where Microsoft seems to be pivoting into open source. And containerisation. And we have all these new technologies and tools and formats and acronyms to learn: K8s, Docker, Containers, YAML, Helm, Dapr, DTF, Azure Arc, Sidecar, VS Code.
We’d just gotten our heads around the fact that we could use Logic Apps and Integration Accounts to replicate *some* of the workload we do in BizTalk, but in Azure. And we were talking to management and program directors and security people about moving to the cloud, and hybrid scenarios, and security and cost etc.
And now… Logic Apps running on the Functions runtime. Logic Apps running on the Functions runtime, but connected to Dapr. And now, Logic Apps on Dapr, but in a Docker container.. deployed in a Kubernetes cluster… and managed by Azure Arc.
We’re not in Kansas anymore, Toto.
For years, we’ve been used to working with a monolithic, proprietary technology on-premises. One that is difficult, sure, but also lovable, in a way (c’mon!).
We even embraced integration in Azure: different, slightly weird, more powerful, sure, but still proprietary.
But now… GitHub. Open Source. Visual Studio Code. Developing on a Mac. Or Linux. Cloud-agnostic.
I can see a future where, as an integration Developer, I’ll write a workflow, package it to a container, deploy and manage it using Azure Arc… to AWS. Once we’re in the container world, the cloud I use doesn’t matter anymore (sorry Microsoft). I go where my customers want me to go – maybe because of price, or features, or existing contracts. The “host” is irrelevant, as long as it supports my container.
It’s a brave new world, and I think that as Mature Integration Consultants, we’re in a prime place to exploit it. It’s easy to be scared or suspicious of something we don’t understand or know. But now’s the time to learn. Get to know Kubernetes. Install Dapr on WSL2 on your Win10 box, create a Docker container and have a play running Logic Apps locally. Sign up for the Logic Apps on Functions preview. Install Visual Studio Code. Learn YAML. Learn Helm. If you’re still using TFS or TFVC source control, try switching over to GitHub.
The Integration world is a-changing, and due to our experience with integration, we’ll be able to be right at the forefront… but only if we equip ourselves with the knowledge and tools and skills that we need.
As always, we here at Affinus are always willing to offer advice or guidance on any of this, or even just to answer questions.
All of this is another steep learning curve. But remember the first time you tried developing something in BizTalk. And how difficult it could be. It took a while to crack open that mechanical fruit to get to the goodness. This new world is like that. Now is the time to change.
If you want to discuss this in more detail, contact us. We’re always happy to talk.
Previous Post Back to Blog Next Post