Everyone wants to go cloud native these days. But what does that mean?
A truly cloud native application is one that is designed to perform well in a cloud environment. It’s one that takes the advantages and disadvantages of the cloud into account. Running an application on a public cloud or in a Kubernetes cluster doesn’t mean it’s “cloud native” if that application could run as well, if not better, outside of the cloud.
But there’s still confusion about the term. A survey of 1,000 developers and IT decision makers by software maker Lightbend found that a plurality of respondents (41.7%) ranked writing applications that specifically leverage underlying cloud infrastructure as the most important aspect of cloud native, but a majority picked the other two options: utilizing Kubernetes and containers (34.5%) or moving to a cloud infrastructure provider (23.8%). In other words, most respondents still prioritize where applications run over how they’re built.
"I think it starts with people misunderstanding the term," says Lightbend president and CEO Mark Brewer. "Many think that if you build your applications in the cloud first, you're building cloud native."
But just because you're building applications in the cloud doesn't mean they're taking full advantage of cloud infrastructure. A cloud native application should have the ability to automatically scale-up or scale-down, depending on demand. Users shouldn't have to wait for a DevOps person to adjust resources on a control panel. And an organization shouldn't have to pay for resources they're not using. "If you just run it in Kubernetes, you're not going to get any of the benefits you're looking for," Brewer says.
Getting the most out of the cloud also means tapping into the various special features offered by cloud providers, such as authentication or database-as-a-service offerings. "There are literally hundreds of services and offerings out there you can take advantage of, instead of building features yourself," Brewer says.
Another important aspect that cloud native development is enabling is continuous delivery. "It's better for developers if they can update a system in a rolling fashion," he says. That requires organizations to move away from traditional, monolithic applications developed with the waterfall approach, and move towards agile development and microservice architectures.
Brewer cites automation and abstraction as some of the key benefits of the cloud.
"Serverless will be the dominant way to develop business applications," he predicts. "It goes hand in hand with other cloud services. Developers will be like general contractors putting together pieces that have been built by subcontractors. Combining prepackaged services will remove a lot of work for the developer."
But the Lightbend survey shows that developers are torn between automation and configurability. A slight majority (52.6%) say they expect to move towards ever-increased automation; but 47.4% percent say that despite trends towards automation, developers will still need to focus on maintaining underlying systems. Meanwhile, 58.1% prefer frameworks they can configure and scale themselves over frameworks delivered as-a-service or consumed via an API.
Developers are particularly reluctant to give up configurability for automation, but managers are more keen on automation and serverless. For example, 66.2% of managers would prefer *aaS or APIs over configurable frameworks. But executives interviewed for the survey spoke with worry about vendor lock-in and wished for more portability between serverless offerings.
Brewer hopes Lightbend can help with the concerns of both managers and developers. For example, Lightbend's Akka Serverless offering aims to make cloud functions more portable.
He admits the tension between automation and configuration will probably never go away. "There will always be a need for completely configurable minutia, there will be use cases where that's a requirement," he says. But here too he hopes that Lightbend's solutions help provide automation in most cases, but also configurability when you really need it.
"Developers won't give up what they've been using for years or decades overnight," Brewer says. "It's going to take proof points to help them see that it's possible to develop quality applications with serverless and get their jobs done faster."
Brewer, who worked at SpringSource when it was acquired by VMware for $420 million in 2009, says he's seen this sort of change happen before. "Developers adopted Spring in droves once they saw how it increased their productivity," he says.
But Brewer says many business applications simply don't need that level of configurability, so in those cases it makes more sense to relinquish some control to take advantage of the speed and simplicity of more abstract offerings.
He argues that the pandemic shows how important agility will be in the future. Many organizations had to create new digital experiences — or retool old ones — practically overnight. The pandemic probably won't be the last time organizations will need to develop or change existing software systems rapidly.
Check out Cloud Native Adoption Trends 2020-2021 to explore the ongoing tension between developers and IT leaders about what the highest priorities are for cloud native migrations.
