Redefining Cloud Native to Focus on Business Value
Redefining Cloud Native to Focus on Business Value
Cloud native isn’t limited to containers and microservices orchestration. This was the main conclusion the Cloud Native Computing Foundation (CNCF) reached when it set out this year to re-define the term “cloud native,” said Justin Garrison, co-author of the book Cloud Native Infrastructure, who was involved in the CNCF’s lengthy process. Under the new definition, CNCF recognizes that cloud native is not just a set of technologies to adopt, but that it also reflects a change in an organization’s structure and processes.
“Technology is not the point. The point is business value and that may be about speed of deployment and speed of shipping function,” Liz Rice, technology evangelist at Aqua Security and co-chair of the CNCF’s KubeCon + CloudNativeCon event, said. “You need all the processes and the team structure and everything else around it.”
This is why Garrison and Rice have lately seen even technologically mature organizations deciding to rollback their microservices architectures and return to a monolith. These organizations realized that their own internal processes and teams just weren’t set up for microservices. They can iterate faster without them. Does that mean they’re not running cloud native applications? Not at all.
“It doesn’t matter if you own five little services or one big service, as long as people can iterate quickly on that and gain velocity to solve business problems,” Garrison said. “You can be just as successful with a bunch of VMs or possibly even bare metal or some of these things as long as you have the processes and people in place to take advantage of them.”
As active members of the CNCF’s open source community, Garrison and Rice have learned a lot from other end users and developers. Organizations that get involved can learn from each others’ mistakes and avoid some of the pitfalls that those on the leading edge of adoption have encountered. For example, many organizations fall into the trap of using familiar tools to try to solve issues that are specific to cloud native environments, Garrison said.
“Do I declare my pods in Terraform? You can. Should you? Maybe not, because you’re going to have this state conflict,” he said. “There’s different levels of abstractions where the tools just don’t make sense anymore.”
Conversely, organizations may also misstep by misusing a new cloud native tool, like a container image scanner that they end up rolling back because it gives too many false positives, Rice said. They don’t know that there is a good explanation for this. If your scanner doesn’t know about the patches that your Linux distribution has applied, for example, it will flag vulnerabilities that don’t exist.
Instead, “they’ve kind of thrown up their hands and gone, ‘You know what? I’m better off not even scanning the images. I’d rather not know. This is burning too many cycles chasing down these false positives,’” she said. “And they’re pretty much just relying on hearing about people saying there’s this terrible, terrible meltdown/spectre/heartbleed/whatever, and then checking whether or not that applies to them. Which kind of seems like not a great approach. … They don’t notice when a real, significant problem comes along.”
In this podcast, Garrison and Rice discuss the definition of cloud native, why some organizations have decided to move away from microservices and back to a monolith, and some of the approaches organizations are taking to cloud native implementations.
In this Edition:
4:25: How are you defining “cloud native”?
8:47: How some companies are going back to a monolith.
11:50: What is the balance in adoption helping to define cloud-native microservices.
14:32: What is the iteration on trying new services fast enough?
17:20: The security of one’s infrastructure and managing vulnerabilities.
26:54: Container architectures, state, and statelessness.