• Will the telecoms resilience baby be thrown out with the cloud-native bathwater? Many telecoms experts worry that it might
• Now, a new(ish) advance on DevOps, dubbed platform engineering, might part-solve the problem by creating an internal developer platform to integrate the tools and technologies required for full lifecycle management of applications
• It’s supposed to free up developer time and enable a more efficient cloud-native culture, but does this solution have gaps of its own that might limit its appeal?

This year’s TelecomTV Cloud Native Telco Summit heard a ringing affirmation of the cloud-native approach for 5G. The strong consensus was that cloud native was clearly here to stay and will grow in importance on the road through 5G standalone to 6G and beyond.

“If we’re going to reach the cost-savings and service capabilities that 5G and future G promises, we have to have cloud-native solutions,” said Warren Bayek, vice president of technology at Wind River, speaking in the opening session of the summit. “If you don’t want to add new services, then maybe it’s not needed, but I think it’s essential for reducing power usage and improving customer capabilities,” he added.

According to Dell Technologies’ Leon Taiman, “It’s a competitive environment and we have to take advantage of cloud native. Plus, most of our customers have already embraced it to accelerate their own digital transformations, so there really isn’t any alternative… it’s table stakes for service providers,” he claimed.

But not everybody at the summit (and participating online) was ready to swallow the full cloud-native enchilada – public cloud, DevOps and all – without a little pushback, indicating that more discussion and more work may still be required before telco cloud native wins full-hearted support.

For some, cloud native as currently formulated, is emphasising the wrong imperatives and needs more thought. Laurent Leboucher, group CTO and SVP of Orange Innovation Networks, argued in a TelecomTV interview that cloud native isn’t just a tech thing, but ultimately a way for telcos to transform their businesses. So it had to be instrumental in helping them move to a “horizontal model with a common platform and common tools,” enabling them to more easily interact with each other and federate services, and build application awareness. Leboucher said he’d like to see a debate to produce a common set of practices. “We don’t want to reinvent the wheel, but for telcos [cloud native] is not about functions, it’s about end-to-end services. And it’s not a question of infrastructure, it’s a question of operating model,” he explained.

In summary, many participants argued for parallel developments, such as more action on common practices, to make cloud native more fit for telecom purposes.

Reservations such as these are not new. The telecoms technical community has always bridled at the encroachment of IT technology where it was seen to clash with telecoms best practice. The arrival of internet protocol (IP) in the 1980s, for example, was certainly not welcomed by all in telco land, mostly because the qualities that made those networks initially popular with end users made them difficult to manage, police, quality assure and monetise. 

In particular, the non-deterministic nature of the open internet made service quality difficult to guarantee – always a ‘no-no’ for telcos anxious to offer quality of service to their valuable and unforgiving corporate customers. More recently, virtualisation and cloud have also experienced telco difficulties, mostly because they too were sometimes difficult to integrate and were prone to failing key telco quality and reliability thresholds. Essentially, the ‘suck it and see, and if it doesn’t work roll it back’ approach is often viewed with distrust.

In fact, network function virtualisation (NFV), the immediate predecessor to cloud native, failed when it (or rather the companies promoting it) attempted to mount a challenge to hardware-based telecoms network infrastructure with trials that didn’t turn out well. That resulted in a major reset with cloudified virtualisation slickened-up with orchestration, an ability to scale out, and other software enhancements. Cloud native subsequently emerged to lead the charge on next-generation networking.

But despite (or perhaps because of) today’s general acceptance that cloud native is now the only option, some network experts now worry that its adoption, along with a forced diet of network openness, is leading telco software teams to choke on the plethora of new tools and technologies: The resulting cloud-native complexity, it’s thought, might be a stretch too far for already overburdened in-house technical talent.

This is an issue TelecomTV has already dwelt on when Vodafone CTO Scott Petty was enlisted as co-host for the DSP World Leaders Forum to discuss the transition from telco to techco. Petty made the argument that a future built around digital services provision required telcos to drop some of the outsourcing they had pursued in the preceding decades to concentrate on bolstering their in-house engineering talent. Only by being right on top of their software engineering game, he claimed, could they hope to meet their DSP ambitions.

At first sight Petty’s rallying cry might have been part-answered by the emergence of another buzz-phrase, platform engineering, which can be seen as applying corporate or team structure to the effort to foster collaboration and ongoing software improvement between development and operations teams.

According to Hasan Jafri, VP of platform engineering at Telus, platform engineering is a set of guidelines introduced as an evolution of DevOps which, he said, had not scaled very well. Platform engineering was required as a next stage to “create a broader spectrum of concerns beyond development and operations to establish building blocks, tools and best practices,” offering faster processes with higher reliability. “It’s about bringing feature-functionality releases on an equal footing with reliability changes and updates,” he added.

For Red Hat chief architect Fatih Nar, platform engineering is about lowering complexity so that “developers can come and use the platform that I have built with tools, such as automation, CI/CD, security check and lifecycle management, hidden inside so that the applications can be built faster and leaner.”

Fatih’s comment highlights an opportunity for players with the necessary scale, resources and talent to build and maintain a software engineering platform for others – both application developers or telecom peers.That might help telcos not endowed with sufficient scale, capital or in-house software engineering skills, to make the decision to sidestep the platform engineering question entirely by adopting a pass-through-applications approach using other providers, instead of trying to support application delivery directly.

In this respect, Colin Bannon, CTO at BT Business, claimed the concept of the network as a platform [for others to use] is “the new paradigm that we’re working from,” during a live Q&A discussion on day two of the summit.

Bannon said that businesses today have their own DevOps and their own third parties, and what BT has learnt is that ecosystems and partnerships are supremely important. As a result, not only is the telco prioritising third-party application programmable interface (API) interactions on its networks but is working on “interworking and stretching our fabric into other fabrics.” 

He also noted that business customers are developing applications that need an ability to “reach in and take components out of our network APIs and enrich the services that they are doing for their customers.”

With all this fabric stretching and interworking becoming at least practically possible, it may be that telcos with less inhouse technical talent are already looking to lean on others if the integration challenge within cloud native looks too great. If so, this lends support to Beth Cohen of Verizon’s belief that, while there are signs that platform engineering is taking off beyond telecoms, it is not likely that many telcos will follow. “The industry’s changing… we have great skill sets for designing, developing and operating networks but we’ve never been great at the applications and I don’t see that changing,” she said.

That’s not to say that DSP-oriented telcos won’t adopt platform engineering for all its advantages but, given its difficulties, it could be that the smaller telcos will look to benefit from platform engineering via their ecosystems, rather than investing in it themselves.

- Ian Scales, Managing Editor, TelecomTV