Amazon’s effort in making sure things _actually are up_ is fundamentally different than budget clouds.
The systems you design when you have reliable queues, durable storage, etc. are fundamentally different. When you go this path you’re choosing to solve problems that are “solved” for 99.99% of business problems and own those solutions.
Still, things fail. A-tier clouds also fail, and you may still have to design for it. Rule of thumb, if you are capable of rolling out your own version, you'll be far more competent planning for & handling downtime, and will often have full ownership of the solution.
Also, any company with strict uptime requirements will have proper risk analysis in place, outlining the costs of the chosen strategy in case of downtime; these decisions require proper TCO evaluation and risk analysis, they aren't made in a vacuum.
This is a strangely limited view. Cloud providers have done the work of building fault-tolerant distributed systems for many of the _primitives_ with large blast radius on failure.
For example, you'd be hard pressed to find a team building AWS services who is not using SQS and S3 extensively.
Everyone is capable of rolling their own version of SQS. Spin up an API, write a message to an in memory queue, read the message. The hard part is making this system immediately interpretable and getting "put a message in, get a message out" while making the complexities opaque to the consumer.
There's nothing about rolling your own version that will make you better able to plan this out -- many of these lessons are things you only pick up at scale. If you want your time to be spent learning these, that's great. I want my time to be spent building features my customers want and robust systems.
I see where you’re coming from — no doubt, services like SQS and S3 make it easier to build reliable, distributed systems without reinventing the wheel. But for me, the decision to shift to European cloud providers wasn’t about wanting to build my own primitives or take on unnecessary complexity. It was about mitigating regulatory risk and protecting revenue.
When you rely heavily on U.S. hyperscalers in Europe, you’re exposed to potential disruptions — what if data transfer agreements break down or new rulings force major changes? The value of cloud spend, in my view, isn’t just in engineering convenience, but in how it helps sustain the business and unlock growth. That’s why I prioritized compliance and risk reduction — even if that means stepping a little outside the comfort of the big providers’ managed services.
> For example, you'd be hard pressed to find a team building AWS services who is not using SQS and S3 extensively
I design and develop products that rely on queuing systems and object storage; if its SQS or S3 is an implementation detail (although S3 is also a de-facto standard). Some of those products may rely on millions of very small objects/messages; some of them may rely on fixed-size multi-MB blocks. Knowing the workload, you can often optimize it in a non-trivial way, instead if just using what the provider has.
> The hard part is making this system immediately interpretable and getting "put a message in, get a message out" while making the complexities opaque to the consumer.
Not really, no. As you said, is already a solved problem. Aws obviously has different scale requirements than my reality, but by having ownership I also have only a fraction of the problems.
> There's nothing about rolling your own version that will make you better able to plan this out -- many of these lessons are things you only pick up at scale.
I cannot agree with you on this. As an example, can you tell me which isolation level is guaranteed on an Autora instance? And what if it is a multi-zone cluster? (If you can, kudos!); next question is, are developers aware of this?
If you have done any cursory solution design, you will know the importance of mastering the above questions on development workflow.
Fred Brooks, the author of The Mythical Man-Month said:
> “Software is ten times easier to write than it was ten years ago, and ten times as hard to write as it will be ten years from now.”
Ansible, Hetzner, Prometheus and object storage will give you RDS if you prompt an LLM, or at least give you the parts of RDS that you need for your use case for a fraction of the cost.
Hetzner is also working on their own Managed RDS offering. Their own S3 Offering is also relatively new. Back then, they've also had job offerings for DB Experts
The systems you design when you have reliable queues, durable storage, etc. are fundamentally different. When you go this path you’re choosing to solve problems that are “solved” for 99.99% of business problems and own those solutions.