From Silos to Services: Cloud Computing for the Enterprise

May 30 2018   8:20PM GMT

The Many Choices for Deploying Applications to Kubernetes

Brian Gracely Brian Gracely Profile: Brian Gracely

Tags:
containers
DevOps
Kubernetes
OpenShift
operators
Service Broker

This past week, on the PodCTL podcast (@PodCTL on Twitter), we received a question from a listener asking about a frequently asked question (and frequent point of confusion). With all the different tools that exist for deploying a containerized application to Kubernetes, how is someone supposed to know which one to choose?

Tools are an interesting space in the open source world. No matter what the broader project, two things are always true: [1] People love their tools and like they to be specific to them, [2] People love to build new tools, even when a previous tool already did about 75-90% of what they put into their new tool. And since tools are often outside the scope of the main project, the ability to have sprawl is pretty easy, without disrupting the main project.

In the case of Kubernetes, there is actually some reason for why there are many tools available to help deploy applications. In the simplest terms, it because Kubernetes can have many different types of people or groups that will interact with it. Kubernetes co-creator Joe Beda discussed this at a recent KubeCon, and we discussed it on PodCTL #28 episode. There can be developers that deploy applications to a Kubernetes cluster, and operators that also deploy applications to a Kubernetes cluster. Applications can be deployed just within the Kubernetes cluster, and other applications that have to interact with services or application that reside outside a Kubernetes cluster. These various tools and frameworks, from Helm Charts to OpenShift Templates to Service Brokers to Operators, are all focused on the Day 1 and Day 2 aspects of getting containerized applications onto a Kubernetes cluster.

But beyond those tools (and more) is an emerging set of tools that are focused on trying to make it simpler for a developer to write an application that is Kubernetes-aware. Tools such as these are now beginning to be lumped into a category called “GitOps

It’s important to understand that the earlier tools that were used with Kubernetes tended to be replacements or augmentations for existing config-management tools such as Chef, Puppet, Ansible, Salt, Terraform. The newer generation of tools, such as the Operator Framework, are more advanced as they now take into consideration the context of the application (deployments, upgrades, failure scenarios) and are leveraging the native APIs within Kubernetes to be able to align with the deployment models. Expect to see more ISVs begin to package their applications as Operators, as it makes it easier “embed” operational knowledge, and it gives them a consistent way to deploy their application into a Kubernetes cluster running in any private cloud or public cloud environment.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: