Anyone who predicted that 2017 would be the “Year of DevOps” has proved to hit the nail on the head. More enterprises than ever before are ditching their old methodologies, leadership philosophies, and legacy processes in favor of DevOps to achieve speed and agility in today’s constantly evolving technology landscape. In fact, a survey of 700 IT professionals conducted earlier this year found that 50 percent of companies polled were integrating DevOps, or had already done so this year. We are well beyond critical mass.
[ Get wisdom from your peers on leading DevOps teams: Culture, metrics, talent, and more. See our resource DevOps: The IT Leader's Guide. ]
So what have we learned? If you are early on your journey, you may be interested to know the biggest lessons learned by companies who are well down the path with DevOps. We’ve rounded up seven of these below. If you are more experienced with DevOps, feel free to share your biggest lesson learned this year in the comments below.
Look for a broad skill set
Flint Brenton, CEO, CollabNet: “DevOps brings together siloed, disparate teams across an enterprise, which means we will want to hire individuals who are adaptable and open to change. Hiring folks who fit into a company's DevOps culture may mean looking at those with a broader or well-rounded skill set and who like to think outside the box. Workers of all ages and backgrounds have the opportunity to reinvent themselves in this DevOps framework, and this will only work to benefit tech organizations looking to hire forward-thinking team members.”
Correct issues with software architecture, delivery, and DevOps measurement
Anders Wallgren, CTO, Electric Cloud: “It's become clear that in addition to the ‘big three’ DevOps mantras of culture, process, and tooling, we also need to spend time and resources on some very concrete issues when improving our DevOps efforts:
- Architecture: Software architecture matters. Loosely-coupled architectures are highly correlated with successful DevOps outcomes. Monolithic architectures are correlated with high friction in the software pipeline.
- Measurement: DevOps is a continuous improvement game. We can't reliably and repeatedly improve that which we can't (or don't, or just won't) measure.
- Software Delivery Pipelines: Manual steps in the software delivery pipeline are correlated with delays, errors, and rework. None of those are correlated with good DevOps outcomes.”
Enable developers to have operational control
Richard Li, CEO, Datawire: "One of the biggest lessons we learned in 2017 is that DevOps is absolutely essential as organizations adopt cloud-native practices. Developers who are building cloud-native applications are enormously more productive when they have (some) operational responsibility over their service. For example, the developer of a service is better equipped to specify the resource requirements (memory, CPU, etc.) for a service, versus delegating that responsibility to a dedicated operations engineer. One of the key technical challenges that organizations face as they adopt cloud-native technologies such as Kubernetes is how to enable developers to have the right level of operational control."
Not just for IT; Not just about tools
Sacha Labourey, CEO, CloudBees: “One lesson learned is that DevOps is not just for IT. While there is certainly more of a focus on DevOps when it comes to IT, many of these principles apply to non-IT teams too. The principles are easily applied, because DevOps is more about culture, versus technical skills. DevOps is not something that is a one-size-fits-all approach, and as organizations realize what works best for them they should extend that knowledge to non-IT teams. Having transparent and clearly outlined objectives, goals, and key results for the overall team to be aligned around helps to ensure success.
Another lesson: DevOps is not solely about tooling. In fact, there is technically no such thing as a ‘DevOps tool,’ so choosing the toolchain that you are betting business-critical operations on is a very important, strategic decision. Choose wisely, build in flexibility and know where you are going. As each company will adopt and implement DevOps differently to adapt to their infrastructure and cultural needs, the selection of technology will also be dependent on each company’s goals and objectives. Being open-minded to change is the first step. To maintain a competitive edge, regularly conduct audits and assessments of what the current and future needs are for employees to succeed. Understand where there are still pain points and know what you need to implement to continue on a path of rapid growth.”
Build in security from the start
Dan Timpson, CTO, DigiCert: “Security integration in DevOps is happening. Smart companies are learning that if they bring security into the process from the beginning, they can save money and meet deadlines, and avoid security finding bugs at the last-minute that could halt projects. When integrating, DevOps can take advantage of automation of basic and important security programs such as digital certificates, which provide authentication and encryption. Using APIs, we can build encryption and authentication into dev workcycles. This facilitates successful continuous development, and prioritizes security appropriately as a business imperative.”
Don't skimp on processes or tooling up front
Gordon Haff, Technology Evangelist, Red Hat: “Everyone's gotten the message that DevOps accelerates the pace at which software gets delivered and updated. But less effective DevOps teams have found that they're trading off reliability and recovery times to gain that speed. DevOps leaders are learning that they need to invest in establishing the right processes and implementing the right tooling up-front if they're going to have both agility, quality, and security.”
Build up team knowledge around expected changes
Jesse Lakes, CEO, GeniusLink: "The past year was a busy one for DevOps at Geniuslink. We completed many challenging projects throughout the year, the most extensive and challenging project still inflight – transitioning to containerized deployments to support a standalone dev environment buildout. At this point, I think it’s fair to say I underestimated the resources and timeline required as well as the team disruption for the project.
Unfortunately, developers saw significant productivity impacts due to suddenly needing knowledge of Docker/Nomad/Consul, changes to day-to-day process such as application build/deploy, as well as changes to actual code/config they work with. These impacts were above and beyond those originally expected from the Ops side of things. Anyone taking on a similar book of work should carefully consider building up team knowledge on new technologies and working in process changes slowly over time to minimize the impact of the actual migration.
Would I do it again? Sure. Would I do it differently? You bet! I’m still learning – which is a good thing! Going forward into 2018, I’ll be sure to realistically assess the impact DevOps changes may have on my Dev/Test team, and you should too."
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.
