They did it again. Another company has taken their old software, cleaned it up a little for deployment in the cloud, and called it cloud-native.
We call it cloud-washing. Like the “green-washing” of old, where companies would make claims of environmentally friendly products and practices when, in fact, little had changed from the past, cloud-washing is simply the rebranding and repackaging of monolithic, sub-optimal, on-premise software to appear innovative. Creative, maybe. Innovative, never.
True cloud-native software is built specifically to leverage the inherent benefits of a cloud architecture: hyper-scale, high resiliency, service velocity, and hybrid cloud flexibility, for example. Unfortunately, some companies have discovered their own shortcut to the cloud: port their old software onto virtual machines, repackage it as “virtualized” software and stuff it into a container. That isn’t cloud-native, it’s cloud deceptive.
At the core of the deception is a desire for innovation. Communications service providers (CSPs) are facing unprecedented challenges as they look to support an ever-expanding digital economy. Services revenues are flat or declining, while data and video traffic are exploding. As a result, the business model for CSPs is currently inverted, as revenue per bit converges with cost per bit, leaving little room for profit.
Hyper cloud providers such as Amazon, Google, and Microsoft, on the other hand, are turning in record profits by delivering innovation at a very low cost using cloud-native models, open-source services, machine learning, and self-service models. To survive and thrive in the new digital economy, service providers will need to follow suit, embracing the same models, processes, and technologies used by the leading hyper cloud providers. It’s a new world for CSPs, which is why it’s critical for them to have truly cloud-native solutions.
What does a real cloud-native solution look like? Basically, there are five main design principles that determine whether an application is truly cloud-native:
- Multi-Cloud Support
- Container Packaged
- Dynamically Managed
- Microservices Oriented
- Externalized State
1. Multi-Cloud Support
By its very definition, cloud-native software is designed to be hosted in a multi-cloud environment. Software that cannot be deployed in a public, private, and hybrid cloud environment is not cloud-native, period. Simply connecting to a cloud isn’t the same as being built to run in any cloud.
2. Container Packaged
Software packaging and delivery have evolved from single, monolithic software packages to virtual machines and, more recently, containers. Container and orchestration platforms such as Docker and Kubernetes bring clear advantages to a cloud-native architecture by making applications more lightweight, open, portable, and easier to deploy, orchestrate, operate, upgrade, and manage. Some vendors use the right buzzwords (e.g., containers, pods, Docker, Kubernetes) but have the wrong ideas about cloud-native characteristics, and instead, they package their software as a big, complicated blob.
3. Dynamically Managed
Cloud-native software should be elastic. It should be scaled once for the initial load and then automatically scale up or down using cloud-native tools such as Kubernetes or Helm as demands increase or decrease. We call this dynamic management, and it’s a monumental mind shift for CSPs that are accustomed to dimensioning network solutions based on peak traffic scenarios with very limited agility.
4. Microservices Oriented
IT teams have already successfully implemented a microservices-based architecture for front-end channel applications as well as for back-end customer management and order management applications. CSPs can now invoke and re-use these microservices components in different combinations to simplify software upgrades or create new services. If software claims to be microservices oriented but shows little evidence of delivering autonomous, changeable, replaceable services, you’re probably looking at a cloud-washed product.
5. Externalized State
One of the limiting factors in scaling an application is statefulness, particularly its session state. Applications in which the application and session state have not been externalized to a high-availability store will have a hard time functioning in the cloud.
The Last Word about Cloud-Washing
The promise of 5G as a catalyst for nonstop reliability, new service innovation, and increased revenue is well documented. Re-architecting the network around the aforementioned architectural principles is the foundation for the promise of 5G. At Affirmed, we call that a platform for innovation.
The race to digital services is already underway, and competition will come from all sides. CSPs need a web-scale, cloud-native network architecture that can deliver next-gen digital services. These networks will have to deliver ultra-high performance and advanced features such as network slicing, service automation, and real-time analytics to radically accelerate service creation and drive down network costs.
More than ever, service providers will need to roll up their sleeves and fully evaluate each architectural element, principle, and capability of their 5G platform. This means challenging vendors on their cloud credentials, their roadmaps, and their commitment to open-source technology. In short, insist that your vendors come clean about whether or not they’re selling true cloud-native technology or simply cloud-washing their old products. A high-performance, cloud-native architecture using open-source technology can open your 5G future to more agility, flexibility, and opportunity. Don’t settle for anything less.