_euvw

All true. Life is so simple all of a sudden. Thanks!

Because I want to limit the impact of maxing out a creditcard to one environment.

And I want engineers to be able to futz about with all cloud services available, without having to worry about any negative impact on production.

And finally: What happens when $cloud_provider makes changes to the accounts interface and you want to mess around with those new features, without hitting production?

Give your future-self a break, and make sure you can futz around on any and every layer.

Another common practise is using seperate domainnames. Don't use 'dev.news.ycombinator.com'. Instead, use 'news.ycombinator.dev'. This frees you up for messing around with the API of the DNS provider. And when switching DNS provider, test whatever automation you have in place for this.

Yup - that works pretty well. And gives developers some insight into what is required to get stuff working.

It does assume no hardware or complex networking needs to be handled.

And there is the point of observability. When there is a proper testing ground for developers that is as-production, it enables developers to dig into and mess with logging, tracing, debugging of all sorts.

This adds value by providing developers insight into what a reliability engineer (or whatever they call sysadmins these days) needs to provide whatever service it is that the developers' code is part of.

Nice piece. Looking forward to Part II.

What I am missing (often, in these type of articles as well as in actual production environments) is the fact that if you develop (infrastructure) code, you also need to test your (infrastructure) code. Which means you need actual infrastructure to test on.

In my case, this means network equipment, storage equipment and actual physical servers.

If you're in a cloud, this means you need a seperate account on a seperate creditcard and start from there to build up the infra that Dev and Ops can start deploying their infra-as-code on.

And this test-infrastructure is not the test environments other teams run their tests on.

If that is not available, automating your infrastructure can be dangerous at best. Since you cannot properly test your code. And your code will rot.

> The Product Owner prioritises the backlog

Note: This would require a _really_ good product owner that does not merely focusses on features, but also on feasibility and 'fitness functions'.

The rest of that article had me cheering all the way.

Which is exactly what the author writes. "Was it ever the right sollution? It depends."

From 2012.

Being in a simular situation what do you consider "reasonably large"?

> at least in the good times

Exactly.

Could it be possible that sometimes laws are immoral? And that companies, while following the letter of the law are in fact acting immoral too?

Why defend those companies?