How to work with Azure’s managed MariaDB

If Microsoft is to succeed in making Azure its future, it needs to bring developers to its cloud platform. That would be easy if we were back in the early days of the PC, when it was still possible to build and lock in an ecosystem. But we live in a world were developers have choice, and where they choose the appropriate tools for the tasks at hand, mixing and matching proprietary and open source tools.

Azure’s original platform-as-a-service (PaaS) approach made that hard to deliver, with only a limited number of services supported. So developers went where there was flexibility, to Amazon Web Services and its virtual infrastructures. Microsoft’s resulting pivot to Azure supporting infrastructure-as-a-service (IaaS) simplified bringing your own tools and services, but like AWS, you were only using Azure as a managed data center, hosting your VMs and your data.

As Azure continues to evolve, and as cloud-native development models based on microservices and container orchestration replace lift-and-shift monolithic VM-based architectures, it’s begun a slow shift back to PaaS. In line with the rest of the industry that’s also led to Azure offering new platform services that can replace applications running on VMs.

Azure’s return to PaaS goes through database services

Perhaps the most obvious of these changes has been the launch of a series of managed database services, offering simpler billing models and less administrative overhead than running your own database VMs. With a managed database service, you can bring existing application back ends to the cloud, ready for use with newer application development models, without having to manage your database infrastructure and storage.

Azure’s managed databases include popular open source databases, as well as Microsoft’s own SQL Server. One of the more important services is its managed MariaDB instances, letting you run MySQL databases on Azure, simplifying ports and upgrades of older web applications. To help increase confidence in its platform, Azure has become a Platinum-level sponsor of the MariaDB Foundation, helping fund development and taking part in the community.

Managed MariaDB on Azure

Developed by the original MySQL team, MariaDB is a modern update of the popular open source database. With support for the same APIs, and able to run on the same platforms, it’s an alternative to Oracle’s MySQL that’s guaranteed to remain open source. Perhaps the most important feature is that there’s binary compatibility between MariaDB and MySQL data, simplifying migration.

With MySQL at the heart of many web applications, you can bring existing data and applications to a new MariaDB database. Azure’s support for MariaDB gives you a simple route to lift and shift existing web applications from your own servers to Microsoft’s platform. Once your data is in place, you can start updating applications using cloud-native development techniques, or take advantage of it in newer services without having to change your database.

Azure Database for MariaDB is based on the Community Edition of MariaDB, so there’s very little learning curve. Once data has been uploaded, you can work with it in your code, or use it with applications from the Azure Marketplace, such as hosting WordPress on Azure with a MariaDB back end. Data from MariaDB can then also be used in other Azure services and applications, so you can use it as part of a mobile application or as a source of data for a machine learning service.

Setting up Azure’s MariaDB

Because Azure manages your MariaDB instances for you, you configure them as part of an Azure resource group, using the Azure Portal. Once in a resource group, a MariaDB database can be managed alongside the rest of the resources used to build an application. You can also use the Azure command-line interface or ARM templates to set up and deploy MariaDB databases.

One important point to note is that once you’ve created a database, it’s automatically firewalled. So you’ll need to open access to your application and to any management PCs. If you’re using an ARM template, you can add the appropriate firewall rules as part of your resource group deployment; otherwise, you’ll need to manually configure the firewall through the Azure Portal or command-line interface.

Because MariaDB is API-compatible with MySQL you can use familiar tools like the MySQL Workbench or the MySQL CLI tools, to work against an Azure MariaDB instance. You’ll find the login details you need for a connection in the Azure portal, including the fully qualified domain name for the database server and the administrator user name.

Once connected, you can create a database, add tables, and load data ready for use. Code will access your database using familiar APIs and SDKs, simplifying porting applications from on-premises to the cloud. The Azure Portal automatically generates connection strings for most common SDKs, including ADO.Net and JDBC, as well as PHP and Node.js.

Pricing for MariaDB instances is based on compute resources; you pay for storage as well. A basic workload uses one or two Gen 5 logical CPUs, with storage of up to 1TB. General-purpose workloads have from two to 32 logical CPUs, and up to 4TB of storage. There’s a closely related Memory Optimized option, which is intended for use with in-memory MariaDB instances. Compute is charged on a per-CPU hour basis, with storage per gigabyte per month.

Choosing MariaDB workload instances

You can use a vasic workload instance for development and test, while you port on-premises MySQL or MariaDB to Azure. Once your application is running, you can then switch to a general-purpose workload, tuning CPUs to scale your application. Because storage is handled separately from compute, you can scale the two independently. While I/O isn’t currently billed, it will be from April 2019, so you’ll need to factor that upcoming change in your budget.

Azure provides a backup option for your data, with free backup storage for a single copy of your data. Additional backup storage is charged on a per-gigabyte basis, but it can be set up to give you geographic redundancy. Backups are managed through the Azure Portal, with data stored for seven days. You can restore an existing server to a previous backup (a process that actually deletes the current server instance and replaces it with one that has the backup data and the same configuration), or you can use the backup to create a new server.