AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]

Welcome back to the MC65F and podcast. Today we are talking about something every enterprise depends on, but very few organizations actually wanted to think about integration. Applications need to communicate, data needs to move, our piece needs to connect, business processes need to cross-system boundaries, and somewhere behind all of that, somebody has to make sure that entry things doesn't fall apart when APIs change, system become unavailable or business decides that yesterday's processes no longer good enough. My guest today is Sunny Gilson, Microsoft MVP, who is specialized in Azure integration services with a particular focus on Azure Logic apps. Solid describes this mission very simple, making complex integration simple, but the idea we are going to explore today goes much further than simply connecting system A with system B. So Sunny describes that how AI turns integration into on mechanism as a service. That's an interesting concept because an organism isn't static, it's set, yeah, it sends its environment, it's a response to change, it's adapt and potential it learns. So what happens when we started applying those ideas in enterprise integration? So yeah, well, I think we have a really, really interesting topic today. - Yeah, thank you, Mergo, and thank you for having me. And well, yeah, you explained it perfectly already because at first to start with that integration, it is a commodity at this point. Everybody just thinks it's there and it automatically works because it's like turning your tap water on, it just flows water, right? It's simple, but nobody actually sees what's all going on in the background. - Yeah, so before we get into AI and organisms and let's start with your background, how did you originally get into integrations? - I accidentally roll into it. And that is because at the A-A previous employer, I was a part of what they called a Microsoft team. So I thought, okay, that's cool. I'm a Microsoft fan, so I'm gonna do stuff with Microsoft and I thought this would be SharePoint and Forms and List and you know, all that kind of M365 kind of topics. But before I actually knew it, I was already working with Azure Logic Apps, building integrations with SAP. It was primarily focused around M365 still because that was, we used SharePoint as a UI to actually visualize the process, but my main work was integration at that point. And well, going forward, I noticed that this was actually a thing, yeah, it's really in my veins, in my DNA, I really like to integrate systems obviously, but I noticed that integration goes far beyond systems because we're actually connecting people here. - Yeah, yeah. But I found really interesting, you just drive yourself as someone who makes complex integrations simple. What makes enterprise integrations? So complex in the first place? - Well, in my opinion, it's basically because enterprises tend to make processes complex. And especially when ERP is involved because at first I thought it's SAP that makes things complex, but that's not actually true because Microsoft Dynamics ERP also makes things complex because ERP is a complex process. It has a lot of movements and everything has to be audited because basically it's just financial transactions, or let's say transactions. So it's a reasonable why it is a complex. And with that in mind, there are a lot of different departments involved and everybody has its own gut feeling, which actually counts because a lot of information and knowledge is stored in heads still. So well, with that in account, you just noticed that because the processes are complex, integration becomes complex as well. And my idea with my statement and need to make complex integrations simple is to boil down to the base question, basically what every consultant does or at least should do in my opinion, is not answering the question that they ask, but going deeper into what do you actually want? What is your question? And how can we help you in being your better self and perform your job better? - Yeah, this is complexity usually caused by the technology itself or by years of architectural, the system accumulated on the pub of each other. - I think the latter one because basically, and at least nowadays technique is something that everybody can learn. And with AI, we're going to that topic in a moment, but with AI in mind, the technique isn't a complex part anymore. Everybody can do it, but the trick here is to make sure that we as people get what we want, basically, that's the only thing because we used to have an IT landscape where IT simply dictates what you need. And if IT installed an application, you as business should use it. But that is now a thing of the past because at this day and age, we basically want the business to tell IT what they need and we're going to support them. - Yeah, yeah, we have all these low code, to no code, my code, integrations, now, yeah. But what separates a good integration architecture from one that really happens to work? - There are several topics that make a good integration. One of the main one is that the reusability is high. And nowadays we say composable architecture. So one could just grab a part and use it for its own purpose. That's one thing because simply rethinking everything through and through again, that's not making any progress, or at least not the SPS companies should do in this day, especially with AI. So that's one thing and obviously there's security because the availability of an integration is also determined by the level of security you're adding because if you have a bridge, or at least say you want to avoid bridges. So I think those are the two most interesting topics to distinguish a good integration from a, maybe not so good integration. - Yeah, that is the foundation. Microsoft used the term Azure integration service, but that includes several different technologies. When you say integration service, what exactly falls under that umbrella? - That is a good question. Basically what you have with that is Azure Logic Apps. That's one thing, so that's the low code perspective. You have API management because that's your gateway to everything you built also for AI. There is a debate that Azure functions because you can use it more broadly, falls also falls under the Azure integration services umbrella because you can integrate with it and at some point you shoot because Logic Apps, low code is super cool, but it lacks at points where pro code can simply, yeah, well, fix a problem better or sooner. So that's one and we've got Azure ServiceBuzz, which makes an integration decoupled. So then you've got no A to B kind of connections, but you've got A to ServiceBuzz to B to make sure that it's always decoupled and it makes an integration repeatable and reprocessable at the point where you wanna hook into your integration again. Then we've also got EventGrid, which is something maybe or maybe not with EventHub because that's basically telemetricized, which can also be used for IoT, but in a sense, IoT is also maybe integration because we're simply connecting again. And I think those are the main, I'm thinking, now am I forgetting something? I don't think I forgot a big one. I think we had Azure Logic Apps, Azure Functions, Azure ServiceBuzz, Azure EventGrid, Azure Management. I think that's the big five. But is there a simple, mental model architect can use when deciding which service should solve which problem? It depends on your company and I know that is a consultancy answer because in consultancy there's not always a one-off or maybe let's say almost never. Because if your company is fully into low code and has developers that actually love to low code, then Azure Logic Apps makes sense to use. And API Management has predefined policies which are also low code in a way. It looks like XML, but it's not actually that. So from that perspective, if your company is like that then that would be a choice you can make. On the other hand, if you've got a company with a set of dot net developers and they like ProCode, then maybe it's best to use Azure Functions together with Azure API Management and also an API Management even though they're predefined templates, you can also make use of a C#. It's not full C#, so it's not the entire stack, but still you can also add in code. I think Azure ServiceBuzz in my opinion should never be a debate. At least not for the, let's say the backend processing. If you want to have a synchronous call where you call an API and get a response then maybe ServiceBuzz isn't good to add in because it adds, it lowers the speed of your integration. And so it lowers the UX obviously. But from for a couple of purposes and backend processing, I would always advise ServiceBuzz. - Good. - Okay. - Yeah, that's interesting. Let's focus especially on your strongest area. I think the Azure logic adds, what makes logic adds interesting enough for you to a special live in them? - Jeez, that's a good question. I think mainly because I'm not a developer by heart. So I can read C# code and I can write it, but not as fast as any developer would. So that's a part because low code is better understandable for me. I can think as an application because that's still what you need for logic apps. But I can't write them in pro code in a good speed. So that's one thing but also on the other hand, when you're coding in a function, for example, you have to make sure your monitoring is in place, you're logging at the correct points, it's not visible until you make it visible. And in an Azure logic app, it's just a canvas. So as soon as you run your first logic app, you can see what it did, why it did it, what's the result? And it has basically automatic troubleshooting options already present. So you have to think less on the overhead of coding and more on the process you're actually supporting. - What do developers typically misunderstand about logic apps? - I think that, and I know it's, I have to be careful what I'm going to say right now. But most developers simply want to write code and have a feel that they're faster when they're writing their own code. And at some points, I may even believe they're right. However, for quick integrations and for setting up stuff and to lower your overhead, a logic app can help in that part. But it's also kind of what you're used to using, right? Because if you're a, let's say, back in the day, I made applications, as you call it, with Excel and in football, and with access. And that's also a low code kind of way of setting up applications. So by nature, I'm fitting in the logic app perspective already. And coders do not, because the syntax is different, you have predefined functions instead of your own function. So it adds a feel of limitation there. However, at this point, there are also code full workflows. And code full workflows try to bridge that gap where you can use the logic app perspective in a pro code setting. OK. Interesting. I think a little bit involved, or what I think it's, showed logic apps always be treated as code and deployed through CI and CD, or how is it working? I think that would be the best approach, because you can create your logic app in a def environment, for example, and then export the ARM template and import it again into your Azure environment, be it through CI, CD, but there's always that one moment where you actually forgot to copy it over, and then you've got differences between your environments. And that can be hazardous to your total operation, basically. So in my opinion, it's best to always work from CI, CD, but with that said, if you're now using logic app consumption, which is the Bayeshi Go kind of way, then you have to take it to account that the local development, for example, is a bit trickier, whereas the logic app standard that provides a designer from VS Code. So those are parts that you should take into consideration. OK. I think, how did the the the the the the esologic apps in, I think, one of the yeah, infrastructure topics I often speak about, it's infrastructure as code. Yeah. What role do is logic apps here play? Well, logic apps is basically the part of Azure that you deploy through in for infrastructure as code. It's not so well. Let me refresh that it could support deploying infrastructure as code, so it could you could use a logic app for pre deployment steps, post deployment steps, use the API and use it in your infrastructure as code flow, but as we see it now, I mainly see environments where logic apps are simply deployed as infrastructure as code. OK. And what what rule do things like by set terraform and out templates play in as a logic app project? Yeah, well, they basically make your integration because that's the deterministic language that. Yeah, well, that's why they call it deterministic baby. It determines what your logic app looks like. So it it provides this SKU. It provides a location. It provides the resource groups. All that kind of information is stored into either a bicep, which is basically in the back and translated to a AM. So those are related. I wouldn't say they're the same, but bicep lowers the duplication that a ram natively has. And terraform is also a way of deploying your infrastructure as code. So it's supporting the deployment basically. OK. You say before we have to talk about consumption and logic at standards. I think, yeah, this is it. It's people like me. It's got a little bit of the confusing when we look at it. I'm not so used to it. How do you explain logic app consumption versus logic app standard? It's basically rather simple. And I can understand that it may sound confusing at times. But the consumption is pay as you go. So that's on a managed platform, which is managed by Microsoft. So basically you're building your workflows there. And you pay as much as you use it. And obviously there's degradation in what you pay actually, because if you call SAP, that's more expensive than where you call an HTTP trigger, for example. So those are the parts. But it's fractions of cents that we're talking about for every execution. And eventually that will turn into 10 or 100 of euros a month. But you're never actually quite sure on what your bill will look like at the end of the month. Standard is a reserved capacity, basically. So it's running on your own service plan. So you have your own compute. And within that compute, you run your workflows. So basically you're not only building your workflows anymore like you would with consumption. You're now also managing a server in a sense, because you have to make sure that your compute is capable of running the workload you're aiming at. And that's the difference between the two. And to make it even more complex, we now also have logic app automation in public preview. And logic app automation is basically the power of logic app consumption, the pay as you go model, with the power of logic app standard, the reserved compute, and all network isolation, and basically the infrastructure side of that. And on top of that, they put AI to let it build your workflows. So you cannot-- you don't have to actually click your workflow together anymore. You can just explain your intent. And logic app automation will create it for you. Yeah. I think one topic or a bigger topic, it's-- yeah, logic app has a side on one side. It's a superpower, and then on the other side, it's like a trap. And I think one of the biggest, from my perspective, setting points of logic is the connector ecosystem. How important are these connectors to a false success of logic apps? I think they're majorly important. And on top of that, Microsoft decided to bring the connectors out of logic apps. So we're back in the day, and I'm talking back in the day is a month to go, right? You had to create a logic app to make use of those connectors, and those connectors are managed by Microsoft, so you don't have to worry about API versions, and what do I need to call, et cetera. That's all managed by Microsoft, so you're basically leaving some overhead behind because Microsoft takes care of that. But nowadays, you've got Azure Connector namespace, which is basically the logic app connector. But now it's placed as a separate resource in Azure, so you can also use it in your function, or you can use it in your own code in a web app or whatever, you can use it everywhere within Azure. So basically, you're using the power of that managed connector outside of logic apps now. Yeah, yeah, it sounds-- yeah, it sounds-- yeah, it's a little bit easy. But the Duke connector sometimes-- yeah. I don't know. Yeah. Is there something-- I think-- use my connector and click-click. I'm ready. So is it really this or looks like it's only like the simple? It's basically both. And the reason I'm saying it like that is, yes, you can click-click, and then you're ready. So that's one part of the story. But as you correctly mentioned, logic app sounds like a superpower. But a super hero, and I can't remember rich, said, great power comes with great responsibility. And that is basically the same with logic apps, with the connector namespaces, et cetera, because, and then we're revolving back to the beginning of this podcast where we talked about what makes a good integration. Security, for example, is a great thing. You really need to think through about how to set it up, because, sure, we can give a connection access to a system, and then it can freely do anything. But is that really what we want? Or is there a risk involved? And can if we got access to a table, for example, do we want that full table exposed? Or do we only want several fields of the table exposed? So from that behalf, you really need to think through on what am I actually trying to achieve here? What are the risks? And how can I mitigate the gap between those? Because that's still-- even though it is click-click, you really need to think about your setup and your infrastructure. So we're in Azure, we're in the Cloud, it's super cool. But still, it's also an infrastructure project. Is there any limitations on architect-should evaluate before using managed connector? Yes, there are several. Depending on the connector, you have to make sure that one simple example for is does it use a user to connect, or does it use an app to connect? Because if I'm connecting as a user, let's say, I'm using the user Mirko. That would mean that if there's also another trial in the system, my integration will act on behalf of you making every other trial leading back to you. But because other people use that integration, it might not even be you. It might be someone at a desk somewhere in the company. And that is a security risk. Because you get hit by security that you change something, which you didn't, because someone else in the integration did it. So those are parts that you also need to think through. With AI in perspective, you have to think about user permissions again, because AI will act as the user. Because if you have access to it, and AI can have access to it. But if you don't, then it's not a good thing if your AI connects as an app and provides you everything that the app has. So we're shifting again to that perspective. So you really need to think on what otherizations do I need? And how do I embed that? And how do I make sure that it always beats back to the correct? Yeah, let's say a point of failure. And then the-- Yeah. I think we have-- if we are for ways to integrate-- for integrations-- when should you use a built-in connector, a managed connector, a custom connector, or simply call API directly? Our main objective is to always use built-in connectors when you can, because the built-in connectors are running within the logic app runtime. So are basically part of your integration, are really part of your integration, whereas the managed connector is managed by Microsoft. So it always leaves your environment. And with a built-in, that's not the case. Usually, and especially at this point, it could potentially have a better support for the connectors you're aiming at. And then you're connecting to a system that's not known, or you're using your own API management, because Microsoft best practices to basically use your API as the central gateway of all your connections. Then that could be a perfect custom connector. OK. How did we handle the authentication and credential management properly in logic app? Yeah, well, basically you have to look at, and you mean from what the logic app uses, right? Not the one who's calling the logic app, because there's also a difference there. OK. The best practice would always be, would always go for the least-prince privileged. So don't make sure you're only providing the access and alterations that are necessary for that logic app. And I'm specifically saying that logic app, because you could reuse the same credentials for other logic apps as well. But it should be as granular as possible, because if there's a breach, if you kill one connection, and you're reusing that on every integration, you're killing your entire integration. So you should make sure that you can isolate it in a way, and only provide the right state you need. OK. And how important are the managed identities in modern logic app architectures? Majorly important. In my opinion, and I know there are different opinions on this topic, but the great thing about a managed identity is that it's part of your resource. So if you delete the resource, your identity is gone as well. And because the identity is connected to a resource, you're also in a way in the least privileged mode, because only your resource can access it, because you have to actually provide access for that specific resource. You've also got user managed identities, and I know why people should use them, because user managed identity is basically the same kind of principle only not connected to a resource, but you can connect multiple resources to it. But with that said, that obviously could potentially expose the security risk, because orphaned resources, for example, still have access through that user managed identity. And in my opinion, if you can use managed identities, if your environment allows you to, then that would would always be my recommendation. OK. [INAUDIBLE] Ideally, yes. Obviously, we're always aiming for the highest possible option, but we also know we have to deal with legacy. And some systems, let's take SAP, for example, especially older ERP versions. They still use plain basic username and password credentials. And I know there's something like secure network connections, and you can set it up with carbrose. And it's a pain in the ass to connect in the first place. And it's even more pain in the ass to maintain it while it's running. So yes, there is to secure it a bit more, but it really depends on how stable you want your connections to be. Nowadays, luckily, also SAP is turning more and more to allow it, for example, and allow it to use a app. But then again, you should think about whether to use an app or not, especially in ERP systems like SAP, because there are a lot of information that can be breached. But yeah, if there's a possibility to remove the need for keys, then that would ideally be the best fit. Yeah, you say of observability, I think, yeah, building the integration is only the half of the problem, then it comes to operate it. What does a good observability look like for Azure integration services? As we're now addressing it is to have, and then you're also almost coding again, we're working with a track catch block, for example, so we're trying to execute an integration and when it fills, we've got a catch that checks, okay, what error did appear? And then it should be locked, obviously, because observability is way more than just logging. It's also making use of, as we call it, in logic apps, tracked properties and a tracked property is different from logging in that sense that you've got the default diagnostics that is sent to log analytics for an Azure logic apps. That is something that you could use, but if you extend that with tracked properties, you're also adding your own business information to the default Azure diagnostics. And then you've got the full end-to-end scope, then you can see what connector failed, for what order was it, or for what user or for what customer. And then you've got a full scope, and then obviously to make the observability, or the observability, a connected story is to also make sure that you have your dashboards and your metrics, and that you also can view it in a proper way. So basically what you want to know is, did my integration run? Did I see failures? If it failed, why did it fail? And that why is in my idea, not a technical, I've got a 500 internal server error, because then everybody thinks, okay, well, great. It should be something like, I couldn't process this invoice because it has no invoice number. So it should, in my opinion, be more like business-driven data. So you can also move the responsibility for monitoring your entire environment. So from your own desk to the business who is actually running the operation. Yeah, what first come in my mind, where is the Azure Monitor? Yeah, that's one thing that you can use in need. How do application insights and look at the links? Yeah, really fit in this picture how we can we use this for getting to do it perfectly from your perspective. Yeah, well, if you use the default Azure diagnostics, then you're already logging to Log Analytics. And you can extend it with your own logging. There's a connector also for that to connect to a Log Analytics workspace. And in my opinion, you should make sure that your logging can tell you what happened. And the or why it happened. So it explains a bit and your track properties are added on top of that to tell you what, what where did it happen? And you know that you can always track. For a let's let's take the invoice example, the why the invoice isn't processed and why the number isn't present. And then you can dig into your logic caps going back to the why I love logic caps because then you've got your full run history. And you can just click through the actions and see, oh, oh, I see it. I have a mapping here, but the mapping field. Yeah, I think what went a little bit different, but I think when I worked in cybersecurity, we got these thousands of hundreds of thousands of of alerts. Nobody pays really attention to because it's too much. Now we have the security copied of its helps. Is there anything else for for for the logic caps? Yeah, well, basically because you're logging to log analytics. At least that's let's say the default you can obviously use other logging and monitoring solutions as well. You could use Sentinel and the trick is what most companies in my opinion, try to do is log everything as much as possible because then we've got the information. The only thing they're forgetting at that point is that by logging everything, you're also making sure the noise is raising. And there's so much information basically what you said, there is so much we can look at it all. So make sure to log only which need. So in our best practice, for example, we've got a as I mentioned the try catch block and we're only logging once at the start and once at the end. To make sure that we've got the start of the run, we've got the end of the run because then we can measure the execution time. And for example, and we know did it successfully run or did it fill and if it filled, why did it fill? And that's all all there's to it. You can add multiple actions and log everything and it just doesn't make sense. You only need to you really need to think of what should you log because also the security copilot and basically every AI application. If you provide it with too much context, the results are getting bloated. Yeah, yeah, of the overlying with this. So for my best victim, I log the logic app completely successful enough. You mean if you log if the logic app runs successful of that is that enough? Depends if you don't want to measure the execution time then yes, if that helps your situation because obviously again that's also a cause of the answer. You need to log what fits your situation. And if your situation is helped with just a single lock rule. Sure. Why not? As long as it doesn't bother your operation, it's perfectly fine. And when I think on monitoring, we have both to big monitoring. We have on the business level monitoring and the technical monitoring. We separated or shall we put it together? That is an interesting debate and I think we should separate it. Okay, because at first the business should be informed something happened with the integration and this is something you can fix. If the business should not be involved because there's a technical error, then maybe the business should only be informed by hey, we noticed that the integration had a failure, but your technical colleague is already looking at it. And that's why I think a separation of duties is really helpful there. And I think often workers, ETL pipelines in the past. And what we often have is the ETL pipelines work technically perfect. It's a succeed, but the business side say on their side is failing. Did you see that could be also possible and non-check at the problem? Sure, yeah, the thing is your logic app can provide a green check mark in the run, which is the same with ETL because I think you're aiming for a data factory, for example, and it's the same there. If your error handling is set up correctly, your logic app may not fill because the run completed. But during the run, it experienced an error which you captured somewhere or did something with or basically ignored it because I also see that situation sometimes. And then your run seems to be just fine, nothing happened, everything's green, cool. But still on the business side, that simple invoice that we took as an example earlier still isn't processed. And that's an issue. So yes, and it gets it gets even more interesting with AI in the mix because going going to that topic, obviously is. And then you've started off with your logic apps are running like a system, right, it's top down, it's just executing what it's told to do. But when you talk about an organism, it's basically stating that it responds to the environment that it has a feeling of something or some sort. Basically, what AI does with the logic app because you used to have a top down workflow and that used to run perfectly fine or not. And now with AI, if the or not situation happens, you don't have to think specifically about, OK, is it a 500 error is the 503 is the 429 or you don't have to think about that. And then you can think, what happened here, get us some more information and with the information determine itself, should I connect to the business or should I connect to my technical colleague. And from that point, your logic app, which was a integration as a service suddenly becomes an organism as a service because it basically reacts and it responds. Yeah, I like to talk about the idea, I stuff, but the before I think we have to do the the the bad part. What when I often see, I don't know, it's only from my perspective, but integration platforms often have extra extra extra ordinary access across an organization. Is the integration layer something sometimes one of the most privileged parts of an enterprise architecture. And it happens to be, but in my opinion, it should not be going back to the to the authentication that we talked before because if your integration platform has privilege to the application that it should access, then you may have a major security risk because then there's one single point of failure and that your integration platform. And if you need to kill it because there's a breach, you're killing your entire integration platform, which could potentially run your primary process. And with that said, it basically means your company has come to a standstill. And I think from a, well, let's say, healthy way of working and especially in this modern day and age, you simply cannot do it like that anymore because your integration, not your platform. But your integration should have the privileges to execute what it should execute and no more. Yeah, what I think is it's we have start with integrations and I don't know, to a to do will be. And now we have departments and sub-departments have hundreds or thousands of integrations. How should organizations manage the identities, especially when we get in this high level of integrations? Yeah, and to extend that a bit further, the departments that have thousands of integrations may potentially even build our own integrations. So it's not even managed by our department itself anymore. So that also basically moves the security risk to the desk of the user that's working with it. So then there's a governance is the key there because you have to make sure which department can ask for which permissions at what level for which integration. So you have to really drill it down into a specific purpose. And that purpose is supported. And if at some point a new integration comes in and says, I want to do similar thing. You're in your integration. So you're getting new access. That's at least how I see it. Unless you can say, OK, this is basically the same process we're working with because then you could potentially say, OK, if we need this process to get to a standstill because there's a bridge, for example, then the entire process should stop. So then that makes sense to use the same authorization. But again, you have to make sure that your logic app will not have more permissions than it actually needs. And then we have to talk also about the least privilege. Yeah, yeah, the least privilege is basically the best practice that also Microsoft aims for every time. Basically states and I know it's not it's not always feasible for 100% because of support of application, for example, I know the graph connector. Microsoft graph API, which is basically the heart of a Microsoft environment doesn't always have a really granular permission set. So then from that point, you can aim for least privilege, but leave privilege and maybe everybody knows this from their Microsoft exam, right? They always ask for I want to achieve this task, but I want to have least privilege. And then the answer is you need to be global admin because other roles are simply can't you know, that's still a thing. So least privilege doesn't always mean that you have to go for the lowest role or rule set, but it has to make sure that it can do its task and ideally, not more than that task. And when I think on the itl pipelines, there is, yeah, what one security thing we, we, it's just one of the key security things is it's as a key world is also a topic for logic apps or is it handled completely different. And note that that is a main logic app concern because, for example, with a logic app standard, you've got your own service plan and your own compute, right, as we mentioned before. And it also has its own app settings and the app settings can be referenced to a key vault, for example. And it also boils down to your infrastructure as code because if you're writing code for your logic app and your code contain secrets, then we've also, we've got a high risk of your security over there. So using a key vault makes sense. In my opinion, everything you do at Azure, obviously with the nuance, it should be supported, sure, but every application I touch so far now supports key vaults and also in a logic app consumption, you can also also use the managed key vault connector, for example, and then the managed identity of the logic app connects to the identity of the key vault retrieves the secrets and uses it in the workflow. And it's also sanitized. So if you look at the run history, you don't see what's actually gathered. Yeah, and what's about a private endpoint and network isolation? Yeah, that's, that's difficult with a consumption or at least undoable with consumption because it's a managed platform and you can manage your own network isolation with a standard and with a logic app automation, you can. And you can actually isolate it because I know it's a API management, for example, you've got a basic feature tier, which can do Vnet, sort of standard, V to tear, which can do a Vnet injection or the premium V to tear, which can do network isolation and the difference between those two is that. And with the, with the standard, you're injecting the API management in your network, but it's still publicly accessible and with isolation, it's actually cut off on the internet. And that's the same with Azure logic apps. If you do network isolation, you should always think about cutting it off because at that point, adding a API management in front to actually connect to your logic app would make sense. Yeah, cool. Well, oh, yeah, we are running a little bit of time. So, okay, then we go to the central idea of this conversation, your shortcuts, that is how AI turns integration into organism as a service. Yeah, can you, can you, yeah, can you show the explain what it's, what's really mean? Yes, I had a talk at the, the, the, which is the Microsoft integration user group here in the Netherlands, where I'm based. And it was an idea that popped in my mind and I just thought, okay, well, let's give it some attention and make this a session over there, right? And that there we further explore the idea of that. Because basically we used to have infrastructure as a code, we used to have in the integration as a service, we have software as a service, I mean, everything's as a service at this day. But the integration as a servers was always consisting out of the components we already talked about. And did exactly what you told them to the same with normal code or let's say, pro code. You tell it what to do and it runs top down specifically what you told the two. But with AI in the mix, because now in logic, actually, we've got agent loops, for example, and agent loops are not your deterministic, I go from A to B unless C, then I go to D. So it's I'm putting in A and depending on the input on A, it depends whether it should be C or D. It thinks by itself what route it should take. It also rationalize why it should take that approach. And if an unexpected situation occurs, it can also respond to that. And instead of just going from top to down to your code, it now starts thinking and responding and it's thinking along with you and it's basically not your integration anymore. It's basically your companion. So everything you did not think about yourself, AI could maybe handle that. Let's make this this this practical, imagine a traditional logic and events happen, the workflow starts, there are conditions, direction, there are outputs, everything has effectively been predefined by a developer. Where do the AI and the model basically on the condition, for example, because let's say we've got a logic app that receives an input and based on that input, it calls an endpoint. If that endpoint endpoint would fill, you could add in a condition with a run after as we call it in logic apps and stay, okay, if it went successfully, then we should execute flow A, and then we're responding back with a success to the user, for example, and when when it filled with a 500 error, let make it really specific here, then we should reply back to the user something filled and we need to lock something in the monitoring, for example, or we should send an email to the technical guys. What you didn't capture with that flow is what if there's not a 500 error, what is it, what if it's a 429, which means a 500 errors and internal server error and a 429 means too many requests. So basically your API was still busy or was overloaded or whatever, what do you do then? So you can add in AI to the loop and say, okay, please check for the type of error. If the API is too busy, wait for a moment and then call it again. You don't have to really explain that it's a 429 and that there's a retry header with seconds in it and how long you should wait. You don't have to tell it that you simply say, okay, if there's an error and the API is too busy, wait and try again. That's enough. At some cases, obviously it depends on the context, but to make it really simple, right? If it filled, send an email to the technical guys, but if it filled with a business data-driven error, then send it to the business. And if it succeed, just say, okay, and at that point, AI interprets your text input, so your intent, what do you want to achieve with this integration? And it basically handles it itself. So you don't have to worry about setting up your conditions and making your entire workflow designed the way you want error handling to be. You simply add in an agent loop, you tell it, this is the situation, go for it. So AI can classify incoming information and then choose the appropriate workflow? No, it doesn't create the workflow, but it can indeed check the input. That's one of the things. It can also check the output of an action. So for example, the HTTP call, it can check, did it run successfully, and if it filled, why did it fill, etc. So that's in a possibility, so it can connect to different parts of your process, where you need additional, let's say, where you may expect the unexpected. And at that point, AI can be a really added value, because the unexpected things, even though you're willing enough to do so, you can't predict everything. And if you make it deterministic, then you should make everything as clear as possible. And with AI, there's no need, because you can also instruct your agent, if you really don't know, send me an email. And I think what actually is, I say, the password, it's all talk about selfie integrations. Can you a little bit explain what it isn't, how it really works? Sorry, which one you made? The selfie integration. The self healing integration. Yeah. Yeah, well, I think basically, AI is what could potentially make a self healing integration, because you've got your flow and you've got everything determined and from top down, we know exactly what we want, expect for that unexpected part. And AI could also reprocess itself, for example. So let's take the example of the API that's too busy. At this point, you have to think about your retry pattern, because the standard in the Microsoft environment is that it exponentially waits. So it waits, I believe first 10 seconds, then 20, etc. But is that the idea of the API you're calling? Because maybe that API says I'm too busy now, come back in five minutes. And that interpretation is something that AI can do. And that's basically already self healing, because instead of you thinking about retry patterns, you just say to AI, wait. And it interprets how long should I wait? What does the calling endpoint expect from me? And how can I respond to that? And you can make it as basically as smart as you want it, but still, and that's my tagline, obviously, you have to make sure it's simple and it stays simple, because the more complex you make it, you may run into a context overload. And then your AI may have some unexpected responses again. Yeah, cool. I think I could talk with you hours and hours. I think, yeah, it was. So I have an every round, I have a rapid fire round. I give short questions, you give us all the answers. So ready? Sure. Logic apps are functions. Logic apps. We can't know a bit of all. Sorry, what did you say? We can't know a bit of all. Oh, bit of all. Rest or events? Rest. So in cool or awesome, close? Depends, but I think ask your comments. Visual designer or code? Visual designer. Most underrated, as your integration service. What logic apps? One logic app feature more, you blow up as rules know about. I think it's agent loop, at this point. When such a little guy comes to you, Sony and say, it's okay, I give you all the money and resources to build your dream feature for. What will the be? I think extending the logic app out of the machines, proposition further, because it's cool now, but I think it can be even cooler if the business is also involved. Okay. Who should I invite next to the podcast and what is the secret question I should ask? Oh, that's a good question. If you're aiming for more on logic apps, then I should definitely go for Wagner Silvera for Microsoft. Okay. And I think the secret question is also the question you asked me that if you've got unlimited resources and people, what would you do with the system? Okay. Yeah, finish the sentence, the integration platform of the future will not only think with you, but basically act along you. Yeah, then, yeah, Sony, I think that it was of, yeah, fascinating. Cake away here that integration is moving beyond simply connection systems. Yeah, for decades integration has largely been determined, deterministic, what it's happened, that do that. But yeah, adding AI, potentially changed the model, the integration, they can be interpreted context, regulation, patterns, it's really, really fantastic. For all the people who will know more, especially of your concept, the organism as a service, all the links are in the show loads from the 65th and podcast page. So, yeah, you find all there and yeah, thank you so much for staying with me. Thank you. Yeah, thank you for having me again and I really enjoyed it.