Fork me on GitHub
#dockside
<
2020-01-17
>
Jerreck02:01:35

Does anyone in the rebellion use wikipedia often? I was writing up a blog post about how I got into ITR books and noticed that TPP didn't have an article. Anyone wanna help me take a crack at that? https://en.wikipedia.org/wiki/The_Phoenix_Project_(book)

😍 1
Jerreck02:01:35

Does anyone in the rebellion use wikipedia often? I was writing up a blog post about how I got into ITR books and noticed that TPP didn't have an article. Anyone wanna help me take a crack at that? https://en.wikipedia.org/wiki/The_Phoenix_Project_(book)

😍 1
Ben Curran12:01:02

We have had real trouble lately with the Dev side of DevOps not really embracing the Ops side. Our Ops teams have made great strides learning programming languages and getting into automation and IaC. But the second we ask a Dev to support their own or deploy resilient infrastructure and they throw their hands up. Anyone else got experience like this?

👍 2
Ben Curran12:01:02

We have had real trouble lately with the Dev side of DevOps not really embracing the Ops side. Our Ops teams have made great strides learning programming languages and getting into automation and IaC. But the second we ask a Dev to support their own or deploy resilient infrastructure and they throw their hands up. Anyone else got experience like this?

👍 2
Jonny Muir14:01:11

I got thrown at me in a team meeting recently that if you hired someone to stack shelves you shouldn't expect them to go and work on the tills (as a metaphor for "I am paid to code - I'm not doing anything else"). I guess this relates a bit to the developer who is only interested in creating new features in the book. I had to remind them that we are not shelve stackers. We create working software for people to use. Its a culture thing and it is slow to change (but it is and will change - and people will come along with it, or will step aside). I'm not sure exactly when this culture crept in, somewhere in the 2000s for us I think as a reaction to a growing business and a separation of functions. It wasn't that way when I started in the industry.

Bryan Copeland06:01:24

have had the exact opposite problem, our Dev team for lack of having "Biz or Ops buy-in" for alot of our attempts to automate or streamline (and a bit of a knowledge gap on their side for application usage or platform technical details), have had no choice but to support our own applications, against never ending Business requests and Ops CAB/DCB rules... Typically do most companies not find a greater deal of efficiencies by doing the opposite (after the initial 1-year to "iron out the kinks" and automate that which makes sense to automate)... even Google advocates a use of SRE role primarily within Ops to maintain apps and streamline delivery pipelines... but advocates Dev should launch their own products/services and run them until they're "out of Beta"... Can say we're absolutely overloaded by an unrealistic Backlog (never gonna get to a bunch of it nor should we probably), non-technical unsympathetic Product Owners, and mostly apathetic and only passively supportive Ops team... could sure use those playing the "dump stuff in the Backlog for those guys over there to deal with" roles to take on a greater share of the workload, I can't help but feel that only by taking an active responsibility in deliveries will Biz/Ops side understand the implications of their own demands