As the DevOps trend continues to gain traction, the days of compartmentalization in software development, deployment and management may be drawing to a close. Yet there are still strides to be made in creating seamless cohesion for today's software teams. This includes enabling best practices with tooling, merging DevOps with Agile methods like continuous integration and expanding the team umbrella to be more inclusive, all of which leads to improved software quality. The Server Side spoke to a few professionals working in this space to capture a snapshot of where DevOps is right now -- and where it needs to go next.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
DevOps will always be about people first
What DevOps really comes down to is breaking down the barriers between the development people and the operations people.
Dan Cornelly, Denim Group CTO
This seems to be a common point of agreement. Denim Group's CTO, Dan Cornell, spoke of the need for each team member to broaden their perspective. "What DevOps really comes down to is breaking down the barriers between the development people and the operations people. For example, it's important for the developers to understand, 'I'm a developer and I have certain concerns. You're in operations and your concerns may be different from mine. But if I understand more about what it's like to do your job, if I understand more about what tools and facilities you need, I can help you out by building some of those things in.'"
This focus on human needs is why DevOps can be so difficult to define. There isn't one right way to do things, because every team and every team member is different. Clayton Coleman, lead engineer of OpenShift by Red Hat, acknowledged that a number of approaches coalesce to create a DevOps environment. "Bringing people together is really the heart of DevOps, and there are many different ways to do that. There are processes, technology and organizational changes." Processes certainly come into play when looking at the day-to-day functionality of a DevOps team.
Changing processes leads to improving software quality
One of the changes that seem to go hand in hand with DevOps is a shift toward continuous integration. The speed at which software is developed and deployed is one factor that has made merging development and operations less of a luxury and more of a necessity. Jeremy Eder, principle software engineer at Red Hat, revealed what his performance team is doing in this space. "We've really embraced continuous integration from a performance perspective. That means writing tests that can gate releases for performance and scale regression, not just functional and feature tests. Those are things we're doing internally that excite me in terms of automation because they allow us to have a lot more confidence in software that gets shipped, which is the purpose of CI in the first place."
Assurance of higher quality for each iteration of software is certainly an outcome that makes everyone on the team breathe easier. Neither development nor operations wants to deal with the fallout from nasty surprises.
Newer platforms may ease the pain of adopting DevOps
Of course, that doesn't mean everyone on the team will automatically get on board with the notion of DevOps. Coleman revealed one way that Red Hat is working to enable the shift for everyone via the OpenShift platform. "We're trying to make things as painless as possible for developers to get started in building Web or mobile app or microservice architecture -- having the tools that let you press a button and deploy real software in an enterprise or public cloud environment. On the flip side, we're making it really simple for operations to roll out changes to hundreds or thousands of applications simultaneously. It's about taking something that was hard before and making it trivially easy."
The logic is evident: When people are relieved of the stress and frustration caused by difficult and time-consuming aspects of their jobs, they play well with others. Making DevOps the pain-free option for everyone involved encourages adoption of new practices that can lead to improving software quality.
Will DevOpSec be next?
It seems natural to merge DevOps into a single organism, but the synergy shouldn't stop there. Cornell directed attention toward an often overlooked part of the ecosystem. "I would argue that you need to break down the barriers that both Dev and Ops have with the security people. It's very important for security teams to understand more about how software gets developed because all three of these groups have different concerns and different ways that they get rewarded. It's really only when these three groups are working together that the cost of everyone's job going smoothly collectively goes down."
Right now, that's not happening. "Too many teams aren't thinking about security at all during the development lifecycle. For example, a lot of teams need to start looking at how they do input validation and how they do output encoding as information passes between systems. They really need to take to heart the concepts of authentication and authorization so that they can start addressing those two security concerns and rolling them into the application as they're developing it. That's really going to get them a long way toward avoiding introducing serious security issues."
Cornell pointed out that, while modern frameworks often deal with validation as a matter of course, encoding is the control that must absolutely be implemented to avoid certain classes of vulnerabilities. This is especially true in the mobile development field where new security threats are being uncovered all the time. One thing is certain: DevOps won't be the end of the road. It will open up even greater prospects for collaboration, continuous improvement and improving software quality throughout the software cycle.
What strategies is your organization using to make DevOps work? Let us know.
Experts weigh in on Agile and DevOps methods