Look at market share and ease of switching cloud service providers. A rule of thumb is that if you own more than 50% and can dictate prices, you might be a monopoly.

The parent article literally says > In a summary of evidence given to UK watchdog, the Competition and Markets Authority (CMA), AWS denies that customers face any difficulty in switching from its platform.

This CMA was investigating amazon's possible monopoly on cloud. So, this whole thing started rolling exactly because authorities are asking the exact same questions as you "In what way is AWS a monopoly." and in doing so, see enough leads to at least ask for reports and AWS's reply.

The FTC is actively engaging in a monopoly case against Amazon: the organization whose job it is to break up monopolies certainly believes them to be one

https://www.ftc.gov/news-events/news/press-releases/2023/09/...

Edit: Amazon, not AWS. Sorry for the confusion!

it's not, it's an oligopoly. In corporate it's basically them, microsoft, kind of google and then a tiny sliver of the market is filled with a whole bunch of wannabes.

Personally, I agree with you.

That said, the current argument is that because AWS is part of Amazon at large, it can gain undue advantage by being subsidized by other organizations in Amazon, and forgo profits in order to gain a controlling share in an industry.

This is basically Lina Khan's whole argument [0]

I personally don't subscribe to this argument as a major reason for AWS's dominance compared to Azure in the early 2010s was because of stronger execution (lots of training sessions, evangelization, some truly cutting edge architecture) and better product-market fit, but Hipster Anti-Trust assumes a bunch of smallish companies competing with each other can result in a similar outcome (hence why VCs like Thiel, Horowitz, and Andressen tended to support scholars affiliated to the New Brandeis Movement)

[0] - https://www.yalelawjournal.org/pdf/e.710.Khan.805_zuvfyyeh.p...

Lol. I hope this is sarcasm. They have zero competition and 100% lockins. I would say AWS is a national threat at this point.

The parent article is about the CMA researching whether AWS is a monopoly and the answer to that from AWS.

> Declining revenues isn't the sign of not being a monopoly.

Thats a definition thing, though. Monopoly can mean a lot, depending on which side you are defending.

In this case I meant that AWS had insane margins when they were the only player - first mover advantage etc. But those margins didn't decline when their "competition" started becoming serious. In fact, if you look at their shareholder reports, AWS, GCP, Azure etc all have similar margins now, and AWS's didn't decline.

This tells us not if there's a monopoly. But it does tell us that there's no competion on margin/price.

Bu, what I meant was that if "on prem is a true competitor to AWS" we'd see their gross profits decline, as people are moving off AWS. And if we don't see this happening, than it's not a true competitor.

> How is AWS actually a monopoly?

Like, is Azure not a thing? GCP? Hetzner? DigitalOcean? etc.

It does have overlap though.

The article is about an anti-trust body researching whether that moat is not too much of a monopoly:

> In a summary of evidence given to UK watchdog, the Competition and Markets Authority (CMA), AWS denies that customers face any difficulty in switching from its platform.

Production workloads are incredibly difficult to move, regardless of location.

Try using Cloudflare R2 with zero egress and you'll rapidly discover there are lots of 'gotchas'... - Want to use a cloudflare managed domain - pay for egress if you have enterprise account - Want to use their 'dev' domain - rate limited

It's still a good service - but zero egress comes with conditions. The only exception I've found is Cloudflare pages which seems genuinely zero egress (as long as you don't proxy it through a managed domain).

That doesn't really make sense. AWS is very profitable [1]. That means that whatever the amount of money they put into engineering, their customers pay, and then some.

As for the customers, very few of them operate at a scale that requires the monumental amount of engineering required to replicate the whole of AWS with its many dozens of services.

[1] https://www.seattletimes.com/business/amazon/amazon-reports-...

That entirely depends on how you build your stack.

I always strongly push for setting up the whole infrastructure with a future migration in mind, and without tying the company closely to specific cloud services.

You lose out on some of the better cloud features, but it's worth it in cash alone: being able to say "we have built our stack to be platform agnostic, we can switch within a month" is very useful in discussions with sales...

Those are indeed similar situations, but your examples except the first one do not come from the article. So it is not clear why do you assume that everyone did not read beyond the headline.

The thing I don't like about contract/outsourcing is the uncertainty... I'd rather be at a place where I know I don't have to worry about my next job...

The person you're replying to is responsible for what is posted on job boards/sites?

That assumes the only causes of failure are environmental. I’ve definitely seen plenty of hardware failures but software failures are common, too, and keeping things synchronized is going to require more than “any people and processes” - that’s how you learn your backup has never been tested and database replication stopped working 3 days before the failure.

All those points OP raised as difficult - physical space, staffing, capex, etc. - and your response is “yeah, now do it twice”.

> In reality, you can have almost any people and processes.

You've never tried it, huh?

The reality is you will need some very specific processes.

You'll want a test environment, so you can make sure that proposed router reconfiguration actually does what it's supposed to do, and a process that says to use the test environment, and a process for keeping it in a consistent enough state that the tests are representative.

You'll want a process to make sure every production change can be reversed, and that an undo procedure has been figured out and tested before deployment. When that's impossible, you'll need careful review.

You'll want a process to make sure configuration changes are made in all three production data centres, avoiding the risk of a distracted employee leaving a change part-way rolled out.

But you can't roll out to all three sites at the same time, what if the change has some typo that breaks it? So you'll want a gradual process.

You'll want to monitor the load on the three systems, to make sure if one goes down that the other two have enough capacity to take over the workload. You'll have to keep monitoring this, to keep ahead of user growth.

Did I mention the user growth? Oh yeah we're expecting a surge in demand just before christmas. The extra servers we got last christmas have absorbed our user growth, so we'll need more. Of course it'll take time to get them racked and set up, and there will be a lead time on getting them delivered, and of course a back-and-forth sales process. So of course we'll have to kick off the server ordering process in August.

Of course, there's a chance of a partial failover. What if the web servers are still working in all data centres, but the SQL server in data centre B has failed, while the replicas in A and C are fine? If there's a software hiccup you'll need to figure out who to call - yet another process...

This is what people don't realize.

At a certain scale you need tons of people to operate a cloud environment, especially if you take advantage of all the features.

Sure for tiny players the devs can be forced to both write the business code and manage the infrastructure but at a certain scale that just doesn't work because everything becomes non-standard and the amount of time to manage it takes up all the time the devs should be spending on writing business related code.

So then you spin up an infrastructure team. And it won't just be one either because the person creating your VPC/network design won't have time to also be working on your backup design or your database design or your image pipeline or your CI/CD.

So at the end of the day you end up with all the same teams you had in managing your datacenter infrastructure (network, storage, OS) except now you're paying way more for the infrastructure itself and the people cost more because they are not just specialist in their area but have to be specialists in cloud platforms as well.