Scaling DevOps Additional Considerations

DZone 's Guide to

Scaling DevOps Additional Considerations

Get started — progress, not perfection

· DevOps Zone ·
Free Resource

To gather insights on the current and future state of how DevOps is scaling in the enterprise, we asked IT executives from 32 different companies to share their thoughts. As we wrapped up our time together, I asked them, "What have I failed to ask you that you think we need to consider with regards to scaling DevOps?" Here's what they told us:

  • DevOps is not something every other organization has figured out. Most enterprise organizations are just getting started or are struggling with how to start. Don’t suffer from analysis paralysis.  You will never figure out every requirement, concern, aspect, technology option, or opinion.  Trying to get the solution 100% right before starting is the old IT way. You know you need DevOps. You know you need a DevOps platform combining cloud and automation. You know you need to service application developers. Get started with that. Start to build something and adjust as you go.  Don’t wait for all the answers before you start—learn as you go and continuously improve on providing better results.
  • The business is already in the fight. How urgent are they? Focus on outcomes over outputs. Ultimately it has to drive business value. That’s the area when you’re scaling, and you have to justify your initiatives. Make sure you’re not just measuring outputs, ultimately, it’s about the business outcomes. 
  • Plan for success!  Don’t be timid, and don’t underestimate the potential of a compelling DevOps capability to your organization, especially teams outside Dev and Ops. Seek to solve for broad use cases with flexibility and diverse platform support and expect not just the “expected” teams — the teams already pursuing DevOps practices and asking for more DevOps platform support — to jump on board but also teams and applications and projects that aren’t the obvious adopter but may need DevOps methodologies and automation just as much — or more.  Scaling beyond your initial demand is a problem that fixes itself if you’ve carefully and thoughtfully solved for real use cases in your business, as those use cases will find a home in your DevOps infrastructure and take root and flourish, and then word will spread.  You won’t be afraid to “sell” your capability even to teams outside of Development and Operations if you have the capacity to support them, and broad adoption is going to both justify your efforts to scale your DevOps systems but also make your organization better connected, more automated, and increasingly effective as DevOps mentality infects teams all over the building. So be optimistic and plan ahead for the obvious and non-obvious use cases. DevOps thinking might be part of your organization’s new strategic advantage, so make sure your scale expectations consider that exciting possibility.
  • Booking.com is running 1,000 tests every day. If the system observes a degradation of experience during rollout it will shut the feature off and alert the developer. The time between realizing a problem and turning off a feature is less than one second. They build using real-time data.
  • Make sure you change and adapt to the technology.
  • Understand scaling DevOps will not address the challenges companies are facing; instead, companies have to consider the way how they are approaching their challenges. DevOps is one of the methodologies that can help them to achieve it and at the end scale. Scale in an efficient, traceable, automated and maintainable manner. And scale with your organization and product portfolio needs.
  • When scaling a DevOps team, the team make-up and fit are paramount for optimizing outcome. A team where everybody consistently agrees is not a good thing. On the other hand, a team with constant disagreement would be an abject failure. In summary, DevOps supports teams that are in the business of learning. It attracts those who are compelled to put new skills into action, and when it’s working, it benefits everyone.
  • Startups are trying to survive. Automating a process may feel like a lower priority depending on where their startup is at with relation to handling specific customer’s needs. With many startups, having a roadmap has been put on the back burner; however, those startups inevitably discover that their customers like to see long-term plans for feature/function implementation, and if the DevOps team can only show a series of iterations labeled, “We’ll give it a go,” the customers will find another product with a mature roadmap.
  • Security needs to be integrated into ops and dev. Start with information and data security. Think about all the parts that happen when you make a product release and how to automate. 
  • DevSecOps is definitely the future of DevOps.
  • It’s addictive, once you start transforming your company and getting the metrics to see what going on across all your applications. Creating visibility focuses everyone on the job. When things are made public, they get fixed. Make security and DevOps transparent and visible.
  • Automation is a key aspect of DevOps that you can consider.
  • The challenge with DevOps is as we move forward into new environments, such as cloud and different architectures and bleeding into the edge, the DevOps approach will have to continue to evolve to adapt to new technologies. In addition, with the rapid deployment of applications, website and other data sources, how do we deal with all the data? Organizations in the IT space need to continue to apply DevOps to the data warehouse space moving forward.
  • Often the biggest hurdle to adopt new ways of working is organizational readiness — DevOps is no different. The best DevOps tools can’t work around an unwillingness to change the way people work. Education and training are critical to clearly define the benefits of going through this change and to avoid common pitfalls.
  • DevOps should be treated like any other process in the software development lifecycle. We need to reduce software developer aversion to it. Just as everyone does code review, DevOps should be as ingrained.
  • Why do we need to scale DevOps? Because existing cloud providers have failed to provide the right abstractions to minimize DevOps work. Our goal is to completely eliminate the need to scale DevOps by making it effortless to run and scale everything from static sites to the most complex stateful applications.
  • Like all important and transformative projects, don’t forget about why your team decided to scale DevOps efforts. As a team, determine the most important KPIs, set baselines, and see if efforts are bringing the improvements you were hoping for. If not, tune your process and keep iterating until it feels right. Share success stories with other teams to help inspire them to scale their efforts as well!

Here’s who shared their insights:


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}