(full disclosure: I work for Microsoft, and love Elixir )

Hi,

I haven’t yet spent too much time on the actual runtime side of Elixir on Azure. One thing I did was to run a Distillery with multi-stage docker, then push the resulting image to Azure Web Apps (with Linux). Also Azure Kubernetes Service (AKS) is an obvious solution. When it comes to running an Erlang Cluster in a virtual network, there are no reasons why it should not be possible…

Regarding your question on whether Azure plays well with BEAM instrumentation, I would guess all BEAM things would be independent of or orthogonal to Azure?

As for the Elixir application side of things, I started to build libraries to interact with various Azure APIs:

• The chgeuer/ex_microsoft_azure_management_generator repo is a utility which auto-generates a big chunk of client-side proxies for the Azure Resource Manager (ARM) management API.
• You can find the generated code in ex_microsoft_azure_management.
• I have a sample project ex_microsoft_azure_management_samples which demonstrates how for example to list or create resource groups, or how to trigger an ARM deployment.
• The thing where I spend some more love was on the application plane, particularly with the Azure Storage API. The ex_microsoft_azure_storage project shows you how to interact with Azure blob storage. This is an early stage API client, but works for me ™.
• Ramon (a colleague) created an Azure KeyVault client ex_azure_key_vault

Feel free to ping me via mail (chgeuer@microsoft)…

Various Azure services allow you to authenticate using 2 different ways, some sort of password-based authN, and using Entra ID (formerly known as Azure Active Directory).

First a bit of history: When storage accounts were released back in 2008/2009, you only had storage account keys (2 secrets), that you supplied per request. Then shared access signatures came out (where you derive a value from the secrets). Then AAD/Entra authN was introduced. Same for SQL database (and MySQL and PostgreSQL), where in early versions you had to pick an admin username and password, and later supported Entra authentication.

Now storing passwords for services is kind-of a bad thing: You need a different password/credential for each service you want to call. If your app calls storage, SQL, service bus, event hub, Key Vault, you have to store (and protect) 5 credentials. And if one of these credentials is compromised, you must rotate it for all callers. It’s in general messy.

If you on the other hand have an Entra credential (which still can be a username/password combo like in the example with client_id/client_secret), you still must protect that one. But if it’s compromised, you only rotate a single credential of a single app, all server-side ACLs remain as they are.

What’s even more important, if your app workload runs in the cloud, you can use “managed identity”, where you tie an Entra identity to the VM or web app or Kubernetes pod you’re running on, and your workload doesn’t have to store any cred at all. When you need a token, you just issue a token request to 169.254.169.254, say you need a token for PostgreSQL, and off you go.

If you don’t want to do Entra authN, just skip all the Entra bits in the blog article and just do your username/password thing like before…

However, I strongly recommend to use Entra authN. For example, in the words of the storage team:

For optimal security, Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests against blob, queue, and table data, whenever possible. Authorization with Microsoft Entra ID and managed identities provides superior security and ease of use over Shared Key authorization. src

Using Entra authentication at the first glance makes it more complex: You must create an Entra app (setup takes longer), and prior authenticating to the DB you need to request a token. However, once you figure out you must rotate creds, or one credential is compromized, our you want to audit which app did what, you certainly start to appreciate having not used the same PostgreSQL password for all your workloads.

Added a short section here:

How did your setup look like?

Terraform with its state stored on s3 (could be azure’s alternative), distillery with docker to build releases (on CI) and upload them to s3 (could be azure’s alternative), epmdless distribution over azure’s vpn (might later move to partisan).

Did you use Azure Container Instances or Azure Virtual Machines?

Azure Virtual Machines (mostly the spot instances)

Did you deploy to a single node or multiple nodes?

Multiple. No issues.

Were you using some kind of containers and orchestration, e.g. Docker and Kubernetes?

No, but we used some bash scripts though which would download the releases from s3 and then enable and start the apps via systemd.

Does Azure play well with BEAM instrumentation and debugging tools?

Since it’s just a linux instance, it works as any other linux instance (which is ok).

Did you experience any significant difficulties?

It would be a bit too expensive for us if it wasn’t for the spot instances.

Hello @chgeuer how would you do this today? especially with releases introduced. I would love to know how you deploy docker images to Azure Web Apps, connect to a Postgres database on Azure, run migrations and seed the database.

Hi @dumadi, once your Elixir app is in a Docker image, you can host it (like any other workload) in Azure App Services, Azure Kubernetes Services or Azure Container Apps. When connecting to PostgreSQL on Azure, you just have to ensure that your workload uses TLS to connect to the PostgreSQL database.

@hoetmaaiers, apologies, not clear what the Q is. Terraform is kind-of the outer part. From an Elixir perspective, I guess the Azure-specific Qs are how can an Elixir workload talk to platform-specific services. Whether you deploy an Elixir workload to Azure using Bicep, ARM, Terraform, Pulumi or something seems not the big concern to me?