"The growing zeitgeist is that “platform engineering is the future.”[1][2] And given that I co-founded a product in the space, I sure hope so! "
oh, now i understand this blog post..
DevOps is broken
211–220 of 363 posts
Re: DevOps is broken
#212Earlier quoted context omitted.
> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :) As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all. My personal favourite is how many large multi-nationals are now building in-house clouds? WTF is the difference between an "in-house…
> WTF is the difference between an "in-house cloud" and a shared-use datacenter from the 1990's? Can't call a mainframe a bunch of buzzwords like "Hyper-converged, high availability, on-premise software as a service cloud platform".
I'm pretty sure mainframe guys are calling it exactly that:
https://www.ibm.com/ca-en/products/z16
warning: buzz word alert!
Re: DevOps is broken
#213The article was interesting. It seems like it misses that the complaints of why DevOps is dead is a culture problem, which I've found are hard to solve by throwing new tech at the problem.
Re: DevOps is broken
#214Earlier quoted context omitted.
Agreed, anytime I talk with someone about DevOps ... we end up having to hash out the entire process to really know what either of us are actually talking about. Otherwise you have these situations "Yea the DevOps guy messed up the widget and nobody notic---" "Wait, what is the DevOps guy doing even touching that widget.... what is even DevOps to you?" "Bro that widget IS DevOps." -silence- Same applies to the topic…
this devops is also a dumping ground for anything else not happening on a developers computer which they should control but wont because "That is devops job" mostly this happens alot with node projects for some reason..
Humans are kinda terrible when they can just "not my problem" things.
Re: DevOps is broken
#215I have bewilderingly tried to discern why software development continues to grow more and more complex. It wasn’t always like this. There was a time when we talked about languages and OSes and libraries as if they made a difference on how much you could get done with as little people and cognitive load as possible (the claims were very much overrated, but the point was we acted like it mattered). And then it started…
> I have bewilderingly tried to discern why software development continues to grow more and more complex. It's because of growth, software development today is both simpler and way more complex than before and that's entirely due to growth in the sector. In many ways it's simpler than it ever was, I'm writing an API using Lambda/API Gateway in AWS and it blows me away how quickly I am able to get services stood up an…
> writing an API using Lambda/API Gateway in AWS and it blows me away how quickly I am able to get services stood up and configure my API
> for this same API I spent 2-3 weeks experimenting and researching IAM roles and how all my AWS resources would interact with one another.
same experience here, and trying to understand/test un/poorly documented AWS behavior with public/private APIs and EC2 resources has been a huge time sink :(
Re: DevOps is broken
#216Earlier quoted context omitted.
> There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. That's Conway's law. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." https://en.m.wikipedia.org/wiki/Conway%27s_law
Totally agree. The best succinct summary of Conway’s Law I've heard is “you ship your org chart.”
Which is a good way to word it because if your org chart is screwy enough you won't ship at all.
Re: DevOps is broken
#217Earlier quoted context omitted.
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…
> Making DevOps/DevSecOps/$BUZZWORD the responsibility of developers is a cost-cutting measure not a responsibility measure. My background is large multinationals so my view here is a bit bias but i don't think cost cutting is the driver. Large orgs get large change management processes and procedures. Over time, these change management teams become overwhelming behemoths with minds of their own. I think "DevOps" was…
Almost everywhere I've worked that I helped run software in production for would have a step in CD which filed an automatically-approvable change req with automation; just like the automated deploys.
It becomes just robots pushing around paper for compliance.
Re: DevOps is broken
#218I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
> I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers. This is a great way to do it. There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. Being direct about roles goes a long way towards simplifying corporate complexity.
Roles are muddy because life is muddy...and because people can do more than one thing at a time. Also because save for a few roles, businesses rarely need people 100% allocated to one role or task. Responsibilities are nice, and job titles mean people mostly do x or y.
My favorite example is that of a restaurant. You hire waitors, diswashers, bartenders, line cooks, prep cooks, hosts and hostesses, and managers. And your waiters might be 100% focused on taking orders during prime dining hours, but at the end of the night, they help clean up assuming other roles. Your bartender might be busy making drinks, but they take a table or two if they can. Your prep cook might finish the prep early, and come on the line to help out. Your manager focuses on expediting everything and keeping the ship running smooth, but also can fill holes at time.
Re: DevOps is broken
#219Earlier quoted context omitted.
> There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. That's Conway's law. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." https://en.m.wikipedia.org/wiki/Conway%27s_law
Totally agree. The best succinct summary of Conway’s Law I've heard is “you ship your org chart.”
I like "the org chart is the asymptote," i.e. it's the best you could possibly do, and your reality will actually be worse. (see Casey Muratori)
Re: DevOps is broken
#220I have bewilderingly tried to discern why software development continues to grow more and more complex. It wasn’t always like this. There was a time when we talked about languages and OSes and libraries as if they made a difference on how much you could get done with as little people and cognitive load as possible (the claims were very much overrated, but the point was we acted like it mattered). And then it started…
I think it is because of what is described through Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.[2][3] — Melvin E. Conway The problem isn't necessarily software itself, but how we organize people (more than 2 or 3), how we communicate, how we mirror opera…
Small teams have honestly always been successful to the flaw that they outgrow themselves constantly in my experiences.