DevOps is great. I like it. Some days, it even boosts morale more generally, as related Agile practices do, at their best.

It never gets easy, though. DevOps isn't an answer to adopt, as much as an awareness to practice. Whatever methodologic labels we use, we have a professional responsibility to keep them in balance.

Recent pieces by Julia Evans and Charity Majors reminded me of this. Those of us in the trenches know that Everything-As-A-Service doesn't solve fundamental problems, it just shifts them. Some of the shifts are to a better, safer place. It's not guaranteed, though; a little insight's required. A human who combines empathy (!) and experience needs to make delivery of business functions to paying customers real.

Evans and Majors shine useful spotlights on how absurd we can be when we lose perspective: development is trivial because it's just gluing APIs together, operations is trivial because this stuff works on my desktop, and so on. Over and over, I see startups that strain for "scalability" for operations that peak at a few dozen transactions per second, or evenper day! Plenty of real-world projects would be better off an a well-maintained Raspberry Pi than with the fancy rack-mounted blade where they end up.

Engineering is about trade-offs. At its best, DevOps helps us reach better judgments about how we combine reliability, flexibility, economy, responsiveness, and function. DevOps does not remove all the limits, give answers that plug into every possible situation, or implement stateful business results over a stateless architecture.

Majors says it well: "You can outsource labor, but you can't outsource caring." DevOps is about clarifying our responsibilities, not walking away from them.