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:

• The current DevOps flow is generating a high cost of infrastructure due to overuse of resources needed by virtual machines.
• It is difficult for the organization to manage Sitecore infrastructure because of varying dependencies between different versions of Sitecore.
• The organization is wasting a lot of time setting up Sitecore environments.
• The various environments are deployed on multiple cloud hosting environments.
• The team needs to be able to replicate specific environments quickly, such as doing support for reported production issues.
• 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.).
• Developers move from one Sitecore project to another, needing to get started up quickly, and then tear down quickly.
• 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:

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

• 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.
  
  
• 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.
  
  
• 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?
  
  
• 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.
  
  
• 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, Vice President, Engagement, Fishtank Consulting
https://jasonstcyr.com