Why not Azure

Posted under others On By xpk

I recently attended a 4-day training on Microsoft’s cloud platform. Quickly I learned why it should not be used if you’re serious about your business.


The portal, both classis and preview are very slow. But it’s not just the portals, the operations inside these systems are slow. Simple tasks like adding an end-point (AKA port) for a VM doesn’t happen instantaneously. At times, the portals contain cached values and I had to navigate away, go back 5-6 times just so the portal picks up the new value.

Some of the management tasks can only be performed with powershell, but I quickly notice the response from powershell is also not very fast. The overall efficiency is further reduced when these 3 tools need to be used together in order to perform all the basic tasks. There is a 4th tool called azure-cli, which can only do a subset of tasks compared to powershell. For instance, it couldn’t update the pre-shared key on vnet gateways. That can only be performed with powershell.

VM limitations

Windows VMs have a hard-coded 127G c:, Linux VMs have a 30G root disk. That cannot be changed at deployment time or after. Unless you’re willing to detach the VHD, mount it as a data disk on another VM, and do the resize manually. Some say VHDX support is coming which will allow disk resize.

When it comes to OS support, MS has decided not to offer Redhat VM.

VM Auto-scaling

I would not call it auto-scaling. This function should be called auto-power-cycle instead. Your auto-scaling group needs to be pre-populated with VM instances. You can power them off afterwards and Azure will power on/off for you on-demand. You will NOT be able to give auto-scaler an image and deploy the instances on-the-fly. When you think about updating the machines inside an auto-scaling group, that’s going to be a headache. You’ll need to delete the instances, update it, possibly clone them, and possibly reconfigure the availability set and load balance rules – because the end points will be changed.

SQL server

To my surprise, Azure SQL database service can only be accessed via Internet. Your Azure VMs will not be able to access it via private network. Yes the connection can be encrypted, and on the latest v12 database, there is a preview function to enable TDE. But still, database servers should be placed in database tier not just for security reasons.

CDN is a joke

I have not used any CDN that requires me to enable query string. And Azure’s CDN does not support purge. It’s at best good for caching static downloadable. For a dynamic web site, there are many options out there that are more mature.

What I like about Azure

I like its VPN. Client-to-site VPN is pretty easy. Once configured, it will provide a link to download an installer which creates the connection for you, on Windows platform. Site-to-site VPN seems easy too, but that’s not unique to Azure.

CIFS / SMB2.1 service

It’s a preview feature. A shared filesystem will make scaling out a lot easier. I think this is one of the must-have feature on cloud so administrators won’t need to waste time managing a file server.

AD integration

It can be used as LDAP or perhaps SSO server. I don’t know AD well enough but I do like core components being servicized.

To me, cloud is about pay-as-you-go and offloading core services from administrators. It should allow me to go from very small to very big without the up-front investment and re-architecting the whole thing. Components like database, cache, directory service, file server, VPN, etc should be converted to standardized services so I don’t need to set them up myself. I guess Azure still meets these requirements so it’s not a total disaster. But it has a long way to go  to catch up with AWS.

 583 total views,  4 views today

Leave a comment

Your email address will not be published. Required fields are marked *