Feb 26, 2019
Alex Hisaka
D2iQ
Your organization has its pick of the pack when it comes to container orchestration solutions. But if you're like most organizations, you'll go with Kubernetes for its architecture, innovation, and the large open source community surrounding it. This soon-to-be de facto standard is the cause for rallying cries throughout enterprises. If you're hearing those demands for a production Kubernetes environment, you've got your work cut out for you figuring out the right deployment model. It's enough to make your head swirl. Check out these tips from on how to select the best deployment model for your organization.
The Three Main Deployment Models
Public Cloud Container Services
In this model, users (e.g., your developers) will access a managed Kubernetes service through a public cloud Infrastructure as a Service (IaaS) provider. Think Amazon Elastic Container Service for Kubernetes, Azure Kubernetes Service, and Google Kubernetes Engine. While the provider will take care of building and managing Kubernetes clusters for you, you get no choice when it comes to details like the Kubernetes version to be used.
Container Management Software
Here you build and manage Kubernetes clusters either on-premise or off-premise using a packaged software solution. The package usually combines what's needed to both distribute and manage Kubernetes (such as for security, monitoring, and storage/networking integration).
Gartner highlights two major product approaches using this model:
- Container Operations: You'd choose this solution if you want to simplify container operations management and get more choice when it comes to DevOps toolchains and application infrastructure software. Examples of solutions enabling this approach include Mesosphere Enterprise, Docker Enterprise Edition, Heptio, and Rancher.
- Kubernetes-based Application Platform: In this scenario, you get a more in-depth DevOps and microservice development experience through toolchains and application infrastructure software for adjacent middleware services. Examples of platforms supporting this approach include Pivotal Cloud Foundry, Red Hat OpenShift Container Platform, and SUSE Cloud Application Platform.
Do-It-Yourself With Upstream Version
It's also possible for you to build and manage Kubernetes clusters either on-premise or off-premise using the open-source Kubernetes upstream version from its GitHub repository. The example Gartner gives is Kubernetes hosted by the Cloud Native Computing Foundation.
The Tradeoffs of Each Model
As you can imagine, each deployment model has its pros and cons.
Public Cloud Container Services
- Pros: You'll simplify operations since you don't build or manage clusters. You can also remove or add clusters on demand, and use Kubernetes master services free of charge or at a low price.
- Cons: If you want a Kubernetes cluster outside the public cloud, you need to deploy it separately. Also, some providers don't let you control many configurations and you'll be limited when it comes to troubleshooting since you can't access the lowest infrastructure layers.
Container Management Software
- Pros: You'll gain comprehensive management features not built into Kubernetes. Plus, you can manage multiple Kubernetes clusters across a hybrid cloud or multicloud environment.
- Cons: You need to be familiar with the series of operations of a Kubernetes cluster (and that's no small task!). In addition, you get less flexibility and customizability when it comes to DevOps and microservices development You will also pay product and support costs, which tend to be on the high end compared to public cloud container services, which are free (for Kubernetes master services) or at least more affordable.
Do-It-Yourself With Upstream Version
- Pros: Because you can choose your operation tools and easily customize Kubernetes code, you can more quickly test new features in Kubernetes.
- Cons: You'll likely need several dedicated engineers familiar with Kubernetes and its intricacies to design and maintain a DIY Kubernetes platform. You'll also need engineers who can interact with the open-source community for integration and troubleshooting. Unless you are an extremely large enterprise with large deployments, you'll probably end up paying quite a bit for these specialized resources. Your organization will need to move slowly to plan, evaluate and test your deployment, and you'll need to take the time to build scripts that automate deployment and updates. According to Gartner, it usually takes more than half a year in production to for your organization to comfortably get up to speed on Kubernetes.
To learn more about managing and orchestrating Kubernetes, download the eBook "The Quick and Easy Guide to Implementing and Orchestrating Kubernetes at Scale."
