This year’s MS Build was very different – we all know that. But for most of us, me included, was the first opportunity to join the event officially. And what event it was.
Ran across three time zone, with a mix of live sessions, Teams Live events and smaller Teams events, like focus groups, which allowed the attendees to really interact with the product groups and advocates from Microsoft.
This year there were some interesting announcements around the Azure Integration Services technologies. I’ve recently shared those announcements on a Auckland Azure User Group meetup, and thought that, since I already had everything collated, it would be a good idea to just share this with you on the blog as well. So, let’s talk about what is now available, or just \around the corner for AIS
Logic Apps News
Logic Apps probably got the most exciting news from the bunch, but at the same time, it is one of the news we will still have to wait a bit more to get our hands on. There were two big news announced:
Logic Apps will run on the Azure Functions Runtime
Really soon we will see support for logic apps to run on the Azure Functions Runtime! This got everyone really excited and for good reason. The Azure Functions today is probably one of the most versatile applications in the Azure toolbox for developers and integration specialists. Its runtime can be deployed locally, supported by a powerful CLI that allows you to build and run functions on-premises. It also can be deployed on a containers and executed on both Docker and Kubernetes engines. And logic apps will inherit all of that! This will probably be the answer for logic apps to the new push by Microsoft to have technologies running on any cloud, on the cloud and on the edge. It will also finally create new options for executing workflows on-premises, getting closer to have a single solution for hybrid integration workflows – a solution that requires the mix of Logic Apps and BizTalk Server today.
Logic Apps VS Code Extension improvements
Together with the push for Logic Apps to run on Azure Functions Runtime, comes a new VS Code extension, that not only integrates Azure Functions and Logic Apps in a single deployment unit, but also finally enables the Logic Apps Designer surface as a local experience. So you won’t need to use Visual Studio connected to the internet, or implement your workflows in the Azure Portal anymore. This will bring Logic App as a technology choice much closer to the developers.
The product team also promised a better parameterization experience, which will simplify the deployment of the logic apps in the future – hopefully this will indicate a better way to define connections, decoupling their definitions.
Logic Apps Stateless option
After I’ve published this, Paco de La Cruz reminded me that I forgot one important aspect on the announcements for Logic Apps:
And he was right (thanks, mate)! Another area where the team is doing some research for improvements is in the performance of the Logic Apps execution- today, the full auditing capability available in Logic Apps (inputs and outputs of all actions) end up impacting the performance of the workflow execution. In some cases, you will might want to sacrifice that information for better latency. And this is what the Stateless Logic Apps will provide. There is not much info about how it will work in the end, but at this stage, what the product team presented was the ability to create Stateless Logic Apps (versus what we have today marked as Stateful). Don’t get confused by the name (I know I did in the beginning) – state in this case means the logging the inputs and outputs of each action instead of keeping state between executions. Maybe the name needs some work, but it will be an interesting choice to have available.
All in all, those are very exciting news to Logic Apps developers – and the development community in general. Unfortunately those items are still a couple of weeks away at least from private preview. I would expect more news coming from Integrate 2020, which is less than 10 days away.
API Management News
The news from API Management didn’t come from Build directly, but was the center of their presentations anyway. There were two main items that dominated the API Management presentations:
APIM self-hosted gateways are now GA
If you follow this blog, you will remember that I was quite excited about the new possibilities from API Management with the new self-hosted API Gateway (which I called Arc enabled at the time). The component is now GA and available on the Development and Premium tiers for API Management.
This is another push from the Azure Integration Service team to enable a continuous story between cloud and on-premises.
APIM extension for Visual Studio Code improvements
API Management have been investing on integration with Visual Studio Code for some time to improve the life cycle of API developers that need to publish APIs through the platform.
The latest incarnation of the tool brings this integration to the next level, enabling the majority of the activities required by an API to be implemented within the VS Code interface. The extension connects directly to a API Management instance in the cloud, and presents an hierarchical view of all the components that exists in APIM.
There are some key features in this version of the extension that improves the development experience:
- Direct editing access to policies at all levels (global, product, API and operations), with intelisense and with the same level of validation you get from the portal experience. This allow developers to implement policies, which is one of the most common activities during development from an IDE that it might be familiar with, although an internet connection is still required.
- API testing running directly from the IDE, a right click away. You can now choose any of the API operations and select Test… from the context menu. That will generate a page that uses the Rest Client extension to execute a call to the API Management instance, with all the hints required, including an integration with Name Values, allowing you to store the API Keys in name values and inject them from there.
- Import or creation of APIs from the IDE. You can now import APIs from an Open API file or URL, or import it from a Function or API App. At this stage there is no support yet for either Logic Apps yet, WSDL or WADL.
- Export APIS from the IDE. This feature integrates the APIM DevOps Kit directly into the IDE allowing you to export the ARM template associated to an API definition. The package includes all the required components, including Name Values, Backend Services, among others.
Be careful while using the Export API – while I was using it, I’ve noticed that it exports ALL named values and ALL backend services, even if they are not connected to the API. Named values can be particularly troublesome in this case, because the values will be exported in clear text, even if the item is marked as a secret.
One of the items that are not available yet but have been demoed and will be available in preview soon, is the ability to debug a policy. This will be extremely valuable, since now the only way to debug a policy is by enabling tracing and reading all the traced information – which can be quite verbose, specially when you are dealing with a complex policy which includes policy expressions in C#.
Service Bus News
The biggest news on Service Bus is the preview of the Service Bus Explorer. If the name is familira, is because a companion application with the same name, created by Paolo Salvatori, is probably the most used application to manage Service Bus queues, topics and subscriptions.
Most of the core functionality of the application can be found now directly on the Azure Portal.
To access this new functionality you need to go to the queue or topic you want to connect, and then select Service Bus Explorer (preview). From there you will be able to send, receive and peek the messages.
Be quite careful when using receive. This command works just like the auto-complete trigger in Logic App or the auto-complete mode in the SDK. Using this command will remove the message from the queue permanently.
For me in special, the ability to not only see the details of a subscriptions but also add or edit filters associated to it, was the highlight of that functionality.
Event Grid News
Event Grid Partner Topics dominated the news on Event Grid. According to Microsoft, “Partner Topics allow you to connect third-party event sources directly to Event Grid. This integration allows you to subscribe to events from partners in the same way you subscribe to events from Azure services”.
The first partner to have events enabled at time of MSBuild was Auth0 – allowing applications to receive a comprehensive list of events on both administration and user events.
While in preview, Partner Topics will be subjected to the same limits and pricing that we have today for system and custom topics.
Although this is not an MS Build news, Event Grid also have a on-premises capabilty, of sorts. As part of the IoT on edge push from Microsoft, Event Grid provides an edge container that can be used to create custom topics and event driven applications on an edge device.
How to find more
If you are interested in more information about those news, you can look for the following sessions on MS Build.
- BOD127 – Build scalable hybrid integration applications that run anywhere with Azure Logic Apps and API Management
- INT161 – Build messaging and integration apps on Azure
- INT174 – Build messaging and integration apps on Azure
Summary
MS Build brought Integration developers quite interesting developments (pun intended)! Finally the Roadmap vision of an integration capability that can be implemented on your terms and where is needed, be it in the cloud, on-premises on on the edge is starting to form.
The next months will probably quite exciting as some of those items start to hit both private and public preview. So stay tuned on MS News and here, as I will make sure I will try to get my hands on them as soon as they are publicly available!
Leave a Reply