Azure Container App internet outages

Question

Hi everyone!

I'm struggling with a problem and could use some advice.

I have a Python application that acts as a typical data sink, listening to data from a websocket provided by an exchange. The program runs in Docker, with the image stored in Azure Container Registry. From there, it's deployed to Azure Container Apps.

The application listens continuously and renews the websocket connections every 6 hours, so each websocket has a lifespan of 6 hours. The Container App doesn't have ingress enabled or any firewall configured. The application has been thoroughly tested—our test suite alone consists of 12,000 lines of code. Unfortunately, ready-made data sink solutions like Azure Data Factory or Data Lake aren't suitable because the exchange limits the websocket lifespan to 24 hours.

Approximately every 1 to 3 days, the connection to the exchange drops with an error from the websocket-client library: "Connection to remote host is closed." The issue coincides with times when even the Azure portal has trouble loading.

My question is: Is there a class of Azure resource where I can have a guaranteed stable connection 24/7 without interruptions in internet connectivity over a long period? Is Azure Container Apps not designed for maintaining a stable 24/7 connection? Should I consider attaching a network interface resource, or would moving to a virtual machine be a better solution?

Any insights or recommendations would be greatly appreciated!

Answer 1

Hi Daniel Lasota,

Thanks for reaching out to Microsoft Q&A.

Azure Container Apps can generally maintain long-running connections, but they are optimized for event-driven workloads and lightweight microservices rather than handling uninterrupted, long-lived connections like websockets over long periods. This can lead to occasional internet connectivity interruptions or other issues, as you are experiencing.

For a guaranteed stable connection over a long period, you might want to explore the following options:

1. Virtual Machines (VMs): A virtual machine offers more control over network configurations and internet stability. Since you can manage things like dedicated network interfaces, private IPs, and even attach a public IP directly to the VM, it might provide the consistency you're looking for in long lived websocket connections. If continuous uptime is critical, pairing it with Azure VM Scale Sets and leveraging redundancy might be a good approach.

Azure Kubernetes Service (AKS): If containerization is essential, moving to AKS might give you more control than Azure Container Apps. AKS also supports attaching a network interface (NIC) resource and customizing networking configurations, which might reduce intermittent outages.

High Availability Zones: Whether using VMs or AKS, deploying resources across Azure Availability Zones can help ensure resilience against outages in a specific zone.

Network Interface Resource (NIC): If you stick with Azure Container Apps or AKS, you could explore adding a network interface resource for more stable networking. However, this may require moving to AKS, as Azure Container Apps doesn't provide as much flexibility in terms of networking.

Azure Application Gateway or Front Door: These services can also provide better management of long-running connections with failover capabilities, especially if combined with load balancing.

In summary, a move to VMs, or even AKS with attached NICs, would likely offer more control over network stability, making them better suited for maintaining long-lived websocket connections.

This might be a bit generic answer but I hope this will help you narrow down.

Please 'Upvote'(Thumbs-up) and 'Accept' as an answer if the reply was helpful. This will benefit other community members who face the same issue.