Cloud Native Users Struggle to Achieve Benefits, Report Says

For nearly all of the 82% of organizations that have adopted a cloud native approach, the shift hasn’t fully delivered on its promise, according to a new survey.

Of those organizations that have “gone cloud native,” 95% reported that challenges are preventing them from seeing the full benefits of cloud native development.

Among the top challenges: adapting legacy processes to the cloud (cited by 46% of cloud native adopters), training their development teams (also reported by 46%), and automating processes like testing, deployment and monitoring (44%).

Those challenges are having knock-on effects, the survey indicated. Users are encountering issues around security, tool sprawl and cultural difficulties, including poor collaboration between developers, security and operations.

The online survey, conducted in September by Foundry, a wholly-owned subsidiary of IDG, for UST, a digital transformation services company, sampled 100 IT professionals and executives.

Respondents were employed in IT, or executive management roles, at large enterprises that are testing, piloting or adopting cloud native development approaches and tools. Nearly half were from the C Suite, with senior engineers and IT managers making up the rest.

Defining Cloud Native

Though the sample size is small, the survey nevertheless highlights some interesting trends, and some of the challenges involved in transitioning to cloud native development.

The study's findings should be considered in this context: the researchers used a noticeably broader definition of "cloud native" than is accepted by bodies like the Cloud Native Computing Foundation.

Cloud native is perhaps suffering from an increasingly wooly definition—what software developer and author, Martin Fowler, refers to rather brilliantly as ”semantic diffusion.” As Holly Cummins, a senior principal software engineer at Red Hat, told The New Stack, “I’ve often thought we just use cloud native as a synonym for ‘modern and nice,’ or ‘built in the 2020s.'”

That said, what the survey highlights is interesting — in particular the widespread use of low-code/no-code tools, with 57% use in some industries, and strong interest in generative AI.

The latter is perhaps unsurprising, given where we are in the AI hype cycle, but it is striking to see low-code tools getting this level of adoption. Perhaps this is indicative of how much better the current generation of low-code tools is when compared to their predecessors, as noted when we looked at WS02's Choreo.

What’s Motivating Cloud Migrations?

The majority of survey respondents cite cost efficiency and business agility as their primary drivers for migrating to the cloud. Scalability also scored highly.

This chimes with my own experience. As Anne Currie and I noted in our book, “The Cloud Native Attitude,” some combination of speed, scale and margin are the most common reasons why firms migrate to the cloud from their own data centers. Interestingly, this survey also highlights the more cultural aspect of improving collaboration between ops, developers and SREs, with 37% of firms citing this.

The survey participants cited the following level of adoption of various technologies associated with distributed, cloud architectures:

• Sixty percent  of responders have adopted microservices in one or more areas of their application environment
• Fifty-five percent said they were using serverless.
• Just under half (49%) have also adopted Kubernetes in one or more areas of their application environment, with a further 41% evaluating, or planning to evaluate, the container orchestration behemoth.

Technical Challenges with Cloud Transformations

Microservices and serverless, when correctly implemented, mesh well with the goal of increased business agility. However, to do this, you need independently deployable units which, in turn, means correctly defining the service boundaries — an area that many people struggle with. If you end up with a situation where your CI/CD pipeline has to deploy many, or all, of your microservices together, you’ve likely not gained anything.

If you do get the service boundaries correct, you are able to build new functionality faster and gain strong horizontal scalability, but at considerable cost in operational complexity. This complexity saw firms like Netflix and Facebook build their own observability tooling, later made more widely available through both open source and pioneering vendors like Honeycomb.io.

In the survey, we can see this challenge reflected in the 31% of firms who noted a longer time to detect errors and the 29% who mentioned reduced visibility/observability in the application environment — an issue more likely to be cited by larger enterprises (defined here as those firms with $10 billion or more in revenue).

At 45% of enterprises, the scope of security responsibilities has increased for developers, presumably as a consequence of adopting a ”shift left” approach, with those at larger enterprises more affected.

A corollary comes from a 2022 report from the Shadowserver Foundation,  which claimed that more than 380,000 Kubernetes APIs around the world were exposed to the public internet. This reflects the growing complexity that developers face. Distributed environments increase the attack surface, and lack of visibility compounds the problem.

Among the other top pain points cited by development teams in the UST survey:

• Complexity/tool overload (43%)
• Poor collaboration with IT Ops and/or SecOps teams (41%)
• Pressure to increase productivity without introducing risk (40%).

Too Much Choice?

