Is DevOps making the same mistake as IT?

Source:-techbeacon.com

I’ve been “DevSecOps-adjacent” for some time. My background is in the ops side of IT, and I have had several roles in cybersecurity. Like many who’ve been in cybersecurity for a while, I’ve become disheartened at the lack of progress—at the way the industry and its customers seem to be suffering from the same issues, not just year after year, but decade after decade.

I see DevOps, and especially DevSecOps, as a way forward—a different way of working that might finally break the cycle, and make more of the talent and investment in the industry. Despite my interest, I’ve never really been directly involved in DevOps—until now. Now I’ve had an idea or two for a project I want to try, and the DevOps methodology appeals; it’s a way to build on my experience in ops to try out an idea.

The idea is for a game that teaches people how to use the online services out there, or even just highlight the bewildering array of services that are available. Something competitive, where players vie to organize or sort or understand data, and where efficiently leveraging cloud services to stay on top of that process would help them win against other players.

I’ve also got an idea for a simple strategy game that just runs on top of modern cloud services, that will illustrate the consequences of strategic decisions in a two-sided or multiple-sided conflict. Just an abstract depiction of a territory; orders on whether to attack or defend, fire, or move; and an engine that automatically works out the consequences and communicates them back to the players.

I might use the first game myself to learn how to build the second. That feels like the ideal situation for a DevOps mentality: a methodology built on creating a Minimum Viable Product to see if the idea works. DevOps is a way of working that can respond rapidly to new ideas but also has the intention of creating a stable infrastructure that mainly looks after itself.

However, when I delve deeper into DevOps, beyond the conversations I’ve had and presentations I’ve watched, what I see reminds me of the problems I’ve experienced with more traditional ways of doing IT.

[ Learn the secrets of successful DevOps initiatives in TechBeacon’s guide. Plus: Download the EMA analyst report on Optimizing DevOps Initiatives: The View from Both Sides of the DevOps Divide ]

Tools vs. results
Overall, IT has focused on the technology, not on what it does. Traditional IT is still focused on which operating system to use, how technology decisions in one part of your infrastructure affect what you can or cannot use elsewhere, how those choices fit within existing long-term support and maintenance contracts, and how the staff you have affects the technology you can choose, or what technology you choose means which staff you keep or release.

Similarly, large-scale IT is seemingly dominated by systems integrators. These are large providers that have tended to have a set of proven solutions they’ll crowbar your requirements into, or a menu of options for you selected only from those service providers with the most profitable relationships for themselves.

But DevOps is meant to be a new way, with processes and approaches in mind rather than a focus on tool chain and technology. As a seasoned cybersecurity professional, that’s the kind of new thinking that attracted me to the methodology, and as an aspiring developer with half-formed ideas, the same applies.

Tool talk is old school
Of course, I don’t expect the same level of success, but when I read about Amazon’s flexibility to deploy or stand down systems in response to demand, or Google’s overall ability to develop or abandon services, that’s the kind of flexibility I will need to see if my ideas will work.

DevOps seems to be the methodology to make the most of my background, so where do I start? Where is the conversation right now?

The DevOps community doesn’t seem to discuss continuous development much, but they discuss Git; they don’t discuss continuous integration, but they discuss Jenkins and how that integrates with Selenium when moving to continuous testing.

For continuous deployment and the required containerization, there’s no discussion at all, just pledges of loyalty to the fiefdoms of Chef or Puppet or Ansible, and Docker or Vagrant—it feels like Vi versus Emacs all over again. Monitoring at least seems more what I expected, with many different solutions available, including those I’m familiar with already.

As an aspiring developer, I don’t feel as though I need to track tickets and issues, but Slack appears to present a universal interface in lieu of needing a dashboard for such a small project. So maybe I do need to talk to myself using ChatOps, but nothing more.

There’s a “Do you even Jira, bro?” feeling about DevOps as a methodology.

From my involvement in the wider community, the same issues apply. There are as many conversations about which tools to use as there are about modifying your approach, or taking on your existing corporate culture. There are also many conversations where the use of certain tools is assumed.

[ Get up to speed on quality-driven development with TechBeacon’s new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]

On the outside looking in
I’m on the periphery of the community—on the outside looking in. For those of you already deep into DevOps culture, maybe who’ve been lucky enough to avoid the “death march” projects of waterfall or the adherence to agile, take a step back and ensure you avoid the failings of your predecessors. If tools aren’t interchangeable in your tool chain, are you falling into the same trap?

Both of my ideas seem so early-state that I’m embarrassed by publishing an article listing them with my name attached—but also so full of possibilities that I am afraid of publicizing them in case you, the reader, make a version of them first. They are half-formed, and will definitely evolve over time. I’m not sure what direction they’ll go in. I might want to pass them on to someone else, but they might strike a chord with people and need to scale up quickly.