Comment by nodesocket | Hacker News Reader

Comment by nodesocket | Hacker News Reader

Parent Full thread

I just founded my third startup Elastic Byte (https://elasticbyte.net), which is a DevOps and infrastructure consulting company operating as SaaS (public monthly pricing plans).

Indeed culture is a big part of the DevOps puzzle besides software. This mentality shift is also a part of what we offer (training and advice). Individual ownership, moving fast, are all parts of the greater strategy. I've found the talk "You shipped it, you fix it" [1] by Ron Cohen (CTO of Opbeat) a great source of solid ideas.

https://opbeat.com/community/posts/you-shipped-it-you-fix-it...

The old model where developers hand off their code to the ops department is fundamentally a bad strategy because it leads to:

   "It worked fine in test... Ops problem now!"

There is no accountability. If your code causes problems when deployed to production, ops is the one getting a call/page in the middle of the night, and trying to fix the problem for which they have no domain experience or understanding. However, if you deploy your own code at your own pace, then there is accountability.

Yeah that mindset shift was the hardest part of transitioning from a traditional ops to a no-ops approach at our last company. The technology has no chance if the culture isn't ready.

We especially see this with F500 companies. They insist on multiple manager approvals for deployments. CI/CD is really scary to them because it feels too risky.

One of our prospective customers (at a F500 company) told us about how they have a cross-functional deployment 'swat team' that all gather in a room on a Friday night and literally press a button to deploy the update, then see what happens. They take their website offline in anticipation of errors (and put up the '90s construction worker logo) and then their ops people get paged over the weekend to deal w/ errors. Just ridiculous!

The irony is that the slower deployment velocity creates more risk, making deployments scary affairs. It's a terrible cycle. Deploying 7x per year means each deployment contains many more features/fixes, which introduces more risk. Vs. breaking a monolith up into microservices, and letting each component deploy at whatever cadence is best for it. And with Spinnaker each deployment can be traced back to the original git commit hash / jira ticket / etc., creating much more transparency in the deployment process.

Reply on news.ycombinator.com