AWS claims its cloud faces competition from on-premises IT
theregister.com
theregister.com
Off course a company will deny that they are a monopoly (or cartel etc). They'll keep pointing out their competition to these authorities. Ironically, the investor relations of such companies often point at the same data, to tell their investors how big their moat is and how insignificant their competion.
I'll believe this change is really happening when AMZN starts reporting decline in their AWS gross returns. Is this declining?
https://www.ftc.gov/news-events/news/press-releases/2023/09/...
Edit: Amazon, not AWS. Sorry for the confusion!
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...
Some of the more "fundamentalist" members of that movement want de facto single product companies, with little to no consolidation/M&A.
Hypothetically good if you assume small players can compete optimally, but in action this absolutely means significant inefficiencies, at least in the tech industry because all small players inevitabely try to become large players in order to optimize on margins via economies of scale.
I guess the UK has different laws, but here in the US it works like this:
* 50% and below means you are definitely not a monopoly unless there is some weird set of facts than SCOTUS couldn't imagine the last time they considered monopolies.
* At some threshold around 60-70% you might be a monopoly, but market share alone isn't enough to prove that.
* Around 90% you are presumed to be a monopoly unless you can provide some very good evidence why you are not.
We can see this when researching the books as published to shareholders. When AWS was the "sole" player (first mover advantage) they had insane margins. Then competition stood up: GCP, Azure etc. And grew. Their margin has staid the same. And is roughly similar to that of GCP and Azure. Which means they either have secret gentlements agreement over pricing (highly illegal, not likely, the risk is just too high) or there's other mechanisms at play that allow them to keep dictating the price.
Cost of switching is very likely such a mechanism. They lure you "on board" then once you start feeling the pain of the high margins, there's simply no way you can move to a competitor with lower margins - either that competitor isn't one really (Digital Ocean, OVH, Linode) or these competitors aren't competing on your margin (GCP, Azure) and have similar margins.
As a baseline, moving production workloads that run entirely on VPS or physical servers between datacenters is already a very high cost/high effort task.
Anything you do to make the architecture more complicated is going to increase those costs.
All AWS (and co) did was offer a platform for building complicated architectures. The market response was overwhelmingly positive, and entire new engineering disciplines sprung up around managing and building these new complicated architectures.
Migrating them is typically rather difficult and high cost, but everybody knew this from the beginning, and this is what the customers want. The PaaS providers could maybe do something here or there to make it easier, but there’s nothing they can do to address the fundamental problem.
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 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.
Declining revenues isn't the sign of not being a monopoly. How is AWS actually a monopoly?
Like, is Azure not a thing? GCP? Hetzner? DigitalOcean? etc.
> 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.
IONOS Virtual Private Servers - $30/month - zero egress fees.
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).
Sure it made me pay$5/month after some number of requests.
I don’t expect to pay nothing.
I just think 9 cents per GB for egress is robbery.
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-...
It is true that you pay for the engineering done by AWS, but you also need to take into account the network effect and compatibility with third-parties.
With this being said, AWS is still very expensive. But AWS being profitable doesn't imply it is profitable for you to run your own infrastructure. The same way it is not profitable for you to run your own shipping company, or your own internet backbone provider.
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...
I’ve been in jobs with cloud platform responsibilities at large financials for the last nine years. With all of the regulatory oversight and internal controls, the all-in price for cloud is actually quite high and usually gives businesses pause when they start to realize that.
Operating data centers is also incredibly expensive. The biggest costs come when you need to build new ones while maintaining what you have. The last place that I worked we spent several billion dollars in data center builds over the course of five years. Cloud was seen as a way to reduce the demand, but it takes a long time to build and mature a delivery platform that can run at reasonable velocity and adapt to business demands.
Now regulators are really focused on concentration risks and are demanding multi-cloud architectures and are testing contingency plans in the event of massive failures on the part of service providers. This will in part drive a demand for reserve capacity in datacenters as well as build out of platform management capability that that can move workloads around without substantial incremental engineering work.
That being said, this reeks of making a anti-monopoly argument and seems wildly overstated.
Seriously though, it does feel like above a certain company size you really do get into a position where, if you can hire the team to run it, on-prem just feels right. Especially if you're not even really in the "internet" business in the first place. Cloud is so costly!
To me it is - Systems Manager: centralized access to servers with logging. - RDS: backups, replication, DMS, DB autoscaling with Aurora. - ECS: simpler k8s, autoscaling - CloudFormation, terraform, CDK and pulumi. - Lambda
Which one do you think is true for amazon?
From experience, if AWS can tell customers what computes/capacity is not fully utilised and can be shutdown, it will help. I am not sure if it does in some form.
Another thing would be customer definable cap on cost.
Another pain points - Need to keep a DR region active all the time, fearing Data center/AZ outage.
However, the not being realtime might be a deal breaker for many.
I managed a tier 2 datacenter for some 4 years. Fire risk alone still gives me anxiety.
“Cloud It’s more expensive stupid!” Yeah… you know what’s way more expensive? People.
People and processes you’ll have to manage to achieve SLAs like Amazon’s? Well, good look with that. If you manage to find the people please write a book about how you achieved the process.
Oh, and new services on top of that every time a new technology appears? With the SLA and the consistent quality?
And the hardware, the building, the never ending decay of physical things. The drives for gods sake. The never ending pursuing of storage space.
The enterprise premium for hardware, that you’ll pay to have the manufacturer saving your ass. And please don’t think your employees will let you touch the fancy open source or community versions of things. You’ll blink and you’ll be paying the premium (and thanking the vendor for the option), because the risk won’t let you sleep.
And the most amazing part: business in you heels demanding innovation, quality, uptime and… change.
Four years, 10 years ago and my palms just got sweat thinking about that.
Your company is lucky that someone is willing to receive money to do that for you. And luckier yet that this company can do that very well. So well in fact that is very easy to forget how well they do that.
Although the name is "air gapped" - it does not have to be if client doesn't want air gapping. It's "buy commodity hardware from vendors HP, we will give you software and training to manage it".
Much leaner stack than whole GCP/AWS/Azure, but deployed "on-prem" with "cloud-like" experience.
Centralization vs. Decentralization. And the pendulum swings on.
What if I want a cloud, but I only want two or three 9s of availability?
In reality, you can have almost any people and processes. The trick is to put your servers and data in more than one place. If you have uptime of just 99% for a server (~3 days off in a year) and have them in 2 unrelated places, you will get 99.99% uptime. 3 places will give you 6 9's. The only thing that has to be ensured by people and processes is graceful fallback.
Notice how I say uptime and not SLA. SLA just means that you will get a little bit of money back if uptime dips below the SLA level. Oh, and for EC2 it is just 99.95%. So, if you really care about your users, you will engineer your systems to stay up rather than hoping that a third-party provider's SLA will save you.
These avoid all of the costs you were talking about.
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...
> You'll want a test environment
You need that in the cloud too...
> You'll want a process to make sure every production change can be reversed
You need that in the cloud too...
> You'll want a process to make sure configuration changes
You need that in the cloud too....
> you'll want a gradual process.
You need that in the cloud too...
> You'll want to monitor
You need to do that in the cloud too....
> user growth / surge in demand
The problem with the cloud is everyone thinks they need to design for Google-scale from day zero.
Sure the cloud providers don't mind, more money for them ...
> there's a chance of a partial failover.
Could, and does, happen in the cloud too....
Cloud providers want to provide some layers for you. Thank god they exist and live with the layers you can’t pay someone else to do.
Aaah yes, those AWS SLAs that ....
- (a) Famously apply anywhere except US-EAST region which has a proven tendency to blow itself up on a scheduled basis
- (b) Are more marketing fluff than reality. A bit like the old Verizon leased-line 100% uptime SLA, nobody sensible who worked in IT believed it, but your boss was paying the Verizon-tax so that Verizon could afford to pay out some hard-dollars when (not if !) the SLA was inevitably breached.
"Error Rate” means, for each request type to an Amazon S3 storage class: (i) the total number of internal server errors returned by Amazon S3 for such request type to the applicable Amazon S3 storage class as error status “InternalError” or “ServiceUnavailable” divided by (ii) the total number of requests for such request type during the applicable 5-minute interval of the monthly billing cycle. We will calculate the Error Rate for each AWS account as a percentage for each 5-minute interval in the monthly billing cycle.
"If you did not make any requests in a given 5-minute interval, that interval is assumed to have a 0% Error Rate."
Also what happens if AWS breach their over-confident SLAs ? Oh yeah, that's right, typical corporate style hand wringing, an apologetic sounding email written in corporate-speak and approved by legal, and that's that. Maybe a mea-culpa public blog post if you're lucky.
Also when you have your own datacentre, you don't have all the stupid nickle and diming of the cloud providers. The major cloud providers are particularly bad about it, all sorts of obscure "hidden" charges just waiting to bite you in the backside if you don't look carefully at the bottom half of their price sheets.
(And it doesn't save you from downtime, either. Cloud just introduces a new set of risks. Also, Most companies don't actually need anywhere near the kind of infrastructure that AWS does).
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.