DevOps Topologies
web.devopstopologies.com
web.devopstopologies.com
For real it means that the devs and ops collaborate. Leaving aside that we don't need a term for that, it cannot be a strategy. It's something that evolves in years between decent people. You cannot hire devops. You cannot train devops. There is no such thing.
Massive reason behind devops is to get Dev teams to take more ownership of ops so they improve their Dev practises, I don't see a dedicated team being able to improve the code base in the same way.
Based on...what?
> As companies grow they tend to hire based on specific skill sets
By which you probably mean they tend to prefer hiring more narrowly specialized individuals. That may be a common trend, but to the extent it stops you from hiring or training for devops across your technical organization, it's incompatible with any meaningful devops implementation. DevOps doesn't work as a silo, any more than (as an enterprise I know pretends to do) can you do kaizen by way of an isolated “Kaizen team” reporting to a senior executive. Some things are definitionally not siloes and “doing” them in a silo is a failure to do (or even understand) them at all.
You can hire somebody with extensive experience in jenkins, and building and integrating tests, deploying, logging, diagnosing production issues, systems/performance-experience, DBA skills, secret management, etc.
And many companies do. If you don't think hiring a specialist in those things should be called "hiring devops" what realistically should we call it?
But I think the article does point out the many ways "hiring devops" can go wrong.
Yes. The most simple, boiled-down definition is that: collaboration. But how the f%&k do you do that?
You might say, "Oh I dunno, they'll just figure it out." But guess what? People have spent their entire lives trying to figure out how to get random teams to collaborate better. It's hard. It's harder than coding, harder than supporting an app in production. It's not something you get good at by just doing engineering and hoping for the best.
And that is the entire reason DevOps was invented. A bunch of engineers basically got together and said, "Shit. We need to collaborate better. And we've known that for a while, but it's just not happening. What can we actually _do_ to collaborate better, and produce better outcomes?" Over the past decade, there has been a lot of collaboration on how to do better collaboration. This topologies page is a very small example of what they've found.
I think that to engineers, DevOps can seem like a buzzword because there's all this stupid-sounding "business stuff" that people keep tacking onto DevOps. But the reason that happens is there are people whose job it is to help people collaborate better, and produce better outcomes, who have spent their lives working on these problems, and are trying to apply them to technology-related businesses. A lot of the things they've figured out are built on other things that have proven successful in the past, such as Lean manufacturing/software, Agile software development, and all the many other business strategies developed and practiced over the last century. Many companies, both large and small, have applied these ideas and seen real results from them.
> DevOps is just a buzzword.
"Cloud" is also a buzzword, as well as "Agile", but they are real things that real people use every day. Misunderstood? Absolutely; but definitely real.
In my last Organization the devs largely treated ops like trash, it was only the dev teams on the most business critical and performance sensitive apps that really worked well with ops because it necessitated a close working relationship through the good times and through the hard times & they natuarally came to respect each other's skills