This is Wayne Watson and I'm the CTO of appLariat. I'll be posting on a variety of technology subjects related to appLariat, cloud native, containers, container runtimes and more. I hope you'll find my posts interesting and valuable to your own journey to cloud native. I'm going to start with a discussion of container runtime environments and why we chose Kubernetes to start with.
As appLariat is a Container Automation Platform, you can think of us as an "orchestrator of orchestrators", delivering cloud native capabilities to your existing applications efficiently and without costly re-architecture. Of course, we would need to work with an existing container runtime environment since:
- There were several strong choices that were mature enough to support our goals
- We certainly weren't going to build our own
Our initial goal was to be agnostic to the underlying technologies we enable, so we intended to support multiple runtime environments, specifically the "Big 3":
- Docker Swarm (now Docker Native Orchestration)
- Mesos (Marathon/DCOS)
We started testing with each of them and it quickly become clear that if we were going to bring our product to market quickly to support our business goals, we were going to have to make a bet on one runtime environment to leverage initially. Each has pros and cons and, of course, there is no perfect solution. As a startup, time was of the essence, so we focused on the answers to three key questions to choose our initial container runtime to integrate:
Which orchestration platform will provide flexibility to adapt as we move forward?
- Mesos provides the greatest amount of flexibility as it is a general orchestration framework that can support multiple schedulers and workloads, including containers. A primary concern for us was that the Mesos, as a framework, was not designed specifically for containers.
- Docker Swarm is specifically designed for containers, but to be more specific it was designed for Docker containers. Our concern here was that we knew we would need to support a variety of container engines and not just Docker's.
- Kubernetes offered a great balance as it was designed from the ground up as a container orchestrator and is based on Google’s years of experience deploying and managing containers, but fundamentally Kubernetes is agnostic to the underlying container engine.
Do the features enable us to support both existing and new application workloads?
- Mesos was the relative newcomer when it came to managing containers, and the feature set specific to containers was not well documented. Our concern was that the time to ramp up and learn the best practices for managing containers on Mesos would be lengthy.
- Docker Swarm was quick and easy to get started with, but there were also a lot of changes coming as it became integrated into the core of the Docker engine. Our concern was that stabilizing these extensive changes would take awhile.
- Kubernetes offered a rich feature set of capabilities, including high availability, replication, jobs, daemon sets, config maps, secrets and many more in development, such as stateful sets and operators. This extensive feature set demonstrated how much Kubernetes is focused on addressing real world problems.
How likely are we to be able to find assistance with problems we are going to encounter as we develop our solution?
- All 3 platforms have active communities with participation from a variety of companies.
- Mesos and Docker additionally offer enterprise support, but we didn't want to pass this cost along to our customers.
- Kubernetes clearly had the largest community of contributors to the project and would provide the best assistance in problem solving as we built our product.
Based on the answers to the questions we asked ourselves, Kubernetes was the best choice and after many months of developing our solution around it, we have not regretted our decision and we've learned many lessons that we are driving into our product. These include:
- There is a steep learning curve to be successful with managing applications on Kubernetes, especially around day 2 operations. appLariat is meant to solve this.
- The community driven aspect of Kubernetes has been a key factor in the progress we have made, but it can be a double edged sword as many times you find yourself overwhelmed with potentials options to solutions. That is why we are putting best practices into our platform.
- Kubernetes can run nearly any workload, but that doesn't mean that its the best possible option for all of them, so maintaining an agnostic approach is still key to our solution.