What I like (and don't like) about DevOps
What I like (and don't like) about DevOps
Join the DZone community and get the full member experience.Join For Free
Discover how you can reduce your Kubernetes installation from 22 steps to 1.
So, from a software development manager and CTO perspective, this is what I like (and don’t like) about DevOps so far.
What I like
The DevOps community is real: it's about people solving real problems, hard problems that a lot of us face in managing large systems. It's about people working together to come up with new ideas on how to do a better job. It's about taking ownership of problems and the solutions to these problems.
It is not an idea that has been crafted outside and that is being sold to people because it is good for them – not like Rugged Software for example. DevOps has authentic buy-in, it is being built from the ground up, and I can see things actually happening.
And there is no right or wrong, there’s no Manifesto (please please keep it that way), there’s no fundamentalism or religious wars – so far at least. DevOps is still in that early place and time where things are fluid and searching. People can disagree, and as long as they are smart and pragmatic and fair, they are listened to. Nobody is worried about contradicting one of the Creators (unlike in the Scrum community, or the the software Kanban community). Most of the people involved in DevOps today seem to be practical and open minded, and focused on finding answers. I hope it stays this way, forever and ever and ever.
DevOps has strong support from vendors. There’s configuration management and deployment automation technology like Puppet and Chef of course, and companies selling Continuous Delivery services and technology, the stuff needed for Infrastructure as Code, for effectively integrating application and infrastructure changes. And there is an important need in DevOps for highly scalable but lightweight data management technology, network management and monitoring platforms, tools to collect and analyze system and application metrics and logs. And then there's the Cloud.
Yes, there has to be a role for vendors: somebody has to act as a sponsor, to help sustain momentum, and people need technology to solve DevOps problems, to make deployment and management and operations of large-scale systems possible. But DevOps is not vendor-led, or consultant-led. Big Blue and HP haven’t figured out what DevOps means to them, or how to turn it to their advantage. Most of the technology is Open Source, making it easier for the community to get involved in solving their own problems.
The people in DevOps who are worth listening to are techies or hands-on managers who have real day-to-day responsibilities and solve real problems and who are sharing what has worked for them, and who are actively trying to find ways to do their jobs better and are interested in answers. Most of the thinking and writing in DevOps is being done by the doers, not by people trying to sell something, trying to convince you that you have a problem and that you need their help to solve it.
DevOps is about solving some interesting and challenging problems, in some cases extreme problems. I don’t have to manage the technology for a platform with thousands or tens of thousands of servers or millions of online customers, but I can learn from people who do. It’s fun and it’s worth paying attention to.
What I Don’t like
There’s a lot of enthusiasm in the DevOps community, people excited because they are onto something that is working, creating new tools, finding new solutions to problems. There are times when those of us who have been around for a few years recognize old ideas, even when they’ve been given cool new names. Listening to someone excitedly describing “dark launching” and “feature flippers” and pretending that this is a new idea is tiresome… But you can get over it, you can still enjoy the enthusiasm and wait to see if there are any new lessons to be learned.
Not surprisingly, there is much talk by DevOpsers about Values and Culture and Collaboration and Trust and other Capitalized Important People Stuff. This is all necessary when you are trying to get people to work together in new ways, but it has the potential to slide into pop psychology and New Age philosophizing like too much of what passes for thinking in the Agile development community today by consultants and "coaches". Hopefully, DevOpsers will stick to solving problems and getting things done in an open way, and not wandering down this path.
DevOps hasn’t come to terms with ITIL, and it needs to. ITIL is used as a straw man by some of the DevOps thinkers, in the way that Waterfall development is used by some Agile development enthusiasts: as an outmoded way of thinking and working, a collection of antipatterns. This naive approach is not fair or practical, it alienates a large community of people working in enterprise organizations and government IT organizations who have adopted more structured frameworks to get their work under control. There’s a lot to like in DevOps, but there’s a lot that DevOps can learn and has to learn from ITIL as well.
More fundamentally concerning to me is that DevOps has failed to take responsibility for security. They don’t seem to understand or care about what’s involved in deploying and operating secure systems, or if they do, they don’t explain how it fits. This will limit DevOps adoption, because most operations and development teams who want to take advantage of the ideas and practices and technologies coming out of DevOps, to become more efficient and more agile, also need to do this in a secure way. And this is reflected in the ongoing security problems that some of the organizations that are pioneering DevOps ideas continue to face. Would you trust your email to Facebook, would you really?
There’s a lot of interesting ideas coming out of large-scale online social media companies like Facebook and Twitter, and Flickr and Etsy, and some of the online multi-player Internet game platforms. But there’s a gap in trying to apply their lessons to the problems and requirements that the rest of us deal with: smaller-scale, but just as hard, just as real. Secure design and deployment and operations, all kinds of compliance and auditing, real data privacy, real transaction reliability, B2B integration, protecting compatibility with customers and legacy systems. Ideas taken to extremes like Continuous Deployment are exciting and challenging, they force you to think about how you can get better. But they aren’t ready for the enterprise yet.
DevOps doesn’t represent or meet the needs and priorities of most of us working on enterprise systems. But that doesn’t mean that they shouldn’t keep going. And that doesn’t mean that the rest of us shouldn’t keep following them – and trying to keep up.
Published at DZone with permission of Jim Bird , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.