kreizihorse - Fotolia
Just as the real-life Rosetta Stone helped explorers decipher ancient hieroglyphics, Docker has been the key go-between for developers and operations at the company named after the famous rock.
Rosetta Stone Inc., a global education technology software company that offers language, literacy and brain-fitness products, uses a pastiche of tools to make up its application development pipeline. This begins with Atlassian's JIRA ticketing system and Bamboo continuous integration/continuous delivery tool and ends with Chef for configuration management on the IT operations side of the house.
When the company embarked on DevOps automation about 18 months ago, it was still so early in Docker's development that inter-container networking wasn't baked in to Docker Engine, and products including Docker Datacenter and Docker Cloud had yet to see the light of day. So Rosetta Stone started its DevOps journey with a system that used Chef to deploy applications onto the production infrastructure and maintain configurations on the underlying virtual machines running in Amazon's cloud.
This worked, according to Wes Deviers, manager of data center services at Rosetta Stone -- and would have continued working, if not for a lack of alignment between app dev release cycles and the configuration changes made by ops to maintain the production environment.
"Sometimes the Chef client runs, especially in Amazon, got to be pretty long -- three, four or five minutes at a time," Deviers said. "We'd have code in staging that we'd have to remote to production very quickly in order for it to sync with something [developers] needed tomorrow."
The Rosetta Stone organization initially created an alignment between application and infrastructure updates in a manual, face-to-face process that resulted in lengthy meetings between developers and systems administrators.
"Some of our lead developers were having to figure out and decipher some of our Chef recipes to make sure [the recipes] didn't intersect with their code changes," Deviers said.
Kevin BurnettDevOps lead, Rosetta Stone
Meanwhile, on the app dev side, this disconnect led to painfully long release planning meetings and threw a monkey wrench into rollback, according to Rosetta Stone's DevOps lead, Kevin Burnett.
"We'd have release readiness meetings and discuss the 60-something issues that were in our issue tracking system that would be released on any given Tuesday and try to figure out ... whether rollback was possible," Burnett said. "When things would go wrong we'd have no idea how to begin to debug what was going wrong."
Docker unlocks DevOps automation
Enter Docker, and an open-source container orchestration tool maintained by New Relic called Centurion.
With Docker containers, IT operations can do security patching for the underlying operating system without having to do full regression testing on everything every time. And since Docker containers offer a boundary between the underlying host operating system and the applications being developed by Burnett's team, "now we can do server modifications, and as long as we present the same version of Docker and the same basic back end, they can release their applications on a Docker image without worrying so much about the changes that we've made," Deviers said.
Meanwhile, Centurion can orchestrate automated zero-downtime rolling deployments with some custom integration code with which Rosetta Stone's IT team automates its load balancers. This extensibility was among the reasons Rosetta Stone chose Centurion over other orchestration products, but the company is continually evaluating container orchestration products as they evolve to see if another one might be a better fit. For example, the company is currently experimenting with another open-source Docker management tool called Rancher.
This pipeline for DevOps automation is still being fine-tuned, but the company is already seeing results: Application releases happen seven to ten times faster than they did previously, according to Burnett.
"We've been able to fix load-balancing and other issues that are essentially coming from our codebase," he said. "We can fix them prior to customers complaining about them -- and that is a really good advance for us."
Getting started with container orchestration
The container scalability struggle is real
Exploring container orchestration options for OpenStack