Skip to main content

Flavors of SQL inside Azure (Azure SQL)

Just realized a few days ago that there are so many flavors of SQL inside Microsoft Azure that you need to be careful when you decide which one to use. In this post, I want to present the most important flavors of SQL that you can have inside Azure and to define a demarcation line between them.

1.0 SQL Server inside Azure VMs (IaaS)
The classical IaaS approach where customer needs to manage the VMs and the SQL Server instance that is running on top of Azure. The list of tasks that you need to do when you run your SQL instances on top of Azure VMs are the same as you would have the SQL Server instances inside your own data-centers. From license, to backup and restoration procedures, all of this needs to be managed by yourself.

2.0 SQL Database (PaaS)
The current offer of Azure related to SQL on the PaaS environment is more complex than you would expect. In this moment there are 3 options available, that cover most of the uses cases that you might have.
  • SQL Database (Singleton)
  • Elastic Pool
  • Managed Instance
A short overview on each of one can be found below.

2.1 Azure SQL Database (Singleton)
It’s part of SaaS category from industry perspective, but it falls in both categories SaaS and PaaS. It’s fully hosted and managed by Azure, client is responsible only for the content that is pushed inside the storage. All the maintenance and complex procedures to have a high SLA and good backup and restore procedures and fully managed by the platform.
You just specified the tier and the DB size and from that moment, you don’t care about anything else. You pay based on your use and you can scale up or down dynamically.
There is no management of infrastructure cost, being out of the box fault tolerance. Features like Point-In-Time restoration, geo-restoration and replication are included. It’s a good option when you start from scratch and you want to focus on your business value.
Each instance of database has its own virtual resources. It is important to remember that even if each tier has a specific number of resources reserved this does not mean that physical servers are dedicated to your own SQL database instance. Because of this, you cannot share available resources between different SQL database instances. In comparison with this, Elastic Pool allows us to share resources between database instances.

2.2 Elastic Pool
In comparison with Azure SQL Databases, elastic pool is a little bit different. Even if you still create SQL Database instances, you put all of them in the same pool, where all resources are shared. These means that all your DB instances that are part of the same Elastic pool are using and sharing the same CPU, IO and memory.
These is a model that works great if you have multiple DBs, where the pick of each instance is in different time periods. When you are using Elastic Pool don’t forget that all the DB instances are having the same tier and performance of database instances can be affected by the other databases that are in the same pool.
I compare Elastic Pool with farm with steroids. You can reserve computation power that it is shared between database instances, but without caring about backup, pooling and other stuff that are coming for free.
Just do not forget that things like SQL Agents, SSIS and Service brokers are not available inside Elastic Pool.

2.3 Managed Instances
This new service is part of Azure SQL family. In comparison with Elastic Pool you have all the features that you have on-premises (like SQL Agents, SQL CLR, cross-database querying), but in the same time you can use the full power of Azure SQL offering you out of the box support for automatic backups, high-availability and many more.
An interesting thing of Managed Instance is how you can configure it. You can put it inside a VNET, using his own private IP, without direct access to internet. It’s like having an Azure SQL Database with all the features inside a private network.
In comparison with Azure SQL Database, the DB size can reach 35TB without having to do any custom configuration. It is the right place when you start a migration from on-premises to Azure.

In conclusion I would like to share with you a comparison between SQL Server running on Azure VMs and SQL Database offered as PaaS (Azure SQL Database Singleton)


Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…