How to Manage the Change Containers Bring
While we love the containerized world that Molly the blue whale has us swimming toward, the technical advantages that containers and microservers bring also carry implicit cultural changes. If not handled correctly, they could disrupt the workplace routine, and not in a good way.
Just like when introducing scrum and other radical restructuring processes, bringing the microservices architecture to your team shouldn’t be taken lightly and shouldn’t be done from the top down. At Dockercon EU, held this week in Barcelona, Ian Miell, author of “Docker in Practice,” provided an overview of what team leaders should expect and how to manage the change that containers and microservices bring.
Know Your Team
When it comes down to it, you know your team, your environment, your workflow and your needs. That’s powerful.
“It’s a call to arms really, trust yourself,” Miell said. “When I was introducing Docker two years ago at my company and people were saying you’re doing it wrong and you should do it this way.” But “I had the experience through past failures to trust my instincts.”
He said that as a team leader you simply have to trust yourself because you know your local environment and you know the local solutions to your environment. “You know the answers for your businesses.”
For Miell, the move toward Docker all started back in 2013 when he saw the prodigious Wired article “The Man Who Would Build a Computer the Size of the Internet.” Founder Solomon Hykes had recently launched his open source software aimed at standardizing the shipping of applications across the Internet and around the world.
Miell read it and said, “That’s what I’ve been waiting for!” He was then working as the head of DevOps for a 600-developer team at OpenBet online gambling platform, juggling between 25 competing customers who each had their own demands and expectations. “Big-pocket customers, happy to pay for support. They were quite happy to shout at me when things when wrong.”
But when it came time to make a change to Docker, it wasn’t the clients that caused him the most grief.
“I was pretty frustrated because everyone was pretty accepting of technical debt,” Miell explained. “I was living daily with the consequences of managing outages.”
But the standard at the time was to use virtual machines (VM) to manage a demand for continuous delivery. Not thinking this was right for his particular needs, Miell broke his decision-making process down into four phases:
Projects vs. Skunkwork—Projects came with the structure, approval and funding while Skunkworks would be a motivated fund and democratic system where investment would have to be deferred. Choosing Skunkworks he soon realized that “Those that didn’t deliver anything found they had no voice and then dropped out. But those that did deliver found they did have a voice.” He explained that Skunkwork particularly goes well in organizations where you get around processes and leverage individuals’ experience and knowledge. “By focusing on building solutions instead of getting support elsewhere, a lot of time was saved.”
Microservices vs. Monolith—This was the time he went with the standard because he simply couldn’t bear the thought of overcoming 15 years of legacy code. He pointed out that many companies can benefit from using Docker to enable microservices but it doesn’t only need to be used for that.
Standard Tools vs. Not Invented Here—Standard means the most well-supported and proven while NIH refers to the fast, feature-sufficient, investment deferred kind. This is where he got a lot of pushback with folks saying “You should be using industry standard tools here” to which he replied “OK go ahead and we’ll write one.” It’s called ShutIt.
Secret vs. Open— Secret offers control and focus, while Open runs the risk of “death by bikeshedding” (everyone knowing everything), but cultivates buy-in and reaps benefits that they couldn’t resist.
Miell passed every decision by his team because “Top-down doesn’t work.” He went on to make the comment that people see their own business as uniquely dysfunctional while other companies have it sorted all out.
He said trust your judgment because “If you’re in a business that’s making money, it must be good at something,” namely solving a problem in your domain.
Preparation, Preparation
The most common reason for failed business software adoption is failed onboarding. In fact pretty much everything in the digital world falls under this repeated system of failure. Teams wake up one day and Wham! they are supposed to use something new. This is not the way you adopt Docker, nor any other technology. You need to start by selling your teammates on the decision—why you are moving to Docker and how it will make their jobs easier—and create and communicate a plan of implementation—how will Docker be used and what you will be containerizing in what order.
And because Docker isn’t a one-size-fits-all tool, you should openly review with your colleagues which process they already use, try to anticipate how they could be affected and brainstorm any hacks and workarounds you may further need.
This should all be done as far in advance as possible, with at least one meeting—but probably several as it may take some thinking through processes in a new way day to day—particularly dedicated to Docker.
Oh and most importantly, these meetings must bring together both developers and operations. Here is where you can put your foot down a bit and almost force Devs and Ops to work together for at least a couple days, sitting together, trying out each other’s roles, organically developing empathy.
Flip The Switch
Unless you are building a business, applications or software from scratch, the switch to Docker can’t be made overnight. And developers didn’t want to switch to Docker mid-project, so it took longer than expected to finally implement. But once they did, Miell said there was a noticeable cultural shift.
You can see (above) how the process suddenly became clear for everyone. Friction between teams was dramatically reduced because there was no discussion about the archeology of the environment,” as each developer could choose to work in her own language and space, as well as the operations could replicate that same environment.
Miell said some early wins for Docker included:
- When there was a crash, they were able to provision in minutes via a laptop.
- Improved speed of delivery based on a reduction of duplicated effort.
- Daily rebuilding.
- Iteration earlier in the cycle.
But, as it is a large business, once he had made these decisions and implemented them, the only way to persuade the guys upstairs was to prove if it had a cost-saving result. Because of Docker, he was able to save the equivalent of four developer days per month
Miell’s final piece of advice for using Docker is “Try to avoid dependencies and bureaucracy when you can. Think in small tangible steps and future out the rest along the way.”
Docker is a sponsor of The New Stack.
Feature Image: Gaudi’s Sagrada Familia in Barcelona, via Pixabay.
