Getting DevOps right
DevOps

Getting DevOps right

One of the key findings of GitLab’s 2018 Global Developer Report is that “organizations that have adopted DevOps are more likely to deploy on demand and prioritize automation than those practicing Agile.” No longer a “nice to have” to improve workflow for developers and software professionals, DevOps is increasingly a must. In GitLab's poll of over 5,200 developers, CTOs and IT professionals, two-thirds called DevOps a “tremendous time saver” in the development process. Close to 30% plan to invest in DevOps for 2018.

In a survey conducted by New Relic last year, a high adoption of the DevOps “mindset” resulted in much higher satisfaction levels around key metrics like communication between teams. In fact, when asked which area of their organization was most improved after adopting DevOps, 23% to 57% of respondents answered communication. “Effective communication within teams fosters good working relationships and a more creative culture which, therefore, is a key basis for DevOps success,” says Eveline Oehrlich, Director of Market Strategy: EMEA at New Relic.

 

Making the mind-shift

Getting DevOps right, though, is tricky, and use of agile and DevOps is not mutually exclusive; they can work well together. Chip Childers, CTO of Cloud Foundry Foundation, stresses that, ultimately, you cannot buy DevOps. “It’s not something that is a tool or a product, even with plenty of companies trying to sell it to you. DevOps is about a cultural shift, and it requires implementing the technologies, tools and products that are actually a fit, in the context of that culture, between new processes and existing systems.”

For Mark Pundsack, head of GitLab, culture can be a roadblock to successful deployment of DevOps, but it is vital to get right. “It’s hard to get Dev and Ops to work harmoniously in a cross-functional way. And, that issue can be compounded by tooling. Disjointed toolchains lead to disconnected processes and barriers to communication that get in the way of working together – the crux of DevOps,” he says.

Peter Betting, VP and Global Leader for DevOps Community, Sogeti at Capgemini stresses the importance of the Ops part in the overall DevOps process with a focus on deployment and maintenance, very often in a cloud environment.

“An Ops engineer should be integrated from the start of the project to ensure the correct deployment of the products developed in each sprint,” he says. “Deploying a product in production does also mean delivering the automated scripts and the necessary specifications next to the code, this is to ensure the right level of maintenance and making it possible to rapidly restart a sprint to work further on the product in question.”

Jon Topper, Principal Consultant at The Scale Factory, emphasizes that DevOps is a way of working, where developers and operations engineers work together on deploying software.

For Topper, the main challenges when trying to bring these two disciplines together are finding ways to bring teams together, who may not always use the same language or have had competing ideas in the past. “It’s not a case of deploying DevOps, it’s a case of enacting it,” he says.

 

Phasing in

With that in mind, Andy Hawkins, VP of Technical Operations at SignalFx , says there are three key phases of adoption.

The first part is about setting up some teams as labs and experimenting with DevOps methodologies and practices. “Acquiring data and metrics are critical capabilities which are necessary but often overlooked -- if you don’t measure it you can’t manage it,” he says.

The second phase for Hawkins is enabling those DevOps teams more broadly. “This is good, but many organizations don’t yet have the centralized controls in place to monitor their work. Scope is important; organizations often select products which are too complex initially. They should instead build something meaningful but don’t try and boil the ocean,” he says.

Lastly, he says it is about organized enablement, which has the controls and enablement built into the workflow. In this phase there should be an emphasis on teams adopting capabilities which include automation, testing and monitoring.

When companies consider DevOps, Pundsack adds they should not just think about Development and Operations. There are many teams involved in delivering great software, including Product Managers or Business folks, and Security specialists. A great DevOps culture will break down the walls between all of these groups.

Pundsack says companies should consider applying “shift-left” to DevOps, which means shifting tools and knowledge to earlier phases in the development process. “For example, don’t wait until the feature is nearly finished before doing a security audit, or worse, waiting until it’s been in production for several weeks. Do automated security testing from the first code commit.”

Pundsack adds that the first step to getting it right is to appreciate and address the inherent cultural challenges of teams working cross-functionally (Development, QA, Security, Operations, etc.). “Often, their goals and performance metrics are inconsistent, so before diving headfirst, ask yourself whether or not you’re rewarding the team for shortening end-to-end cycle times (DevOps) instead of sub-optimal goals usually found in functional silos.”

Secondly, he says, look closely at your tools and toolchains. Often, organizations have cobbled together a mixture of point solutions requiring integrations, introducing friction and overhead. “It’s important to simplify and standardize on the fewest number of different tools in order to achieve economies of scale. If you can go from ten tools to five or from five to three or even one, you’ll undoubtedly make your teams more efficient,” Pundsack explains.

Naveen Kumar, Vice President: Technology Innovation at Aricent, says companies wanting to implement DevOps need to consider:

  • Responsibility: Some companies assume that DevOps is the responsibility of a centralized team. This might work well at the onset or for a start-up, but certainly not on a continuous basis for businesses.
  • Silos: Never “silo” DevOps. It needs to be pervasive so development teams across the enterprise can adopt DevOps by default. This is critical if you want to scale your deployment.
  • Quality: Quality checks need to have a schedule and be regimented as software release toolchains can be declarative and policy based. It is important to constantly be aware of quality and the right levels of code in use
  • Security: Conduct robust security checks and tests to automate the releases in a continuous manner so they can be undertaken irrespective of the underlying DevOps tools
  • Lack of transparency:  Avoid keeping DevOps as “exclusive”. The DevOps process and activities should also be measured and made transparent to every stakeholder
  • Culture: Fostering a culture that tolerates experimentation where new things are tried out is essential. This changes the status quo of established norms and process.

 

