CloudBees DevOps Evangelist, Brian Dawson sits down with Red Hat's Sales Director, Rich Savage to discuss how CloudBees can ease the pain of shifting to DevOps.
Rich Savage: Hello everyone. I'd like to thank you all for joining our podcast today to take a deeper dive into DevOps Solutions with CloudBees. I'm Rich Savage with the Open Source Team at Carahsoft Technology and I'm here today with Brian Dawson, DevOps Evangelist with CloudBees. Thank you for joining us today, Brian.
Brian Dawson: Thank you Rich. Glad to be here as we head into the Thanksgiving holiday and I'm looking forward to our conversation.
Rich Savage: The team at Carahsoft often receives many questions from our government customers asking about how CloudBees can ease the pain of shifting to DevOps and the benefits to using CloudBees' technology to make their agency work smarter and faster. So for our listeners, Brian, let me start by asking you a couple of questions here. The first one being, how would you describe the current state of DevOps adoption in the federal government?
Brian Dawson: Well, I'd say still coming along, but fully underway. I continue to be surprised that when either we engage with fed agencies or I meet DevOps personalities and software development and delivery stakeholders and government, how much they're in tune with DevOps and the benefit that DevOps can provide. I think as we're all aware, technology operations and government are dominated by compliance and there are a wealth of requirements that dictate the security and reliability of federal systems. And that's led to many, if not most, government agencies exploring and adopting new ways of continuously improving and just delivering better software. And that's led to continuous integration, continuous delivery, and as an extension or embodiment of continuous integration and continuous delivery, DevOps.
Now I don't want to oversell it, I'd say that the shift to DevOps in the government has not been blazing fast, rapid, amazing. There are some unique challenges to overcome, but from department of energy to department of defense to CMS to immigration services, there's been some great examples of application of DevOps to improve overall delivery. I always do like to call out, because I was so blown away, not only the progress that we've seen in the DOD, not only some of the progress I had the pleasure of participating with personally with the center for Medicare and Medicaid services, but in particular, US citizenship and integration services or USCIS. We had the benefit of having them come and speak at our sort of traveling road at CloudBees in DC. It was great to see that they're seeing a higher frequency of software deployments, lower failure to change failure rates aligned with the DevOps research and assessment or DORA report. Fantastic metrics. And really we had private sector in that room listening to what USCIS was doing and they were blown away.
So this is an example of a government agency, among others, that is at least on par, if not beyond, many organizations in the private sector. So, some great successes, a lot of work to do but well underway.
Rich Savage: Well, thank you for that. And as we all know, security is very important to the federal customer. Have you seen DevSecOps kind of re-energize this DevOps movement in the government?
Brian Dawson: Well, so it's interesting that you say reenergize because that kind of fits with my philosophy of DevSecOps. So to start at the top, the Sec in DevOps, as I always say, is silent. DevOps fundamentally is about a quality first approach and delivering software rapidly, reliably, and repeatedly. So if you're reliably delivering software with a quality first approach, I contend that security is quality. Insecure software is low quality software. But I hone in on the word invigorate because what the DevSecOps movement has done is focus a necessary spotlight on the importance of security to make sure that it's at the forefront. And I think in sectors like the government, explicitly calling out security has a signaling effect, kind of a comforting effect to go, "Okay, this DevOps thing is great. It means we all work together, we automate everything, we move fast. But what about security?" Well, the DevSecOps movement calls that out.
And I think where DevOps, and by extension DevSecOps, has been really important is it's driven a reconciliation or realization that speed can better enable compliance and security. When we're able to automate and automate with velocity, we're able to ensure that those critical checkpoints that oftentimes are... Well first are maybe manual, so human error may introduce vulnerabilities. We're able to automate out that potential for human error, but also when we're able to automate, we're able to better create reliable confident sources of traceability and auditability.
Brian Dawson: Now the other thing that happens with speed are things are twofold. When we can move faster, we can improve and mature software faster, which means we don't have eight, 10 year old pieces of software and code that someone has infinite time to try to figure out how to exploit. We also, however, can respond to immediate security threats or known vulnerabilities and quickly get fixes or protections against those in the application, cycle them out and prove them. So again, DevSecOps is critical to DevOps but DevSecOps, I think, helps DevOps find a place in the government and it really underpins that speed and automation or a path to achieving security and compliance.
Rich Savage: Excellent. Thank you for that. Brian. For agencies that have not embraced DevSecOps yet, what's the business case for them doing so?
Brian Dawson: Okay. Well, in contrast to what we'll call traditional development where you have different functional groups working independently with heavy manual gates and processes to ensure compliance, a couple of things happen. The handoff between the groups are often fraught with miscommunication, blame, delays. That miscommunication, the blame, delays, et cetera, can introduce additional errors actually. They can slow down your ability to sure up your security posture.
Brian Dawson: Moreover by not, say for example, automating authority to operators, we like to say pursuing continuous ATL. What you get is... And then paired with the lack of speed, is a significantly slowed down process that has a number of gates that are heavy and difficult to cross and they tend to span over time. Meaning these gates don't necessarily catch everything, we can't respond, again, as I said earlier, to bugs and security.
So the old software development process has resulted in, at times, absolute lack of speed. But as well, questionable stability and security that ends up coming at a failure to truly serve the citizens via software, cost overruns, defects, et cetera. What DevOps will deliver is it'll deliver value by enabling you to move from manual to mission critical. Moving your focus from manual processes, tedious rote processes to putting the human intelligence on mission critical, high value work through automation, minimizing rework, bloat, overages, and overall making better use of dollars and funding that had been provided by improving ROI and efficiency. I like to say that with DevOps you achieve velocity through automation so that you have a faster time to capabilities and you ensure quality with speed while you ensure security with speed.
And what you're going to find... And the federal government, I've heard this talked about a bit though. Yeah, I had a bunch of conversations about it, is that just like software is critical that every business, software is already and becoming even more so increasingly critical to efficient operation of government and the fed systems. All the way from military to immigration to healthcare. And what you need to power that is you're going to need up to date talent. You're going to have to be able to bring in those sharp whizz kid's, recent college graduates, et cetera, and where they want to work is they want to work in places where they can do what they entered this field for, they want to develop things that matter. They want to have an impact, they want to deliver change, better things for their users and moving forward and adopting modern development methodologies is a key part in enabling them to do that, which is a key part of attracting that talent, which will ultimately fuel our drive towards improving federal operations and federal systems through software.
Rich Savage: That's a great point, Brian. And actually it leads me right into my next question. What challenges are you seeing the federal government face today when it comes to software development and how is continuous integration and continuous delivery orchestration changing that?
Brian Dawson: Yeah. Well, so I think this is some things that we already noted and I’ll roll in some other ones. Compliance. It's critical to maintain the authority to operate. It's critical to ensure that every stage you're compliant, it is critical to ensure that you're secure and on par, and again, the world's sort of shifting and changing with data protection concerns for security, but way beyond on par with what is required for the private sector. We look at agencies that have virtually every citizen in the country's private information or every Medicare or Medicaid patients private information, security is critical. Compliance is critical. And why I do say security is embedded with DevOps, the government struggles to meet those security and compliance requirements baked into what I call legacy procedures for maintaining that and then trying to figure out how to not only automate those processes at a technical level, but change the mindset to involve everybody and bring everybody along with figuring out how that automation can replace those traditional systems. So that's a challenge.
Another challenge that I think as people start to run into as you implement continuous integration, continuous delivery in DevOps ops is the silos. Much akin to what you see in private sector. We have a business analyst group in the private sector, a Dev group, a QA group, an operations group, and they're all funded differently and managed differently. So the organizational structure in private and oftentimes government entities alike, inhibits the ability to deliver software rapidly, reliably, and repeatedly. As I said earlier, I like to use Conway's law. So if you look at the government or private sector, the system, and I'm going to get it slightly wrong here, but the systems that an organization develops represent the structure of that organization. So if you have disjointed silo operations, distorted silo structure, that tends to show up in your software.
So these are the challenges that the government faces prior to DevOps, that both percent a challenge to the implementation but are also things that the implementation helps overcome. So continuous integration, by default, is about continuously integrating changes so that you can find problems fast. Cutting down that silo of say a API team with a front end team. That they're continuously integrating their changes sort of a conflict or a problem, we find them. A quality first approach.
Continuous delivery, by extending continuous integration, seeks to automate across and through those silos. And while at the end of the day, you really can't achieve forward movement without a cultural change, a mindset change, which we'll get to. Oftentimes, especially with engineers and people of the technical mindset, that starts in a tool chain, builds on to a process and then works to kind of establish a culture and continuous delivery is that tool chain and process platform.
Now at the end of the day when we start to talk about culture, what DevOps does as people adopt a DevOps mindset is it focuses more on collaboration. It focuses on a culture where we seek to tear down communication barriers between those silos that I noted not only in DevOps, but the business, QA, Dev operations, et cetera. And when you adopt that cultural mindset, now we're able to move faster, we're able to overcome some of the friction, as I said earlier, some of the errors, slow down potential lack of quality, et cetera, that we suffer due to the manual handoffs.
Rich Savage: I see that Jenkins is a key part of the DOD's DevSecOps technology stack. Can you briefly describe what Jenkins is and the critical role it plays by automating the software development process? If there's a use case you can share, that would be great.
Brian Dawson: Yeah, absolutely. So what Jenkins is, is an open source automation solution that helps users implement continuous integration and continuous delivery in pursuit of DevOps. And I like to share that it is the most popular automation server, automation solution of open source or commercial and we're proud that it was created by our CloudBees chief scientist Hudson in 2004. The key thing with Jenkins is that it has a paralleled integration ecosystem. So it has over 1600 plus integrations which allow the DOD, specifically, to integrate with pretty much any tool or technology in its stack. And you can use Jenkins to define simple automation, "Hey, every time a code commit happens, I'm going to run a component dependency scan to see if there are any vulnerabilities in any of our components that we're dependent on." Or, I can extend that and you can use what we call Jenkins Pipeline as code to define an entire complex end to end software delivery pipeline.
We've also had the privilege of working with the DOD as a key player in their DevSecOps software platform initiative. And there we had an opportunity to provide a hardened version of CloudBees core built on Jenkins to DOD to function as part of their hardened software factory. And as I noted earlier, leveraging our rich integration ecosystem to ensure that they can integrate any of their existing or new tools into a standard templated process. And what we've been able to do there is enabled DOD programs, across all DOD services, to begin to apply that hardened software factory to their existing or new environments. Classified, disconnected and in the cloud and we've enabled them to do that within days or weeks instead of years.
So when we go back up to the top of the call and we talk about adoption, we're proud to say that CloudBees work with DOD has enabled the key federal entity to significantly accelerate their adoption of these best practices. We've also paired with them not only in providing the software but professional services as well to assist with onboarding, training on, implementation of, and execution of best practices.
In our next release of the product, based on our work with the DOD, we're going to take the DevSecOps vision to another level and we're going to go even further at enhancing our risk management or the security posture while providing developer freedom that facilitates or fosters speed and innovation. And I think that's the key thing that is often missed I think by federal vendors and in fact in the private sector. When you're in sectors that require significant governance and security, oftentimes that's where the tool and process focused goes and that's at the expense of that ability to innovate end developer freedom, which I also alluded to earlier is so critical to getting the resources and so critical to building reliable software quickly.
Rich Savage: Can you talk about CloudBees role in supporting the Jenkins Project?
Brian Dawson: Yeah, I would love to. I'll start first with the Jenkins Project because something we're really proud of. While the Jenkins Project is an open source project, it has a separate community and governing board. Actually, it's under the Linux foundation, now being run under the continuous delivery foundation. Yet, we are still major contributors, we contribute something to the order of 85% plus commit and development activity. We have a number of members including the founder of Jenkins, Kohsuke Kawaguchi our chief scientist, on the governing board and we invest a lot of capital beyond those contributions into the development of Jenkins. So we bind that to... We're being less than modest in terms of CloudBees. We're a great sort of intersection between this powerful open source solution and enterprise and fed needs for an enterprise level software solution. We bring knowledge around this key project to bear to help the government use Jenkins to implement TI and CD in a secure and reliable way.
We are also, as I think you've heard above, we are working across government entities or federal entities, not only in providing the software, but also in providing services and best practices as part of those agreement and engagements. But also with working to get the different agencies together to connect and share information and best practices. What we'd like to help the government do is really implement and build the culture of collaboration that is so key to DevOps. And when I say a cultural collaboration, it's not just to say Dev collaborating with Ops, but it's actually one organization collaborating with another. It's the building of a community of software development and delivery professionals putting their heads together to come up with the best solutions for delivering software the best way. What we're doing, and I hope we continue to do in a big way for the government, is just that. Build that community.
Rich Savage: What's the main takeaway you want listeners to gain from this podcast?
Brian Dawson: So I think the main takeaway for me is if our listeners, as I assume, are in a government agency and at times you feel like you're looking at these cool things happening with software development and software development technologies across a wall and you can't reach them, know that you can. There are no rote really or fixed practices, there's principles and tenants, but no hard and fast rules for how DevOps, CICD and DevOps are implemented.
So you know what? When you see technologies and new processes and new practices developing that you would to see implemented in your organization, go ahead and take the chance, get started, think creatively. How can this approach to automation of quality or should security be modified or re-factored to be applied internally? And do recognize that it is... Both requires a culture of collaboration, experimentation and continuous learning. So don't be discouraged by or threatened by the fact that this is not something that you that get right, right away.
But instead, look at those practices, bring them in, re-factor, start implementing, and proving them out, and then adjust and improve as you move along. And as you arrive at more of a stable, proven solution, I also encourage you to take the time to socialize those successes with your peers, with management and other stakeholders in your organization because that's how you help move the needle forward is to spread the bug, spread the virus of the success of DevOps.
So, what'd I say final takeaway is, go ahead and take a shot. Bring things in, learn as you go, and then socialize and promote those successes so that together we can bring change forward in the software development and delivery in the government.
Rich Savage: Thanks for that, Brian. Where do you suggest our listeners go to learn more about DevOps information for government agencies?
Brian Dawson: Oh, well, I'd say we have a wealth of pages. I would recommend that you just start by going to a cloudbees.com. There's a resource center there where you... There are a number of white papers around DevOps and the federal agency, a number of articles around DevOps in general, as well as a calendar of events that we'll be running nationally and locally where you can come join us and learn more.
Rich Savage: Great suggestions, Brian. Thank you so much for your time and valuable insights and information. For our listeners, please check out Brian's suggestions and the resources on this podcast landing page and feel free to contact us at any time via email at cloudbees@carahsoft.com or call us at (703) 871-8570.