Cloud-Native vs. Cloud-Washing: What’s the Difference?
Over the last few years, cloud-native has become a popular buzzword in the tech industry. There are cloud-native applications, cloud-native network functions, even cloud-native storage. But, like many buzzwords, the true meaning of cloud-native has itself become clouded by overuse. The original definition of cloud-native as set forward by the Cloud Native Computing Foundation (CNCF) describes cloud-native practices as those that “empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner.” CNCF goes on to describe these practices as “loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable” using technologies and architectures that include “some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs.”
Ribbon's Cloud-Native Solutions
As you can see, there’s quite a bit of work that goes into being cloud-native. In fact, building a cloud-native anything is a sizable investment in time and resources that requires you to build (or re-build) your solution in terms of which features should be broken into microservices, how those microservices should be packaged into containers, which features will need to scale up/out and how to achieve that scale efficiently, etc. It’s a long road and, frankly, many vendors prefer to take a shortcut by simply retrofitting their existing solutions for a cloud environment and calling them cloud-native. But that’s not cloud-native, that’s cloud-washing. Similar to greenwashing, cloud-washing implies a solution that wishes to appear like something it really isn’t.
Cloud-Washing: A Shortcut to More Complexity and Cost
At first glance, a cloud-washed solution might appear cloud-native because it can be deployed in a cloud environment and may even use some type of microservices architecture. But there are fundamental differences between cloud-washed and cloud-native that eventually lead to more cost and complexity. For example:
- A cloud-washed solution will often be built around proprietary rather than industry-standard tools. Instead of using the common tool of Kubernetes to orchestrate containers, it will use a vendor-specific orchestration tool that is unique to that solution and requires additional training and cost.
- In a cloud-washed solution, you won’t find the out-of-the-box support for industry-standard APIs that you will in a cloud-native solution, meaning that you won’t be able to leverage industry-standard tools such as Prometheus or Grafana to run your cloud more efficiently and securely.
- A cloud-washed solution may require a lot of manual configuration to move between clouds, while a cloud-native solution can easily be moved to any cloud that supports open, industry standards.
- Cloud-washed solutions don’t scale as efficiently or effectively as cloud-native solutions, resulting in a need to buy (or lease) more infrastructure to handle peak capacity workloads.
- Lifecycle management is more complex in a cloud-washed solution because you’re dealing with a siloed technologies and different vendor approaches to handle automation and orchestration. Any automation is likely to be proprietary and not based on the industry standard GitOps.
How to Spot a Cloud-Washed Solution
Now that you know the dangers of a cloud-washed solution, how do you distinguish it from one that is truly cloud-native? For starters, a cloud-native approach starts from the very beginning with container-based microservices. If a solution is available primarily as a highly integrated, non-containerized virtual application, it’s a near certainty that its cloud-native version is merely cloud-washed. Likewise, if a solution uses a fixed resource profile or a proprietary orchestration tool instead of Kubernetes, it’s not cloud-native. Does it provide APIs to dozens of open-source cloud tools including Prometheus, Istio, and Docker? If not, it’s not cloud-native. Are the microservices architected in a way that they can be instantly replaced in the event of a failover? Cloud-native solutions require that kind of redundancy.
Cloud-native solutions should be so simple that developers don’t even think about the internal plumbing that goes into making them cloud-native. Instead, DevOps teams should focus on rolling out new apps and updates in a continuous integration/development (CI/CD) pipeline rather than worrying about things like security, container management, failover, load balancing, and other issues on a microservices level. When you take that worry and multiply it by millions of carrier interconnect sessions or hundreds of millions of mobile device sessions, you begin to understand why it’s so important for session border controllers and IP Multimedia Subsystem (IMS) solutions to follow a cloud-native architecture.
Hopefully, that clears up some of the confusion around cloud-native and cloud-washed. In the next blog, we will dive deeper into how cloud-native IMS solutions can benefit a 5G core.
