It started with a Shaky Leaf. Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry’s signature features, which signals to users that there’s a helpful hint you can use to find out more about your family tree.
So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on Kubernetes, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon’s recommended products, but instead of recommending products the company recommends records, stories, or familial connections. “It was a very important part of the site,” says Ancestry software engineer and architect Paul MacKay, “but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way.”
And when it went live smoothly in early 2016, “our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,” MacKay adds. “The development team was just thrilled because we’re focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.”
Figure 1: Paul MacKay presenting “Taking the Helm – Ancestry’s Journey to Kubernetes” at CloudNativeCon + KubeCon Seattle
The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. “It worked well for us in the past, but then some of the legacy systems became quite cumbersome in its processing and was time-consuming,” says MacKay. “We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products.”
That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like Java and Python on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, “but it always comes down to the orchestration part of it to make it really work,” says MacKay.
His team looked at orchestration platforms offered by Docker Compose, Mesos and OpenStack, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. “At the forefront, we were looking at the secret store, so we didn’t have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy,” he says. “We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit.”
The success of Ancestry’s first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. “After a while the engineers became our champions,” says MacKay. “At training sessions, the development teams were always the ones saying, ‘Kubernetes saved our time tremendously; it’s an enabler; it really is incredible.’”
The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don’t have to be moved over. MacKay estimates that the company is “approaching halfway on those features that are going forward. We don’t have to do a lot of convincing anymore. It’s more of an issue of timing with getting product management and engineering staff the knowledge and information that they need.”
To learn more about what’s ahead for Ancestry with Kubernetes, check out this in-depth case study.
Interested in more Kubernetes content? Get on the CNCF newsletter list for more Kubernetes information and updates.