General overview of Azure relational databases and AWS

Below is a general table, based on it, we see which DBMS are presented in the cloud as a service (SaaS).

Presentation of relational databases in the clouds

DBMS in AWS are presented as part of a single RDS service

In fact, when you create a database instance in RDS (relational data service), you will meet the features of specific DBMS, and not the general RDS service.

That is, if you are deploying MS SQL Server, you need to select the type of licensing – Enterprise, Standard, Express or Web edition, select the version (2012-2019), disks and capacities of the virtual machine on which the instance will be deployed, and configure the infrastructure. If the work will be with other types of DBMS, then, accordingly, everything is configured for a specific DBMS with all its features.

Thus, RDS for the most part repeats and implements full-fledged DBMS, and when choosing and configuring, users are guided by knowledge of ground-based full-fledged implementations.

This allows for full compatibility with ground instances, which facilitates migration in certain scenarios and provides access at the operating system level.

DBMS in Azure are separated into separate services

Services in Azure primarily allow you to focus on developing applications and solutions from scratch, can be used for various types of workloads with the ability to change technical characteristics depending on the intensity of the workload, type or conditions. These performance changes can occur automatically or on demand, and these capabilities describe the level of scalability of services.

The ability to scalability is due to the fact that infrastructure management in most DBMS services is completely transferred to the Microsoft responsibility level, and only data and application management remains at the user level.

RDS also refers to PaaS, but since it provides full compatibility with terrestrial instances, it requires a deeper understanding of the specialist precisely the features of terrestrial full-fledged instances.

Cloud DBMS services in Azure have their own approaches, support full code compatibility, but do not provide full compatibility with the full version of the DBMS, of which they are a projection.

This is also due to the fact that Microsoft is trying to implement a higher granularity of functionality. Generally speaking, they separate the functionality into separate services or settings, charged separately. This allows you to build a transparent and flexible approach to pricing, which, in the case of the right service and settings, will allow you to build the optimal solution in terms of price / performance.

Relatively speaking, the functionality of MS SQL Server in the cloud can be divided into separate services with their own pricing principles.

For many scenarios, the “full set” is really redundant, and often it will be enough just to use the database functionality, and not all related services at once, for the availability of which the client somehow pays payments covered by the license of a full instance.

Example: Granularity is an inexhaustible number of possible services and pricing factors.

In addition, Azure has a wider range of database options offerings related to MS SQL server DBMS types. This is not really surprising since Azure is Microsoft and SQL Server is also Microsoft.

The company is trying to expand its line of offerings to suit a variety of users with different workloads, from total newbies who want to try databases and understand what it’s like to install a database without too much hassle, to experienced developers or administrators choosing databases. and quite finely configure the database for industrial loads.

At the same time, many administrative issues will still remain on the side of Microsoft.

Much that RDS can do with SQL server databases will also be able to Azure, but in addition it will offer even more hybrid versions for different users and for different cases.

I propose to take a closer look at the proposals of Azure and AWS.

What does Microsoft offer with Azure SQL

Deployment models in Azure SQL

What AWS Offers

A relational database is a virtual machine with MS SQL Server installed. SQL Server on Azure Virtual Machines are identical services (IaaS).

Further , AWS offers the mentioned RDS from MS SQL Server (SaaS).

Here you will not manage a virtual machine, but you will choose from many types. It is necessary to understand not only the simple and main indicators of database efficiency, namely IOPS, memory, CPU – you will need to understand the characteristics of virtual machines. Yes, of course, there is documentation, but this story will be more difficult for pure developers or analysts, and not profile admins.

Again, Azure also gives you the ability to be subtle.

Azure has a managed instance, an Azure SQL type that most closely matches the RDS, where the VM is also selected. You need to understand its features and configuration details, but in addition, Azure SQL single database, which really works as a service, is the most cleared of infrastructure issues and is a “pure” database engine.

This ensures the T-SQL standard for all versions.

For example, options for selecting virtual machine (ec2) settings for RDS.

Part of the parameters that are configured: Allocated storage, Architecture settings, Auto minor version upgrade, Availability zone, AWS KMS key, Backup replication, Backup retention period, Backup target, Backup window, Character set, Collation, Copy tags to sna Database management type, Database port, DB engine version, DB instance class, DB instance identifier, DB parameter group, DB subnet group, Deletion protection, Encryption, Enhanced Monitoring, Engine type, Initial database name, License, Log exports, Mainten Master password, Master username, Microsoft SQL Server Windows Authentication, Multi-AZ deployment, National Character Set (NCHAR), Network type, Option group, Performance Insights, Provisioned IOPS, Public access, Storage autoscaling, Storage type, Time zone, Virtual Private Cloud (VPC),VPC Security Group (Firewall).

Some parameters have their own nested parameters.

Opposite  options for creating Azure SQL

Azure SQL has two general deployment models, classified more compactly (I will describe them in detail in the following articles on cloud databases).

First model

Second model:

That is, the choice of service is unified to the types of load with gradual scaling.

If Vcore is 1, 2, 4, 8, 16, 32 and so on. If DTU is 20, 50, 100, 200, 500, 1000 and so on.

Of course, there are many details in choosing an Azure SQL type, most of which have a business context. A clear understanding of the business needs is very important because the technical details are integrated into the business definition to make it easier to understand which database you need to choose if you are not a DBA but a developer or a startup owner.

This is a topic for a separate article, but it is interesting to pay attention to the pricing and cost of Azure SQL compared to peers in terms of performance from other cloud providers. The difference in price between medium and expensive plans can exceed 100%, but you need to understand how to balance the functionality.