|
|
|
|
|
|
by gg-klotho
1279 days ago
|
|
|
> 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. |
|
|
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.