AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]
Key Takeaways
- Enterprise integration has evolved into a critical infrastructure layer that operates invisibly until something fails, requiring a deep understanding of underlying business processes rather than just technical connections.
- Azure Logic Apps provide a visual, low-code canvas that significantly lowers the overhead of logging, monitoring, and basic troubleshooting compared to traditional pro-code development.
- Treating Azure Logic Apps as code and deploying them through automated CI/CD pipelines and Infrastructure as Code ensures consistency and prevents configuration drift between development and production environments.
- Choosing between Azure Logic Apps and Azure Functions doesn't have to be an ideological battle; modern enterprise architectures can successfully combine both low-code orchestration and pro-code flexibility.
Enterprise integration is everywhere, yet most people only notice it when something stops working. Applications need to communicate, APIs need to exchange information, ERP systems need to connect with business processes, and data needs to move reliably across organizational boundaries. For decades, integration has largely followed a deterministic model: when this happens, do that. Developers and architects define triggers, conditions, transformations, retries, exceptions, and destinations in advance. But what happens when AI becomes part of that integration layer? In this episode of M365 FM, Mirko Peters talks with Sonny Gillissen [MVP], an Azure Integration Services specialist with a particular focus on Azure Logic Apps, about a concept he calls “Organism as a Service.” The idea is that enterprise integration can evolve from static workflows into systems capable of interpreting context, responding to unexpected situations, choosing appropriate actions, and potentially recovering from failures more intelligently. The conversation covers Azure Logic Apps, Azure Integration Services, API Management, Azure Functions, Azure Service Bus, Event Grid, managed connectors, managed identities, Azure Key Vault, Infrastructure as Code, Bicep, Terraform, CI/CD, observability, Log Analytics, security, least privilege, network isolation, AI agent loops, self-healing integrations, and the future of intelligent enterprise integration.
WHY ENTERPRISE INTEGRATION MATTERS
Integration has effectively become infrastructure. Employees open an application and expect the information they need to appear. Customers place orders and expect them to reach the correct systems. Financial transactions move through ERP platforms. APIs exchange information. Events trigger downstream processes. From the user's perspective, this often feels automatic. Sonny compares it to turning on a water tap: people expect water to flow without thinking about everything happening behind the wall. Enterprise integration works similarly. The complexity becomes invisible until something fails. Behind seemingly simple processes can be dozens of applications, APIs, business rules, security controls, identities, transformations, queues, monitoring systems, and organizational responsibilities. Integration therefore isn't simply about connecting application A with application B. It is about keeping business processes operating across systems that were often never originally designed to work together.
WHY ENTERPRISE INTEGRATION BECOMES SO COMPLEX
The technology itself is not always the primary source of complexity. Enterprise business processes are complicated. ERP environments such as SAP and Microsoft Dynamics contain extensive transactional processes because financial and operational activities need control, consistency, and auditing. Multiple departments participate. Business knowledge remains distributed among employees. Organizations accumulate years of architectural decisions. Eventually, integration architecture begins reflecting all of that organizational complexity. Sonny argues that a good integration consultant therefore needs to look beyond the technical request. Instead of simply asking “How do we connect these systems?”, the more important question is: “What is the organization actually trying to accomplish?” Simplifying integration starts by understanding the business process behind it.
WHAT MAKES A GOOD INTEGRATION ARCHITECTURE?
An integration that works today is not necessarily a good integration. Sonny highlights reusability and security as particularly important characteristics. Modern integration architectures should become increasingly composable. Instead of rebuilding the same functionality repeatedly, organizations should be able to reuse components in different processes. Security is equally fundamental. Integration services frequently connect highly privileged business systems. Poorly designed access can turn an integration platform into an extremely attractive attack path. A successful request is therefore only one measure of integration quality. The architecture also needs to remain reusable, supportable, secure, observable, and adaptable as business requirements change.
WHAT ARE AZURE INTEGRATION SERVICES?
Azure Integration Services is not one product. It is a collection of Microsoft Azure capabilities that can be combined to build enterprise integration architectures. During the conversation, Sonny and Mirko discuss five major technologies: Azure Logic Apps provides workflow orchestration and low-code integration. Azure API Management provides an API gateway and management layer. Azure Functions provides serverless code for scenarios where pro-code functionality is appropriate. Azure Service Bus supports messaging and helps decouple systems. Azure Event Grid provides event-driven integration capabilities. Different services solve different pieces of the integration problem, and real enterprise architectures frequently combine several of them.
AZURE LOGIC APPS VS AZURE FUNCTIONS
One recurring architectural question is whether a particular integration should use Azure Logic Apps or Azure Functions. There is no universal answer. Organizations with strong low-code expertise may find Logic Apps particularly effective because developers and integration specialists can visually construct workflows. Organizations with experienced .NET development teams may prefer Azure Functions for scenarios where custom code provides greater flexibility. The important point is that this does not need to become an ideological choice between low code and pro code. An enterprise integration architecture can use both. Logic Apps can orchestrate processes while Functions provide specialized code where required.
WHY AZURE SERVICE BUS MATTERS
Azure Service Bus plays an important role in decoupling enterprise systems. Without a messaging layer, application A may directly depend on application B being available. That creates tight coupling. Introducing Service Bus can separate those systems. Application A can send information to Service Bus, while application B processes it according to the architecture. This can make backend integrations more resilient and provide opportunities for reprocessing. Sonny notes that Service Bus is not automatically appropriate for every synchronous scenario because adding asynchronous messaging can affect response time and user experience. But for backend processing and decoupled architectures, he considers it an important component.
WHY SONNY SPECIALIZES IN AZURE LOGIC APPS
One reason Sonny focuses heavily on Azure Logic Apps is visibility. Traditional code requires developers to deliberately implement logging and monitoring. A Logic App provides a visual workflow and run history. After executing a workflow, developers can inspect what happened, which actions executed, what results were produced, and where failures occurred. This allows integration specialists to spend more time thinking about the business process and less time building basic troubleshooting infrastructure. For people who naturally think visually about processes rather than primarily through code, this can make Logic Apps particularly effective.
THE DEVELOPER MISUNDERSTANDING ABOUT LOGIC APPS
Developers sometimes assume that writing custom code will always be faster or more powerful than using a visual integration platform. For some scenarios, that may be true. But the calculation needs to include more than the time required to write the core functionality. Monitoring matters. Logging matters. Deployment matters. Error handling matters. Operations matter. Maintenance matters. Logic Apps provides significant platform functionality around the workflow itself. Sonny also discusses codeful workflows as an attempt to bridge the gap between visual Logic Apps development and traditional pro-code development approaches.
LOGIC APPS SHOULD BE TREATED AS CODE
Low code does not mean organizations should abandon software engineering practices. Sonny recommends treating Logic Apps as code and deploying them through CI/CD. An organization could manually create something in development, export it, and reproduce it in another environment. But manual deployment creates an obvious risk: Eventually, somebody forgets something. Development and production begin to differ. Those differences become operational problems. Automated deployment provides repeatability and helps organizations maintain consistent environments.
INFRASTRUCTURE AS CODE WITH LOGIC APPS
Azure Logic Apps can be deployed as part of an Infrastructure as Code strategy. The episode discusses ARM templates, Bicep, and Terraform. Infrastructure as Code describes the desired Azure environment deterministically. The configuration can define resources, SKUs, locations, resource groups, and other infrastructure properties. Bicep provides a more concise Azure-focused authoring experience while ultimately relating closely to ARM deployment. Terraform provides another approach for defining and deploying infrastructure. The important architectural principle is repeatability. Integration infrastructure should not depend entirely on somebody remembering which buttons they clicked in the Azure portal.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
Frequently Asked Questions
What is the difference between Azure Logic Apps Consumption and Standard?
Consumption is a pay-as-you-go model managed entirely by Microsoft, while Standard runs on your own dedicated compute and reserved capacity plan, giving you more control over infrastructure and network isolation.
Why should Azure Logic Apps be deployed using CI/CD?
Deploying Logic Apps through CI/CD and Infrastructure as Code prevents manual deployment errors, ensuring that development, staging, and production environments remain completely consistent and reliable.
When should you use Azure Service Bus in an integration architecture?
Azure Service Bus is ideal for backend processing and asynchronous messaging to decouple systems, though it may not be necessary for simple synchronous API calls where immediate response times are critical.
1
00:00:00,000 --> 00:00:04,720
Welcome back to the MC65F and podcast.
2
00:00:04,720 --> 00:00:06,960
Today we are talking about something
3
00:00:06,960 --> 00:00:08,600
every enterprise depends on,
4
00:00:08,600 --> 00:00:10,240
but very few organizations
5
00:00:10,240 --> 00:00:13,440
actually wanted to think about integration.
6
00:00:13,440 --> 00:00:15,760
Applications need to communicate,
7
00:00:15,760 --> 00:00:17,440
data needs to move,
8
00:00:17,440 --> 00:00:18,800
our piece needs to connect,
9
00:00:18,800 --> 00:00:21,440
business processes need to cross-system boundaries,
10
00:00:21,440 --> 00:00:23,720
and somewhere behind all of that,
11
00:00:23,720 --> 00:00:26,760
somebody has to make sure that entry things
12
00:00:26,760 --> 00:00:31,240
doesn't fall apart when APIs change,
13
00:00:31,240 --> 00:00:34,600
system become unavailable or business decides
14
00:00:34,600 --> 00:00:37,080
that yesterday's processes no longer good enough.
15
00:00:37,080 --> 00:00:39,200
My guest today is Sunny Gilson,
16
00:00:39,200 --> 00:00:41,080
Microsoft MVP,
17
00:00:41,080 --> 00:00:45,800
who is specialized in Azure integration services
18
00:00:45,800 --> 00:00:49,040
with a particular focus on Azure Logic apps.
19
00:00:49,040 --> 00:00:51,280
Solid describes this mission very simple,
20
00:00:51,280 --> 00:00:53,880
making complex integration simple,
21
00:00:53,880 --> 00:00:58,720
but the idea we are going to explore today
22
00:00:58,720 --> 00:01:01,000
goes much further than simply connecting
23
00:01:01,000 --> 00:01:02,960
system A with system B.
24
00:01:02,960 --> 00:01:07,080
So Sunny describes that how AI turns integration
25
00:01:07,080 --> 00:01:10,200
into on mechanism as a service.
26
00:01:10,200 --> 00:01:13,080
That's an interesting concept because an organism
27
00:01:13,080 --> 00:01:15,040
isn't static, it's set,
28
00:01:15,040 --> 00:01:17,800
yeah, it sends its environment,
29
00:01:17,800 --> 00:01:19,600
it's a response to change,
30
00:01:19,600 --> 00:01:22,680
it's adapt and potential it learns.
31
00:01:22,680 --> 00:01:26,400
So what happens when we started applying
32
00:01:26,400 --> 00:01:29,360
those ideas in enterprise integration?
33
00:01:29,360 --> 00:01:31,400
So yeah, well,
34
00:01:31,400 --> 00:01:36,160
I think we have a really, really interesting topic today.
35
00:01:36,160 --> 00:01:37,080
- Yeah, thank you, Mergo,
36
00:01:37,080 --> 00:01:38,400
and thank you for having me.
37
00:01:38,400 --> 00:01:42,840
And well, yeah, you explained it perfectly already
38
00:01:42,840 --> 00:01:47,840
because at first to start with that integration,
39
00:01:47,840 --> 00:01:50,920
it is a commodity at this point.
40
00:01:50,920 --> 00:01:54,680
Everybody just thinks it's there and it automatically works
41
00:01:54,680 --> 00:01:58,560
because it's like turning your tap water on,
42
00:01:58,560 --> 00:02:00,040
it just flows water, right?
43
00:02:00,040 --> 00:02:01,040
It's simple,
44
00:02:01,040 --> 00:02:05,440
but nobody actually sees what's all going on
45
00:02:05,440 --> 00:02:06,360
in the background.
46
00:02:06,360 --> 00:02:13,440
- Yeah, so before we get into AI and organisms
47
00:02:13,440 --> 00:02:16,160
and let's start with your background,
48
00:02:16,160 --> 00:02:20,040
how did you originally get into integrations?
49
00:02:21,040 --> 00:02:23,760
- I accidentally roll into it.
50
00:02:23,760 --> 00:02:27,840
And that is because at the A-A previous employer,
51
00:02:27,840 --> 00:02:32,040
I was a part of what they called a Microsoft team.
52
00:02:32,040 --> 00:02:33,440
So I thought, okay, that's cool.
53
00:02:33,440 --> 00:02:34,600
I'm a Microsoft fan,
54
00:02:34,600 --> 00:02:36,720
so I'm gonna do stuff with Microsoft
55
00:02:36,720 --> 00:02:41,800
and I thought this would be SharePoint and Forms and List
56
00:02:41,800 --> 00:02:45,360
and you know, all that kind of M365 kind of topics.
57
00:02:45,360 --> 00:02:48,320
But before I actually knew it,
58
00:02:48,320 --> 00:02:51,120
I was already working with Azure Logic Apps,
59
00:02:51,120 --> 00:02:54,040
building integrations with SAP.
60
00:02:54,040 --> 00:02:58,840
It was primarily focused around M365 still
61
00:02:58,840 --> 00:03:01,800
because that was, we used SharePoint as a UI
62
00:03:01,800 --> 00:03:04,640
to actually visualize the process,
63
00:03:04,640 --> 00:03:08,960
but my main work was integration at that point.
64
00:03:08,960 --> 00:03:12,040
And well, going forward,
65
00:03:12,040 --> 00:03:15,240
I noticed that this was actually a thing,
66
00:03:15,240 --> 00:03:19,880
yeah, it's really in my veins, in my DNA,
67
00:03:19,880 --> 00:03:24,520
I really like to integrate systems obviously,
68
00:03:24,520 --> 00:03:27,840
but I noticed that integration goes far beyond systems
69
00:03:27,840 --> 00:03:30,400
because we're actually connecting people here.
70
00:03:30,400 --> 00:03:34,000
- Yeah, yeah.
71
00:03:34,000 --> 00:03:35,840
But I found really interesting,
72
00:03:35,840 --> 00:03:38,080
you just drive yourself as someone
73
00:03:38,080 --> 00:03:40,640
who makes complex integrations simple.
74
00:03:40,640 --> 00:03:43,360
What makes enterprise integrations?
75
00:03:43,360 --> 00:03:46,480
So complex in the first place?
76
00:03:46,480 --> 00:03:52,240
- Well, in my opinion, it's basically because enterprises
77
00:03:52,240 --> 00:03:55,360
tend to make processes complex.
78
00:03:55,360 --> 00:03:57,800
And especially when ERP is involved
79
00:03:57,800 --> 00:04:01,720
because at first I thought it's SAP that makes things complex,
80
00:04:01,720 --> 00:04:03,000
but that's not actually true
81
00:04:03,000 --> 00:04:06,680
because Microsoft Dynamics ERP also makes things complex
82
00:04:06,680 --> 00:04:09,560
because ERP is a complex process.
83
00:04:09,560 --> 00:04:12,640
It has a lot of movements and everything has to be audited
84
00:04:12,640 --> 00:04:15,280
because basically it's just financial transactions,
85
00:04:15,280 --> 00:04:17,000
or let's say transactions.
86
00:04:17,000 --> 00:04:22,000
So it's a reasonable why it is a complex.
87
00:04:22,000 --> 00:04:25,960
And with that in mind,
88
00:04:25,960 --> 00:04:28,320
there are a lot of different departments involved
89
00:04:28,320 --> 00:04:31,560
and everybody has its own gut feeling,
90
00:04:31,560 --> 00:04:34,560
which actually counts because a lot of information
91
00:04:34,560 --> 00:04:37,000
and knowledge is stored in heads still.
92
00:04:37,000 --> 00:04:40,480
So well, with that in account,
93
00:04:40,480 --> 00:04:45,480
you just noticed that because the processes are complex,
94
00:04:45,480 --> 00:04:48,040
integration becomes complex as well.
95
00:04:48,040 --> 00:04:50,800
And my idea with my statement and need
96
00:04:50,800 --> 00:04:53,280
to make complex integrations simple
97
00:04:53,280 --> 00:04:55,520
is to boil down to the base question,
98
00:04:55,520 --> 00:04:58,040
basically what every consultant does
99
00:04:58,040 --> 00:05:00,360
or at least should do in my opinion,
100
00:05:00,360 --> 00:05:03,440
is not answering the question that they ask,
101
00:05:03,440 --> 00:05:06,800
but going deeper into what do you actually want?
102
00:05:06,800 --> 00:05:07,960
What is your question?
103
00:05:07,960 --> 00:05:12,560
And how can we help you in being your better self
104
00:05:12,560 --> 00:05:14,160
and perform your job better?
105
00:05:14,160 --> 00:05:20,040
- Yeah, this is complexity usually caused by the technology
106
00:05:20,040 --> 00:05:25,920
itself or by years of architectural,
107
00:05:25,920 --> 00:05:28,960
the system accumulated on the pub of each other.
108
00:05:28,960 --> 00:05:35,000
- I think the latter one because basically,
109
00:05:35,000 --> 00:05:37,960
and at least nowadays technique is something
110
00:05:37,960 --> 00:05:39,960
that everybody can learn.
111
00:05:39,960 --> 00:05:43,080
And with AI, we're going to that topic in a moment,
112
00:05:43,080 --> 00:05:45,120
but with AI in mind,
113
00:05:45,120 --> 00:05:49,240
the technique isn't a complex part anymore.
114
00:05:49,240 --> 00:05:53,840
Everybody can do it, but the trick here is to make sure
115
00:05:53,840 --> 00:05:58,840
that we as people get what we want, basically,
116
00:05:58,840 --> 00:06:03,640
that's the only thing because we used to have an IT landscape
117
00:06:03,640 --> 00:06:06,480
where IT simply dictates what you need.
118
00:06:06,480 --> 00:06:09,000
And if IT installed an application,
119
00:06:09,000 --> 00:06:11,520
you as business should use it.
120
00:06:11,520 --> 00:06:16,520
But that is now a thing of the past because at this day and age,
121
00:06:16,520 --> 00:06:21,000
we basically want the business to tell IT what they need
122
00:06:21,000 --> 00:06:22,360
and we're going to support them.
123
00:06:22,360 --> 00:06:28,360
- Yeah, yeah, we have all these low code,
124
00:06:28,360 --> 00:06:32,440
to no code, my code, integrations, now, yeah.
125
00:06:32,440 --> 00:06:37,440
But what separates a good integration architecture
126
00:06:37,440 --> 00:06:42,520
from one that really happens to work?
127
00:06:42,520 --> 00:06:50,720
- There are several topics that make a good integration.
128
00:06:50,720 --> 00:06:56,960
One of the main one is that the reusability is high.
129
00:06:56,960 --> 00:07:00,920
And nowadays we say composable architecture.
130
00:07:00,920 --> 00:07:05,920
So one could just grab a part and use it for its own purpose.
131
00:07:05,920 --> 00:07:12,160
That's one thing because simply rethinking everything through
132
00:07:12,160 --> 00:07:16,560
and through again, that's not making any progress,
133
00:07:16,560 --> 00:07:20,280
or at least not the SPS companies should do in this day,
134
00:07:20,280 --> 00:07:22,200
especially with AI.
135
00:07:22,200 --> 00:07:25,040
So that's one thing and obviously there's security
136
00:07:25,880 --> 00:07:30,880
because the availability of an integration is also determined
137
00:07:30,880 --> 00:07:34,840
by the level of security you're adding
138
00:07:34,840 --> 00:07:39,360
because if you have a bridge, or at least say you want to avoid
139
00:07:39,360 --> 00:07:40,200
bridges.
140
00:07:40,200 --> 00:07:44,720
So I think those are the two most interesting topics
141
00:07:44,720 --> 00:07:48,880
to distinguish a good integration from a,
142
00:07:48,880 --> 00:07:50,680
maybe not so good integration.
143
00:07:50,680 --> 00:07:55,480
- Yeah, that is the foundation.
144
00:07:55,480 --> 00:07:59,160
Microsoft used the term Azure integration service,
145
00:07:59,160 --> 00:08:04,160
but that includes several different technologies.
146
00:08:04,160 --> 00:08:06,400
When you say integration service,
147
00:08:06,400 --> 00:08:10,080
what exactly falls under that umbrella?
148
00:08:10,080 --> 00:08:13,160
- That is a good question.
149
00:08:13,160 --> 00:08:17,160
Basically what you have with that is Azure Logic Apps.
150
00:08:17,160 --> 00:08:20,520
That's one thing, so that's the low code perspective.
151
00:08:20,520 --> 00:08:23,560
You have API management because that's your gateway
152
00:08:23,560 --> 00:08:26,960
to everything you built also for AI.
153
00:08:26,960 --> 00:08:31,920
There is a debate that Azure functions
154
00:08:31,920 --> 00:08:34,080
because you can use it more broadly,
155
00:08:34,080 --> 00:08:38,800
falls also falls under the Azure integration services umbrella
156
00:08:38,800 --> 00:08:40,560
because you can integrate with it
157
00:08:40,560 --> 00:08:43,400
and at some point you shoot because Logic Apps,
158
00:08:43,400 --> 00:08:48,080
low code is super cool, but it lacks at points where pro code
159
00:08:48,080 --> 00:08:53,080
can simply, yeah, well, fix a problem better or sooner.
160
00:08:53,960 --> 00:08:57,440
So that's one and we've got Azure ServiceBuzz,
161
00:08:57,440 --> 00:08:59,800
which makes an integration decoupled.
162
00:08:59,800 --> 00:09:04,280
So then you've got no A to B kind of connections,
163
00:09:04,280 --> 00:09:07,520
but you've got A to ServiceBuzz to B to make sure
164
00:09:07,520 --> 00:09:12,440
that it's always decoupled and it makes an integration
165
00:09:12,440 --> 00:09:15,400
repeatable and reprocessable at the point
166
00:09:15,400 --> 00:09:18,280
where you wanna hook into your integration again.
167
00:09:18,280 --> 00:09:22,920
Then we've also got EventGrid, which is something
168
00:09:22,920 --> 00:09:27,160
maybe or maybe not with EventHub
169
00:09:27,160 --> 00:09:29,400
because that's basically telemetricized,
170
00:09:29,400 --> 00:09:33,680
which can also be used for IoT,
171
00:09:33,680 --> 00:09:36,560
but in a sense, IoT is also maybe integration
172
00:09:36,560 --> 00:09:39,720
because we're simply connecting again.
173
00:09:39,720 --> 00:09:42,880
And I think those are the main,
174
00:09:42,880 --> 00:09:46,200
I'm thinking, now am I forgetting something?
175
00:09:46,200 --> 00:09:47,880
I don't think I forgot a big one.
176
00:09:49,120 --> 00:09:52,880
I think we had Azure Logic Apps, Azure Functions,
177
00:09:52,880 --> 00:09:55,880
Azure ServiceBuzz, Azure EventGrid,
178
00:09:55,880 --> 00:09:57,640
Azure Management.
179
00:09:57,640 --> 00:09:59,880
I think that's the big five.
180
00:09:59,880 --> 00:10:08,080
But is there a simple, mental model architect can use
181
00:10:08,080 --> 00:10:12,840
when deciding which service should solve which problem?
182
00:10:15,120 --> 00:10:21,960
It depends on your company and I know that is a consultancy answer
183
00:10:21,960 --> 00:10:25,440
because in consultancy there's not always a one-off
184
00:10:25,440 --> 00:10:28,400
or maybe let's say almost never.
185
00:10:28,400 --> 00:10:33,960
Because if your company is fully into low code
186
00:10:33,960 --> 00:10:38,200
and has developers that actually love to low code,
187
00:10:38,200 --> 00:10:40,960
then Azure Logic Apps makes sense to use.
188
00:10:40,960 --> 00:10:45,320
And API Management has predefined policies which are also
189
00:10:45,320 --> 00:10:46,640
low code in a way.
190
00:10:46,640 --> 00:10:50,240
It looks like XML, but it's not actually that.
191
00:10:50,240 --> 00:10:52,520
So from that perspective, if your company is like that
192
00:10:52,520 --> 00:10:56,240
then that would be a choice you can make.
193
00:10:56,240 --> 00:10:58,360
On the other hand, if you've got a company
194
00:10:58,360 --> 00:11:01,720
with a set of dot net developers and they like ProCode,
195
00:11:01,720 --> 00:11:06,560
then maybe it's best to use Azure Functions
196
00:11:06,560 --> 00:11:08,440
together with Azure API Management
197
00:11:08,440 --> 00:11:12,760
and also an API Management even though they're predefined templates,
198
00:11:12,760 --> 00:11:16,480
you can also make use of a C#.
199
00:11:16,480 --> 00:11:18,880
It's not full C#, so it's not the entire stack,
200
00:11:18,880 --> 00:11:21,520
but still you can also add in code.
201
00:11:21,520 --> 00:11:24,760
I think Azure ServiceBuzz in my opinion
202
00:11:24,760 --> 00:11:26,640
should never be a debate.
203
00:11:26,640 --> 00:11:30,960
At least not for the, let's say the backend processing.
204
00:11:30,960 --> 00:11:33,040
If you want to have a synchronous call
205
00:11:33,040 --> 00:11:35,480
where you call an API and get a response
206
00:11:35,480 --> 00:11:37,680
then maybe ServiceBuzz isn't good to add in
207
00:11:37,680 --> 00:11:42,680
because it adds, it lowers the speed of your integration.
208
00:11:42,680 --> 00:11:46,600
And so it lowers the UX obviously.
209
00:11:46,600 --> 00:11:52,440
But from for a couple of purposes and backend processing,
210
00:11:52,440 --> 00:11:54,160
I would always advise ServiceBuzz.
211
00:11:54,160 --> 00:11:56,000
- Good.
212
00:11:56,000 --> 00:11:56,840
- Okay.
213
00:11:56,840 --> 00:11:59,600
- Yeah, that's interesting.
214
00:11:59,600 --> 00:12:03,880
Let's focus especially on your strongest area.
215
00:12:03,880 --> 00:12:05,680
I think the Azure logic adds,
216
00:12:06,760 --> 00:12:10,160
what makes logic adds interesting enough
217
00:12:10,160 --> 00:12:12,160
for you to a special live in them?
218
00:12:12,160 --> 00:12:15,760
- Jeez, that's a good question.
219
00:12:15,760 --> 00:12:22,960
I think mainly because I'm not a developer by heart.
220
00:12:22,960 --> 00:12:27,280
So I can read C# code and I can write it,
221
00:12:27,280 --> 00:12:29,240
but not as fast as any developer would.
222
00:12:29,240 --> 00:12:34,080
So that's a part because low code is better understandable for me.
223
00:12:34,080 --> 00:12:35,720
I can think as an application
224
00:12:35,720 --> 00:12:38,280
because that's still what you need for logic apps.
225
00:12:38,280 --> 00:12:42,320
But I can't write them in pro code in a good speed.
226
00:12:42,320 --> 00:12:45,840
So that's one thing but also on the other hand,
227
00:12:45,840 --> 00:12:49,800
when you're coding in a function, for example,
228
00:12:49,800 --> 00:12:52,160
you have to make sure your monitoring is in place,
229
00:12:52,160 --> 00:12:53,760
you're logging at the correct points,
230
00:12:53,760 --> 00:12:57,680
it's not visible until you make it visible.
231
00:12:57,680 --> 00:12:59,880
And in an Azure logic app, it's just a canvas.
232
00:12:59,880 --> 00:13:02,520
So as soon as you run your first logic app,
233
00:13:02,520 --> 00:13:05,240
you can see what it did, why it did it,
234
00:13:05,240 --> 00:13:06,400
what's the result?
235
00:13:06,400 --> 00:13:11,360
And it has basically automatic troubleshooting options already present.
236
00:13:11,360 --> 00:13:15,480
So you have to think less on the overhead of coding
237
00:13:15,480 --> 00:13:18,400
and more on the process you're actually supporting.
238
00:13:18,400 --> 00:13:27,480
- What do developers typically misunderstand
239
00:13:27,480 --> 00:13:29,320
about logic apps?
240
00:13:31,080 --> 00:13:37,600
- I think that, and I know it's, I have to be careful
241
00:13:37,600 --> 00:13:39,240
what I'm going to say right now.
242
00:13:39,240 --> 00:13:44,040
But most developers simply want to write code
243
00:13:44,040 --> 00:13:46,960
and have a feel that they're faster
244
00:13:46,960 --> 00:13:49,280
when they're writing their own code.
245
00:13:49,280 --> 00:13:52,760
And at some points, I may even believe they're right.
246
00:13:52,760 --> 00:13:57,480
However, for quick integrations
247
00:13:57,480 --> 00:14:02,120
and for setting up stuff and to lower your overhead,
248
00:14:02,120 --> 00:14:04,240
a logic app can help in that part.
249
00:14:04,240 --> 00:14:08,440
But it's also kind of what you're used to using, right?
250
00:14:08,440 --> 00:14:13,440
Because if you're a, let's say, back in the day,
251
00:14:13,440 --> 00:14:17,040
I made applications, as you call it,
252
00:14:17,040 --> 00:14:22,040
with Excel and in football, and with access.
253
00:14:22,040 --> 00:14:25,400
And that's also a low code kind of way
254
00:14:25,400 --> 00:14:27,000
of setting up applications.
255
00:14:27,000 --> 00:14:32,000
So by nature, I'm fitting in the logic app perspective already.
256
00:14:32,000 --> 00:14:35,560
And coders do not, because the syntax is different,
257
00:14:35,560 --> 00:14:38,520
you have predefined functions instead of your own function.
258
00:14:38,520 --> 00:14:43,000
So it adds a feel of limitation there.
259
00:14:43,000 --> 00:14:47,080
However, at this point, there are also code full workflows.
260
00:14:47,080 --> 00:14:49,400
And code full workflows try to bridge that gap
261
00:14:49,400 --> 00:14:54,400
where you can use the logic app perspective in a pro code setting.
262
00:14:55,040 --> 00:14:56,840
OK.
263
00:14:56,840 --> 00:14:58,840
Interesting.
264
00:14:58,840 --> 00:14:59,840
Interesting.
265
00:14:59,840 --> 00:15:09,360
I think a little bit involved, or what I think it's,
266
00:15:09,360 --> 00:15:15,360
showed logic apps always be treated as code
267
00:15:15,360 --> 00:15:21,360
and deployed through CI and CD, or how is it working?
268
00:15:22,680 --> 00:15:25,400
I think that would be the best approach,
269
00:15:25,400 --> 00:15:31,240
because you can create your logic app in a def environment,
270
00:15:31,240 --> 00:15:34,800
for example, and then export the ARM template and import it
271
00:15:34,800 --> 00:15:39,560
again into your Azure environment, be it through CI, CD,
272
00:15:39,560 --> 00:15:43,280
but there's always that one moment where you actually
273
00:15:43,280 --> 00:15:47,520
forgot to copy it over, and then you've got differences
274
00:15:47,520 --> 00:15:48,640
between your environments.
275
00:15:48,640 --> 00:15:55,440
And that can be hazardous to your total operation, basically.
276
00:15:55,440 --> 00:15:59,600
So in my opinion, it's best to always work from CI, CD,
277
00:15:59,600 --> 00:16:03,080
but with that said, if you're now using logic app consumption,
278
00:16:03,080 --> 00:16:09,720
which is the Bayeshi Go kind of way, then you have to take it
279
00:16:09,720 --> 00:16:12,240
to account that the local development, for example,
280
00:16:12,240 --> 00:16:15,840
is a bit trickier, whereas the logic app standard
281
00:16:15,840 --> 00:16:19,520
that provides a designer from VS Code.
282
00:16:19,520 --> 00:16:22,680
So those are parts that you should take into consideration.
283
00:16:22,680 --> 00:16:26,080
OK.
284
00:16:26,080 --> 00:16:33,200
I think, how did the the the the the
285
00:16:33,200 --> 00:16:37,760
the esologic apps in, I think, one of the yeah,
286
00:16:37,760 --> 00:16:40,640
infrastructure topics I often speak about,
287
00:16:40,640 --> 00:16:43,680
it's infrastructure as code.
288
00:16:43,680 --> 00:16:47,640
Yeah. What role do is logic apps here play?
289
00:16:47,640 --> 00:16:53,160
Well, logic apps is basically the part of Azure that you
290
00:16:53,160 --> 00:16:56,000
deploy through in for infrastructure as code.
291
00:16:56,000 --> 00:16:58,680
It's not so well.
292
00:16:58,680 --> 00:17:03,080
Let me refresh that it could support deploying infrastructure
293
00:17:03,080 --> 00:17:08,240
as code, so it could you could use a logic app for pre deployment
294
00:17:08,240 --> 00:17:12,120
steps, post deployment steps, use the API and use it in your
295
00:17:12,120 --> 00:17:16,920
infrastructure as code flow, but as we see it now,
296
00:17:16,920 --> 00:17:21,480
I mainly see environments where logic apps are simply deployed
297
00:17:21,480 --> 00:17:23,720
as infrastructure as code.
298
00:17:23,720 --> 00:17:31,560
OK. And what what rule do things like by set terraform and
299
00:17:31,560 --> 00:17:35,960
out templates play in as a logic app project?
300
00:17:35,960 --> 00:17:39,960
Yeah, well, they basically make your integration because that's
301
00:17:39,960 --> 00:17:43,440
the deterministic language that.
302
00:17:43,440 --> 00:17:46,400
Yeah, well, that's why they call it deterministic baby.
303
00:17:46,400 --> 00:17:49,600
It determines what your logic app looks like.
304
00:17:49,600 --> 00:17:52,040
So it it provides this SKU.
305
00:17:52,040 --> 00:17:54,320
It provides a location.
306
00:17:54,320 --> 00:17:56,040
It provides the resource groups.
307
00:17:56,040 --> 00:17:59,600
All that kind of information is stored into either a bicep,
308
00:17:59,600 --> 00:18:03,720
which is basically in the back and translated to a AM.
309
00:18:03,720 --> 00:18:06,600
So those are related.
310
00:18:06,600 --> 00:18:09,400
I wouldn't say they're the same, but bicep lowers
311
00:18:09,400 --> 00:18:13,280
the duplication that a ram natively has.
312
00:18:13,280 --> 00:18:18,360
And terraform is also a way of deploying your infrastructure as code.
313
00:18:18,360 --> 00:18:24,400
So it's supporting the deployment basically.
314
00:18:24,400 --> 00:18:25,840
OK.
315
00:18:25,840 --> 00:18:30,400
You say before we have to talk about consumption and logic
316
00:18:30,400 --> 00:18:32,360
at standards.
317
00:18:32,360 --> 00:18:37,120
I think, yeah, this is it.
318
00:18:37,120 --> 00:18:39,280
It's people like me.
319
00:18:39,280 --> 00:18:45,640
It's got a little bit of the confusing when we look at it.
320
00:18:45,640 --> 00:18:48,880
I'm not so used to it.
321
00:18:48,880 --> 00:18:55,720
How do you explain logic app consumption versus logic app standard?
322
00:18:55,720 --> 00:18:58,120
It's basically rather simple.
323
00:18:58,120 --> 00:19:02,560
And I can understand that it may sound confusing at times.
324
00:19:02,560 --> 00:19:05,640
But the consumption is pay as you go.
325
00:19:05,640 --> 00:19:10,480
So that's on a managed platform, which is managed by Microsoft.
326
00:19:10,480 --> 00:19:13,200
So basically you're building your workflows there.
327
00:19:13,200 --> 00:19:16,520
And you pay as much as you use it.
328
00:19:16,520 --> 00:19:19,920
And obviously there's degradation in what you pay actually,
329
00:19:19,920 --> 00:19:22,440
because if you call SAP, that's more expensive than where
330
00:19:22,440 --> 00:19:24,720
you call an HTTP trigger, for example.
331
00:19:24,720 --> 00:19:26,280
So those are the parts.
332
00:19:26,280 --> 00:19:29,400
But it's fractions of cents that we're
333
00:19:29,400 --> 00:19:31,120
talking about for every execution.
334
00:19:31,120 --> 00:19:35,600
And eventually that will turn into 10 or 100 of euros a month.
335
00:19:35,600 --> 00:19:39,360
But you're never actually quite sure on what your bill will look
336
00:19:39,360 --> 00:19:41,360
like at the end of the month.
337
00:19:41,360 --> 00:19:46,840
Standard is a reserved capacity, basically.
338
00:19:46,840 --> 00:19:48,680
So it's running on your own service plan.
339
00:19:48,680 --> 00:19:50,680
So you have your own compute.
340
00:19:50,680 --> 00:19:54,120
And within that compute, you run your workflows.
341
00:19:54,120 --> 00:19:59,840
So basically you're not only building your workflows
342
00:19:59,840 --> 00:20:01,640
anymore like you would with consumption.
343
00:20:01,640 --> 00:20:06,320
You're now also managing a server in a sense, because you have
344
00:20:06,320 --> 00:20:10,640
to make sure that your compute is capable of running the workload
345
00:20:10,640 --> 00:20:12,960
you're aiming at.
346
00:20:12,960 --> 00:20:14,240
And that's the difference between the two.
347
00:20:14,240 --> 00:20:17,040
And to make it even more complex, we now also
348
00:20:17,040 --> 00:20:22,240
have logic app automation in public preview.
349
00:20:22,240 --> 00:20:24,680
And logic app automation is basically
350
00:20:24,680 --> 00:20:28,640
the power of logic app consumption, the pay as you go model,
351
00:20:28,640 --> 00:20:33,960
with the power of logic app standard, the reserved compute,
352
00:20:33,960 --> 00:20:37,160
and all network isolation, and basically the infrastructure
353
00:20:37,160 --> 00:20:38,360
side of that.
354
00:20:38,360 --> 00:20:41,800
And on top of that, they put AI to let it build your workflows.
355
00:20:41,800 --> 00:20:45,640
So you cannot-- you don't have to actually click your workflow
356
00:20:45,640 --> 00:20:46,480
together anymore.
357
00:20:46,480 --> 00:20:48,840
You can just explain your intent.
358
00:20:48,840 --> 00:20:51,000
And logic app automation will create it for you.
359
00:20:51,000 --> 00:20:55,120
Yeah.
360
00:20:55,120 --> 00:21:00,680
I think one topic or a bigger topic, it's--
361
00:21:00,680 --> 00:21:05,080
yeah, logic app has a side on one side.
362
00:21:05,080 --> 00:21:07,920
It's a superpower, and then on the other side,
363
00:21:07,920 --> 00:21:08,720
it's like a trap.
364
00:21:08,720 --> 00:21:15,520
And I think one of the biggest, from my perspective,
365
00:21:15,520 --> 00:21:20,680
setting points of logic is the connector ecosystem.
366
00:21:20,680 --> 00:21:25,960
How important are these connectors to a false success
367
00:21:25,960 --> 00:21:27,520
of logic apps?
368
00:21:27,520 --> 00:21:31,640
I think they're majorly important.
369
00:21:31,640 --> 00:21:34,840
And on top of that, Microsoft decided
370
00:21:34,840 --> 00:21:37,440
to bring the connectors out of logic apps.
371
00:21:37,440 --> 00:21:40,680
So we're back in the day, and I'm talking back in the day
372
00:21:40,680 --> 00:21:43,120
is a month to go, right?
373
00:21:43,120 --> 00:21:46,200
You had to create a logic app to make use of those connectors,
374
00:21:46,200 --> 00:21:48,880
and those connectors are managed by Microsoft,
375
00:21:48,880 --> 00:21:51,640
so you don't have to worry about API versions,
376
00:21:51,640 --> 00:21:53,920
and what do I need to call, et cetera.
377
00:21:53,920 --> 00:21:57,280
That's all managed by Microsoft, so you're basically
378
00:21:57,280 --> 00:22:01,640
leaving some overhead behind because Microsoft takes care of that.
379
00:22:01,640 --> 00:22:06,360
But nowadays, you've got Azure Connector namespace, which
380
00:22:06,360 --> 00:22:09,800
is basically the logic app connector.
381
00:22:09,800 --> 00:22:13,880
But now it's placed as a separate resource in Azure,
382
00:22:13,880 --> 00:22:16,000
so you can also use it in your function,
383
00:22:16,000 --> 00:22:18,280
or you can use it in your own code in a web app
384
00:22:18,280 --> 00:22:20,840
or whatever, you can use it everywhere within Azure.
385
00:22:20,840 --> 00:22:25,480
So basically, you're using the power of that managed connector
386
00:22:25,480 --> 00:22:28,840
outside of logic apps now.
387
00:22:28,840 --> 00:22:35,280
Yeah, yeah, it sounds--
388
00:22:35,280 --> 00:22:39,800
yeah, it sounds-- yeah, it's a little bit easy.
389
00:22:39,800 --> 00:22:43,440
But the Duke connector sometimes--
390
00:22:43,440 --> 00:22:43,960
yeah.
391
00:22:47,400 --> 00:22:49,400
I don't know.
392
00:22:49,400 --> 00:22:52,200
Yeah.
393
00:22:52,200 --> 00:22:57,120
Is there something--
394
00:22:57,120 --> 00:23:00,720
I think-- use my connector and click-click.
395
00:23:00,720 --> 00:23:01,520
I'm ready.
396
00:23:01,520 --> 00:23:08,480
So is it really this or looks like it's only like the simple?
397
00:23:08,480 --> 00:23:10,960
It's basically both.
398
00:23:10,960 --> 00:23:15,240
And the reason I'm saying it like that is, yes, you can click-click,
399
00:23:15,240 --> 00:23:17,160
and then you're ready.
400
00:23:17,160 --> 00:23:19,120
So that's one part of the story.
401
00:23:19,120 --> 00:23:24,680
But as you correctly mentioned, logic app sounds like a superpower.
402
00:23:24,680 --> 00:23:28,840
But a super hero, and I can't remember rich,
403
00:23:28,840 --> 00:23:32,120
said, great power comes with great responsibility.
404
00:23:32,120 --> 00:23:35,520
And that is basically the same with logic apps,
405
00:23:35,520 --> 00:23:37,760
with the connector namespaces, et cetera,
406
00:23:37,760 --> 00:23:40,360
because, and then we're revolving back to the beginning
407
00:23:40,360 --> 00:23:43,640
of this podcast where we talked about what
408
00:23:43,640 --> 00:23:45,880
makes a good integration.
409
00:23:45,880 --> 00:23:50,360
Security, for example, is a great thing.
410
00:23:50,360 --> 00:23:53,920
You really need to think through about how to set it up,
411
00:23:53,920 --> 00:23:58,000
because, sure, we can give a connection access to a system,
412
00:23:58,000 --> 00:24:00,040
and then it can freely do anything.
413
00:24:00,040 --> 00:24:01,440
But is that really what we want?
414
00:24:01,440 --> 00:24:03,040
Or is there a risk involved?
415
00:24:03,040 --> 00:24:07,280
And can if we got access to a table, for example,
416
00:24:07,280 --> 00:24:09,320
do we want that full table exposed?
417
00:24:09,320 --> 00:24:12,760
Or do we only want several fields of the table exposed?
418
00:24:12,760 --> 00:24:17,880
So from that behalf, you really need to think through on what
419
00:24:17,880 --> 00:24:19,800
am I actually trying to achieve here?
420
00:24:19,800 --> 00:24:20,840
What are the risks?
421
00:24:20,840 --> 00:24:24,440
And how can I mitigate the gap between those?
422
00:24:24,440 --> 00:24:27,680
Because that's still--
423
00:24:27,680 --> 00:24:30,840
even though it is click-click, you really
424
00:24:30,840 --> 00:24:34,600
need to think about your setup and your infrastructure.
425
00:24:34,600 --> 00:24:39,240
So we're in Azure, we're in the Cloud, it's super cool.
426
00:24:39,240 --> 00:24:42,040
But still, it's also an infrastructure project.
427
00:24:42,520 --> 00:24:52,000
Is there any limitations on architect-should evaluate
428
00:24:52,000 --> 00:24:55,360
before using managed connector?
429
00:24:55,360 --> 00:24:57,520
Yes, there are several.
430
00:24:57,520 --> 00:25:00,720
Depending on the connector, you have to make sure
431
00:25:00,720 --> 00:25:08,360
that one simple example for is does it use a user to connect,
432
00:25:08,360 --> 00:25:10,880
or does it use an app to connect?
433
00:25:10,880 --> 00:25:14,360
Because if I'm connecting as a user, let's say,
434
00:25:14,360 --> 00:25:17,400
I'm using the user Mirko.
435
00:25:17,400 --> 00:25:20,320
That would mean that if there's also another trial
436
00:25:20,320 --> 00:25:25,240
in the system, my integration will act on behalf of you
437
00:25:25,240 --> 00:25:29,480
making every other trial leading back to you.
438
00:25:29,480 --> 00:25:31,840
But because other people use that integration,
439
00:25:31,840 --> 00:25:33,760
it might not even be you.
440
00:25:33,760 --> 00:25:37,240
It might be someone at a desk somewhere in the company.
441
00:25:37,240 --> 00:25:39,320
And that is a security risk.
442
00:25:39,320 --> 00:25:43,960
Because you get hit by security that you change something,
443
00:25:43,960 --> 00:25:46,560
which you didn't, because someone else in the integration
444
00:25:46,560 --> 00:25:47,440
did it.
445
00:25:47,440 --> 00:25:50,560
So those are parts that you also need to think through.
446
00:25:50,560 --> 00:25:53,520
With AI in perspective, you have to think about user
447
00:25:53,520 --> 00:25:58,280
permissions again, because AI will act as the user.
448
00:25:58,280 --> 00:26:01,400
Because if you have access to it, and AI can have access to it.
449
00:26:01,400 --> 00:26:04,880
But if you don't, then it's not a good thing if your AI connects
450
00:26:04,880 --> 00:26:07,600
as an app and provides you everything that the app has.
451
00:26:07,600 --> 00:26:10,240
So we're shifting again to that perspective.
452
00:26:10,240 --> 00:26:15,000
So you really need to think on what otherizations do I need?
453
00:26:15,000 --> 00:26:16,200
And how do I embed that?
454
00:26:16,200 --> 00:26:19,360
And how do I make sure that it always
455
00:26:19,360 --> 00:26:22,040
beats back to the correct?
456
00:26:22,040 --> 00:26:25,680
Yeah, let's say a point of failure.
457
00:26:25,680 --> 00:26:26,480
And then the--
458
00:26:26,480 --> 00:26:28,680
Yeah.
459
00:26:28,680 --> 00:26:29,760
Yeah.
460
00:26:29,760 --> 00:26:32,720
I think we have--
461
00:26:32,720 --> 00:26:36,600
if we are for ways to integrate--
462
00:26:36,600 --> 00:26:44,200
for integrations-- when should you use a built-in connector,
463
00:26:44,200 --> 00:26:46,680
a managed connector, a custom connector,
464
00:26:46,680 --> 00:26:49,880
or simply call API directly?
465
00:26:49,880 --> 00:26:56,920
Our main objective is to always use built-in connectors
466
00:26:56,920 --> 00:27:00,160
when you can, because the built-in connectors
467
00:27:00,160 --> 00:27:03,200
are running within the logic app runtime.
468
00:27:03,200 --> 00:27:06,120
So are basically part of your integration,
469
00:27:06,120 --> 00:27:07,520
are really part of your integration,
470
00:27:07,520 --> 00:27:10,440
whereas the managed connector is managed by Microsoft.
471
00:27:10,440 --> 00:27:12,240
So it always leaves your environment.
472
00:27:12,240 --> 00:27:15,920
And with a built-in, that's not the case.
473
00:27:15,920 --> 00:27:18,200
Usually, and especially at this point,
474
00:27:18,200 --> 00:27:21,600
it could potentially have a better support
475
00:27:21,600 --> 00:27:23,920
for the connectors you're aiming at.
476
00:27:23,920 --> 00:27:28,320
And then you're connecting to a system that's not known,
477
00:27:28,320 --> 00:27:30,480
or you're using your own API management,
478
00:27:30,480 --> 00:27:33,760
because Microsoft best practices to basically use your API
479
00:27:33,760 --> 00:27:36,800
as the central gateway of all your connections.
480
00:27:36,800 --> 00:27:39,360
Then that could be a perfect custom connector.
481
00:27:39,360 --> 00:27:44,600
OK.
482
00:27:44,600 --> 00:27:51,560
How did we handle the authentication and credential management
483
00:27:51,560 --> 00:27:55,800
properly in logic app?
484
00:27:55,800 --> 00:27:59,520
Yeah, well, basically you have to look at,
485
00:27:59,520 --> 00:28:02,920
and you mean from what the logic app uses, right?
486
00:28:02,920 --> 00:28:04,600
Not the one who's calling the logic app,
487
00:28:04,600 --> 00:28:06,360
because there's also a difference there.
488
00:28:06,360 --> 00:28:08,400
OK.
489
00:28:08,400 --> 00:28:11,280
The best practice would always be,
490
00:28:11,280 --> 00:28:15,440
would always go for the least-prince privileged.
491
00:28:15,440 --> 00:28:19,720
So don't make sure you're only providing the access
492
00:28:19,720 --> 00:28:23,720
and alterations that are necessary for that logic app.
493
00:28:23,720 --> 00:28:26,880
And I'm specifically saying that logic app,
494
00:28:26,880 --> 00:28:30,120
because you could reuse the same credentials
495
00:28:30,120 --> 00:28:32,680
for other logic apps as well.
496
00:28:32,680 --> 00:28:34,760
But it should be as granular as possible,
497
00:28:34,760 --> 00:28:39,000
because if there's a breach, if you kill one connection,
498
00:28:39,000 --> 00:28:41,720
and you're reusing that on every integration,
499
00:28:41,720 --> 00:28:44,400
you're killing your entire integration.
500
00:28:44,400 --> 00:28:49,600
So you should make sure that you can isolate it in a way,
501
00:28:49,600 --> 00:28:53,440
and only provide the right state you need.
502
00:28:53,440 --> 00:28:54,960
OK.
503
00:28:54,960 --> 00:28:58,800
And how important are the managed identities
504
00:28:58,800 --> 00:29:02,200
in modern logic app architectures?
505
00:29:02,200 --> 00:29:04,360
Majorly important.
506
00:29:04,360 --> 00:29:07,160
In my opinion, and I know there are different opinions
507
00:29:07,160 --> 00:29:12,400
on this topic, but the great thing about a managed identity
508
00:29:12,400 --> 00:29:14,840
is that it's part of your resource.
509
00:29:14,840 --> 00:29:18,720
So if you delete the resource, your identity is gone as well.
510
00:29:18,720 --> 00:29:22,560
And because the identity is connected to a resource,
511
00:29:22,560 --> 00:29:25,280
you're also in a way in the least privileged mode,
512
00:29:25,280 --> 00:29:27,200
because only your resource can access it,
513
00:29:27,200 --> 00:29:30,200
because you have to actually provide access
514
00:29:30,200 --> 00:29:32,480
for that specific resource.
515
00:29:32,480 --> 00:29:35,000
You've also got user managed identities,
516
00:29:35,000 --> 00:29:38,040
and I know why people should use them,
517
00:29:38,040 --> 00:29:41,120
because user managed identity is basically
518
00:29:41,120 --> 00:29:44,240
the same kind of principle only not connected to a resource,
519
00:29:44,240 --> 00:29:47,080
but you can connect multiple resources to it.
520
00:29:47,080 --> 00:29:51,040
But with that said, that obviously could potentially expose
521
00:29:51,040 --> 00:29:55,440
the security risk, because orphaned resources, for example,
522
00:29:55,440 --> 00:29:59,680
still have access through that user managed identity.
523
00:29:59,680 --> 00:30:02,840
And in my opinion, if you can use managed identities,
524
00:30:02,840 --> 00:30:07,120
if your environment allows you to, then that would
525
00:30:07,120 --> 00:30:12,240
would always be my recommendation.
526
00:30:12,240 --> 00:30:13,240
OK.
527
00:30:13,240 --> 00:30:25,640
[INAUDIBLE]
528
00:30:25,640 --> 00:30:28,120
Ideally, yes.
529
00:30:28,120 --> 00:30:33,400
Obviously, we're always aiming for the highest possible option,
530
00:30:33,400 --> 00:30:36,640
but we also know we have to deal with legacy.
531
00:30:36,640 --> 00:30:40,320
And some systems, let's take SAP, for example, especially
532
00:30:40,320 --> 00:30:42,760
older ERP versions.
533
00:30:42,760 --> 00:30:48,280
They still use plain basic username and password credentials.
534
00:30:48,280 --> 00:30:50,880
And I know there's something like secure network connections,
535
00:30:50,880 --> 00:30:52,400
and you can set it up with carbrose.
536
00:30:52,400 --> 00:30:55,600
And it's a pain in the ass to connect in the first place.
537
00:30:55,600 --> 00:31:01,400
And it's even more pain in the ass to maintain it while it's running.
538
00:31:01,400 --> 00:31:03,840
So yes, there is to secure it a bit more,
539
00:31:03,840 --> 00:31:10,720
but it really depends on how stable you want your connections to be.
540
00:31:10,720 --> 00:31:14,280
Nowadays, luckily, also SAP is turning more and more
541
00:31:14,280 --> 00:31:17,200
to allow it, for example, and allow it to use a app.
542
00:31:17,200 --> 00:31:20,520
But then again, you should think about whether to use an app or not,
543
00:31:20,520 --> 00:31:24,480
especially in ERP systems like SAP, because there are a lot of information
544
00:31:24,480 --> 00:31:27,480
that can be breached.
545
00:31:27,480 --> 00:31:32,600
But yeah, if there's a possibility to remove the need for keys,
546
00:31:32,600 --> 00:31:37,120
then that would ideally be the best fit.
547
00:31:37,120 --> 00:31:44,840
Yeah, you say of observability, I think, yeah, building the integration
548
00:31:44,840 --> 00:31:51,840
is only the half of the problem, then it comes to operate it.
549
00:31:51,840 --> 00:31:59,760
What does a good observability look like for Azure integration services?
550
00:31:59,760 --> 00:32:02,960
As we're now addressing it is to have,
551
00:32:02,960 --> 00:32:05,520
and then you're also almost coding again,
552
00:32:05,520 --> 00:32:07,960
we're working with a track catch block, for example,
553
00:32:07,960 --> 00:32:11,920
so we're trying to execute an integration and when it fills,
554
00:32:11,920 --> 00:32:16,480
we've got a catch that checks, okay, what error did appear?
555
00:32:16,480 --> 00:32:20,520
And then it should be locked, obviously,
556
00:32:20,520 --> 00:32:25,480
because observability is way more than just logging.
557
00:32:25,480 --> 00:32:28,920
It's also making use of, as we call it, in logic apps,
558
00:32:28,920 --> 00:32:34,640
tracked properties and a tracked property is different from logging in that sense
559
00:32:34,640 --> 00:32:39,360
that you've got the default diagnostics that is sent to log analytics
560
00:32:39,360 --> 00:32:42,120
for an Azure logic apps.
561
00:32:42,120 --> 00:32:45,000
That is something that you could use,
562
00:32:45,000 --> 00:32:48,000
but if you extend that with tracked properties,
563
00:32:48,000 --> 00:32:54,520
you're also adding your own business information to the default Azure diagnostics.
564
00:32:54,520 --> 00:32:57,120
And then you've got the full end-to-end scope,
565
00:32:57,120 --> 00:33:00,400
then you can see what connector failed, for what order was it,
566
00:33:00,400 --> 00:33:03,400
or for what user or for what customer.
567
00:33:03,400 --> 00:33:08,480
And then you've got a full scope, and then obviously to make the observability,
568
00:33:08,480 --> 00:33:15,160
or the observability, a connected story is to also make sure
569
00:33:15,160 --> 00:33:17,480
that you have your dashboards and your metrics,
570
00:33:17,480 --> 00:33:20,880
and that you also can view it in a proper way.
571
00:33:20,880 --> 00:33:25,680
So basically what you want to know is, did my integration run?
572
00:33:25,680 --> 00:33:26,960
Did I see failures?
573
00:33:26,960 --> 00:33:28,840
If it failed, why did it fail?
574
00:33:28,840 --> 00:33:36,080
And that why is in my idea, not a technical, I've got a 500 internal server error,
575
00:33:36,080 --> 00:33:40,200
because then everybody thinks, okay, well, great.
576
00:33:40,200 --> 00:33:47,800
It should be something like, I couldn't process this invoice because it has no invoice number.
577
00:33:47,800 --> 00:33:51,600
So it should, in my opinion, be more like business-driven data.
578
00:33:51,600 --> 00:33:58,800
So you can also move the responsibility for monitoring your entire environment.
579
00:33:58,800 --> 00:34:06,040
So from your own desk to the business who is actually running the operation.
580
00:34:06,040 --> 00:34:14,240
Yeah, what first come in my mind, where is the Azure Monitor?
581
00:34:14,240 --> 00:34:20,560
Yeah, that's one thing that you can use in need.
582
00:34:20,560 --> 00:34:25,440
How do application insights and look at the links?
583
00:34:25,440 --> 00:34:37,440
Yeah, really fit in this picture how we can we use this for getting to do it perfectly from your perspective.
584
00:34:37,440 --> 00:34:41,200
Yeah, well, if you use the default Azure diagnostics,
585
00:34:41,200 --> 00:34:45,640
then you're already logging to Log Analytics.
586
00:34:45,640 --> 00:34:48,440
And you can extend it with your own logging.
587
00:34:48,440 --> 00:34:54,120
There's a connector also for that to connect to a Log Analytics workspace.
588
00:34:54,120 --> 00:35:01,800
And in my opinion, you should make sure that your logging can tell you what happened.
589
00:35:01,800 --> 00:35:04,920
And the or why it happened.
590
00:35:04,920 --> 00:35:10,360
So it explains a bit and your track properties are added on top of that to tell you what,
591
00:35:10,360 --> 00:35:11,680
what where did it happen?
592
00:35:11,680 --> 00:35:16,040
And you know that you can always track.
593
00:35:16,040 --> 00:35:22,720
For a let's let's take the invoice example, the why the invoice isn't processed and why the number isn't present.
594
00:35:22,720 --> 00:35:30,720
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.
595
00:35:30,720 --> 00:35:34,120
And you can just click through the actions and see, oh, oh, I see it.
596
00:35:34,120 --> 00:35:37,720
I have a mapping here, but the mapping field.
597
00:35:37,720 --> 00:35:47,920
Yeah, I think what went a little bit different, but I think when I worked in cybersecurity,
598
00:35:47,920 --> 00:35:56,120
we got these thousands of hundreds of thousands of of alerts.
599
00:35:56,120 --> 00:36:01,920
Nobody pays really attention to because it's too much.
600
00:36:01,920 --> 00:36:04,520
Now we have the security copied of its helps.
601
00:36:04,520 --> 00:36:12,720
Is there anything else for for for the logic caps?
602
00:36:12,720 --> 00:36:15,320
Yeah, well, basically because you're logging to log analytics.
603
00:36:15,320 --> 00:36:22,120
At least that's let's say the default you can obviously use other logging and monitoring solutions as well.
604
00:36:22,120 --> 00:36:35,920
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.
605
00:36:35,920 --> 00:36:43,920
The only thing they're forgetting at that point is that by logging everything, you're also making sure the noise is raising.
606
00:36:43,920 --> 00:36:50,720
And there's so much information basically what you said, there is so much we can look at it all.
607
00:36:50,720 --> 00:36:54,920
So make sure to log only which need.
608
00:36:54,920 --> 00:37:06,320
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.
609
00:37:06,320 --> 00:37:13,520
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.
610
00:37:13,520 --> 00:37:20,720
And for example, and we know did it successfully run or did it fill and if it filled, why did it fill?
611
00:37:20,720 --> 00:37:22,120
And that's all all there's to it.
612
00:37:22,120 --> 00:37:27,320
You can add multiple actions and log everything and it just doesn't make sense.
613
00:37:27,320 --> 00:37:36,720
You only need to you really need to think of what should you log because also the security copilot and basically every AI application.
614
00:37:36,720 --> 00:37:41,720
If you provide it with too much context, the results are getting bloated.
615
00:37:41,720 --> 00:37:45,520
Yeah, yeah, of the overlying with this.
616
00:37:45,520 --> 00:37:57,920
So for my best victim, I log the logic app completely successful enough.
617
00:37:57,920 --> 00:38:06,120
You mean if you log if the logic app runs successful of that is that enough?
618
00:38:06,120 --> 00:38:16,320
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.
619
00:38:16,320 --> 00:38:19,920
You need to log what fits your situation.
620
00:38:19,920 --> 00:38:26,120
And if your situation is helped with just a single lock rule.
621
00:38:26,120 --> 00:38:26,920
Sure.
622
00:38:26,920 --> 00:38:27,520
Why not?
623
00:38:27,520 --> 00:38:32,320
As long as it doesn't bother your operation, it's perfectly fine.
624
00:38:32,320 --> 00:38:45,120
And when I think on monitoring, we have both to big monitoring.
625
00:38:45,120 --> 00:38:49,520
We have on the business level monitoring and the technical monitoring.
626
00:38:49,520 --> 00:38:55,120
We separated or shall we put it together?
627
00:38:55,120 --> 00:38:59,320
That is an interesting debate and I think we should separate it.
628
00:38:59,320 --> 00:39:09,520
Okay, because at first the business should be informed something happened with the integration and this is something you can fix.
629
00:39:09,520 --> 00:39:23,320
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.
630
00:39:23,320 --> 00:39:28,320
And that's why I think a separation of duties is really helpful there.
631
00:39:28,320 --> 00:39:34,320
And I think often workers, ETL pipelines in the past.
632
00:39:34,320 --> 00:39:42,320
And what we often have is the ETL pipelines work technically perfect.
633
00:39:42,320 --> 00:39:49,320
It's a succeed, but the business side say on their side is failing.
634
00:39:49,320 --> 00:39:56,320
Did you see that could be also possible and non-check at the problem?
635
00:39:56,320 --> 00:40:10,320
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.
636
00:40:10,320 --> 00:40:19,320
If your error handling is set up correctly, your logic app may not fill because the run completed.
637
00:40:19,320 --> 00:40:29,320
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.
638
00:40:29,320 --> 00:40:34,320
And then your run seems to be just fine, nothing happened, everything's green, cool.
639
00:40:34,320 --> 00:40:40,320
But still on the business side, that simple invoice that we took as an example earlier still isn't processed.
640
00:40:40,320 --> 00:40:42,320
And that's an issue.
641
00:40:42,320 --> 00:40:57,320
So yes, and it gets it gets even more interesting with AI in the mix because going going to that topic, obviously is.
642
00:40:57,320 --> 00:41:07,320
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.
643
00:41:07,320 --> 00:41:19,320
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.
644
00:41:19,320 --> 00:41:31,320
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.
645
00:41:31,320 --> 00:41:45,320
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.
646
00:41:45,320 --> 00:41:57,320
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.
647
00:41:57,320 --> 00:42:11,320
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.
648
00:42:11,320 --> 00:42:23,320
Yeah, I like to talk about the idea, I stuff, but the before I think we have to do the the the bad part.
649
00:42:23,320 --> 00:42:41,320
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.
650
00:42:41,320 --> 00:42:53,320
Is the integration layer something sometimes one of the most privileged parts of an enterprise architecture.
651
00:42:53,320 --> 00:43:16,320
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.
652
00:43:16,320 --> 00:43:26,320
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.
653
00:43:26,320 --> 00:43:32,320
And with that said, it basically means your company has come to a standstill.
654
00:43:32,320 --> 00:43:45,320
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.
655
00:43:45,320 --> 00:43:53,320
But your integration should have the privileges to execute what it should execute and no more.
656
00:43:53,320 --> 00:44:05,320
Yeah, what I think is it's we have start with integrations and I don't know, to a to do will be.
657
00:44:05,320 --> 00:44:15,320
And now we have departments and sub-departments have hundreds or thousands of integrations.
658
00:44:15,320 --> 00:44:26,320
How should organizations manage the identities, especially when we get in this high level of integrations?
659
00:44:26,320 --> 00:44:36,320
Yeah, and to extend that a bit further, the departments that have thousands of integrations may potentially even build our own integrations.
660
00:44:36,320 --> 00:44:41,320
So it's not even managed by our department itself anymore.
661
00:44:41,320 --> 00:44:48,320
So that also basically moves the security risk to the desk of the user that's working with it.
662
00:44:48,320 --> 00:45:00,320
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.
663
00:45:00,320 --> 00:45:04,320
So you have to really drill it down into a specific purpose.
664
00:45:04,320 --> 00:45:06,320
And that purpose is supported.
665
00:45:06,320 --> 00:45:12,320
And if at some point a new integration comes in and says, I want to do similar thing.
666
00:45:12,320 --> 00:45:15,320
You're in your integration. So you're getting new access.
667
00:45:15,320 --> 00:45:18,320
That's at least how I see it.
668
00:45:18,320 --> 00:45:32,320
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.
669
00:45:32,320 --> 00:45:35,320
So then that makes sense to use the same authorization.
670
00:45:35,320 --> 00:45:44,320
But again, you have to make sure that your logic app will not have more permissions than it actually needs.
671
00:45:44,320 --> 00:45:52,320
And then we have to talk also about the least privilege.
672
00:45:52,320 --> 00:46:01,320
Yeah, yeah, the least privilege is basically the best practice that also Microsoft aims for every time.
673
00:46:01,320 --> 00:46:12,320
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.
674
00:46:12,320 --> 00:46:24,320
Microsoft graph API, which is basically the heart of a Microsoft environment doesn't always have a really granular permission set.
675
00:46:24,320 --> 00:46:33,320
So then from that point, you can aim for least privilege, but leave privilege and maybe everybody knows this from their Microsoft exam, right?
676
00:46:33,320 --> 00:46:38,320
They always ask for I want to achieve this task, but I want to have least privilege.
677
00:46:38,320 --> 00:46:45,320
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.
678
00:46:45,320 --> 00:47:01,320
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.
679
00:47:01,320 --> 00:47:23,320
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.
680
00:47:23,320 --> 00:47:37,320
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.
681
00:47:37,320 --> 00:47:45,320
And it also has its own app settings and the app settings can be referenced to a key vault, for example.
682
00:47:45,320 --> 00:47:58,320
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.
683
00:47:58,320 --> 00:48:02,320
So using a key vault makes sense.
684
00:48:02,320 --> 00:48:27,320
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.
685
00:48:27,320 --> 00:48:34,320
And it's also sanitized. So if you look at the run history, you don't see what's actually gathered.
686
00:48:34,320 --> 00:48:41,320
Yeah, and what's about a private endpoint and network isolation?
687
00:48:41,320 --> 00:48:55,320
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.
688
00:48:55,320 --> 00:49:19,320
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.
689
00:49:19,320 --> 00:49:32,320
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.
690
00:49:32,320 --> 00:49:46,320
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.
691
00:49:46,320 --> 00:50:01,320
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.
692
00:50:01,320 --> 00:50:11,320
Yeah, can you, can you, yeah, can you show the explain what it's, what's really mean?
693
00:50:11,320 --> 00:50:20,320
Yes, I had a talk at the, the, the, which is the Microsoft integration user group here in the Netherlands, where I'm based.
694
00:50:20,320 --> 00:50:27,320
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?
695
00:50:27,320 --> 00:50:31,320
And that there we further explore the idea of that.
696
00:50:31,320 --> 00:50:44,320
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.
697
00:50:44,320 --> 00:50:52,320
But the integration as a servers was always consisting out of the components we already talked about.
698
00:50:52,320 --> 00:50:59,320
And did exactly what you told them to the same with normal code or let's say, pro code.
699
00:50:59,320 --> 00:51:06,320
You tell it what to do and it runs top down specifically what you told the two.
700
00:51:06,320 --> 00:51:21,320
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.
701
00:51:21,320 --> 00:51:34,320
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.
702
00:51:34,320 --> 00:51:39,320
It also rationalize why it should take that approach.
703
00:51:39,320 --> 00:51:44,320
And if an unexpected situation occurs, it can also respond to that.
704
00:51:44,320 --> 00:51:59,320
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.
705
00:51:59,320 --> 00:52:03,320
It's basically your companion.
706
00:52:03,320 --> 00:52:10,320
So everything you did not think about yourself, AI could maybe handle that.
707
00:52:10,320 --> 00:52:29,320
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.
708
00:52:29,320 --> 00:52:47,320
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.
709
00:52:47,320 --> 00:53:01,320
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,
710
00:53:01,320 --> 00:53:22,320
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.
711
00:53:22,320 --> 00:53:36,320
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.
712
00:53:36,320 --> 00:53:45,320
So basically your API was still busy or was overloaded or whatever, what do you do then?
713
00:53:45,320 --> 00:53:57,320
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.
714
00:53:57,320 --> 00:54:03,320
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.
715
00:54:03,320 --> 00:54:10,320
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.
716
00:54:10,320 --> 00:54:17,320
That's enough. At some cases, obviously it depends on the context, but to make it really simple, right?
717
00:54:17,320 --> 00:54:28,320
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.
718
00:54:28,320 --> 00:54:39,320
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?
719
00:54:39,320 --> 00:54:50,320
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.
720
00:54:50,320 --> 00:54:55,320
You simply add in an agent loop, you tell it, this is the situation, go for it.
721
00:54:55,320 --> 00:55:05,320
So AI can classify incoming information and then choose the appropriate workflow?
722
00:55:05,320 --> 00:55:15,320
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.
723
00:55:15,320 --> 00:55:23,320
So for example, the HTTP call, it can check, did it run successfully, and if it filled, why did it fill, etc.
724
00:55:23,320 --> 00:55:38,320
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.
725
00:55:38,320 --> 00:55:51,320
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.
726
00:55:51,320 --> 00:56:05,320
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.
727
00:56:05,320 --> 00:56:19,320
And I think what actually is, I say, the password, it's all talk about selfie integrations.
728
00:56:19,320 --> 00:56:26,320
Can you a little bit explain what it isn't, how it really works?
729
00:56:26,320 --> 00:56:28,320
Sorry, which one you made?
730
00:56:28,320 --> 00:56:31,320
The selfie integration.
731
00:56:31,320 --> 00:56:51,320
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.
732
00:56:51,320 --> 00:57:09,320
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.
733
00:57:09,320 --> 00:57:23,320
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.
734
00:57:23,320 --> 00:57:34,320
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.
735
00:57:34,320 --> 00:57:59,320
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.
736
00:57:59,320 --> 00:58:05,320
And then your AI may have some unexpected responses again.
737
00:58:05,320 --> 00:58:22,320
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.
738
00:58:22,320 --> 00:58:31,320
So ready? Sure. Logic apps are functions. Logic apps. We can't know a bit of all. Sorry, what did you say?
739
00:58:31,320 --> 00:58:41,320
We can't know a bit of all. Oh, bit of all. Rest or events? Rest.
740
00:58:41,320 --> 00:58:55,320
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.
741
00:58:55,320 --> 00:59:07,320
What logic apps? One logic app feature more, you blow up as rules know about. I think it's agent loop, at this point.
742
00:59:07,320 --> 00:59:17,320
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.
743
00:59:17,320 --> 00:59:32,320
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.
744
00:59:32,320 --> 00:59:40,320
Okay. Who should I invite next to the podcast and what is the secret question I should ask?
745
00:59:40,320 --> 00:59:50,320
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.
746
00:59:50,320 --> 01:00:00,320
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?
747
01:00:00,320 --> 01:00:13,320
Okay. Yeah, finish the sentence, the integration platform of the future will not only think with you, but basically act along you.
748
01:00:13,320 --> 01:00:24,320
Yeah, then, yeah, Sony, I think that it was of, yeah, fascinating. Cake away here that integration is moving beyond simply connection systems.
749
01:00:24,320 --> 01:00:34,320
Yeah, for decades integration has largely been determined, deterministic, what it's happened, that do that.
750
01:00:34,320 --> 01:00:45,320
But yeah, adding AI, potentially changed the model, the integration, they can be interpreted context, regulation, patterns, it's really, really fantastic.
751
01:00:45,320 --> 01:00:59,320
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.
752
01:00:59,320 --> 01:01:07,320
So, yeah, you find all there and yeah, thank you so much for staying with me.
753
01:01:07,320 --> 01:01:21,320
Thank you. Yeah, thank you for having me again and I really enjoyed it.
Founder of m365.fm, m365.show and m365con.net
Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.
Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.
With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.