No matter how much you want it, you can't use a clever definition of "cloud native" to pretend that you compete with the AWS/Azure/Google stack. And please don't try to fool people with a wonky definition, it will backfire eventually. "There is no cloud just other people's computers" means you don't understand what modern developers are doing with clouds. https://berthub.eu/articles/posts/the-european-cloud-ladder/

@bert_hubert I would love to enable alerts on this thread to see what the responses will be... 🙃

TBH, I'm among the cloud-skeptics myself. Its an Orwellian marketing term intended to replace one (mainframe) that older generations feared. The word mainframe suggests centralized structure and someone doesn't want us to think about that.

@tasket well, I did not mean to endorse AWS etc, but I am pretty fed up with linguistic tricks used by at best "container" providers that they are in the same business as AWS/GCP etc.

@bert_hubert @tasket The more I look at the amazing new security boundaries that cloud providers are building, the more amazed I am that anyone would think of building on classic patterns without them.

Why would anyone allow new (production) code to store data on a filesystem in 2025? There are better patterns.

@bert_hubert
Thank you for your excellent article. Still reading through it, I stubled over the following statement:

"even in 2025, GitHub still heavily relies on AWS for simple services like S3."

Is there a statement somewhere corroborating this? (Searching for GitHub and S3 is useless in this regard.)

@marcel https://fosstodon.org/@bert_hubert/114057995728305816 has the goods! Added a link too the post as well. Thanks for noticing!

@adamshostack @tasket maybe not the best example (for me), but perhaps I know too much. I'm not putting that much stock in security barriers I can't see. The history is not that great. https://www.techradar.com/pro/amazon-pauses-usd1bn-microsoft-365-rollout-following-russian-security-concerns

@bert_hubert @marcel I don't want to sound too "Well Actually" in y'all's mentions but I think they're making progress.

Release objects used to come from https://github-production-release-asset-2e65be.s3.amazonaws.com/; now they use https://objects.githubusercontent.com/github-production-release-asset-2e65be/, which is Fastly with a bunch of HTTP headers that look like Azure Blob Storage.

@bert_hubert @tasket I'm largely focused on the ones we can see, including side-effect-free code, migrating from filesystems to other data stores, immutable deployments, configuration as code, configuration in version control, getting away from spaghetti in legacy data centers...

@adamshostack @bert_hubert @tasket Those problems don't seem to be dependent on running on a cloud platform though? We implemented most of these things on-prem - admittedly with the help of software that was inspired/made by cloud platforms.

@mnordhoff @bert_hubert
Thanks!

I'm still wondering why the kept the same hex sequence. I would only do this when creating some kind of proxy in front of the old storage, if at all. 🤷

@marcel @bert_hubert Yeah.

Maybe they started using the CDN before moving the backend and didn't want to update all their URLs twice?

Maybe it was just easier to keep the bucket names the same instead of needing a big spreadsheet of conversions.

@adamshostack @bert_hubert @tasket
The benefits of these is what everyone expects when they talk about their "journey to the cloud". But standardization, automatization (IaC, CI/CD, testing) and thorough versioning are the actual workhorses.

You can get several of the benefits your management expects from "the cloud" by even doing that OnPrem.

And not doing that thoroughly when moving to the cloud will not solve your problems. On the contrary.

@marcel @bert_hubert @tasket But there's no point (which an MBA can understand in a PPT) to doing it on prem. We get to do them as we move to the cloud to be "Cloud NaTiVe!"

@buherator @bert_hubert @adamshostack @tasket This gets into the dichotomy of “cloud”. It’s used to refer both to hugely valuable techniques which can be implemented everywhere like reproducible deployments or fine-grained object storage, and also to shared hosting. The hosting part can be valuable, but in far fewer ways:

1. It’s great for small companies which don’t yet have the ability to forecast demand. Your product becomes an unexpected hit? You don’t have to take the latency of buying more hardware, waiting on shipping, waiting on setup, etc.
2. For big companies, it bypasses crusty old business practices. Microsoft doesn’t care what your patch testing cycle is or what your maintenance windows are; if you store data in their hosted SQL server, they patch it when they feel like it.
3. Accounting witchery. I don’t understand why, but companies are happier to spend more money if it’s on a monthly basis rather than every few years.

@bob_zim @buherator @bert_hubert @adamshostack @tasket re. 3, it's because capex like hardware purchases can often only be tax deducted over three years, while opex like monthly subscriptions can be deducted immediately.

@sanityinc I understand that’s the mechanic (though I don’t understand why; just bizarre quirks of tax code?). What I don’t get is why that results in companies being willing to spend $1M a month for something they could do on-prem for like $3M every five years. Sure, they don’t get to keep deducting that expense, but at the same time, they don’t have to keep *spending* it. “Reduce expenses” is rule number one of how to improve margins, but that just goes out the window for some reason.

