I work with Azure SQL Managed Instance, which is a managed instance. Azure SQL Managed Instance is basically a single database and is a fully managed isolated database. There is also an elastic pool in it, which is a single collection of databases that share a set of resources like CPU and memory. Regarding the different features, it has independent selection of compute or compute tiers like the provisioned one. In terms of service tier, it can be used for general purpose, business critical, as well as Hyperscale up to 128 terabytes. Regarding the advantages, it is highly available. It also has multimodal flexibility. We can store and process JSON, XML, graph, spatial, and vector databases for AI use. It has built-in intelligence which is used for automatic performance tuning and advanced security including Microsoft Entra ID for authentication, vulnerability management, and more. The most important thing about Azure SQL Managed Instance, which I appreciate, is its serverless compute. It has cost efficiency and massive scalability. It also has elastic pools and Hyperscale tier. Regarding built-in security and high availability, it is 99.9% available. It has AI-driven security and advanced encryption. It has always encrypted, which keeps our sensitive data protected in transit as well as at rest. Even during memory query processing, all our data is encrypted. Regarding performance intelligence, it has automatic tuning, so it automatically creates the missing indexes. It has no infrastructure management, as PaaS services have zero touch maintenance. It also has automated backups. I have integrated it with other Azure services, including Entra ID, as Azure SQL Managed Instance natively integrates with the Azure ecosystem because of its foundational cloud services. It has AI and machine learning integration, event-driven and serverless computing, and analytics and big data integrations. It also has identity and management integration for Entra ID and more.
If you have an application that will probably require a database engine or database solution like SQL, and probably your solution is being deployed within Azure environment, there's no need of creating a new server, probably a server instances, such as a virtual machine within your Azure environment, and then probably install or start installing a new SQL on it. It is a little bit cumbersome when it comes to manageability. You don't need to, you have to take the headache off yourself because Microsoft has a complete solution already, which is Azure SQL Managed Instance, within the Azure infrastructure, whereby you can deploy your SQL instances and then point your solution to it and then it's scalable. You can start small and then grow big later. It has a lot of advantages. You don't need to worry about the security, you don't need to worry about the patching. Microsoft does that for you. At the same time, you don't really need to worry about the licensing because for instance, if you have a license assurance, you can bring in your license to that environment to reduce the cost. I have been working with automated backups in Azure SQL Managed Instance. Once the instance is being provisioned, I immediately enable the backup on it and then I've been using Azure Backup automation for so many years, which covers both Azure virtual machine, SQL instances and some other solutions within the Azure environment. It is a kind of automation that is very easy to use and then it's going to take care of your environment. Let's say for instance, when it comes to the restore, restoration, probably there's a problem or probably you want to do a kind of restore test. The solution is very, very good. It's capable of doing that because I still remember I've done a lot of restoration within the infrastructure on several occasions. I'm also doing something else too within the environment. I can restore to another geo-location within the Azure environment as well. Let's say for instance, my infrastructure is being provisioned within the West Europe and I want to do a kind of restoration to another geographical location, I can do that. I am working with multi-layered security features in the Azure environment. The company has different departments, the infrastructure team, the IT security teams and then the database team itself. We have some set of people that manage the entire database. My own responsibility is to make it available, provision it, make it available, give access to the database guys and their application guys to work with. When it comes to security, I have my own side of it, while the database guys also have their own side of it, especially when you are talking about the database. It is a shared responsibility. I'm not the only one handling that. We run vulnerability checks on a regular basis, on a quarterly basis, to see if there's anything that we need to probably close within the infrastructure.
My main use case for Azure SQL Managed Instance is for storing information related to insurance and claims in the staging database to avoid using Dataverse because it is more expensive. I use Azure SQL Managed Instance to store claim information, which allows me to save the data there. Typically, I have a retention period of 30 days in my own Dataverse. Once the data is moved from Dataverse to Azure SQL Managed Instance, I immediately delete that data from Dataverse. The retention period in Azure SQL Managed Instance is eight years, and I display that data on Dataverse by using the OData API in the virtual table.
Azure SQL Managed Instance is a managed database service that combines the rich SQL Server programming surface area with automated operations like patching, backup, and performance tuning, providing a seamless way to modernize applications with cloud efficiencies.Designed for enterprises looking to migrate to the cloud, Azure SQL Managed Instance offers a high level of compatibility with SQL Server, making it an attractive option for those aiming to move existing applications with minimal...
I work with Azure SQL Managed Instance, which is a managed instance. Azure SQL Managed Instance is basically a single database and is a fully managed isolated database. There is also an elastic pool in it, which is a single collection of databases that share a set of resources like CPU and memory. Regarding the different features, it has independent selection of compute or compute tiers like the provisioned one. In terms of service tier, it can be used for general purpose, business critical, as well as Hyperscale up to 128 terabytes. Regarding the advantages, it is highly available. It also has multimodal flexibility. We can store and process JSON, XML, graph, spatial, and vector databases for AI use. It has built-in intelligence which is used for automatic performance tuning and advanced security including Microsoft Entra ID for authentication, vulnerability management, and more. The most important thing about Azure SQL Managed Instance, which I appreciate, is its serverless compute. It has cost efficiency and massive scalability. It also has elastic pools and Hyperscale tier. Regarding built-in security and high availability, it is 99.9% available. It has AI-driven security and advanced encryption. It has always encrypted, which keeps our sensitive data protected in transit as well as at rest. Even during memory query processing, all our data is encrypted. Regarding performance intelligence, it has automatic tuning, so it automatically creates the missing indexes. It has no infrastructure management, as PaaS services have zero touch maintenance. It also has automated backups. I have integrated it with other Azure services, including Entra ID, as Azure SQL Managed Instance natively integrates with the Azure ecosystem because of its foundational cloud services. It has AI and machine learning integration, event-driven and serverless computing, and analytics and big data integrations. It also has identity and management integration for Entra ID and more.
If you have an application that will probably require a database engine or database solution like SQL, and probably your solution is being deployed within Azure environment, there's no need of creating a new server, probably a server instances, such as a virtual machine within your Azure environment, and then probably install or start installing a new SQL on it. It is a little bit cumbersome when it comes to manageability. You don't need to, you have to take the headache off yourself because Microsoft has a complete solution already, which is Azure SQL Managed Instance, within the Azure infrastructure, whereby you can deploy your SQL instances and then point your solution to it and then it's scalable. You can start small and then grow big later. It has a lot of advantages. You don't need to worry about the security, you don't need to worry about the patching. Microsoft does that for you. At the same time, you don't really need to worry about the licensing because for instance, if you have a license assurance, you can bring in your license to that environment to reduce the cost. I have been working with automated backups in Azure SQL Managed Instance. Once the instance is being provisioned, I immediately enable the backup on it and then I've been using Azure Backup automation for so many years, which covers both Azure virtual machine, SQL instances and some other solutions within the Azure environment. It is a kind of automation that is very easy to use and then it's going to take care of your environment. Let's say for instance, when it comes to the restore, restoration, probably there's a problem or probably you want to do a kind of restore test. The solution is very, very good. It's capable of doing that because I still remember I've done a lot of restoration within the infrastructure on several occasions. I'm also doing something else too within the environment. I can restore to another geo-location within the Azure environment as well. Let's say for instance, my infrastructure is being provisioned within the West Europe and I want to do a kind of restoration to another geographical location, I can do that. I am working with multi-layered security features in the Azure environment. The company has different departments, the infrastructure team, the IT security teams and then the database team itself. We have some set of people that manage the entire database. My own responsibility is to make it available, provision it, make it available, give access to the database guys and their application guys to work with. When it comes to security, I have my own side of it, while the database guys also have their own side of it, especially when you are talking about the database. It is a shared responsibility. I'm not the only one handling that. We run vulnerability checks on a regular basis, on a quarterly basis, to see if there's anything that we need to probably close within the infrastructure.
My main use case for Azure SQL Managed Instance is for storing information related to insurance and claims in the staging database to avoid using Dataverse because it is more expensive. I use Azure SQL Managed Instance to store claim information, which allows me to save the data there. Typically, I have a retention period of 30 days in my own Dataverse. Once the data is moved from Dataverse to Azure SQL Managed Instance, I immediately delete that data from Dataverse. The retention period in Azure SQL Managed Instance is eight years, and I display that data on Dataverse by using the OData API in the virtual table.