I think dev teams should own their deployments, or at least have a basic understanding on how it is deployed into the environment. Someone more knowledgeable of DevOps should review the deployment, though.
This is why I like Kubernetes, since the language (in human terms) for a deployments is already agreed upon, and there's plenty of resources for everyone involved to learn about it. Kubernetes can have interesting challenges for people maintaining clusters (and it's becoming increasingly easier), but for users (i.e.devs) it's really straightforward
If the deployment environment is too complex for the developers to manage and understand, it's too complex to accept as an option in the first place.
As Colin Chapman, the founder of Lotus cars famously said, "Simplify, and add lightness." That means brutal intolerance of obesity anywhere in the system.
Over the course of a 20+ year career, I did everything soup-to-nuts as a way to build broad experience and skills. So that included understanding how to build out and secure infrastructure, build automation for deployment, rollback, etc, in addition to my main expertise in building software. I think it's commendable for developers to do this because it helps them anticipate and understand how the software will actually be operated.
But what I found was that few employers really wanted this or were willing to pay for this added expertise. In fact many seem threatened by it, as they wanted to keep roles siloed. They didn't want to encourage cross-pollination of ideas or improvement. Maybe that sounds like sour grapes on my part, but that's what I observed. I'd say too that they ones who were keen to see developers add these skills did so because they wanted to cut the labor costs of people who were focused on operations - so now as a dev you were getting paid for one job but expected to do two.
5 comments
[ 4.2 ms ] story [ 24.9 ms ] threadAs a developer, I know what infrastructure I need, but I don't have to learn how to create or deploy.
Exactly the same as I use an Operating System and I don't know how all the internals work.
This is why I like Kubernetes, since the language (in human terms) for a deployments is already agreed upon, and there's plenty of resources for everyone involved to learn about it. Kubernetes can have interesting challenges for people maintaining clusters (and it's becoming increasingly easier), but for users (i.e.devs) it's really straightforward
As Colin Chapman, the founder of Lotus cars famously said, "Simplify, and add lightness." That means brutal intolerance of obesity anywhere in the system.
But what I found was that few employers really wanted this or were willing to pay for this added expertise. In fact many seem threatened by it, as they wanted to keep roles siloed. They didn't want to encourage cross-pollination of ideas or improvement. Maybe that sounds like sour grapes on my part, but that's what I observed. I'd say too that they ones who were keen to see developers add these skills did so because they wanted to cut the labor costs of people who were focused on operations - so now as a dev you were getting paid for one job but expected to do two.