Over the waterfall to GitOps

One of the first steps on the journey to cloud native is transforming culture. This starts with embracing Agile methodology, followed by implementation of DevOps processes and eventually GitOps, as we explore in this extract from the recent e-bookMind the gap: bridging the skills divide on the journey to cloud native.

Most CSPs agree that culture, including governance and skills, is the single biggest obstacle to adopting a cloud-native architecture.

Traditional waterfall project management focuses on a linear progression, where one task or process needs to be completed before the next can start. This approach is time-consuming and costly, and it stifles innovation. It’s a major reason why it typically takes a CSP more than a year to develop a new service.

Adopting Agile methodology (see graphic below) is a completely new way of working that focuses on building cross-functional teams to speed innovation and service creation. This requires CSPs to find people who have the new project management skills and are adaptable and quick-thinking. Agile isn’t appropriate in every part of the business or for every project, but it is critical for moving to cloud-based and eventually cloud-native environments.

Agile’s assumptions

• Early, continuous delivery of software leads to happy customers
• Changing requirements are always welcome, even in late development
• Working software is delivered frequently (within weeks, not months)
• Business teams and developers work together every day
• Projects are built around motivated and trusted individuals
• Face-to-face is the best way to communicate
• Working software is the principal measure of progress
• Development is sustainable and constant
• Attention to technical excellence and good design are required
• Simplicity is essential
• The best architectures emerge from self-organizing teams
• Teams look for ways to be more effective and adjust accordingly

There are lots of Agile approaches, but many CSPs use a model made popular by Spotify, which organizes teams into “squads”, “tribes”, “chapters” and “guilds”. Vodafone Group follows this model and uses “very, very flat, non-hierarchical governance”, according to Dr. Lester Thomas, Chief IT Systems Architect at Vodafone Group. “We’ve learned doing this in the digital space…but we’re trying to adopt that software approach right into our network.”

Culture eats technology
UScellular began adopting Agile methodology about five years ago, and the company is implementing cloud-native applications wherever they make sense. During its shift to the new way of working, cultural change has been the most difficult obstacle to overcome, significantly harder than technological change, according to Kevin Lowell, the company’s Chief People Officer and former Executive VP in charge of IT.

The shift started with creating “a compelling why” – in this case improving how customers experience using UScellular services. The company replaced some waterfall processes with iterative Agile processes managed in scrums and implemented in sprints. The IT team also began meeting regularly with business stakeholders and educating them about how Agile works. Telecom Argentina is also embracing Agile. It is working with Red Hat to adopt a framework called Team Topologies to create a more efficient way of collaborating. The company is applying Team Topologies within its network division to create cross-functional teams that not only focus on evolution and operation of technological platforms, but also on creating and delivering services.

From Agile to DevOps
While Agile methodologies help to establish communication between IT teams and other stakeholders in the company, DevOps goes further by introducing an end-to-end software lifecycle that establishes a continuous flow of development, integration, testing, delivery and deployment.

Google’s approach to DevOps, which is called Site Reliability Engineering (SRE), has been widely adopted in telecoms. It provides the foundation for the ODA Canvas, and it’s how Vodafone Group is implementing DevOps.

Vodafone is a cloud-native pioneer. For the past several years, the company has been transforming into a platform provider, using what it calls a “telco-as-a-service”, or TaaS, strategy. Vodafone is becoming a software company on its quest to become a techco, which includes hiring 7,000 new software engineers to add to the 9,000 the company already has. A key driver for embracing a cloud-native approach is “moving from our millions of human customers to billions of things”, says Thomas.

Instead of offering just four primary services – fixed voice, broadband Internet, mobility and TV – he envisions using 5G network slicing to support thousands of IoT services per vertical market. “Unless we can drive this through software-driven approaches and automation, we’re not going to be successful,” he says.

From DevOps to GitOps
The problem with DevOps, however, is that most CSPs aren’t developing their own software; they buy solutions from vendor partners. As Omdia’s James Crawshaw, Principal Analyst, Telco IT & Operations, notes in a research report, this makes it difficult for operators to create CI/CD pipelines that cut across organizational boundaries between CSPs and suppliers. To address this, CSPs “have adapted DevOps to their needs and created GitOps, which they use to take third-party applications and deploy on their own platforms”, Crawshaw explains.

Philippe Ensarguet, Group CTO at Orange Business Services, recently explained that GitOps requires continuous integration and continuous operations, or CI/CO. This means moving away from a prescriptive way of implementing operations to a declarative approach that supports full automation.

What is GitOps?

“If you rely mainly on the prescriptive approach, the day you want to move into production and scale up the number of applications you implement…you have to manage it purely with humans, and you hit the wall on scalability,” says Ensarguet.

William Caban, Telco Chief Architect at Red Hat, sees GitOps as foundational to the concept of zero-touch, zero-wait and zero-trouble services, which will be orchestrated end-to-end in autonomous networks. “This is exactly what GitOps is about: eventdriven, intent-based networks,” he says. “It becomes the operational model for architectures based on the ODA and autonomous networks.”

CSPs must hire software and automation skills for GitOps. They also must reskill network experts such as radio access network (RAN) engineers to work in CI/CO teams, so that everyone is using common terminology. Some operators are going even further by creating centers of excellence (CoEs) where cross-functional teams from business, network and operations collaborate. “In GitOps, it is also necessary to codify team members’ knowledge, so that even as people move around or leave the company, the software development and operations lifecycle processes are not disrupted,” Caban says.