JAXenter: Who is leading the DevOps show? Develops or operators?
Eric Vanderburg: It depends on the company and the culture. One element of the culture that can be an indicator of leadership frame of reference is where senior management got their start. Those that primarily started out in the services space sometimes have more operations-focused leaders spearheading DevOps while those that started with a software concept more commonly are development focused. Frequently, DevOps leaders include the CIO, chief architect, director of operations, CIO, or director of software development.
JAXenter: The focus is slowly shifting from “What is DevOps?” to “Where do we start?” How do we answer the second question?
Eric Vanderburg: DevOps can begin from the ground up or the top down. Many successful DevOps stores started as a grassroots initiative. However, at some point, grassroots DevOps initiatives will need to have top management support. Likewise, top-down approaches will need to have the buy-in of those in development and operations for the change to be successful. Leadership provides the funding and direction, but cultural change requires a much larger percentage of the company to take place.
JAXenter: How important is it to incorporate security into DevOps (DevSecOps)? What are the benefits? Should it be a priority or an afterthought?
Eric Vanderburg: Security is vital in DevOps. Companies spend a great deal of time and money fixing security problems after the software has been released or close to the release date that could have been solved much cheaper and more efficiently had it been identified earlier in the software development lifecycle. Security should be involved in each stage of the life cycle to ensure that project requirements include requirements for security and privacy, initial code is tested for security issues, and deployments are performed in a secure manner, and configurations utilize security principles such as hardening, reducing the attack surface, least privilege, separation of duties, auditing, identity management, patch management, and many other core security concepts. Creating, managing, and securing applications is still a team effort and it requires a broad set of skills from different people to do it right. Whether you call this team DevOps, SecOps, or DevSecOps, the team must work together to accomplish the business objectives efficiently and securely.
JAXenter: How important is automation in a DevOps context and what are the areas where automation is really needed?
Eric Vanderburg: Automation is critical in DevOps and one of the driving forces behind further adoption. Automation can be used at each stage of testing the application, validating code, vulnerability scanning, deployment, the creation of testing environments, and many other areas.
JAXenter: Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?
Eric Vanderburg: Of course. CI/CD is not about just pushing out new features and functionality. New code must perform reliably as expected, produce the desired results, preserve data integrity, protect data confidentiality, and ensure customer privacy. Without testing, none of these can be assured.
JAXenter: Some companies are still struggling with DevOps metrics. What are the key metrics that matter and how can they enhance DevOps success?
Eric Vanderburg: Firstly, it is important to define metrics that you determine are crucial to success. I can provide some examples, but the best ones are those that you can directly tie to business objectives and reliably measure. Some companies create metrics but measure them ineffectively, and the metrics do not accurately reflect reality. Some important metrics to consider include the number of errors detected per volume of code, deployment time, build frequency, error remediation time, requirement discrepancy percentage, change volume, customer satisfaction, and performance.
JAXenter: How important is it to not skip steps in the DevOps transformation cycle? What are the steps that companies and/or teams usually ignore or underestimate?
Eric Vanderburg: Most of us learn early on that skipping steps is not a good idea. Skipping steps typically results in an error such as skipping a step in solving a math problem, research project, or a first date. You are far more likely to end up in a dangerous situation if you skip steps in DevOps transformation too. The steps are there because each phase builds on the one before it, receiving inputs from that stage, and refining the application. The two phases I see most often skipped are the planning and testing phases. Applications are still built, deployed, and maintained in some way, but teams, in a rush, to get a product out the door, skip the planning stage and jump right in or they skip the testing phase and go directly from development to operations. Skipping the planning stage results in missed requirements, more errors, rework poor coordination, poor project management, cost overruns, and security problems. Similarly, skipping the testing phase results in poorly performing software, missed requirements, bugs and flaws, security holes, and a very poor customer experience.
We do see game development somewhat combining prototyping with deployment to gain further enthusiasm for the product. Unlike a beta test, game development firms release a game to the community at a reduced price, but the game lacks features or contains bugs that the community evaluates and tries. New versions of the software are released to the community as the game works its way towards completion. Some might say that this skips a step. Instead, I would say that they are simply pursuing CI/CD. Each build is released to the community to use, and it meets their customers’ expectations. The game may never be complete as the community continues to offer new ideas for improvement which takes us back to digital transformation, not a skipped step. Skipping steps will only provide you with more headaches.
JAXenter: Do you think the abundance of DevOps tools have helped or slowed down DevOps adoption?
Eric Vanderburg: An abundance of tools adds complexity to the tool selection process. However, with this abundance comes diversity and the opportunity to address niche needs of DevOps consumers. It can be challenging to work through the marketing information and truly understand what differentiates DevOps tools so it is important for independent parties to evaluate and compare these tools so that DevOps consumers can make an informed, unbiased decision as to which tool is the best fit for their company, team, product, and customers.
JAXenter: There’s a huge demand for DevOps professionals. What skills do you need to have in order to tap into the perks that accompany the job description?
Eric Vanderburg: Communication remains the single greatest skill. DevOps is a team sport and that means that DevOps success depends upon the ability for team members to communicate.
Thank you very much!