It is a mistake to assume that if we give our developers more autonomy to choose the tools and languages they want, they will be happier and more productive. In my experience, developers often prefer it if those choices have been made for them, provided they are able to make different decisions if their particular demands require it.

“As well as shift left, we should be looking at shift down,” said Cummins, of Red Hat. “Don’t just expand one engineer’s role; move some of the stuff that’s a bit boring, tedious and repetitive down and into our platforms through increased automation and improved curation. This way, we benefit from higher value platforms rather than allowing these technologies to become an extra burden.”

Carl Coryell-Martin, a senior director at Cloud Advisory, UST, echoed this sentiment, suggesting that many organizations in the survey aren’t implementing platform engineering — or not implementing it correctly.

“Kubernetes, I think, is very dangerous when it is at the development team level,” he said, “You can see problems signaled in the trade-off between productivity and risk, and the increase in security workloads. Companies are not understanding, or investing in, the discipline of platform engineering.”

Investing in a Platform

This lack of investment in platform engineering is often a consequence of how funding works in larger organizations.

In a “Hacking the Org” podcast I made earlier this year with Syntasso COO Paula Kennedy, we touched on a few antipatterns, such as when the money resides with the product team and the platform team ends up being starved of resources. Kennedy suggested that this came about because “platform teams are just seen as another infrastructure cost.”

Coryell-Martin echoed this idea, telling The New Stack that, “Platform engineering is difficult to pay for because it is a new capability that is expensive to develop. A typical business customer would prefer to spend 10 percent more on building their app, than pay for the development of a platform.”

Moreover, he added, “Although the benefit of effective platform engineering is spread across all business outcomes, it’s only effective if you can change how teams are working.”

One piece of advice he offered was to build a proof of concept at the individual team level. This allows you to show a team that is able to ship software much faster and at much higher quality. Then, Coryell-Martin said, “you need to have a conversation with the CFO and CIO, or CTO, where you talk about the business benefits you can get if you ship higher quality.”

I’d add that as developers and software team leads, we also need to be better at putting our arguments in business terms. There’s no point in trying to persuade a business sponsor to invest in a platform, more automation, or pay down technical debt, if there isn’t a clearly defined business benefit to doing so.

Cloud Native Culture

Another issue Coryell-Martin highlighted: “Many obstacles to success are entangled, and to realize the transformative outcome of cloud native development, you need to solve them all. It isn’t a case of, ‘I solve one and life gets 10% better, and then I solve a second and life gets another 10% better.’ Instead, each one makes life about 2% better, but when you solve the whole set of 10 things, your life gets 100% better.”

That set of things includes cultural aspects as well as technology. Cummins has gone as far as to argue that, “Cloud native is about culture, not containers.”

The new survey’s results underscore that, Cummins said. “Cloud native is hard, and you have to think about the people,” she said. “While some of the challenges were technical, so many were about people not having the skills, or that existing business processes weren’t fixed as much as they had hoped. So, if the motivation to move toward cloud native was agility, those technologies alone didn’t improve collaboration, which then remained a sticking point.”

This can be true even when cost is the main motivator, because so often what drives cost up is a lack of effective collaboration.

Cummins reiterated that it is really important to think about which problem you are trying to solve: “If you charge in and hope to improve agility, it won’t help.”

Successful collaboration requires you to have strong psychological safety. “A prerequisite for a successful cloud native transformation is that people have to trust the organization,” Cummins said, “so staff aren’t spending all of their energy trying to protect what they have.”

Likewise, people will be reluctant to tell you things if they think that jobs might be put at risk. “I’m not going to tell you about an inefficiency if I think my friends are going to get laid off, because you’ll need less staff when you fix it,” Coryell-Martin said.

In any large transformation, you also run the risk that your IT staff will grow more skilled and valuable — and then will leave for more enticing opportunities.

“I’ve run into situations so many times where a company would be transforming, and then their best people would be evaporating out of the company,” Coryell-Martin said. Some attrition is inevitable, but you need to make sure that you are raising pay in line with market value.

This all sounds rather negative. But, Coryell-Martin said, facing the challenges of a cloud native transformation is worth it for many organizations.

“It’s possible with cloud native to create a set of working relationships, team structures, platform engineering tools and capabilities that result in 10x better outcomes,” he said. “The teams are more satisfied, their business customers are much happier because they are shipping better software, and their control people are more relaxed because it is safer.

“There isn’t a trade-off between productivity and risk if you are managing the risk in the platform, and removing most of it from the team layer. A better world really is possible.”