The problems we faced with Azure

anand pathak
5 min readOct 16, 2018

Recently I got the opportunity to work with Azure services. I was assigned to work on migrating cloud architecture to Azure from AWS. I never worked with Azure services before so initially, was excited to try out some services and check where does it stand compared to AWS.

While migrating cloud architecture to Azure, We faced multiple problems with Azure services, here in this blog I will be focusing on the problems we faced while working with Azure.

  1. The Load Balancer Problem.

Azure provides two services for load-balancing incoming traffic, Load Balancer, and Application Gateway. Load Balancer is layer 4 service and it forwards TCP, UDP or both protocol request to a back-end Pool. it supports back-end Health probing on TCP or HTTP. On the Other Hand, Application Gateway is more of a layer 7 service which allows SSL offloading on the incoming request, Cookie based session affinity and HTTP Load Balancing, but it does not support TCP/UDP based health probing.

In our case, we wanted service to perform SSL termination and Load Balance for TCP based WebSocket. Since the Back-end Pool was TCP WebSocket, Application Gateway fails to Health probe and does not work. In the case of AWS load balancers are capable of handling TCP/UDP traffic and does have the option to do SSL offloading at the same time, so there wasn’t any problem on AWS.

  1. Storage Account

Azure has a lot of options in Storage Account service. Blob, File Storage, Queue, Tables. These Services Seems very stable but we had one problem with the File Storage service. In the Application architecture, we used EFS (Elastic File Storage AWS ) which is mounted to multiple servers and we can share the same data with each server easily. To implement the same on Azure we mounted File storage to Multiple Server, which works similar to EFS. There we encountered one problem with Azure File storage mounted on multiple centos server.

Whenever frequent delete/ move operation is executed, File storage marks the file for deletion but it does not delete the file. So after that, the file can be seen but neither it can be accessed nor can be edited or deleted. After We raised support to Microsoft assuming that its a bug in their service, we got very unusual and dissatisfactory response.

They said that it’s the problem of our architecture it should not do very frequent changes to the same file as every operation in File storage act like an HTTP request, and when we are running any delete or edit it's sending multiple requests without getting the response which is creating the problem.

We understood the problem and also corrected it, but one thing we were not satisfied was, even if it’s calling two CRUD request on the same object, at least this should not corrupt the file, or the file name should be accessible after that some expire time. But that file goes for forever lock mode.

We had a long discussion with Microsoft support team, where we asked that why there isn’t any lock added on each request? there they made a valid point that any lock on the operation will reduce the performance and other users may not have this scenario, for them also the performance may suffer. Well, that made sense but still, if there is any collision In write request at least it should not corrupt file or lock the access forever. we couldn’t use the same filename as they went into delete mode, and It was not allowing another file creation with the same name. which is for sure a bug.

Below script can replicate the issue if ran from multiple clients.

#!/bin/bash

while :

do

dd if=/dev/urandom of=/log/test_conflict.txt bs=2048 count=10

sleep 2

mv /log/test_conflict.txt /log/file.txt

done

Azure Functions and Azure service bus

Serverless technologies are very useful and its gaining popularity as well. In AWS, lambda function provides the option to run a script on the cloud which can be scaled on demand. This makes it very useful functionality. Azure does have similar service named Azure Functions. I used Azure Function service for javascript using Linux platform for 4–5 months and it was so difficult to work with that, comparing Azure function with AWS lambda will be an insult for AWS lambda. From last 6 months, Azure Function is in preview mode for the Linux platform, and there is no option apart from Javascript and C# for Azure Function in Linux environment.

What I feel is, if you want to use C# and windows as a platform for serverless function then the documentation and service are stable, but for the javascript and other languages, it is not at all useful. Azure Function CLI for Node.js has a lot of bugs, and it does not work on Linux machine easily.

Apart from Azure Function, I tried Azure Bus Service with Node.js and Java SDK and I failed to get the example working as there Documentation and latest released API aren’t in sync. some of the services like EventHub had multiple node.js modules for single service which make implementation complex as we had to look for APIs of both the packages.

Apart from these, there are so many things which Azure which does not make it easier for developers to adopt it easily like Azure CLI not easy to install on a Linux machine. Some solution can only be done from PowerShell and does not work with CLI or Web console and vice versa. The documentation is so much tangled and so many references to GitHub repository that it hard to track which details are mentioned where?.

Overall it appears to me, that Azure is only good for them who are comfortable with C# or Microsoft technologies. Azure documentation for Javascript or other language does not have the stable example or aren’t properly maintained for most of the services.

We know that AWS is in the market for a long time and Microsoft just came into action, maybe it will take time to Azure to improve services, still, those services which are new to both AWS and Azure aren’t either easier to implement in Azure. I feel that the way Azure is providing the details about the services are not as good as AWS is. Documentation and Examples are not clear for new services. I hope in future Azure also improves the standard of the Cloud services.

--

--