Scopely is a leading mobile entertainment network. Founded in 2011, Scopely partners with game developers and entertainment companies to bring industry leading distribution and monetization technology to free-to-play games. Scopely games reach millions of users globally and they leverage Amazon Web Services to manage and scale their back-end infrastructure.
Avram Lyon is the Head of Engineering for Scopely’s Publishing Team and led the effort to modernize their CI/CD deployment tooling with Armory Spinnaker.
Scopely’s Home-Grown 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.
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.
Spinnaker Usage Within Scopely
|Armory Spinnaker migration period||1.5 months|
|Armory Spinnaker replaced||Ansible, cloudformation and custom inhouse tools (fleet commander and amibaking)|
|Engineers using Armory Spinnaker||30 across 6 teams|
|Applications deployed with Armory Spinnaker||40+|
|Pipelines||Jenkins (before)/ Spinnaker (now)|
|Number of deployment pipelines||60+|
|Running platform||Amazon/EC2 (before), Amazon/Kubernetes/EC2 (now)|
|Blue/Green deployments||custom tools (before), built-in with Spinnaker (now)|
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.
Armory helps software teams ship better software, faster. The Core of our Platform is powered by Armory’s enterprise distribution of Spinnaker, the open-source continuous delivery platform created by Netflix and Google. Armory’s Platform enables you to increase your company’s safety and velocity, decrease your “time to value”, make your engineering teams more efficient, and minimize the blockers that slow your application teams down.