MakerBot is an American company specializing in 3D printing technology. It has a range of products covering not only the professional industry, but also education programs for universities and schools.
Armory’s Platform at MakerBot
First service migrated to Armory’s Platform in: One week
Transition to Kubernetes from Amazon ECS: 2.5 months (Nine months originally planned)
Armory’s platform replaced: A mixture of Ruby, Chef and Jenkins glue code
Engineers using Armory’s platform: 5
Applications deployed with Armory’s Platform: 45
Number of deployment pipelines: 130+
Platform deploys to: Amazon ECS (before), Kubernetes on Google Cloud (now)
Bills savings from the switch to GCP/K8s: 50%
Deployment frequency: 1-2 times per week (before)/10-12 deployment per day (now)
MakerBot’s homegrown Ruby deployment scripts
Before integrating Armory’s Core Platform, all of MakerBot’s infrastructure was running on Amazon ECS. Deployments happened via a set of Ruby and Chef scripts from a Jenkins CI server. Deployments were only performed by the DevOps team (i.e., Richard), preventing developers from deploying on-demand. In this environment:
- Deployments were only happening once or twice a week
- The DevOps team of one was a single point of failure for all deployments.
The second point was particularly troublesome: If Richard were sick or went on vacation, deployments would inevitably stop during his period of absence. It was clear that self-service, continuous deployment practices would greatly benefit MakerBot.
Richard had heard about the Spinnaker OSS version from a friend at Netflix and decided to leverage Armory’s Platform in order to make all MakerBot deployments run in a self-service manner.
During a needs analysis, MakerBot also revealed that it had decided to transition from Amazon ECS to Kubernetes on the Google cloud. While this may be a problem for a closed source system, because Armory’s core platform is supported by the open source project, Spinnaker, it can natively support both ECS and Kubernetes.
Moving into self-service deployments on Kubernetes
The initial Proof Of Concept (POC), consisting of transitioning a single application into Kubernetes and Spinnaker instead of ECS and Jenkins, took just one week. The successful POC determined that deployments based on CircleCI free up the engineers at MakerBot from managing the continuous integration server themselves.
Armory’s core platform also helped shorten the ECS to Kubernetes migration timeline from MakerBot’s original assessment of nine months to two and half months. Because Spinnaker can support both Amazon ECS and Kubernetes as deployment targets, applications could still target both ECS as well as Kubernetes, which allowed for a smooth and gradual transition.
“The original plan from moving into Kubernetes on Google Cloud was budgeted for 3 quarters (9 months). With the help of Armory’s platform this time was shortened to 2.5 months”
Here is an overview of the migration process:
Armory is Spinnaker at enterprise scale
Apart from the shortened migration period, the other results from the move to Kubernetes and Armory’s Platform are:
- Deployments now happen 10-12 times per day allowing MakerBot to push new features much faster into production.
- Deployments are now completely self-service. All engineers have access to Spinnaker in the Core of Armory’s platform, both for testing and production pipelines and can deploy in any environment according to their schedule.
- Costs from running in GCP and Kubernetes are down 50% from running in Amazon ECS.
- Richard is free to work on the infrastructure itself instead of having to hand-hold deployments and maintain homegrown legacy scripts.
Armory was instrumental for this move to Kubernetes. The first application that was moved into Armory’s platform served as a Proof-Of-Concept that further supported the Kubernetes transition. This convinced MakerBot that Armory Spinnaker could gradually move all applications from the old cloud to the new one.