The Big DevOps Misunderstanding

When automation was kicking off Ops just sucked. Infrastructure teams were slow to respond and automate, were underfunded, whatever. They sucked when Dev's were being driven to deploy faster.

Dev's started do it themselves. They sucked at it too. They got some "ops" guys in the team to help them do it better. This was then called "DevOps" and the consultants built an industry around the cultural change of collaboration between Devs and Ops.

DevOps smushed together so much that it became just "Devs" doing ops work. They realised that Ops is hard and 70% of their work was Ops, with 30% providing business value. Dev's don't want to Ops, they just want to Dev.

Scaling dev's meant building shared deployment platforms. So ops was centralised into a "Devops" team. Usually this is jammed between Dev teams and traditional Infratructure (VMWare) teams. Kubernetes lives here.

Having a devops/platform team also means you have less fingers in your cloudspace breaking things and deploying bad patterns. Good for scale. Dev's just want to write code, throw it at git, tests run, they repeat. No ops for them.

Which is one of the things the whole institution was designed to solve.

I realize that there’s quite a lot of devs these days that got in it solely for the money, and don’t care one whit about what happens after they throw the app over the fence.

But the whole reason I liked the movement was that it gave me more control over my own destiny. With half baked devops systems and processes that I have to follow it’s (mostly) no different from the BoFH of yesteryear.

Jira+Confluence, circle CI as the CI/CD service Artifactory for binary hosting and GitHub+gitlfs

circle had the lowest friction compared to Jenkins and GitHub actions wasn't out at the time!

DevOps, and especially with Pulumi / CDK (where it's actually infrastructure-as-actual-code and not infrastructure-as-a-JSON/Yaml file), is simply becoming a "developer who also likes ops" type of specialization. E.g. front-end, back-end and stack-end.

The nice thing is, and what I try to do in my team (both at my current startup and previously at AWS) is to break the silo and keep the "you build it you ship it" notion. Frontend - TypeScript, Backend - TypeScript, Infra - also TypeScript. When an engineer wants to build a lambda that listens to SQS or a Fargate ECS task or an S3 bucket, they can just do it. I if you know how to use the AWS SDK to let's say read/write to S3/DynamoDB/SQS, the API to create S3/DynamoDB/SQS etc is not that far off, and if you are using CDK in TypeScript for example (whether it's Terraform / CloudFormation / CDK for k8s doesn't matter) then indeed the boundary between backend code and infra code is getting smaller and smaller (both technically and also visually, the declarative code to generate an S3 bucket in CDK is pretty damn close to how it will look to generate that same S3 bucket via the SDK, it's just that CDK takes care of idempotency / change sets / diffs etc...)

In summary. I agree that DevOps should mean - you build it, you ship it and that the current industry trend towards a separate DevOps department is just plain wrong, but on the other hand, it's ok for specialization within a team, some will lean toward frontend, some toward backend, some toward data engineering, some toward data science, some toward security and some toward operations. Some will do a bit of both and some will prefer to focus and specialize, but I think that the main lesson I learned is that it all should be part of the team. Like a D&D party, you don't go to an adventure with just Warriors, then send the Wizards separately to ship the dragon to production.