3 ms·

> for a small four person start up, the best investment is improving the development team's operational posture (e.g. run books, alarming, monitoring). Oops, I

> for a small four person start up, the best investment is improving the development team's operational posture (e.g. run books, alarming, monitoring). Oops, I thought that was DevOps.

fennecfoxen 4y ago
That's actual-devops. Grandparent poster has worked at firms which have abandoned all its lessons and just use it to mean something like "regular old ops teams, but they use software". So he's using the term like all the big companies do, basically. This is also where you will find things like a "CI/CD" team that doesn't do continuous delivery: they just build Jenkins pipelines, and run them as part of the manual cluster bringup every 2-4 weeks. Or "RESTful" to mean "APIs which use JSON and HTTP verbs" regardless of any hypermedia. And let's not even get started on "agile"...
- jbverschoor 4y ago
  'word', as they say
- JamesBarney 4y ago
  Here's a 400 page book and a 12 week training course on all the processes we used to implement Agile's "People over process" principle.
  - Banana699 4y ago
__MatrixMan__ 4y ago
Me too. In my experience it went poorly because us devs are now handling our own deployments and building alerting systems and such, but the "devops" people won't give us the level of access necessary to do that with tools designed for the job, so we end up building custom ops-related tooling into the app and writing backdoors that let us use it without having wake the ops folk. When you're accustomed to having to build everything you need, and you're tasked with ops work, you end up reinventing a lot of wheels in a rather weird way and compromising your app in the process. Or at least that's what we did.
theptip 4y ago
This really substantiates the OP’s claim. Maybe we need to come up with a new term to be more specific. “DevOps for developers” vs. “DevOps for operators” or something like that. (DevDevOps va OpsDevOps?) I always took DevOps to be some combination of 1) applying dev best practices to ops, which could still in theory be done by a separate team, but more 2) unifying dev and ops in one team/role, perhaps enabling developers to own it by providing tools and abstractions that developers can work with, and workflows that unify the processes and improve collaboration by lowering cycle time. It seems that the “bad” DevOps is OpsDevOps where the old ops team just gets some rebranding, and maybe some new tools like Terraform. I’ve always found the “DevDevOps” approach to be quite empowering. Giving developers a tool like k8s so they can abstract away the hard half of ops, and understand the rest.
cortesoft 4y ago
Yeah, to me, the core of the ‘DevOps’ philosophy is that the dev teams owns the product end to end, meaning they write it and are responsible for it in production.

> for a small four person start up, the best investment is improving the development team's operational posture (e.g. run books, alarming, monitoring). Oops, I thought that was DevOps.

fennecfoxen 4y ago

That's actual-devops. Grandparent poster has worked at firms which have abandoned all its lessons and just use it to mean something like "regular old ops teams, but they use software". So he's using the term like all the big companies do, basically. This is also where you will find things like a "CI/CD" team that doesn't do continuous delivery: they just build Jenkins pipelines, and run them as part of the manual cluster bringup every 2-4 weeks. Or "RESTful" to mean "APIs which use JSON and HTTP verbs" regardless of any hypermedia. And let's not even get started on "agile"...

jbverschoor 4y ago
'word', as they say
JamesBarney 4y ago
Here's a 400 page book and a 12 week training course on all the processes we used to implement Agile's "People over process" principle.
- Banana699 4y ago

__MatrixMan__ 4y ago

Me too. In my experience it went poorly because us devs are now handling our own deployments and building alerting systems and such, but the "devops" people won't give us the level of access necessary to do that with tools designed for the job, so we end up building custom ops-related tooling into the app and writing backdoors that let us use it without having wake the ops folk. When you're accustomed to having to build everything you need, and you're tasked with ops work, you end up reinventing a lot of wheels in a rather weird way and compromising your app in the process. Or at least that's what we did.

theptip 4y ago

This really substantiates the OP’s claim. Maybe we need to come up with a new term to be more specific. “DevOps for developers” vs. “DevOps for operators” or something like that. (DevDevOps va OpsDevOps?) I always took DevOps to be some combination of 1) applying dev best practices to ops, which could still in theory be done by a separate team, but more 2) unifying dev and ops in one team/role, perhaps enabling developers to own it by providing tools and abstractions that developers can work with, and workflows that unify the processes and improve collaboration by lowering cycle time. It seems that the “bad” DevOps is OpsDevOps where the old ops team just gets some rebranding, and maybe some new tools like Terraform. I’ve always found the “DevDevOps” approach to be quite empowering. Giving developers a tool like k8s so they can abstract away the hard half of ops, and understand the rest.

cortesoft 4y ago

Yeah, to me, the core of the ‘DevOps’ philosophy is that the dev teams owns the product end to end, meaning they write it and are responsible for it in production.