Cloud-native, as the name suggests, refers to software or services designed specifically for the cloud. However, since the term was coined, few stateful services have truly been “native” to the cloud. On the contrary, their deployment costs are often many times higher than on traditional servers. This is absurd. The original goal of the cloud was to reduce costs and improve efficiency. Today, we can set aside “efficiency” for a moment, as “cost reduction” has become an empty promise. This prompts industry professionals to reflect: is cloud-native a step forward or a step backward?
To answer this, we need data: the same price with better performance, or the same performance at a lower price, is progress. Otherwise, it’s regression. Currently, stateful services deployed using cloud-native approaches neither perform well nor are cost-effective. Such an approach is unworthy of being called “cloud-native” and should rather be termed “cloud-inefficient.”
In simple terms, cloud providers purchase a large number of servers and, using the internet as a medium, offer resource rental services on a pay-as-you-go basis, providing “elasticity.” What does this “elasticity” mean for users? To make it easier to understand, let’s compare it to everyday travel solutions:
From a cost perspective, option 3 has the lowest total cost but the highest cost per use. Similarly, cloud providers buy long-term assets and offer short-term rental services. Beyond hardware costs, cloud providers also bear various management costs and need to ensure profitability. Therefore, cloud computing doesn’t inherently make computing cheaper; instead, it can make it more expensive.
The only way users can genuinely feel the “cost reduction” is through elasticity: paying a higher cost per use when needed but releasing resources when not in use, thus reducing overall costs. But can “cloud-native” truly leverage this elasticity?
“Cloud-native” refers to technologies that empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. Essentially, cloud-native is a set of technologies that ensure software can be deployed in containers.
For stateless services, cloud-native can indeed improve availability and reduce costs. However, for stateful services, the situation is entirely different.
For stateful services like data warehouses or databases, Kubernetes provides StatefulSets and Persistent Volumes for cloud-native deployments. However, options for persistent volumes are limited on cloud platforms. For example, on AWS, the choices are primarily EBS or EFS. Using EBS significantly increases the total cost compared to deploying the same software on traditional servers, making EBS-based stateful services unsuitable for cloud-native.
Given these inherent “genetic defects,” it’s no surprise that so-called “cloud-native” solutions often exhibit “cloud-inefficiency.”
We propose a new architectural principle: CloudFirst.
Checkout the article for the CloudFirst Architecture detail.
Unlike cloud-native, Cloud-First focuses on maximizing the elasticity of cloud computing, shedding components that mimic traditional computing resources. Adopting Cloud-First means developers must abandon much of their existing code, dependencies, and instincts. This paradigm shift aims to optimize costs and truly achieve the promise of cloud computing: cost reduction and efficiency.
In conclusion, stateful services cannot benefit from cloud-native architectures and require a Cloud-First approach to achieve cost-effectiveness and efficiency. Stay tuned as we share more about our Cloud-First designed, next-generation data warehouse: ClapDB.