The excitement fueling the containerization movement is not about the technology itself, but what the technology enables people to do. Docker is exciting because it enables people to package and deliver and unbundle complex applications with unprecedented ease. Kubernetes and Docker Swarm and Mesosphere are exciting because, now, a single developer can set up and manage distributed systems, where before it may have taken entire private datacenters and extensive operations teams. In this way, the heart of the containerization movement has always been about functionality over technology.
An important part of functionality is accessibility - if something is difficult to understand or use, it doesn't matter how well-built it is. Most people won't use it. People don't adopt technology because it's the best technology for their needs - they rarely have the time to evaluate everything they need to make a comprehensive decision. People adopt technology because it's familiar or easy to learn. Thus, for a technology to get new users, it needs to be relatively easy to adopt and understand. While our chosen container orchestrator, Kubernetes, is technically solid, it is too complex for most users to understand and thus adopt it (we're excited for new usability improvements coming out in 1.4).
What drives us at Redspread is increasing accessibility to technology - essentially, enabling new functionality for new users. This is why we obsess about focus on the user interface and making complex applications easy to build by both programmers and non-programmers alike. The end user shouldn't need an architectural knowledge of containers or container orchestration to deploy and use distributed, scalable applications, the same way cloud providers ensure that we no longer need to understand how to configure physical servers.
This is why the first feature of our open source product, Spread, was an easy way to deploy containerized applications configured with Kubernetes to production in one command. We then realized that, in order to lower the barrier to using Kubernetes even more, we needed to build a simple way to spin up a local Kubernetes cluster. We donated this project, Localkube, to Kubernetes, and it now forms the backbone of the official local Kubernetes solution, Minikube.
Now, we're experimenting with templating and the Spread Library, a collection of parameterized applications that can be easily deployed and configured with a few commands. We've combined it with Minikube to make it easy to try out containerized applications anywhere.
The concept of a library of configured applications isn't new - the key innovation here is the design of our simple templating solution. Redspread's templating abstracts away the underlying complexity of Kubernetes from the end user, without sacrificing functionality or flexibility. We designed templating to only expose information that the user needs to know to correctly configure and deploy an application, enabling newcomers to this technology to use and deploy applications without needing to know much about Docker or Kubernetes.
We've started with a useful example application - a virtual private network (VPN) - that can be deployed with Spread and configured with Spread template parameters.
Once a user has set up Spread, she can deploy and configure her own VPN by running the command
spread deploy vpn. She will then be prompted to fill in a series of parameters in the command line. See the specific tutorial for the VPN on how to use these parameters.
Once she fills in the needed information, Spread will deploy her custom-configured application to a remote or local Kubernetes cluster. In the future, if she doesn't have kubectl configured for a remote cluster, Spread will automatically spin up and deploy to a local cluster.
Our user has now deployed and configured a containerized application to a Kubernetes cluster, without necessarily knowing how Kubernetes works, what a Kubernetes object is, or even how to spin up a remote Kubernetes cluster.