Armory and Spinnaker enable Scopely migration from VMS to Kubernetes on EC2
Avram Lyon, Scopely’s VP of Technology, was the Head of Engineering for Scopely’s publishing team when he led the effort to modernize their CI/CD deployment tooling with Armory. Here, he shares some key observations from his team’s transition to Spinnaker.
Spinnaker usage within Scopely
6 Weeks
Spinnaker migration period
30+
Engineers using Armory
40+
Deployment pipelines
Scopely’s homegrown deployment tooling
In 2014, we decided to invest in our deployment tooling to support our growing cloud operation within AWS. At that time, there was no support for blue/green deployments so we built it ourselves using a combination of CloudFormation and Python scripts orchestrated with Jenkins jobs. This enabled us to roll out immutable deployments to all of our new game studios. This system was ahead of its time in many ways; we were using auto-scaling groups, we were baking AMIs, etc. (the details of this system are highlighted in our 2014 AWS re:invent talk). But as we continued to grow we wanted a better framework – one with more flexible scaffolding that would allow us to properly encode how we wanted to deploy without needing to write more tooling from scratch.
Spinnaker enabled us to focus on core business value
By 2017, Spinnaker had been in open source for over a year and was in a good position to enable these patterns for us. We didn’t want to be in the business of writing deployment software – we wanted to join a community and leverage the work that everyone’s doing. Instead of writing more orchestration code on top of CloudFormation or other AWS APIs, we could just use Spinnaker for that. That allowed us to focus on enriching how our game studios deployed.
On the Publishing side we wanted to give ourselves a more simple and less custom deployment strategy. We didn’t want new team members to have to learn all of the legacy systems. For example, we knew we had a severe under-utilization problem in EC2 and we saw Spinnaker as a way to simplify and codify better deployment patterns.
“The entire migration time to Kubernetes took just a few days because Spinnaker made it easy.”
Avram Lyon, VP of Technology at Scopely
Spinnaker as an on-ramp to Kubernetes
Both sets of teams (the Publishing Team and the game studios) quickly ramped up their adoption of Spinnaker internally. Our engineers were getting comfortable going to the Spinnaker UI instead of the AWS console. They don’t really know or care where their code is running, as long as their service has enough CPU, memory, and disk. That made it very easy for the Publishing team to move from VMs to Kubernetes on EC2. Spinnaker abstracts that away from the user. Even within the small application team, people can be insulated from the choice of where a service gets deployed. You don’t even have to think about it. The entire migration time to Kubernetes took just a few days because Spinnaker made it easy.
Scopely deployments at a glance: before and after Spinnaker
Spinnaker replaced four tools with one, making the problem of “too many moving parts” a thing of the past.
Commit. Deploy. Repeat.
Focus on writing great code, not deploying it!