Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't understand the AWS fetish either. I guess nobody ever got fired for using AWS. It's the IBM of the cloud.

If you need managed services Azure and Google Cloud are largely better. If you just need compute and transfer Digital Ocean and Vultr absolutely destroy AWS.



Would really love to hear what makes Azure "largely better". My own experience is far from that. I have yet to meet anyone not relying heavily on moving over a MS stack or that has gone beyond the "hit a template to deploy a test" use case that really likes it. When I get folks down to the brass tacks, it tends to boil down to "I don't have to pay the overhead of the Windows license anymore" or "I like having MS services as a PaaS".

On the other hand there are a lot of inconsistencies and odd limitations on the services.


I echo your sentiments. I run Azure in production at my job, running both Windows and Linux stuff and constantly run into weird edge cases, inconsistencies and stuff that just doesn't make sense.

There's really only one thing I can think of that I love is resource groups. It's nice to be able to group together everything in a deployment, for quick access and administration.


DigitalOcean and Vultr destroy not just AWS on network traffic costs, they destroy all three of them by an absurd margin. I have no explanation for that huge gap. It's the great mystery of cloud computing.


The huge gap is easy: there is significant security in place at the big 3 that DO and other vendors simply do not have.

Google's security team is probably as big as DO's engineering team.


That's not why <cloud provider> networking is so much more expensive than a VPS provider... All of the big providers have fairly serious networking investments (and I think it's fair and honest to say that Google's is the largest) that provide a network quality and performance you won't match with any VPS provider. Do you want to stream more than 100 Gbps during the Olympics to people all over the world? Don't try that on OVH, DO, etc. but you can do it on us. We (Google) in fact charge more than AWS for our networking because of our massive global network.

tl;dr: you get what you pay for, and you don't always need our crazy network!


I understand that in principle, but before paying the big cloud providers between 10 and 20 times what I would be paying Vultr/DO (for network traffic), I would like to know a great deal more about the actual performance difference.

I know it's probably on me to find that out myself.


There's an entire industry of companies and analysts willing to sell you that information :)


Interesting... so with Google and Amazon and the like I am paying more for the existence of capacity that I could hypothetically utilize?

DO and Vultr are colocated at very large sites. For many locations they sit right next to carrier hotels. I am a bit skeptical of whether the real world difference is that huge, especially if I sprawl my endpoints across both these providers and many locations.


I've never heard of Vultr until today. Have you used it? Can you tell more about it?


Samething as DigitalOcean without the hype.

5$ SSD VPS, 768M of Ram instead of 512 at DO, the reason I moved in at first.

The popularity clearly helps DO keeping up with more 1 click apps and other features than Vultr, but they recently made available reserved IPs and Object Storage, so they continue to be a good alternative to DO.


I am using Vultr, but the particular project I'm using it for doesn't put a whole lot of strain on their infrastructure yet.

So far it's been working well and support was very responsive on the one occasion when I needed their help.


As others have said, similar to DO. It has a few more options available, though, including better support for booting your own OSes if you don't want to use a prepackaged one, and dedicated instances (last I checked DO didn't do either, but haven't looked for a bit, might be out of date). I've also found their support to be more willing to work with me to get things running how I want, but that's obviously just anecdotal.


The thing I really like about Vultr is that to use their site, you just have to enable Vultr.com (in NoScript). For DO, you have to enable 15-20 domains because they use all kinds of outsourced services, and every time you go to a new page, there are new things that have to be enabled. I got tired of it.


The gap is that you are expected to serve most of your traffic through their blob stores and CDNs, not through the compute instances.

The traffic prices for each of these are very different.


In that case I can just use S3 for blobs and use Digital Ocean and Vultr and Linode for compute. Amazon charges $0 for bandwidth ingress so uploading to S3 costs me nothing.

We use VPS providers for compute and S3 for backup and large blob storage. The only other Amazon product we use is Route 53, which is a decent DNS-as-a-service and is very reliable.


Of course. The trick is to decide what mix of lower price and lower complexity is your sweet spot.


Very much depends what you are actually doing in the cloud.


Disagree on compute, actually - specifically, AWS Lambda is great. Its lack of Python 3 support certainly is the thing that pisses me off the most across the whole AWS stack but that's also because it's my favourite there. It's fantastic for on-demand distributed computing, and really cheap.


Azure functions seems similar enough and a bit easier to adapt, though the runtime is windows based, so it's easy enough to include other executables.

What I'd really like to see is Compose.io's full product lineup on Digital Ocean already. As it is, I'm considering seeing how well Azure Tables, and Azure SQL work from DO SFO2 to Azure West US...


Its simple - moving to the cloud at all is a big risk for some executives. They don't want to compound the risk by going with anything but the leader.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: