Can You be Cloud Native Without Being in the Cloud?
One would probably assume that being cloud native means running everything in the cloud. But this isn’t always the case. Enterprise software is typically more complex than that and is often hosted in a hybrid mix of on-premises, private and public clouds. So, can you be cloud native without the cloud?
Gartner forecasts that by 2025, 95% of new digital workloads will be deployed on cloud-native platforms. Yet simultaneously, 86.5% of organizations are running at least one private cloud, according to TECHnalysis research. And 40% of workloads are a combination of private and hybrid cloud. These findings beg the question: Can alternative deployments leverage the power of cloud-native technologies, too?
From my perspective, the answer is a resounding yes. Just because it’s called cloud native doesn’t mean it’s cloud only. Cloud native simply means leveraging post-cloud technologies, using platforms and tools that take advantage of new, cloud-aware best practices, such as containerization, distributed computing, high elasticity and resiliency. Standardizing with cloud-native platforms can also help future-proof on-premises environments or bring consistency to hybrid multi-cloud landscapes.
I posed this question on Twitter and LinkedIn and received some interesting responses. Below, we’ll explore some of the reasons IT might be inclined to adopt cloud-native components outside of the cloud. We’ll explore some examples and consider the potential benefits of using cloud-native features in areas like on-premises and private clouds.
Sure, You Can be Cloud Native, Too
You don’t necessarily have to be running infrastructure within a public cloud like AWS, GCP or AWS to be considered cloud native. IT may utilize cloud-native technologies and run its stack in a private cloud on an infrastructure fully managed and hosted by the organization. Plenty of such implementations use these technologies, like the many Cloud Native Computing Foundation tools, on their on-premises or edge environments.
For example, some organizations use Kubernetes, the de facto container orchestrator, on edge environments. We’ve previously shared eight tools to run Kubernetes on the edge or bare metal, including packages like KubeEdge, SuperEdge, Akri, Metal3.io and others. These efforts demonstrate a common desire to port cloud-native practices outside the public cloud. For instance, Kubernetes and Istio have even been deployed on an F-16 jet!
Or, organizations may turn to cloud-native platforms to unify their observability efforts. OpenTelemetry, for example, can be used across clouds, on-premises and hybrid deployments. Looking outside of open source, IT may also choose to adopt cloud vendor software in their private data centers. For example, Anthos, Google Cloud’s hybrid cloud platform, supports these ambitions.
Why be Cloud Native Without the Cloud?
So, we now know that it’s possible. But why would you use these technologies without leveraging the power of the cloud? Here are some reasons you might opt to be cloud-native without technically using a public cloud.
- To reduce spending. Getting an ROI from the cloud can be more challenging than you think. Cloud spending is increasing across the board, and many leaders are surprised by escalating cloud bills enshrouded in opaque pricing models. Organizations might be looking to cut operating expenses, especially within edge environments where constant calls to the cloud are unnecessary.
- To avoid vendor lock-in. If you follow the principles of cloud-native architecture across your stack, you are more capable of switching cloud vendors. This way, you can benefit from using compatible, state-of-the-art technologies while creating a buffer between your software and the environment of choice. On that note, certain organizations might benefit from an infrastructure abstraction layer to enable consistent deployment practices across multi-cloud, coalition or on-premises locations.
- Building to be cloud-ready. Another reason would be to create an implementation that will be ready to ship to the cloud one day. Perhaps a team is in the early stages of designing an application for the cloud. Or, you might be future-proofing on-premises software for eventual migrations. Regardless, there are benefits to taking a cloud-ready mindset, even if you’re not currently using the cloud.
- For data compliance reasons. One obvious reason is to protect potentially sensitive data from exposure. Depending on the industry, certain compliance requirements might bar the organization from using the public cloud for certain workloads. In this scenario, using cloud-native components in private environments can help retain security while keeping the architecture up-to-date with software trends, avoiding technical debt accumulation.
- To reap ROI from server investments. Many on-premises servers have yet to reach their end-of-life and are chugging along just fine. The balance sheet might still be waiting to reap an ROI from an old capital expense or can’t justify new operational expenditures. Whatever the reason, a cloud migration might not be feasible. Like the point above, cloud-native components help keep pace with modern styles within these circumstances.
It’s a Cloud Native, Post-Cloud World
To put it simply, yes. Just as you can be a native to a country without living there, you can be cloud native without residing in a cloud. And as we’ve covered, there are many potential benefits from adopting this architecture in alternative situations.
Conversely, cloud migration does not always equate to cloud native. Interestingly, a Prisma Cloud report found that only 37% of applications deployed in the cloud were completely built in the cloud. The majority of applications are either refactored or rebuilt (27% were migrated to the cloud with significant modifications) or entirely lifted and shifted (36% were migrated to the cloud as-is or with only minor modifications).
This goes to show that the reality of IT software deployments is typically far more complex than cut-and-dry distinctions and most often involve legacy components. Therefore, as an industry, we should detach the idea of cloud native from the public cloud—because having one doesn’t necessarily mean having the other.
All this being said, the public cloud is here to stay, and public cloud usage and spending are forecasted to expand tremendously with the growth of new digital technologies. As such, choosing your architecture and computing environment will boil down to your unique implementation requirements, your business compliance requirements and what makes sense on the balance sheet.