Accelerate your container strategy roll-out by overcoming adoption anxiety
-
You’ve got an awesome new process or tool. You know it’s not a magic bullet, but it definitely solves a need and, if rolled-out properly, could be a game changer.
You’ve done your research, tested it out yourself, ran a small PoC and worked out the kinks so now it’s time to go wide and scale out to the rest of the company(s). You send out communication: “ATTENTION: We’re going live!” with links to all your standards and documentation. But 3–6 months later, barely anyone is using your system.
“w*f?”. Didn’t they see the email? The title said “attention” and it was even in all caps. Maybe we should send another email with the entire title in all caps so everyone knows we really mean business?
Before you send that next email, consider this: maybe the reason you aren’t seeing the adoption rate you were hoping for is because teams are unsure or anxious about taking that first step. This phenomena is what I call adoption anxiety and here are some tips that helped me find success in bringing a Container-as-a-Service (CaaS) platform to an enterprise sized company.
Remember what your goal is.
It’s only natural to love your own “baby”. You came up with this idea and you know exactly why it is so awesome. “Oh, <my idea>, how do I love thee? Let me count the ways.” But just because something is important to you doesn’t ensure that the *need* for your solution will translate to everyone else. The principle of reciprocity is an observation that when someone does something for us, we are inherently compelled to do something for them in return.
First tip: Ask your clients: “What do you want to make happen?”
If your clients were certain in the tools and strategy to make their vision happen, they wouldn’t be talking to you. If the question is “What do you need?” the answer will likely be “I need “x” tool setup with “y” configuration like I saw in “z” GitHub post.”. If the question is “What do you want to make happen?”, you will better understand their goals and how to align your solution to accomplish their goals.
When we asked this question to our dev teams, the answer was that they wanted to create prototypes faster, have more control over their own infrastructure and do code pushes (during the day) with automated testing (CI/CD).
After that, we approached them with a containerization solution that would allow them to own their environments with almost full autonomy and the ability to leverage a fully automated CI/CD pipeline. Now the situation wasn’t our team trying to sell our solution to the dev teams, it was the dev teams asking us what they could do to be next in line to be on-boarded and use this system. The result was that not only were the dev teams persuaded to use our strategy, they began helping us develop automation so that we could on-board other teams faster all because we started the conversation by asking how we could help them solve THEIR goals.
The purpose of forward momentum…
When we first started looking at containers, it would not be an overstatement to say that we knew nothing. Containers were the new hotness and Docker was the black magic that would make all our DevOps dreams come true. I learned all about cluster architecture, etcd, rethink and raft but it would be months before I created my first Dockerfile. Why? Because all I had ever read about containers told me they were going to be a game changer and I was scared that it would take so much time to learn the Dockerfile “language” (think AWS CloudFormation) that I wouldn’t have time to focus on developing the plan for the overall CaaS strategy. Eventually I asked a colleague to show me one of the Dockerfile’s they had written and walk me through the syntax (again, think AWS CloudFormation) and this is the Dockerfile they showed me:
“Oh…”
The Dockerfile was 3 lines to stand up a web server and suddenly the battle I had been amping myself up for was already won.
Second tip: Take their first step with them.
Don’t send communication and hope for the best. Don’t wait for teams to dive in and start from zero by themselves. Instead, spend time hosting workshops or sitting down one-on-one to get them started and show them that getting started is actually a lot simpler than what they think. Walking a team through creating THEIR (read: not just a generic template) first Dockerfile or Compose/Deployment file takes 30 minutes per team and when they are finished, they have the confidence to get started and a working container for their app. Before we took this approach, teams might take weeks or months before they even started trying to create their first containers. Now, we see that from the point where teams know nothing about Docker until their first Prod instances are running in Docker takes an average of 1 week. What’s even more important is that this timeline starts almost immediately after they first show interest in using containers and CI/CD. Once a team has its first app containerized, they are able to teach their other team members how to move new apps in just a couple days.
Don’t “boil the ocean”.
In the 14th century, the Black Plague is estimated to have killed 30–60% of Europe’s total population. In total, the plague may have reduced the world population from an estimated 450 million down to 350–375 million(wikipedia). In the 21st century, something “going viral” can be similar to the Black Plague in its ability to spread rapidly while antonymous to its overall impact. Likewise, our roll-out plan was to spread organically through the company until the project went viral.
Last tip: Grow organically and swim at your own depth.
With no previous experience using Docker, Swarm or CI/CD, it was important that we took small iterative steps rather than trying to line up the perfect shot. We started with a small PoC group of devs we knew were passionate about new technology. We started with apps that were in new development and not business critical. After bringing those apps to production, we brought in another pilot group to test the process and automation we created with the first wave. From those teams, we created examples and reference architectures to train new teams to use Docker and now we have around 50 dev teams and over 400 applications all using CI/CD in our CaaS platform. Of those teams, 85% are able to bring additional applications to production on the platform without any assistance from our team and are able to teach teams around them to setup their app in Docker using CI/CD. From two dev teams in a 6 month PoC, we have grown to have Docker be the preferred run-time environment for our company and are onboarding 1–3 new teams every week. Going into 2019, we are poised to tackle the challenge of migrating thousands more legacy applications into Docker and we believe it is largely because of this phased approach that we were able to maintain momentum while never letting the project go off the rails.
If you are already implementing your vision, I hope you found some of these tips helpful. If you are new to Docker, in the discovery phase or waiting to decide if Docker is right solution for you, the greatest advice I can give you is to take that first step. Force yourself to jump in and I promise that your, “Oh”, moment will come as well. If you need help, contact me directly; I would be happy to help take your first step with you.
