Are Docker and Kubernetes the right fit for my team?

A lot of hype has been happening in the Sitecore community around Docker and containers since the announcement of official support for containerized installations. The community Docker repo has been providing a lot of help with getting images and scripts ready for developers to get set up very quickly. Developers are getting excited by the promise of increased productivity and easier installation management, and now you need to make a decision on whether the organization adopts containerization as a strategy for your software delivery.

Unfortunately, the answer is: ”It depends”. 

A good rule of thumb is that if you are an organization using virtual machines, you probably are better off with containers. It should be noted that your individual developers can benefit from using Docker even if you decide not to adopt it across the enterprise for the full DevOps flow to production.

Generally, the following challenges indicate that your organization might benefit from a container strategy:

1. The current DevOps flow is generating a high cost of infrastructure due to overuse of resources needed by virtual machines.
2. It is difficult for the organization to manage Sitecore infrastructure because of varying dependencies between different versions of Sitecore.
3. The organization is wasting a lot of time setting up Sitecore environments.
4. The various environments are deployed on multiple cloud hosting environments.
5. The team needs to be able to replicate specific environments quickly, such as doing support for reported production issues.
6. The team needs to work on different sites/solutions/projects, which may also use different versions of Sitecore and require different dependencies (SQL Server versions, operating systems, Solr versions, etc.).
7. Developers move from one Sitecore project to another, needing to get started up quickly, and then tear down quickly.
8. The team is struggling to find a way to test in isolation prior to deployment.

Here are my top 4 picks for benefits that can help you explain the reasons for adopting a containerization strategy:

1. Faster time to market. A lot of marketing teams are going to benefit thanks to faster developer setup times, smoother deployment flows between environments, and fewer ”works on my machine” scenarios that cause technical delivery to slow down. This allows the team to iterate more quickly and reduce risk in the dev-to-production flow.
   
   Challenge: The team needs to adapt to a new way of working, so there will be a delay in seeing these benefits. Also, if the organization has other reasons that are preventing code from reaching production (such as long test/accept stages) then you may need to focus on these bigger flow issues first.
    
2. Lower costs of operation. The IT team will see a reduction in infrastructure costs when operating multiple containers on a host when compared to multiple virtual machines on the same host. Fewer resources are required to run the containers on the host since the operating system kernel is shared and no longer duplicated each time.
   
   Challenge: The ease of deploying containers may have a side-effect of ”container sprawl”, which would actually have the opposite effect on your operation costs. It is critically important to have proper orchestration and management of containers to ensure your operation costs are kept down. Kubernetes (K8s) is your friend here!
    
3. Flexibility in the cloud. Due to the nature of the way containers abstract away the operating system, your containers can be moved between different cloud vendors. This gives your organization flexibility in whom they deal with for their cloud infrastructure.
   
   Challenge: While the containers are flexible, if you plan on using ‘Kubernetes as a Service’ (a.k.a. Managed Kubernetes Service), your orchestration may be different between cloud vendors. This is something to plan for if you want to switch between cloud vendors or run on multiple at once.
    
4. Reduced Mean Time to Resolution (MTTR). If your container strategy flows throughout all environments, including production, you are able to have your support team quickly replicate production environments locally so they can work on fixing issues sooner and with less chance of disparity between local and production environments.
   
   Challenge: Before you see a benefit for this scenario you are going to have to adopt this across the entire flow chain, it will not be enough just to have a few developers install Docker. This should be addressed holistically to recognize the benefit.

There are signs that indicate an organization will probably face challenges with adopting a container strategy:

1. Late adopters. The organization has difficulty adopting new technologies as they come out. They do not want to ”figure it out”, they want to do things the way they know how to do it and let others establish new, well-documented practices first. These organizations typically exhibit ”late adoption” behavior such as ”Version Minus One” policies, running on older operating systems and browser versions, hesitancy to move to cloud-based infrastructure, etc. In some scenarios, these older infrastructures may not even be able to meet the virtualization requirements for Docker.
   
   While Kubernetes and Docker are not exactly new, it is still a newer technical solution in the Sitecore community and therefore will have gaps in documentation, proven practices, and widespread adoption.
   
   Facing the challenge: Identify case studies of organizations currently on Sitecore with a similar profile to your own organization. This will help provide some assurance to stakeholders that ”this has been done before”. Then an analysis of the current state of infrastructure technology would be needed to ensure a readiness for containers.
    
2. Highly regulated environments. Whether it is government legislation or enterprise-level policies, these organizations have a lot of rules in place on how you can bring software from development to production. The DevSecOps team may not know how to translate their current policies and regulations to a container world. How do all the teams get educated on how to make sure the containers are meeting policies? Some of those policies were probably developed many years ago and not re-examined against newer tech. 
   
   Facing the challenge: This one is all about education. It’s not that you can’t do it, but people won’t necessarily know how. It helps to identify some champions who can do proofs of concept and have something to ”show” to various teams so they can understand the differences between the existing and proposed technology.
    
3. Infrastructure costs appear to be ’under control’. There is a very small infrastructure overhead, or the technical delivery/operations have been outsourced to an external group where the cost for the service is reasonable compared to the reduced technical responsibility. 
   
   NOTE: The team doing the outsourced work might want to look into a container strategy to increase their profit margin!
   
   Facing the challenge: If the current infrastructure costs are not hindering the business, and you really feel containers are the way the organization should go, it may be worth looking at time to resolution (MTTR) for production defects or the time to market benefits instead of focusing solely on infrastructure costs. Will your organization see more value in those areas?
    
4. Mature and stable application base. There are very few changes happening day-to-day on the Sitecore-hosted environments. Perhaps there is a small team working with Sitecore, a single site, a single software version. No complexity around maintaining different environments, very few changes are happening.
   
   Facing the challenge: This state is actually an innovation warning sign! You should be in a continuous improvement model and a lack of changes is not actually a good thing. If the team is pushing back on adopting new technologies because of this reason, then you may need a deeper analysis into the problems that are leading to this situation. There may be a bigger strategy to address other than a container one.
    
5. Lagging infrastructure automation. If the team responsible for all the infrastructure is having a tough time keeping up with infrastructure automation currently, introducing a new technology requiring infrastructure automation may prove challenging. If these teams are not innovating on how they manage infrastructure, they are sometimes unwilling to take on these new technologies, especially if the organization falls into one of the first two challenges listed here.
   
   Facing the challenge: Before tackling a container strategy, this challenge may indicate that the priority is focusing on how the organization automates their infrastructure (or does not automate, as the case may be). An overall investment in how your team prioritizes automation may be a first step. Perhaps a container strategy is the way to do that, but you may have to do some baby steps here first to get the team to a point where this cultural adoption will work.

• 5 business reasons why every CIO should consider Kubernetes, Kalyan Ramanathan, Sumo Logic
• What are containers and why do you need them?, Paul Rubens, cio.com
• Docker Reference Architecture: Securing Docker Enterprise and Security Best Practices, Docker
• Kubernetes as a Service: GKE vs. AKS vs. EKS, Evan Klein, logz.io

Jason St-Cyr, Manager, Technical Evangelists, Sitecore
https://jasonstcyr.com