How to Avoid a Dead-End Kubernetes Strategy
The Cloud Native Computing Foundation sponsored this post.
Kubernetes is the latest evolution in managing containers and as with any new and fast-moving technology; there are a seemingly endless number of ways to deploy it. Kubernetes is only one piece of the puzzle. Deploying Kubernetes in production at scale requires an entire ecosystem of tools from network and storage to logging and monitoring. Numerous vendors have jumped on the bandwagon to offer a ready-to-use Kubernetes platform allowing enterprises to adopt the technology quickly. Though similar at first glance, there are (sometimes significant) key differences. Since infrastructure decisions are difficult to roll back once you’re up and running, how do you futureproof your Kubernetes strategy?
Life before Kubernetes… and How Kubernetes Became the De Facto Standard
Released in June of 2014, Kubernetes is barely five years old, and has only been considered stable for about four years. Before the industry nearly universally agreed on moving to Kubernetes, there were multiple options available to orchestrate containers. Docker Enterprise (Swarm) had the name recognition of Docker behind it, and AWS ECS was the first widely available container solution on the public cloud. Other commercially-backed competitors included Mesosphere and Cloud Foundry.
Today, all of these previously industry-leading solutions have announced that they are either replacing key components of their own offerings with Kubernetes or are offering Kubernetes management as an add-on. This puts pure-play Kubernetes offerings at an advantage. They can focus solely on the future instead of worrying about keeping previous customers happy while migrating to their new technology stacks. But what else is important?
Key Considerations
Clearly, early adopters didn’t foresee Kubernetes’ dominance. Today, those containerizing applications have the advantage of knowing it is the de facto container orchestrator, but back in the day, there was no obvious choice. While some recognized the potential of Kubernetes early on, numerous organizations started out with ECS, Mesosphere Marathon or Swarm. This choice came at a price because now they need to migrate to Kubernetes — a difficult and expensive endeavor.
While betting on the right orchestration solution early on may have been a gamble, thinking through future requirements isn’t. When selecting your Kubernetes platform, it’s helpful to think beyond a single project’s needs. Kubernetes adoption is skyrocketing and adoption within your organization will likely follow.
The five things you should consider to avoid a dead-end Kubernetes strategy:
- Openness, flexibility, and extensibility: Technology and enterprise requirements are constantly evolving. A platform that is open, flexible, and extensible will evolve with you. It shouldn’t tie you to an OS, single cloud, PaaS, or technology stack as your requirement will change. An opinionated solution may limit your future ability to deploy and manage Kubernetes in multiple environments from a single control plane;
- Managed services or not: While convenient, especially when starting out, managed services limit customization. Kubernetes is highly extensible, with operators, side cars, custom resource definitions, multiple overlay network options, etc. New applications moving to Kubernetes are taking advantage;
- Customization: Once you venture into advanced use cases such as AI or Machine Learning on Kubernetes, or Kubernetes for IoT at the Edge, you’ll need the ability to customize your clusters. If your solution is tied too tightly to a single deployment stack you may be limited in what you can achieve;
- Multi-environment capability: Multicloud strategies are becoming more prevalent and allow you to leverage other clouds in the future, even if you’re only using a single cloud solution now. Hybrid and on-premise are also common scenarios today. Your best bet is a Kubernetes platform that allows you to expand your container infrastructure to where you need it;
- Stateless and stateful applications: Kubernetes is new to most organizations and you may start with stateless containerized workloads. But you will quickly find the need to support stateful applications. Kubernetes provides a persistent volumes subsystem that abstracts storage details for your developers but setting up and running storage systems for Kubernetes is evolving quickly. Make sure you consider your storage needs across all of your environments when choosing your platforms.
Conclusion
To avoid a dead-end Kubernetes strategy, you need a futureproof Kubernetes solution. One that adheres to cloud native principles such as openness, flexibility, and extensibility. While you may not foresee your future requirements, these characteristics will ensure your choice will be able to evolve with your needs. With the rise of open source and cloud native, the time of proprietary enterprise software, that locks you in, has come to an end. Modern enterprise software is compatible with cloud native principals extending the value of your technology investment.
Feature image via Pixabay.