Hacker News Reader

Comment by hliyan | Hacker News Reader

In my experience (worked for organizations that used everything from on-prem server racks, to Linode to AWS to Azure), complaints about cloud infrastructure are proportional to managed service usage. I rarely hear teams that largely rely on virtual machines (perhaps with a managed RDBMS) complain. They do have to maintain a little extra scripting, but that's a minor inconvenience compared to battling issues and idiosyncrasies of managed services.

View on HN

I'm sure it's gotten better now but back in 2016 provisioning VMs in Azure took so long that we joked that every time you provision an instance a Microsoft engineer gets in a car to buy the server.

Reminds me of how my Swiss bank doesn't support transfers outside business hours. I have to imagine when I click "send" in the UBS app, some guy named Hans-Ueli receives a tape printout and goes into the basement to move some silver pieces from one drawer to another.

If everyone in this thread shitting on Azure is going off how it worked in 2016 the comments here make a lot more sense. I know Microsoft bad still lingers in online communities but I have to say I’m surprised hackernews is still this anti Microsoft. In my experience, both Azure and AWS have their issues, it’s not like AWS is some perfect offering but you’d think that based on the comments.

Just restarting a vm still takes 20 minutes from clicking the restart button.

It's okay. We are forced ( by our client, who has forgotten to update it's it since 2005 ) to start several clients in a pipeline. Startup is less than a minute, going from zero to a full resource group with two VMS and ancillary resources.

I'm a little confused by this post. Obviously it's easier to maintain a plain VM than managed services. That's why people are paying a lot more money to the cloud providers for managed services, so they don't have to do it themselves. What you're saying is that this is essentially a pointless endeavor? I don't think this statement is entirely uncontroversial, since managed services are the main reason for many companies to migrate to cloud.

Using managed services is not a pointless endeavor – they can save you a lot of time (and therefore money).

Unless you need to switch providers, at which point it may take more time to adjust for differences in how those managed services operate.

Managed services are absolutely not the main reason for moving to the cloud. Companies do it for the flexibility that comes with renting the real estate/energy/hardware instead of owning it.

We use managed services, but only those that are managed versions of pre-existing software.

For example, we'll used Managed Postgres, but not Azure or AWS's home grown databases.

Makes migrating much easier.

Heh, until you need to rollback a specific table in postgres using their backup solution. IIRC, this is possible in AWS -- or at least, I'm 99% sure you can at least download the backup. In Azure? All you can do is restore the entire database, and you cannot download it.

You can def download it

Not in my azure portal.

>> You can def download it

I would love for you to briefly describe how and where this can be done. I wasted a significant amount of time searching for this exact capability for Azure SQL Database and only ran into dead-ends.

For Azure SQL Database, you can restore any database backup to a new database, and export any existing database to bacpac format on a storage account [0]. The storage account file can be downloaded. You can also do the latter without using through the portal, using sqlpackage.exe on your local machine (same restriction applies: sqlpackage must connect to a live database, so if you want to download/view an Azure backup you must first perform a backup restore).

Not sure how to do the same for Azure Postgresql databases, but looks like standard pg_dump and pg_restore are supported.

[0]: https://learn.microsoft.com/en-us/azure/azure-sql/database/d...

Yes! The longer response is that the closer you stick to standards the easier of a time you will have. VMs are a standard with cloud-init and image formats, etc.

i.e. in 2025 managed Kubernetes is not _that_ different between providers

I mean, if it was solely about renting machines, we’d all just use DigitalOcean, or EC2 on AWS.

People use things like RDS and EKS/GKE to avoid all the administrative overhead that comes with running these things in prod. The database or its underlying hardware has a problem at 1am? It’s Amazon engineers getting paged, not you (hopefully… assuming the fault hasnt materialised to operational impact yet)

It's easier for the provider to maintain a VM provision. It's supposed to be easier for the customer to maintain managed services, but that's often debatable.

I've never seen a managed IaaS that saved time. It is marketed as something that can free you from hiring ops people, but you will absolutely need to hire some supplier relations people to deal with it. (And contract optimizers, and internal PR to deal with the fallout.)

It's different for fully featured SaaS. It's a matter of the abstracted complexity vs. interface complexity ratio that is so common for everything you do in software.

cloud services are great when they work. but in case something isn't you have no way to debug anything except maybe restarting the service if it's even possible.

we had one customer that needed IPsec tunel to vpc where production servers were living, we didn't want to maintain such setup just for single customer so we check Aws offerings. and look at that they have managed IPsec solution, great.

until client called that tunel is down and solution wa that they need to restart it on their end to resume connection. why? you can enable some logging to S3 but according to them everything should work. what we should do next?

but even if you stick to just ec2 thing can go weird. our recent incident: ec2 instance stopped responding but ASG didn't replace it, any action on it throwers error that instance is not running but it was in running state.

I wish I could better help my org see that. Luckily my boss agrees with me, but he's not in full control. Between the vendor lock-in, and the _almost but not quite api compatibility_ with OSS... I just dread as more teams adopt it.

"But it's easier!" ... yeah, we'll see...

Azure's anti competitive conduct is also the reason that AWS stopped lowering prices.

Before 2014 or so, AWS would periodically reduce prices on major services passing on falling technology costs.

Azure didn't like that, so they aligned their prices to AWS's, matching immediately the same discounts on the same service.

This is a form a predatory pricing, because the goal is to kill the incentive for competitors to reduce prices, by denying them market share gains when they do.

"Show us a better price and we'll match it" is not a new tactic nor exclusive to clouds.

Reply on news.ycombinator.com