Last week I’ve attended the Integrate conference once again. It was my 5th time attending the conference, and the 4th time I’ve participate as a speaker.
But Integrate 2020 was quite a different experience from the last years. Dubbed Integrate 2020 Remote, to reflect the fact that was yet another event that had to adapt to the pandemic reality that assaulted the planet since the end of last year. Kovai, the company formerly know as BizTalk 360, and the event organizer since its inception in 2012, took some time to decide that the event would go ahead, but when decided that it would be in a new format, didn’t pull any stops to get it running. With almost 1000 online attendees – which is impressive for a paid event, Integrate 2020 had 28 speakers, between Microsoft Program Managers and Microsoft MVPs and as many technical sessions distributed across three days.
Keynote Highlights
More than ever, this year’s Integrate – and in special the keynote by Jon Fancey – give us some good hints on what is the direction that integration capabilities at Microsoft are going. Here are my take on it:
Integration anywhere
It is quite clear that the Microsoft wants to meet the integration needs of their clients (actually the computing needs in general) independent of where it is needed – within the Azure cloud, on-premises, in other public or private clouds or even at the edge devices. This is becoming a reality thanks to the ability to encapsulate the integration resources within containers that can be deployed the same manner independent on the destination. We should expect more and more investments in container technology as we already saw in API Management, in Logic Apps – with the new preview of Logic Apps running on Azure functions runtime enabling this possibility – and even on Azure Event Grid, which provides a module for edge computing.
Integration is for developers too
Microsoft is pushing the possibility to use low code technology like Logic Apps closer to developers – by enabling development in the tools that developers use daily – and providing the ability to consume those components in a easy way – by including Logic Apps in the Azure Functions runtime and adding it as a DAPR binding – in a bid to really speed up application development. The idea is to make integration tools more pervasive, making it part of the development process instead of an afterthought or needed to be owned by consultants with different skillsets. Where that takes integration developers? For one side it broadens their horizons, allowing them to integrate better in project teams (pun intended) – in the other allow them to lead this new wave of integration development by bringing years of experiences with patterns and practices closer to “mainstream” development. If positioned well this is a win-win situation for us.
Integration is a spectrum
Long gone are the times where integration only meant very specialized middleware software and arcane standards like EDI, HL7, XML, etc. The world today is so connected, that everyone needs to connect to something. That puts integration in almost every initiative today – from the citizen developer applications using Power Apps and Power Automate, to web and mobile applications, with APIs and backend services, to the traditional B2B integrations. That means that today everyone is an integration developer in a way. Understanding the multiple technologies and where they fit in this spectrum is quite important to use the right tool to solve the problem in hand.
It also quite interesting to see in Jon’s session a more “holistic” view of Azure Integration Services – originally, we saw the term – which was pretty much an umbrella name to a group of products that enable the PaaS vision for integration in Azure – Logic Apps, API Management, Service Bus, Event Grid. But the “definition” of Azure Integration Services in the diagram above, broadens that vision and presents a more real life view of what Integration means on the Microsoft Cloud today.
Technical Highlights
My initial expectation was that Microsoft, which had one of its flagship events – MS Build – finished just a couple of weeks ago – would have pretty much the same announcement. But I was wrong! They kept some interesting items that would be interesting mainly to that audience integration specialist just for that audience, while still showing some extra love for developers. Among the news that were disclosed – or discussed in more details – on MS Build, the main items were:
Logic App Support for DAPR
DAPR is a portable event driven framework, based on a “plug and play” architecture, providing building blocks for the both stateful and stateless applications development, based on standard Open APIs.
DAPR now support cloud native workflows based on Logic Apps, thanks to the Logic App runtime being embedded into Azure Functions. This will open a new possibility for applications to implement business processes workflows within a single solutions while still using the best of breed technologies to do so.
It feels to me like Logic Apps will start to realize the promise that Windows Workflow Framework tried to fulfil many moons ago.
Logic Apps SDK
The Logic App SDK that existed before in .NET is being expanded to allow not only management of the Logic App as a resource, but to programmatically define a new logic app in code. The introduction of operations like AppendTrigger, AppendAction and Run will allow developers to implement logic apps on the fly as part of their native code, instead of having the configuration of the Logic App in a different place.
I am not sure how I feel about this particular improvement, being a visual developer for so long, but it definitely make it more appealing for someone that works fully on an environment like Visual Studio coding on a programming language of choice full time. And that will definitely increase the reach of the technology.
BizTalk Migration Tool
Valerie Robb had a fantastic session on Integrate 2020 discussing the future of BizTalk Server and providing some clarity on what can be expected to BizTalk in the next couple of years. But definitely the highlight of her session was the announcement of the BizTalk Server Migration Tool.
The BizTalk Migration Tool is currently in development, with a target for autumn US – approximately September timeframe – will be a an open source command line tools that can be executed against a BizTalk Server Application MSI, which will analyse the application and provide guidance and potentially templates for migration
Azure Service Bus JMS 2.0 Support
The biggest announcement on Azure Service Bus was the unveiling of more details around its JMS 2.0 support. Although Azure Service Bus provide some support for JMS today, this support is not as extensive as other messaging engines like ActiveMQ or RabbitMQ. According to Ashish Chhabris – Service Bus Program Management – Service Bus today supports about 40% of the JMS features, lacking support for temporary queues, subscribers and queue/topic browsers for example. This will be another features added to Azure Service Bus Premium tier.
Once the public preview is available later this month, the list of supported features will increase to cover around 80% of the features. Among the new features are:
- auto-creation of entities over AMQP
- Durable and non-durable subscription
- Message Selectors
- Scheduled messages
- Queue and Topic browsers
Full parity with current JMS implementation can be expected after GA, including features like “NoLocal” – which allow subscribers to ignore messages published by its own connections, RBAC support for JSM clients and link recovery.
The plan is that the new JMS support will allow clients to simply change the current implementation connection configuration to point to Azure Service Bus, which will help with migration of workload form other JMS 2.0 based engines to Service Bus. This also means that most EAI connectors that exists today will be now compatible with Azure Service Bus.
Another change that will have a big impact is that in order to honour the maximum message size supported by JMS today, Azure Service Bus Premium tier will have its message size increased to 100 MB, from its current 1 MB limit.
In summary
We should expect some interesting tools to play with in the coming weeks/months! But most important, we will really soon be able to start having real talks to clients about how to position Azure Integration Services as a integration solution that:
- Meets their needs no matter where it is required – be in Azure, other clouds, on-premises or at the edge.
- Can be implemented at the pace the client needs, with investment being proportional to the return and current requirements.
- Can be used by their teams and cater for the diversity of roles that will be involved in integration within the organisation.
It feels to me that is a good time to be involved in integration. What do you think?
Leave a Reply