Life Before & After Spinnaker
May 3, 2018 by Ethan Rogers
Sometimes a new technology comes along that changes a person’s life in such a drastic way that it’s hard to imagine life without it once you’ve experienced it. All of us who remember life before cell phones can probably relate. How did we ever get in contact with anyone? How did we get anywhere?
Spinnaker is that kind of transformative technology for application developers and engineering leaders, and I’ve experienced the difference first-hand. I’d like to share some personal stories and examples of life with & without Spinnaker, to help everyone understand it who’s never experienced the pain of cloud-native software delivery using outdated tooling meant for the data center, or the difference between using modern tooling like Kubernetes, vs. Kubernetes with Spinnaker.
Let’s start with Kubernetes
The most important point to make is that, for all intents and purposes, Kubernetes is just another “cloud.” Kubernetes as a “cloud” means that it serves all the same purposes as AWS, GCP, Azure, etc., but it does them for containers specifically. When you spin up an EC2 instance in AWS, their “orchestration” places your VM somewhere within their infrastructure. Kubernetes does the same thing, but instead, it abstracts away the orchestration so that you can place containers anywhere within your infrastructure. It also has the added benefit of being cloud-agnostic so that it can run anywhere. Now, just as with AWS Auto Scale Groups, Kubernetes is responsible for keeping your containers running and available. If a container dies, that container restarts.
This is the key differentiator between Spinnaker and Kubernetes: You can think of Kubernetes as being responsible for availablity and Spinnaker as being responsible for delivery, and that is where Spinnaker delivers more value than other tools on the market.
Kubernetes take a very “infrastructure first” approach, which means that engineers deploy their application and supporting infrastructure. What I’ve found, however, is that most engineers don’t actually want or care about all of that power. They want an “application first” approach. They want a tool that is tailor-made for them to focus on what they do best: Delivering their application and adding business value as quickly as possible instead of mucking around with complicated APIs.
Spinnaker is the first tool I’ve ever seen that takes an application-first approach to software delivery. By logically separating resources by application, developers now have a dedicated place to maintain and operate their application. They have a dedicated place to build out pipelines and deliver their applications. This space doesn’t exist in any other tooling.
We’ve written a lot more about using Spinnaker with Kubernetes (including with Helm). You can check that out here.
Spinnaker vs. Roll-Your-Own
Spinnaker is in a very unique position to help teams deliver containerized applications faster because it takes the overhead of developing and maintaining CD solutions out of the equation. Literally, every other solution on the market (Jenkins included), at some level, takes a very code-based, scripted approach to the software delivery problem. Each one of them is reinventing the wheel with different levels of abstraction, but never getting to the heart of the problem: Scripted solutions aren’t as flexible or scalable as you may think. I can’t tell you how many times I’ve seen teams who are using this approach ask the question “well what if I need to do X as part of my deployment pipeline” and other users of these approaches just shrug. I’ve seen it in the workplace, at conferences and online. At the enterprise level, deployments are always unique and need a unique solution that is flexible and can handle the amount of change that these organizations experience on a daily basis and Spinnaker is the only tool that fits that category.
I gave a talk awhile back about my experience moving beyond scripting with Spinnaker (start at minute 2:25):
Spinnaker vs. Extending CI Tools
In my experience and personal opinion, the industry is moving toward Continuous Delivery but trying to force these concepts into existing Continuous Integration platforms. Tools like CircleCI and TravisCI are 100% unsuited to perform deployments in the enterprise because they are extremely inflexible. They don’t have the ability to run 1-off jobs; they can’t be triggered manually, etc. Teams using these tools and who need to have a Manual Judgement as part of their promotion path are stuck doing it by hand because their tooling constrains them. This lack of constraint is where Spinnaker adds tremendous value over off-the-shelf CI tools. With Spinnaker, teams build a single pipeline that handles promotion through as many environments as needed with whatever gates and checks necessary and it’s 100% automated without writing any code or maintaining a homegrown solution.
Specific examples of life with Spinnaker:
Sometimes, specific examples can help showcase the before & after in stark contrast. Here are some use cases that highlight life with Spinnaker, vs. without:
“I don’t want to build yet another deployment platform:” An infrastructure SVP at a Fortune 100 company has application developers coming to his office every day saying they want to move their applications to Kubernetes from VMs, because it allows them to iterate faster on their apps.
This leader knows he needs to containerize his workloads but the prospect of re-doing all of the custom code his team has written over the past five years to deploy directly to VMs on AWS is daunting. He remembers hearing the same reasons five years ago when developers were coming to his office, clamoring to deploy to VMs in the cloud rather than data centers. To him, it’s just like Groundhog Day, and the last thing he wants to do is make all the same mistakes. Based on this pattern, he’ll have to do it all over again in another five years, probably with FAAS and Serverless. Just the thought of re-building this complex, custom deployment platform — which he also has to maintain— every couple of years makes him want to jump out of a window.
With Spinnaker, this SVP doesn’t have to re-build his platform again. Spinnaker abstracts the underlying IaaS providers into a PaaS which his team can now use. Now, for the first time, he can swap out the underlying targets (say, from VMs to Containers) without disrupting his developers’ software delivery workflows. Spinnaker’s cloud drivers handle the connections between the platform and the underlying cloud providers. This SVP can now migrate his workloads to Kubernetes today… and he’ll be ready for whatever the latest cloud trend is the next time developers walk into his office.
“Getting out of scripting hell:” A team of developers at a Fortune 500 Company spent a month creating a new path to production for a mission-critical banking application using Helm for Kubernetes. This banking application is responsible for supporting the bank’s primary line of business. The bank had an urgent issue in another part of the business, and this team of developers was re-deployed for several weeks to resolve that issue. During this period, one of the senior Managers told this application’s developers that he needed to approve all deployments before they went to production since this is such a mission-critical application. But the team that scripted the path to production did not include the ability to have a manual judgment in the deployment process nor did the tools allow for it, leaving the team scrambling to adapt to this new business requirement imposed on them without having the ability to easily change how the application is deployed to production.
With Spinnaker, adding a manual judgment stage would have been a simple 30-second drag-and-drop change in the application’s deployment pipeline.
Here at Armory, we believe software is the highest leverage way to improve humanity — which also makes software the highest leverage way to unlock enterprise value for companies. I hope the examples above help show how life with Spinnaker is transformatively different for enterprises that care about making cloud-native software delivery a core competency.
The Armory Platform automates software delivery, enabling software teams to ship better software, faster. At the Core is the minimum set of developer tooling a company needs to achieve “Stage 3” — Continuous Delivery of software. Powering the Core is our enterprise distribution of Spinnaker, the continuous delivery platform that codifies the software delivery best practices that put Netflix and Google a decade ahead of most other companies.
Contact us if you’d like to learn more.
Recently Published Posts
A day in the life of a TAM
I’ve been asked what a Technical Account Manager (TAM) does so I wanted to take the opportunity to illustrate it by walking through a standard day in the life. Before we can look at what a day in a life of a TAM is, I should provide some background in what is a TAM and […]
Read more →
Nikema’s Spinnaker Summit 2021 Recap
My Second Spinnaker Summit is in the Books! Last week I attended and spoke at my second Spinnaker Summit. Like last year’s summit, it was fully virtual. This time Spinnaker Summit was co-located with cdCon and took place on the Hopin platform. Last year, I spoke on a panel about Black professionals a few months […]
Read more →
Announcing General Availability of Armory Policy Engine Plugin
Armory Policy Engine provides support for automating policy compliance with Spinnaker. Policy Engine Plugin is the latest version of Policy Engine and adds support for both advanced role-based access control (RBAC) use-cases and open source Spinnaker. The release of Policy Engine Plugin comes with new documentation, including a library of example policies from across Armory’s […]
Read more →