DevOps is often described as a journey, a movement, or a culture. DevOps isn't just a set of tools that IT leaders can buy and put into practice the next day. It requires careful planning, continued attention, and a purposeful approach, such as creating a center of excellence or updating your DevOps team model.
No matter where you are on your journey, it's always helpful to hear from those who have been there, done that, and learned along the way. We asked seven IT professionals to share their DevOps lessons learned and best pieces of advice for others who may just be getting started. You'll see that not all of them see DevOps the same way. Some disagree, for instance, on whether you should have a dedicated DevOps team. Who's right? That depends on your company's situation and goals. Let's delve into their advice:
Grassroots adoption is key
Chris McFadden, VP of engineering, SparkPost: "We have come a long way on our DevOps journey, especially since our on-premises focused days when we would have a release every six months. Now we deploy changes continuously to production - multiple times a day. We thought we might have to hire external talent to help with our DevOps transition, but were surprised and proud of the way our existing staff stepped up to solve the problems and get us to where we are today. This was in large part to strong support from top level management at the company.
Our lessons learned: All major transitions take much longer than expected. Be patient and look for steady progress. It is not practical to stop everything else the team is doing and focus only on the future state. It is important to make incremental progress. Avoid bringing in consultants or creating a DevOps team. DevOps is a way of doing things, it is not a job title nor a tool. Everyone in the organization needs to adopt a DevOps way of thinking. So while top-level direction, vision, and evangelism is important, equally important is a grassroots adoption by the staff who believe in the change. Do not get attached to any particular tool. Using a particular tool or deployment method or process should not be the goal. The goal is to continuously deliver value and create an awesome customer experience."
[For more DevOps lessons learned, read our Q&A with Mike McNamara, CIO, Target: Target CIO explains how DevOps took root inside the retail giant]
Focus on value
Matthew Boeckman, developer advocate, VictorOps: “ A thing to be watchful for is that your DevOps team and your IT team don't lose touch as their tooling and approaches diverge. The potential for a new Ops/Ops schism similar to the old Dev/Ops schism is fairly high. The advice I would have loved and I would offer to others is to approach DevOps adoption in traditional IT with a keen eye for the value delivered. Avoid dogmatic adoption of DevOps for all things, and find the right balance between DevOps and traditional practice for the reality of your team.”
It's not for everyone
Carlos Melendez, COO, Wovenware: "Create a separate DevOps team. It’s critical that any company transitioning to a DevOps environment has a separate DevOps team that coordinates with the software development team. Developers can provide the critical testing function and perform automatic testing, while the DevOps team makes sure that the entire DevOps process – from updates to testing to user feedback is completed and shared among departments.
Another thing to consider in DevOps is that it never really ends. Unlike major software upgrades of the past with a clear beginning and end, in a DevOps environment there is a constant cycle of incremental updates, testing, and continuous user feedback, which then flows back into new updates.
Finally, know that DevOps is not for everyone. While many enterprises are embracing DevOps, it’s not something all companies should be jumping into blindly. Desktop or legacy apps are harder to move into a DevOps environment, so companies with those types of applications might want to first consider transitioning to web-based apps."
Tailor your approach
Kofi Senaya, director of product, Clearbridge Mobile: "DevOps is a culture, not a department. Many people get this wrong. Companies that establish a DevOps department won’t solve the issues DevOps is supposed to address. If you just have a department, you don’t have true DevOps.
DevOps is like all processes and practices. It cannot be a cookie-cutter implementation. Whoever is taking on the task of DevOps needs to understand that the product they're building and the skill sets they have internally. They need to take the DevOps fundamentals and tailor it to that particular environment."
Don't take security for granted
Barton Nicholls, senior solutions architect and head of DevOps, Cohesive Networks: "While DevOps is great for shortening the time to create and deploy code, standardizing the processes can still take systems-level requirements for granted, such as security. If security is not a consideration during development, it can slow down the project later if security needs to be added in for larger systems."
Eliminate roadblocks and establish metrics first
Amit Gupta, associate vice president, Ness Digital Engineering: "Organizations tend to start thinking of deploying tools and technologies before understanding the fundamental issues that may need to be corrected regarding effective agile development or engineering practices. If we properly dissect what goes into effectively establishing DevOps, there are five layers: Collaborative culture; efficient agile development process; strong engineering practices and automation; continuous delivery capabilities, and security. For organizations aiming to improve time to market, they must first correctly identify where within these five categories their current issues lie. Within these layers, organizations must determine if they have issues that hamper team collaboration and process efficiency.
Also, an organization needs to determine parameters it would like to establish to track progress towards successful DevOps adoption. The key is to have a few, simple metrics that truly reflect value to the end customer, including production deployment frequency; average lead time for a production change; average production recover time; and change failure rate in production. A true measure of successful DevOps adoption is an improvement in all these parameters over time." (See our related story: DevOps metrics: Are you measuring what matters?)
Ignore the network at your peril
Jim Frey, VP of strategic alliances, Kentik: "My advice for DevOps engineers is that they must be network-aware. The end objective of any DevOps project is to successfully deliver an application to the end user who will consume it. That involves the network: Ignore the network at your peril. A good DevOps engineer will recognize that you have to account for the network in your design, your planning and your testing."
