Live data from Hacker News

You Can’t Trust Amazon When It Feels Threatened

lastweekinaws.com

11–20 of 21 posts

Re: You Can’t Trust Amazon When It Feels Threatened

#12
post #2

When can you trust Amazon?

The same time you can trust any company: never. Representative democracy isn't perfect but at least I get a vote. How many people get to vote on workplace decisions of any consequence?

You vote by talking to decision makers in that case.

Re: You Can’t Trust Amazon When It Feels Threatened

#15
To add an additional layer to this, unions are a market level element, not something individual to one company, so unions don't threaten Amazon in any way, in fact they might help amazon further increase their moat by increasing the barrier to entry.

Unions are a threat to the billionaires, not the company. So this is also to say that Amazon will lie when there is a risk to the bottom line of it's ownership. That is very different than being willing to lie if the company itself is threatened.

Re: You Can’t Trust Amazon When It Feels Threatened

#16
post #9

Earlier quoted context omitted.

From the article: In all the time I’ve been tracking virtually everything that AWS says about virtually everything, I’ve never once caught them lying to me. They will decline to answer, or give partial answers. But they have never once said something that wasn’t true. When they requested clarification on my article about Zoom choosing Oracle Cloud, they didn’t disagree with the contents of the article; they cared str…

Too bad you can't say because they didn't lie so far means they won't lie in the future.

Generally speaking that's the best indicator we have, and why, as the author points out, it's such a big deal that they have lied now.

Re: You Can’t Trust Amazon When It Feels Threatened

#19

Earlier quoted context omitted.

The conventional wisdom is every time you need some online compute or storage resource as well the cloud is the future right? And if Amazon cannot be trusted whats left of the Public Cloud that is actually trustworthy, it's not like Microsoft have an great track record of fair and honest dealings either. That leave basically the smaller 2nd and 3rd tier operators and how much do we really know about their track recor…

The answer, I think, is that we shouldn't be putting all our eggs in one basket. Trust nobody. Distribute hosting across as many providers as possible.

The problem with doing that is that it raises staffing costs, which is one of the things (the major thing, afaik) you're trying to optimize away by going to the cloud. You have to be cloud agnostic, which means not using value add services. No more SQS or the GCP/Azure equivalents, you have to run your own Kafka in case one of them goes evil.

If all you're using is VM's and their infinitely scaling ability, it can pretty easily become cheaper to just run your own hosts and manage a pool of not-yet-in-use hardware. Or to do something like setup greenfield stuff in AWS, then at the start of the next quarter, buy hardware for the stuff in AWS, migrate it to in-house, and start over again.

I don't find cloud-agnostic to be that compelling of a solution, generally. It really only makes sense to me at small footprints. Even then, I'd probably only suggest it if you needed a really small footprint (like 1-3 servers) across a large number of geographic sites, and for some reason you can't just use a CDN.

Re: You Can’t Trust Amazon When It Feels Threatened

#20
post #19

Earlier quoted context omitted.

The answer, I think, is that we shouldn't be putting all our eggs in one basket. Trust nobody. Distribute hosting across as many providers as possible.

The problem with doing that is that it raises staffing costs, which is one of the things (the major thing, afaik) you're trying to optimize away by going to the cloud. You have to be cloud agnostic, which means not using value add services. No more SQS or the GCP/Azure equivalents, you have to run your own Kafka in case one of them goes evil. If all you're using is VM's and their infinitely scaling ability, it can pr…

> The problem with doing that is that it raises staffing costs

...eh. There's a fixed staffing cost of figuring out how to script out deployment to a new provider, and then you're pretty much done. Even if it's some podunk VPS host that doesn't provide an API or anything for automated setup, most of the effort of configuring and deploying to a server happens on the server itself over SSH anyway, so getting that server's (virtual or physical) hardware "powered on" is a pretty small fraction of that "staffing cost".

That is: if your sysadmin is worth one's salt, one will have very little trouble with this. And if you don't have a sysadmin (or someone with approximately that skillset)... well, that's gonna bite you for a lot more reasons than just being beholden to a specific cloud provider.

> which means not using value add services.

The term "value add services" is dependent on the notion that said services actually add value, particularly for a startup in your framed hypothetical. For example:

> No more SQS or the GCP/Azure equivalents, you have to run your own Kafka in case one of them goes evil.

Kafka arguably adds more value than any provider-specific "value add service" like SQS, assuming you actually need a full-blown message queue. Chances are, however, you don't need a full-blown message queue, and trying to architect your app around one - be it SQS, Kafka, or whatever else - is exactly the sort of distraction your fledgling startup can't afford.

> If all you're using is VM's and their infinitely scaling ability, it can pretty easily become cheaper to just run your own hosts and manage a pool of not-yet-in-use hardware.

I mean, if "cheap" is the only thing you care about then on-prem (or colocated) is pretty much the only way to go, period. Those "value add services" that cloud providers provide are themselves pretty expensive compared to just running your own version (even in a VPS, let alone on your own hardware).

But this doesn't address what happens when (not if) that datacenter has an outage, so you'll still end up needing at least two such sites if you need any sort of reliability. And maybe you don't need any sort of reliability - an early stage startup probably doesn't - but a business that already has customers and doesn't want to be on the hamster wheel of perpetually selling itself to investors just to "raise capital" and make ends meet probably should be a bit proactive about resiliency.

Post reply on HN