Because lifecycle management, access controls, auditing, monitoring, delegation/federation, budgeting, capacity planning - all of these other things together, which these tools may or may not help you with - are still far less important than troubleshooting.

Seriously, when shit's on fire, the last thing you want is to be deciphering the magic that brought it to its current state. How many layers to dig thru are there, between "thingctl deploy" and a critical S3 bucket having somehow been deleted?

Not trying to shoot down the idea - I'm sure there are people 10x smarter than me working on this, who are more than able to make a lot of this work well in practice. But that's the problem with using stuff made by people 10x smarter than you - when everything goes wrong, it tends to require being 10x-smarter-than-average to fix it.

The true power and success of Terraform is in the blunt simplicity of its interface. Every time you run it, it will spell out in very large writing, what exactly is it going to do: add this, change that, DESTROY this - it even uses the word "destroy" to signify the danger. I really appreciate any tool that makes it harder to do the wrong thing.

> Because lifecycle management, access controls, auditing, monitoring, delegation/federation, budgeting, capacity planning - all of these other things together, which these tools may or may not help you with - are still far less important than troubleshooting.

I think you're right here and it's going to be something that's really hard to get right. I think prioritising the developer experience is the only way to get this right - even at the expense of other things you want to optimise for like costs.

> The true power and success of Terraform is in the blunt simplicity of its interface. Every time you run it, it will spell out in very large writing, what exactly is it going to do

I agree with this statement 100%. The explicit, simple and clear information on what exactly is being modified is one great piece of devex. This precise workflow is something that's inspired us and we want to bake into shuttle.

> lifecycle management, access controls, auditing, monitoring, delegation/federation, budgeting, capacity planning

I don't think having your infra with your code precludes a lot of these things, depending on how it's done. They're good points, and as engineers we'll likely need to be able to do this for a while (until maybe an AI can).

> Seriously, when shit's on fire, the last thing you want is to be deciphering the magic that brought it to its current state. How many layers to dig thru are there, between "thingctl deploy" and a critical S3 bucket having somehow been deleted?

I see it as analogous to how higher-level languages abstracts machine code. When it was a newer technology, people absolutely needed to debug and analyze the "magic" but as the space has matured that's becoming less and less common.

> I see it as analogous to how higher-level languages abstracts machine code. When it was a newer technology, people absolutely needed to debug and analyze the "magic" but as the space has matured that's becoming less and less common.

The fundamental difference is that you can keep analyzing a program in isolation as much as you like. Infrastructure is a living organism - if you shoot it in the head, you can't copy-paste an old working version over it; you have an outage.

> until maybe an AI can

Why is the solution to every problem always more layers, and never less? We understand running production infrastructure far better than we understand AI.

It's not that I don't appreciate ML/AI - it's fairly impressive what it can do, given you keep nudging it in the right direction - but I would never delegate unsupervised authority to it.

Mostly because the two should be separated, you platform is closed, so now you have very specific code just for shuttle.rs inside "business logic", what if I want to run my code in a docker image somewhere else, now I have to strip the service from some integration with a provider.

Well, I'd be curious if that means it has more permissions that necessary to run in production because of that - e.g. to create an arbitrary bucket, or queue, or IAM policy.

Deployed services don't currently have permissions to provision or modify infrastructure. This is done by our build system while your services are being compiled. It is an orthogonal control plane with its own permission system.