@bob_zim @sanityinc If you are responsible for delivering a working product on time and costs don't come out of your own pocket expensive clouds that just work* are an obvious choice.

*<insert edge cases here>

@bob_zim @tasket I've never heard "cloud" used in the context of the techniques you mentioned, but OK. In my world these practices - that have obvious security benefits - are more on the "pet-cattle" axis that apparently (but not surprisingly) also comes from AWS, but not strictly tied to cloud providers:

https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

Circling back to security boundaries brought up by @adamshostack, my point here is that modern security and ops paradigms up to level 4. on @bert_hubert's scale are doable on-prem where you don't have to deal with the threats arising from e.g. shared hosting in the first place. IMO from that level any security benefits are less about the mentioned paradigms and more about how security investment scales (e.g. can you afford world-class talent and custom tooling for your 10 rack system), while introducing the problems that triggered this whole discussion about the need for an EU cloud.

@adamshostack @bert_hubert @tasket industry surveys show that a vast number (possibly majority) of cloud users still fail at extremely basic security practices. It is very costly, you need really good people to deal with all the complexity, design etc. so those advanced benefits are overall only reaped by a minority. Everyone though pays relatively insane bills that often result in having to cut people (because even to reduce costs in cloud you need finops teams due to the complexity).

@sudneo @bert_hubert @tasket Let's break your two parts apart:

1 - surveys show that people fail at basic security practices

2 - cloud is expensive.

On 1 Incidentally, which surveys, which practices? But fundamentally: I believe that we can cut the word cloud without altering the sentence:

"industry surveys show that a vast number (possibly majority) of ---- users still fail at extremely basic security practices."

@adamshostack @bert_hubert @tasket I'm a bit of a skeptic about the "cloud" design patterns as well because they abstract so much away that people have very little sense of how fast a computer is and what a computer can do. they are talking about needing multi tiered load balanced whatever to serve 100 reqs/sec of static content using node.js and complicated SPAs built with CI pipelines when a simple django app running on the equivalent resources to a cell phone could get the job done far more simply, as long as you aren't trying to "scale" an app to monopoly proportions to try and rent-seek from some niche industry.

There is definitely a case to be made for renting infrastructure but for a lot of small/medium orgs they could be farther ahead with simpler tech running in on-prem servers that they refresh maybe 5-10y

@raven667 @adamshostack @bert_hubert @tasket This.
I wrote about this in "Undifferentiated heavy lifting" https://gist.github.com/sleepyfox/0ee777c2dcab305d48e28c4143243d71

@adamshostack @bert_hubert @tasket I am talking about surveys like the wiz state of cloud security reports. Things like having databases or buckets publicly exposed.

I am there with you about companies failing at basic security but: cloud is expensive, because a lot of the work is outsourced. This means that if clouds don't provide security by design (and in a lot of aspects they don't, https://www.chrisfarris.com/post/aws-call-to-action/) the companies have less resource to invest on security. 1/2

@sudneo @bert_hubert @tasket I think the Wiz state of cloud security survey is unlikely to do a useful compare and contrast with the state of datacenter security. 😜 Are exposed Ivanti/Fortinet/Palo Alto devices worse than exposed buckets?

IOW how should we think about the relationship between cloud and on-prem?

(My answers, https://cra.org/wp-content/uploads/2025/01/2024-2025-CRA-Quad-Paper_-Lessons-for-Cybersecurity-from-the-American-Public-Health-System.pdf and more generally, https://shostack.org/resources/cyber-public-health ... I need to flip that page so its newest first.)

@adamshostack @bert_hubert @tasket second, the cloud is an immense attack surface. By definition, a company merges all its domain into a single abstraction (the cloud API). This means that some small security benefits that came from a physical separation might not apply within the cloud abstraction. It's easy to shoot yourself on the foot by not understanding an interaction within cloud products etc. Which means you need still a ton of specialists (good for me), and you end up paying a lot. 2/2

@sudneo @bert_hubert @tasket Similarly, here, most on prem are literally in a single (AD) domain. So how do we think about a single AD domain vs a single cloud domain?

@adamshostack @sudneo @tasket a key thing everyone should read is this: https://media.defense.gov/2024/Mar/07/2003407863/-1/-1/0/CSI-CloudTop10-Shared-Responsibility-Model.PDF

@bert_hubert @adamshostack @tasket "Customers often assume the CSP’s responsibility to protect customer data is broader
than it actually is, leading to the customer failing to take needed actions." I think is a pretty nice statement. I would add that cloud documentation is often relatively vague at how responsibility is actually shared. This might be me though, I work with the big 3 and I have a troubled relationship with all their docs...