When Azure SQL Becomes an Application Platform- APIs, Automation and AI with Dirceu Resende

Welcome everybody to the MC65 of M podcast. The podcast where we explore the technologies, architectures and people shaping the Microsoft ecosystem. When most people think about Azure SQL database, they think about tables, transactions, store procedures, reporting and reliable data storage. But what if the database could become an active participant in one-on-a-pickation architecture? What is Azure SQL called securely instant the rest API's trigger automated process, connect with external service or support AI applications and help orchestrate intelligent workflows without requiring a large amount of external application code? That is exactly what we're exploring today. My guest is DeCruiResand. I always valid ride. Yeah, that's fine. Yeah, he's a specialist in databases and business intelligence who has been working in the data field since 2013. He could previously work at Microsoft, a senior program manager for Power BI and is currently an Azure Cloud administrator at Ryanair. He's also deeply involved in the technology community and has presented at more than 50 in-person events and over 300 online events. He was a part of the Palian Yaira's Brazil. I don't know. A YouTube channel with more than 160,000 subscribers and some million views. His website contains over 400 technical articles, has received more than 4 million views and has become one of the 10 America's most widely accessed Portuguese language resources for the Azure professionals. Today, we discuss Azure SQL database, rest API integration security automation, AI, Azure Tech Characters, Observability, and the change in the world of database inside modern applications. DeCruiRes, welcome to the N165 show. Thank you, Mirko. Thank you for everybody that is listening to us. It's a pleasure to be here. And I hope you have a very good chat and people can learn about Azure SQL DB and all data technology that you're going to talk about. Yeah, before we deep dive into the topic, can you a little bit tell about yourself and how did your career in data start, especially in the Microsoft ecosystem? Yeah, sure. So I've been in an ironier's old for a while now. I started with technology maybe 20 years ago. I started with computer maintenance. Most of people at that age started with something like this. The IT was not as evolved as it is right now. It was just baby steps at the time. I always had a lot of interest into programming. So I started with programming the coding. Then when you code, usually you have a lot of contact with databases because pretty much every application starts with interacting with the database, like starting data, managing data, and so on. And I really like this experience. I was very passionate about starting a little bit of performance because I like very much this topic on both application side and also on database side. And I really enjoyed this part of the database performance turning, especially because at least in my point of view, it's easier to test than in an application that you need to code. You need to test, you need to deploy, you need to build. In database, you just need to type F5. That's it. You can just run what you're trying to do. So if I create a procedure of function, I can just run in one line of code. With an app, usually, you have to build way more stuff to test than database. So I get no more about database. I started to study them to understand better how it works. I study other topics, not just like performance, good pratics, developing better solutions with database because sometimes you have to write a lot of code. And the database already has a solution for it with way more efficient way. And then after you have quite a good experience on the database itself, I think I reached this point in 2017, in '18, more or less. It went, Power BI became very popular. A lot of people from database background were migrating to business intelligence. AI was at the beginning of AI, machine learning, and so on. So I thought that it was a good idea at the time. I believe it was a good idea right now. But it was the beginning of professional business intelligence. Business intelligence is very old, but it was not that high demand that it is in the last maybe 10 years. And this is when I got into working with business intelligence for BI warehouses and other technologies. And this is what I usually do on my databases currently. And that's my summary. Awesome. You previously worked for Microsoft in a senior program manager for Power BI. Can you tell us a little bit about this work, what this role does and how it's how this helps you connect to the global community? Yes, definitely. I think it was a very good experience to my career. I learned a lot of new things that I was not used to because this role of program manager, especially at Microsoft, you are not very deep connected in terms of hands-on. Usually you work more into your creative specifications and requirements for features that the developers, the code developers that will implement on the Power BI 2 or the engine. So it's not all my career. I was on the other side that I was receiving the requirements and actually trying to create an analysis of SQL, create a pipeline implement a security mechanism on a database. So when I joined Microsoft, it was the opposite way. So I was writing the requirements to other people to implement. So it was a very different experience. I can say that. I think I based on this experience and all my other experience in my career. I'm still more into actually hands-on, more technical, personal, implementing solutions than writing the requirements. I think it's a whole different area. You need to have a whole different mindset because everything needs to be very, very perfect written to other persons. You read that file or that documents to understand. And you need to think and try to cover all the possible different ideas that somebody can have. So you need to try to cover everything. So the feature delivered is exactly what you thought when you create the documents. It's a little bit different when you can use your own creativity, your own ideas to implement something. Awesome. You are now a specialist for the Azure SQL database. For someone who has not followed the platform closely, how will you describe Azure SQL database today? I think if you need the database and you don't want to have any headache, managing backups, performance, having to concern in terms of RANs or where, virus, and a lot of security threads that you may have. The Azure SQL database is a platform. You just created with just some clicks on Azure portal. You have a very professional database so you can use it. You have a lot of different tools already available for you. And also you have the power of SQL server that has been one of the leaders of the market in the last 20 years, for sorry, in the last 20 years. And you have also a lot of good and very useful stuff like you can now make ATP requests so we can integrate your database with pretty much any service or application directly without needing an application to control this workflow. So from the database, you can connect to let's say chat TPPT API, use this API with the data you have on your database and process data, make post requests to change data on other services. And you have a very good job application on the database that can help you to schedule and automate process. So it's a very complete database that provides you more than just a regular database. You have a lot of different features, a lot of different features for form us for many many ability. You have a lot of different tools to better integrate your application with the database in terms of security. If your application is hosted on Azure, you can have manage identity, which is a very secure approach to connect an application with the database because it's a passwordless approach. So we don't have a password to manage to rotate or to somebody try to get an attacker application. So I think it's a very mature database for pretty much any application right now. >> Yeah, and where do the Azure SQL database fit alongside Azure SQL management instance and SQL server? Yeah, the managed instance, the experience in the managed instance is very similar what we have with the on-premise SQL server database. Because you have an instance that can hold various databases. You have the SQL server agent that you can control the jobs. You can publish and create SQL CLR procedures using botnet code, which is very, very powerful. The difference from the Azure SQL DB is that the SQL DB, you're working on a single database. So it's very useful, especially for micro services because you can have multiple smaller database independence. And so you're not sharing resources with other databases and other applications. You can have one server with a different database, but each database can have a different capacity with a different pricing. And also they are totally independent. So if you have an application that you need to use, let's say cross-query databases, so you need to create a joint that you need to join tables from different databases. The best tool for you is going to be the managed instance. If you don't have this scenario, you really want to have totally different and independent databases, especially for micro services approach. Then the Azure SQL DB should be your best option right now. Awesome. And can organizations move existing database to Azure SQL without changing the surrounding architecture? >> It's possible, but depending on how the application was designed, it could be a problem, especially because most of on-premise applications, it's not, it's very common to have linked service, your other instance, or to have cross database queries. To use, let's say, SQL CLR procedures or functions using .NET code, which is not supported by the SQL database. So if you have some features that are not supported, you can have some problems, especially because depending on the tier you're using, it could be slower than the tier you have on your own premise. Because the cloud, the easiest solution you have, the most expensive is going to be. So if you have managed service, probably is going to be more expensive than your VM or your physical server on your company, your data center. But definitely, with the managed service, the experience will be much easier, and it's going to be way better to maintain, because they don't need to be an expert to create and maintain a SQL database. But if you have an on-premise database on a critical production application, then you need to have someone from networking, from security, that understands a lot of turning, or from a stunning, you need somebody that understands about storage. So you need to have a lot of different people working on to maintain and to maintain an on-premise application. On cloud, it's easier because a lot of responsibilities, Microsoft holds for you, so you don't need to maintain everything. Yeah, storage is a good word. Your central message is that Azure SQL database can extend far beyond traditional data storage. What does it mean in practice? Sorry, can you repeat, please? Yeah, the Azure SQL database can extend far beyond the traditional data storage. Can you a little bit explain what it means in practice? Yes, so if you move your data from the on-premise SQL server to an Azure SQL database or a managing instance, because you're already on Azure, it's going to be way easier to integrate with different applications and also different servers. So let's say you have a fabric or a Power BI, or if you have an application using App Service or Kubernetes or Docker, it's way easier to access this data than if you have this on-premise. You can have also a fabric in memory that you can replicate this data from the Azure SQL DB to fabric seamlessly, in a way easier way than having to create a job that copies on a schedule job to fabric. Also, because you have always the latest version of SQL server, you have always the latest new features, especially the SP VWREST endpoint, which you can use to call HTTP requests and integrate with different services. The SQL server 2025 got this feature, but on Azure SQL, you could do this, I think it was two or three years ago, and people that are using the on-premise only got this this year. I think this year, I think it was in the last quarter of 2025, actually, that the 25 version was released. But people that are using the SQL DB got this way earlier than people are using the on-premise. >> Okay. What does it mean for database to be participate actively in an application workflow? >> Well, the database for me is the most important part in an application. Because if usually the code is version I don't get, so if let's say somebody hacked into the application and they destroyed the code, destroyed the resource, you can easily create the new, you can easily create the application again on a new resource and a new server, getting the code from Git. But if somebody destroys your data and they also destroys your backup, they probably most companies can go bankrupt. They can end because they don't have any data anymore. If you don't have a very good backup strategy, like having this stored into different storage types, this could be the end of for the company. So it's very important to have this deep integration, deep integration with the application. Also, the database needs a special attention on it, because you can version code, but you cannot version data. So data is pretty critical and pretty important. >> So I think I'll be moving away from the traditional idea that the database should remain isolated behind the application layer. >> Yeah, no, I agree with this approach. I mean, usually the application is open to internet, so it can access. If it's not an internal application, you can access from any public IPry, usually it's open. But database is usually behind a firewall, a virtual network, that only on a private Dnet can access the database. So it's a very good strategy trying to protect and reduce the surface area for you try to attack the database. But nowadays, the database is not just a place to store the database, can do way more right now, because even in the past, because when you install, for example, the SQL server, you also get the analysis service, which is all up to the integration service, which is an ETL2, and also the reporting service, which is a pixel perfect to just like crystal reports. So you have this since 2005, I guess, or 2008. But now with these integrations, with the possibility to automate jobs and to create automated executions to integrative different services, different apps to integrative AI. So we can use right now AI to actually process the data that you got from the application. Now the database can do much more than it was used to a few years ago. So the database now can be more independent from the application. Definitely the application usually is the main source of data for the database. But now we can have more sources. I can create a job that queries data from an external API store into a database across the data with the data that came from the application. I also can get the data from the blub storage that the user uploaded, XL file, and process all these data together without needing an application to actually orchestrate all this data flow, for example. What do new possibilities become available when Azure SQL can securely communicate well with external services? Yes, so first of all, the firewall will be our first barrier in terms of security. So if you can block external traffic from your database, you already got rid of most of the problems you can have. But you can also have other tools like, let's say I created an integration with an external application. So I created a new user for this application to access the data. If this application is accessing sensitive data, I can use the name data masking to mask that data. So even if somebody can compromise this tradition for this application, it will see mask data. This dynamic data masking is not that secure because you cannot definitely, if you have the credential, you can try to explore using simple select comments. You try to guess the original value. Even if you cannot see, but I can guess, let's see, I have a salary column. I don't know this value, but I can try to guess, let's see if it's below 10, 10k, okay, it's below 10k, the month salary. Let's see if it's below 5k, no, it's not, so it's between 5 and 10. So I can try to guess. But you have also other features like column level security. So you can hide certain columns from a table, from a specific credential. You can also have column encryption, which you can actually encrypt the column. You can have also always encrypted, which is probably the most secure technique you can apply to a SQL Server database, which you're going to have a private and a public key, to encrypt and decrypt the original data. So even if the DBA doesn't control this key, even if the DBA is a CZ, that means it will not be able to see the original data because this person doesn't hold the key for it. So it's probably the best approach for it, but it's a little bit complicated to implement because you have some limitations. It's hard for an application to not able to see the actual data, so it can break some applications on it, so you need to prepare. It's not just a setting that you turn on and that's automatically encrypted and the application will just work fine. So we need to create a project, we need to study a little bit of the limitations. You need to adjust as your application to see if it's going to work. But you have a lot of different ways, but the pre, the pre, the most basic stuff is probably your best friends on it. So it's going to be the firewall, try to separate the applications and integrations using different users. Using the list, what is it called? The principle of list privilege is always one good tip, so try to limit the permissions for each user at the minimum possible to work. And also use the other tools that I mentioned, the Damascan, column encryption, column level security, row level security, as much as possible, to try to reduce the surface area for attacks. So-- Can you-- for better understand, can you describe a simple example of an Azure SQL-driven integration? Sorry, can it be? Yeah, a simple example of an Azure SQL-driven integration. Driven integration? Yeah. OK. What do you mean? Sorry. Yeah. What are the new possibilities with this Azure SQL? That's become more-- that the SQL database can communicate. What can we do with this? OK. Yeah, sure. So if you can use the SP evoke rest endpoints, like similar rest endpoints, you can, for example, let's say I have a form that people can write, like a contact form, so people can write a message or a feedback form that people can write their opinion in terms of a product, a company, a service, something like this. So it's very hard to read one by one and try to decide if this person is happy, if it's not happy, it's very angry, it's very happy. So we can use the cognitive service you can use an AI to try to read all these comments and try to classify or score. So we can easily create a number and based on the number or the score, you can easily select the most happy customers for some action marketing action or some very angry customers that you need to call, you need to send a message and the email, something like this, you try to convert this unhappy customers into happy customers again. Another good example, let's say I have an integration with an external application, could be even a file integration that some company drops a file on an FTP or on some storage. I read this data and I port it to my database. Sometimes in this kind of integration, especially when it's using a file, like a CSV text file, Excel file, you can get a lot of garbage from the data. Let's say if you have a state column and the company was not using a drop down, so somebody can use a name for let's say New York, you could boot an AI, you can type New York wrong. It's really hard to work on this, to remove all these inconsistent data and try to create a standard. You can, in the past, you have to try to deal with it using code. It was very painful, especially because I'm just giving one example for one column. Sometimes you have integration with hundreds, maybe thousands of columns. You have to try to guess the pattern, you have to try to create a code, you should try to fix that data, to clean the data. Now using AI, you can just use the API, try to fix for you in a few minutes or maybe a few seconds instead of having two ways. Maybe days or weeks, maybe months trying to clean that data. So there's unlimited possibility now that you can use AI to work with your data. Let's say I can send emails using this integration. I can connect with let's say a send grid service that I can use the API to send email from the database. The on-premise database, you can use the DB-Mail service that you can use with any SMTP service. But we don't have this on Azure SQL DB, but you can use the HTTP request to integrate with different APIs. You can use now these integrations to upload the file to a different service. You can say, let's say I want to send the SMS if I have a service that allows me to use the SMS from an API. I can now send SMS from the database. I can send a WhatsApp message, a tagger on Slack. So I can use, for example, I want to monitor my database. And now I can monitor it sending emails, sending SMS, sending messages to any communication platform I'm using to receive these alerts. It could be a monitor of the database itself or could be a process. If I reach, let's say I have a product that I sell a lot and I have less than 10% on my storage. And I want to risk giving notification that I need to buy more of these products because I'm going to be out of stock. And so I can create a job at monitors every five minutes one day, I don't know. And send the alerts to the buyer or somebody that needs to buy a product. The possibilities are unlimited. As you say, we can work with rest, our piece, is there other type of services that can be integrated? The other author said? Yeah, you have to say that in your example, we have to talk about rest, our piece. Is there any other types of services that can be integrated? Let me think, any type of service you're talking about? Well, I think if the service has an API, you can pretty much integrate. So let's say I want to integrate with Teams. I could integrate with Outlook with the 365 platform. I can because most of the, I think all the platforms in M365, they have an API that you can automate a lot of different stuff. So now I can do this. I can integrate with office. I can integrate with pretty much how applications with HubSpot. Let's say I use HubSpot as the CRM for my company. I could integrate based on some event that happened at the DB. I can create a task on HubSpot. I can create a lead. I can create any voice. I can do a lot of stuff right now. Interesting. Yeah. I think, yeah, it's, it's, it's really, really interesting. Can you, can you a little bit about explain the difference between Zincronus and Azulcronus integration in this context? Yeah, sure. So if you want to build a synchronous approach on this, you can let's say I can create a trigger on a table that's laver time. Let's say I insert a row on orders table. So somebody create a new order on the application. I can trigger and on this trigger, I can send SMS or somebody or I can create a process on HubSpot that I need to now sell this product that I just made. So this is a synchronous process. So as soon as somebody create a new order on the application, without I need to change the application when this data arrived into the DB that it be already created an action on it. I also could create an a sync approach on this. So when I got, I can create a job that runs daily. So I can read this table. So I can read all this table from what happened it on in the last day. And when I got this data, let's say I received 10 different orders and I can create a summer. And where I can send an email with the summary of the 10 orders and send to a group or to a group of people to take an action on top of these new orders. If they need to sell something, if they need to prepare the warehouse or something like this. And now I can work at I sync. I don't need to show specifically taken an immediate action when this data can I can also use the this integration to query an external API. And then based on the return of this data, I can take another action that I can trigger another API to a different service to do something that I want to do. So it's just like you have the power of an application in the database. So you don't need to code anything. You don't need to deploy. You don't need to. I don't need to create a CICD approach if I don't want. Definitely, I can create the CICD approach to deploy these objects to my database, but I don't need to in this case. And because this already runs inside the database, the security concerns are less strict because I don't have anything external connection to the database. And the database is actually triggering the integration, the integrations. So the database is querying or standing the data to this service is not the opposite way. So I don't have a service trying to reach directly to the database. So in terms of security, it's a little, it's a little better in my opinion. When we normally talk about SQL, especially in Azure, there are, I say, some tools we think about. It's Azure ServicePose, Event Grid, Event Apps, Azure Function and Logic Apps. Is this, what role does it play or is it completely, I don't know, is this new option with this new database? Is it obsolete? Yeah, I think with this, especially because you can actually scan or jobs inside, even the Azure SQL DB, we don't have an interface for it, just like we have for the own primers or the managers. But since let's say, 2020, we can't scan or jobs. We may, we may don't need to use large caps to automate tasks because in the, in the past, if I want to schedule a query, a procedure or some action on the database, one of the alternatives was to use a large cap. So I could schedule this and every X minutes or a specific time, the large cap triggers and runs a specific comment on the database. Right now, I don't need an orchestrator anymore. I can use a factory, I can use ADF, I can use large cap, I'll automate to orchestrate queries and actions on the database. But you don't need now. You can use but it's not more required. So because you now you have options, you have a new options that I don't need an external service to automate executions of something, some integration. Because from the database, I can now use APIs, I can now query data from a blob storage directly. So I don't need an orchestrator or an application to to deal with different data from coming from different places and try to orchestrate and organize because the database now can do everything. I think a lot of companies, when you say you connected a database to external services, I think that immediately raises security questions. What are the biggest risks? Well, the biggest risk is that the database now can export data directly to a service. So imagine if I can hack into your database, I can build a web service. She received the data that I stole from you. So I can use this integration to get data from your database, post into a web service and get these data from these database that I hacked. I understand this concern is really real. But if you can hack into the database, you already have access to all the data anyway. So you can query and save into a file and get the file, upload the file to an FTP. You can just copy all the data to an external application. You can save as a file, you can save as a JSON as a CSV file. So if you can hack into the database, you already have control over the data. So I understand the concern, but I don't see it has an additional layer or an additional thing that you need to protect. Because to be able to actually send this data outside the database, you have to be inside the database anyway. OK, and how should Azure SQL identity Kate to do another Azure source? Using this integration, we are talking about. Well, usually if you can use the anonymous way, but most of service, they require some kind of authentication. You can use bear token, you can use user and password. I think these are the most common that you can use. Also you can use headers. So the X API keys, three common, you pass the token on the header of the request. So we cannot indicate the request you. These are the three most common way to authenticate. And all of three are supported into the SQL DB. It's a very good question though, because I see most of people passing the credential when they are trying to every time they want to make a request, they include the credentials like the token or the password. So you can use the code on the request itself, but the most secure way to work with this is that an admin that holds the credentials. This person can create an object called credential on the database. So when you create this object, you actually include the credential itself like the password, the key or the token. And when other person is wants to work with this service, you can refer it to the credential you created, the object you created. So you don't need to specify the credential anymore. And let's say you have 100 procedures using the same credential. If this token expired, I just run a common auto credential. I use the new token that I created and all the objects that are referring this credential will automatically be fixed because you don't need to update 100 procedures to update the token. And also is safer because the person that is creating these procedures that is actually working with this integration don't need to know the actual token only the person that maintain this credential object inside the database. And I don't know, we have to say, I think how did we handle error handle in Azure. How does it work that the error handling or how did you do it? Yes, SQL server and also Azure SQL DB it supports the begin try begin catch. So you have a track catch approach on the SQL server. Since 2008, 2005 I guess, but definitely it's getting better and better and better over the new versions. So with this integrations are any kind of procedure or workflow that you data flow you create on the SQL server or the SQL DB. You can work with the try catch approach and based on the the whole message or the arrow code, you can also have a sequential begin try catch. So let's say I try to send this request and I got the message that the service is offline by some reason or some code like a whole 500 is an internal issue on the service itself. I probably if I try to send again it will not work. I can use a retry on my catch. So if if it fails based on the arrow code, I can try again or depending on the arrow codes, let's say unauthorized it's I will not fix the unauthorized. If I try to run again, so I can try to use another credential can try to use a fallback service. Like say if I send email using send grid by some reason my send grid is returning unauthorized. So if it happens, I can try to use the fallback to send using send the email using Amazon says or another service. So I can deal with that just like in an application. I agree that an application is more powerful in terms of coding and implementing this kind of hero handling, but the database is not that far behind. So it has a lot of different controls that you can control an exception. You can you can record this into a table into a file into like say login analytics on Azure. I can try to use different different cases or different ifs approach depending on what's happening. So we have a very good hero handling on SQL server. And what's with the topics performance and scalability, how compares to other SQL solutions. The most is a very big topic, especially on Azure because let's say if I have a on premise instance or an on premise server. If you need if you need more performance, you just need to buy more CPUs or buy more memory or buy a faster disk. And it's an investment you pay just once and you're going to be you're going to get the benefits for maybe forever or as soon as your hardware starts to fail on on the cloud is different because you're paying monthly. So if need to increase the capacity increase your compute power, probably going to double your costs. And if you don't invest into performance stunning. I can assure to everybody this action to double the compute the compute power. It's not going to be once because if you don't invest into trying to improve the performance changing the code, doing better queries, implementing a good indexing strategy. This is going to happen once every every every time you increase the capacity in a few months is going to increase again and again and again and you're going to see your database costs are going to be very, very, very high. Performance is a very big topic. It's a it's a very in cloud. It's getting a lot of attention in the last years because you can reduce costs in improving performance on premise. This is this does not happen if I had if I need a 16 course server to to host my database and I did an awesome work reducing my query performance by 98%. Now I just need to course your at about a 16 so you can return your at about 16 code V course for the physical hardware and also for the license for sick of server. So you you definitely going to have more your lifetime is going to be higher because you reduce your compute power. You reduce your cost in terms of execution a query. So you don't need to buy more CPUs in a long time now, but you're going to have still the same cost in Azure if you can reduce your cost by 60%. You can reduce your cost by half because you can reduce your the capacity about for your database. So now that performance turning is actually making a difference in how much you're going to pay and a good performance could save millions of dollars a year. Now people are getting it is giving a lot of attention to people that work with performance turning. Interesting and Microsoft actually have the copilot for for everything all this all this what they are one for as well. So kind of more or less because usually the application that we use in daily basis is the sick of server management studio. And things the the last quarter of last year they included this option should actually they didn't call it copilot, but you can use AI on the two. And you have to use your own key so it's not included in the price you have to use your own key for chat to be to your other platform to kind of have this this AI features on your development platform. So sick of server has some AI features, especially for automatic turning that sick of server keeps analyzing the execution plan all the time to try to suggest you indexes that could benefit your application. At least sometimes they you could get good recommendations sometimes not that much if you try to analyze you could get better results but definitely if you don't have a lot of knowledge in terms of performance turning. At least it's an easy guess easy win sometimes it's not the best but at least it's better than nothing. And yes it's it's strange because you don't have a copilot for SMS probably because on copilot the you don't pay for for the usage they are usage right it's already included in the price. And in the case of the sick of server probably people use this is a lot and Microsoft prefers to okay I'm going to give you this feature you set up your API key you select the service and you can use the AI on the on the development platform. Yeah but when we talk about AI I think we talk most times about RAC and vector search how can you will you explain vector search and why is it so becomes so important for AI applications. Yes so in the in the 2025 version of sick of server and also in the SQL DB since 2024 I if I'm not wrong sick of server and actually SQL DB they now support vector search and RAC and also embedding tokens. This is pretty much the foundation of an AI LLM because it uses the embedding tokens to actually to actually send all these data to the to the billions of parameters that the LLM holds which pretty much is a bunch of instructions and kind of databases in its own form. It's a very compressed in a way that the LLM can easily access all this data this knowledge that is is a storage in forms of this billions of parameters. And now you can implement your own LLM kind of on the database itself so we can host your files your own files your own data you can use the vector search to try to implement. AI engine kind of an AI engine on your data without requiring an external service like chatty pt jmni and traffic aka cloud cloud code so you can use the on. AI engine from sick of server to try to replicate an LLM on your data definitely it's not it's got not going to be as powerful as this big LLM that runs on huge data center with hundreds of machines, cores and and CPUs and in GPUs but you can have some basic functionalities of LLM without having to pay something. To pay an extra cost to the like an AI service that you pay based on a token usage. So it's our wage will implement this without no cost if you understand how it works the embedding the vector search. And what are your also the data specialist what are the capabilities from error SQL especially for business intelligence. Yeah so if you are working with has a build business intelligence and Azure SQL DB Microsoft is pushing everything to fabric so prebich right now is the platform for business intelligence on Microsoft stack because you can have right houses like houses database. You can have also power be eyes deeply integrated with this platform called fabric if you have a data on Azure SQL DB but say I have an application and I have a database for this application and I want to analyze these data on fabric aka power be. We have to do in the past you need to create an ETL pipeline to read this data from the database for the application and copies to a different database for different structure using the data architecture something like this or layers which we used to call raw ODS and D. And transform all these data and then you can connect to power be eye on top of this layer. Of course you can connect power be redirected to the application database but is not recommended again having multiple different issues using that approach. It is possible but not recommended but now with the SQL DB is deeply integrated with fabric you can use the fabric you mirror in feature. It is not only that it is basically integrated all these data from your application in a new real time approach to a fabric warehouse so we're going to have this data available for you in your real time on fabric so we can. Look your dashboards your reports into this warehouse that is hosted on fabric is not using your database capacity so you're not going to have any issues just like blocks blocks or slowness because you're you're running heavy queries on top of database you're not running on a database you're running on the fabric warehouse. So you're consuming fabric capacity for it and you don't need to create an in. It's your pipeline to get this data from your database to fabric using fabric, you can integrate this with justice is more number of clicks and you have this data done on fabric and when you have this data fabric then you can apply your transformations and connect into your dashboard or your reports. So yeah, I think this is what Microsoft is are she right now in terms of the recommendations for the business intelligence intelligence approach in the past before fabric before everything. We used to have another service reporting service and integration service which is also a complete package to have the all app cubes for very high performance. And then we can connect data to so we can connect using excel or power BI into a cube so we're going to have an in memory architecture which is pretty much the the the service is the heart of power BI still nowadays. So you also had the integration service which is the ETL platform similar to ADF probably is the father of ADF the integration service. And I think that's pretty much it what the tools to integrate the actual SQL DB or SQL server with a business intelligence platform or pipeline. One question before we start in your rapid fire out and how do you do governance, how to gather as well. Yeah, so how to go over and okay, the I think is a very very good question. Pretty much if you have a Azure SQL DB, you have a server right so in the server you have the far old level the the far old level the far old in the server level. So let's say if I manage the server but I don't manage the database the database are managed by by the applications. So I block a certain IP at the server level this this IP will not be able to access this database or I can do the opposite. I can block all the IPs and create an allow list. So only certain IPs could access my server itself. I also have the database level far old so let's say I'm allowing all IPs at the server level but at the database level I'm allowing only certain IPs to access this specific database. Let's say I have an HR database usually it contains very sensitive information like salary and personal data. I can have a server that allows all IPs but for this specific database I want to be able to access only from one IP which is the the application IP. So I can set up this kind of security per database or also adding entire server level that holds a different a lot of number a lot of different databases. Also in terms of security I can create a login at the server level and then for this login I can specify in which databases this login can access. So I can I can I have control over the server itself and also everything that I can manage I can also have granular permissions on the database itself. So I can have on one server different app databases with different business rules different security concerns that I can manage at the database level. So in terms of government governance we have a lot of different tools that we can apply to the database itself. Interesting so let's have a little bit over time I'm sorry for this. I hope you have some seconds for the rapid fire route I ask some questions you give you answer so the rational data or vector data. So that's our relational database for sure. So what is the best or even good in a good when such an idali I come to you and say hey, you get all the money and resources for Microsoft to develop the Azure SQL feature. Well, first of all I will try to implement an active active cluster because Oracle has the Oracle hack and I think you'd be good to have more than one point of writing and we don't have this in SQL server because you have all the active and passive replicas. So we cannot have more than one instance running at the same time you should just one receive the rights and the others just have just receive the replications. So I think this would be probably my my first thing to try to implement because yeah, I think it will be something like this an active active cluster. Yeah, awesome and if you will be the next guest I should invite to the podcast and work questions through I ask. I think you should invite Fabiano Mori. I don't know if you know him. He is a specialist in terms of SQL server and performance and also security. He already hacked all the clouds the SQL server in all the clouds he discovered a lot of vulnerabilities in every every cloud AWS Azure GCP Aliba, and I think it will be a very interesting chat with him. Yeah, and then I find the question is what do you want to listen to remember from this session. I think what we talk about at most and it's very interesting and I think is not very explorate by people that use the Azure CPDB is the integration from the database to external service, which now opened on limitless possibilities and port. Because now the database is not the place that you can just store your data. You can actually be more active without requiring an application or an external service to orchestrate or to to command what database should do now the database is alive. It has its own responsibilities. It's on its own tasks that it could do. And in an easily way, because you don't need to deploy to code to create an application to host this to create a server to host this. It's already there. So, Dikuru, thank you for joining me and showing us the Azure SQL database can be more much more than a place where application stores data. My biggest takeaway from this conversion is that modern database architecture is, yeah, increasingly a bow connections Azure SQL can participate in RP integrations automation workflows analytics solutions, AI power experience. But these capabilities must be implemented with care for attention and security or reliable performance and operational visibility. Yeah, the goal is to move, not to move every part of an application database. The goal is to understand when keeping logic close to trust business data creates a simpler, faster, more, yeah, main, tittle solution. And when we decided to integration services is, yeah, better, the better architectural choice. So, thank you for for being here all your. And of course, we just find in the show notes, you are from this episode on the m65 and podcast page. So, yeah, thank you so much for staying here with me more than now. Thank you. Thank you for the invitation and thank you for everybody that's listening to us all this time. I hope you enjoyed the topics and what we discussed here and thank you for everything. [BLANK_AUDIO]