Kubernetes, the Data Center, and the Question of a Full Scale Migration
By: Patrick McFadin
Kubernetes lets devs get maximum utility from containers and build versatile cloud-native apps, independent of cloud-specific requirements. But does it also allow a full-scale migration?
Data centers used to be exactly that — the centers of our data worlds, where all information, files, and records would be kept and controlled.
That’s no longer the case today. More companies are moving to cloud services, whether it’s dialing down on their traditional on-premises environments or never setting them up in the first place.
This doesn’t mean data centers will be wholly abandoned for the cloud. Rather the mix will continue to evolve and become significantly different from today. Gartner predicts that 85% of infrastructure strategies will take a more hybrid approach, integrating on-premises, colocation, cloud, and edge delivery options by 2025, compared to the 20% in 2020.
This melange of different venues, platforms, and approaches is all possible. But that doesn’t mean it’s currently easy or efficient to work this way. It can end up with IT in silos with the dreaded technical debt. In addition, many CIOs admit they fear getting locked into a single provider — according to Bain and Co., around two-thirds of CIOs use multiple cloud providers.
Is Kubernetes the future for the whole data center?
Alongside these trends, developers have been using containerization and microservices to build modern cloud-native applications.
The thinking here is understandable — containers are built to be managed at scale, while microservices applications use lots of different components to assemble services before delivering to users. Taken together, this technology and application design approach will make IT more agile and better deliver what the business wants.
Containers can also run happily agnostic across multiple locations, so this would fit with the idea of running more hybrid and multi-cloud environments over time. Spawn the containers close to the user, and you get the benefit of on-demand compute and low latency. Clouds are left supplying the basic compute, network, and storage.
Making it work in practice takes some work, but it’s getting easier.
Google’s Kubernetes project for container orchestration has become the default standard for developers to manage this, but it has been strongest with application workloads alone. It was designed for stateless application images that could be turned on and off as needed, rather than stateful workloads like data that may have to exist for years.
Kubernetes doesn’t yet cover areas like databases as standard, so Operators are required to integrate into and provide a management layer.
Putting all this together is for the whole Kubernetes community, from cloud providers and data center operators through to open source projects, vendors, and customers. As Kubernetes — and the industry around this project — develops, it can provide operating systems for workloads to exist across multiple locations.
If you love something, set it free
What will this mean in practice for data center operators? Can Kubernetes provide a fully functioning way to migrate whole environments from one provider to another, scaling up server virtualization for the cloud age? I think the answer is yes.
Companies of all sizes care about cloud and lock-in. They want to know the exit route is just behind them and that they can use it whenever they want. But this doesn’t mean they will automatically start looking at the exit (if and when it’s possible). Looking at the Bain research, companies tend to spend the majority of their budgets with a primary provider.
Kubernetes can make workloads easier to move and run across multiple locations. What will change is the definition of a workload, from individual application containers to whole data center environments, especially around commodity applications that rely on standardized compute or storage.
Database implementations with Kubernetes Operators can similarly be moved between cloud or on-premises data centers. For some databases, this involves moving from one provider to another, while distributed databases like Apache Cassandra® can take this further by operating across multiple cloud services or data center locations from the start.
For the data center industry as a whole, embracing more freedom and flexibility around workloads with Kubernetes should provide more opportunities to support customers in their long-term strategies around cloud, data, and IT. Trying to be too controlling will, paradoxically, lead to less engagement and commitment from those that aren’t committed.
With so many moving pieces to think about, using Kubernetes as a standard layer will help everyone to control how and where applications run and data gets created, wherever those locations happen to be.
Subscribe to the DataStax Tech Blog for more developer stories. Check out our YouTube channel for free workshops and follow DataStax Developers on Twitter for the latest news in our developer community.
Resources
- CIOs Say They Want to Avoid Vendor Lock-In, but Most Are Pretty Close to It
- Kubernetes
- Apache Cassandra
- K8ssandra | Production-ready distribution of Cassandra on Kubernetes
- Blog: Why Kubernetes Is the Best Technology for Running a Cloud-Native Database
- Blog: Cassandra Myth Busters: How Hard Is It to Run Cassandra on Kubernetes?
- Blog: 3 Big Takeaways from KubeCon + CloudNativeCon Europe 2022