From Yawn-Driven Deployment to DevOps Tipping Point

Source:- linux.com

GS Shop is one of the largest TV shopping networks in Asia, and one of the largest e-commerce sites in Korea with more than 1000 employees and 1.5 million users daily. Vivek Juneja of GS Shop’s Container Platform Team, at MesosCon Asia 2016, shares how he and his team moved this behemoth to the new agile way of running the datacenter.

We know that change is not easy, and Juneja shares many valuable insights in how to successfully manage completely revamping your IT department. Progress is hard even when the old way is difficult. Juneja describes their old practice of “yawn-driven deployment”: “We practice something called Yawn-Driven Deployment, deploying at 3:00 a.m. That’s what we were doing for a long time. Everybody gets together at 3:00 a.m. It’s a party. We deploy, and we have a lot of yawns, and that code goes to production.” Nobody really like working this way, but it’s what they are used to.

“When we look at any deployments or adoption of DevOps practices,” says Juneja, “We try to follow this adoption graph, which means, at the beginning, you’re in Evaluation Stage. And then you’ll start putting something in production so that you get some feedback, and teams get some confidence that this thing works. And once you reach a confidence in a production environment, you will likely see a tipping point.”

Juneja’s team deployed their new DevOps methodologies on both new and old services, running new and old side-by-side. “Which shows them the difference between the old style and the new style,” says Juneja, “Doing a compare-and-contrast node for that technology… we move traffic between them so that a particular percentage of traffic moves to the old environment and the rest goes to the containerized environment. This has trade-offs, but it also provides us the basis for proving the technology. So everything becomes mainstream. Everything becomes stable. That’s the time where we move everything to our new environment which uses Mesos.”

This process of introducing and proving changes systematically and in small steps worked so well that staffers went overboard and overloaded the new systems. “Our teams started creating more environments. They loved it so much, they would have environments for every new deployment that they were creating too much of it. Making it easy for our teams to deploy a service means there are too many of these environments laying around.” This is a common problem, users not understanding the true cost of their resource usage. Juneja’s team’s solution was to set automatic timeouts on dev-and-test environments. The infrastructure team learned about resource utilitization and developed good resource-management habits.

Watch Juneja’s full talk to learn more excellent insights into progressing from yawn-driven development to a more comfortable schedule, and to learn about bringing all of your diverse and sometimes competing teams together and working towards common goals.