Accepting automation

Kumar adds that while automation is the corner stone for DevOps, it can also be a major challenge. “The scripting of infrastructure is a must for Continuous Integration and Continuous Delivery. Automation helps to deliver efficiencies, transparency and visibility to the overall software delivery lifecycle. It also provides confidence to all stakeholders as it can eliminate error-prone manual tasks,” he says. 

Automation of testing is a must to cope with accelerated releases as testing volumes increase many fold. Automation requires encoding of manual tasks, demands investment, and getting it right can take time.

He says the greatest challenges are finding multi-skilled developers who understand infrastructure to automate, sourcing the right technologies, and trying to automate legacy platforms which do not fit into the standard configuration model.

Ultimately, it is also about bringing together related ideas. Rather than being in opposition, DevOps and Agile are often touted as being complementary. Using them together though can create greater complexity, but as Pundsack notes, they share a common goal of reducing cycle times and getting faster feedback.

“Agile helps development teams to break down work into smaller user stories that they can quickly build, whereas DevOps helps teams deliver working code to users. Simply put, Agile without DevOps isn’t complete. Instead, companies should bring the two together and enable teams to collaborate, integrate, and deliver,” he says.

 

Security concerns

Eric Sheridan, chief scientist at WhiteHat Security, cautions that complexities with application security arise when organizations move towards Agile environments automating as much functionality as possible. “Because automation and/or Agile efforts are ‘top of mind’ for most engineers and information security practitioners, organizations are attempting to identify ways to integrate application security within their DevOps model,” he says. “To improve the protection of applications from vulnerabilities and potential attacks, the DevOps efforts must be extended to include information security to become DevSecOps.”

Eric Schrock, CTO at Delphix, says that DevOps teams have become experts in creating environments very quickly and running tests automatically, but these tests are often lacking in depth because they typically work on only a subset of data. In order to correctly model the production environment, DevOps teams need up-to-date copies of production data instantly, but moving the amount of data needed is a cumbersome task.

At the same time, Schrock notes, enterprises are faced with the increase in demand for data to be made available to more people (“data consumers”) in more places; they are also faced with the countering force of a finite number of people (“data operators”) and resources to execute the requirements to secure, deliver, and ensure data is always available.

“The friction between these two groups kills innovation in companies and prohibits enterprises from delivering application projects on time, reacting swiftly to market forces, and from running a true data-driven business,” he says. Schrock believes that by virtualizing data, companies are able to break through this data friction, transforming the DevOps process.

He adds: “To manage the challenge of data friction within DevOps, organizations need to bring together data operators that are responsible for managing data and distributing it across all environments with the data consumers that are responsible for using it to drive business performance, which is where the concept of DataOps comes into play.”

This concept embodies the idea that people, process and technology should be aligned in order to enable the rapid, automated and secure management of data. Its goal, according to Schrock, is to improve outcomes through the establishment of this collaborative platform. “All of this allows operations to focus on establishing and securing all the data sources needed by the project teams, without being buried under a pile of requests for access from all over the business. This can be achieved whilst developers are equipped with fresh and secure production data. The result is faster projects of higher quality, at a lower cost.”

 

Leading in

Leadership must be an important part of the implementation of DevOps. Hawkins emphasizes that the leadership structures applied by the DevOps visionaries must focus on autonomous teams rather than command and control structures; leadership is key.

“For companies who have historically outsourced there is a natural tendency to try and ‘buy in’ DevOps, but this is a fallacy. DevOps requires close business and customer alignment,” he says.

“Be cautious of trying to go too fast. Develop evangelists who command respect based upon their track record of delivering great products to your customers. Support and coach your evangelists to enable your teams. Measure everything and drive optimizations based on the data you acquire. Be prepared to course correct if the data indicates you have taken a sub-optimal route.”

For those willing to do the work, as Hawkins says, DevOps is most definitely worth the journey.

PREVIOUS ARTICLE

«A buyers' guide to ERP solutions

NEXT ARTICLE

Taxing technology: Why this African trend can pull back connectivity gains»
Bianca Wright

Bianca Wright is a UK-based freelance business and technology writer, who has written for publications in the UK, the US, Australia and South Africa. She holds an MPhil in science and technology journalism and a DPhil in Media Studies.

Recommended for You

phil-muncaster

How a Washington crackdown on Huawei could backfire for everyone

Phil Muncaster reports on China and beyond

dan2

5G is over-hyped and expectations need reining in

Dan Swinhoe casts a critical eye on the future

keri-allan

What can we learn from tech initiatives in the Middle East?

Keri Allan looks at the latest trends and technologies

More Like This

Our Case Studies

IDG Connect delivers full creative solutions to meet all your demand generatlon needs. These cover the full scope of options, from customized content and lead delivery through to fully integrated campaigns.

images

Our Marketing Research

Our in-house analyst and editorial team create a range of insights for the global marketing community. These look at IT buying preferences, the latest soclal media trends and other zeitgeist topics.

images

Poll

Should the government regulate Artificial Intelligence?