[riansanderson]

I've been doing DevOps for a while now and have been struggling to put my finger on why at scale it turns out to be so...complex/underestimated/hard. This blog distills it down to an essence that rings true to me:

>To successfully get an application into production, you need to be an expert in the application itself, the deployment target and the deployment methodology.

I disagree that all that expertise only needs to reside in one person, but you've got to have a well functioning team otherwise. And the more facility each team member has with each of those domains the better your odds of success.

It's a matter of when not if some issue is going to show up in production that is going to require more than a proverbial reboot. If the team lacks, or its dysfunction negates, expertise in any one of these areas then the service is living on borrowed time.

[RetroTechie]

More generally:

Use of any abstraction (or software / management tool) = you exchange one set of problems for another.

This applies in daily life too:

You can mow the lawn, which takes your time / effort. Or you can hire someone to mow the lawn for you.

If you do, you exchange [spending time mowing the lawn] with [spend time to find a gardener + obtain money to pay him/her].

Which to choose? The set of problems that's easiest to handle. If you're short on cash but have the time, mow the lawn yourself. If you're a busy person with a 5-figure salary, pay someone to do it for you.

In programming (or more generally, IT projects) it works the same. But where it often goes wrong, is (usually under-) estimating the nature & size of a set of problems that another set of problems is exchanged with.

"Ooh we should move to the cloud! Flexible compute & storage, easy!". Result: "cloud" is yet another dependency, and turns out to bring complexity in itself. And problems (+costs) attached to it, may just be nastier ones than if things had been kept on-site.

So the art is not always to determine what's an optimal solution (for whatever measure of "optimal"), but to get an accurate picture of the sets of problems you're choosing between.

Sometimes it's wise to pick a sub-optimal solution, if it means picking a set of problems you understand. Versus a 'better' solution whose problems you don't understand (as well).

Or go with something that doesn't work great, but works now, and good enough. Vs one that works great, but only after you needed it.

[hiAndrewQuinn]

I often joke with my wife that capitalism is just a series of solving out problems for the reward of more interesting problems in the future.