Spinnaker & Armory Explained by Matt Miguel, VP of Engineering

Matt Miguel, VP of engineering, chats about how Armory came about and what they are trying to accomplish.

A Transcript of the video is available below:

Hi my name is Matthew Miguel a VP of engineering and talent here at Armory, I am here to chat a little bit about why Armory exist and what we are trying to here. Armory really came from our co-founders, the joined the company at the leadership level and it came to an environment where the engineering team was doing about four releases a month which is actually fairly standard, you’re talking about weekly spreads at that point you know it’s something pretty normal you know everyone bundles up and do this, what ended up happening at about the course of the year is that there is a very significant culture change, the infrastructure code culture delivery really just kind of integrated over and over as fast as possible and over the course of a year or so the engineering team was doing about twenty four hundred releases a month and it’s not again something that happened overnight but what we’re seeing is that it’s a product and an engineering team is able to deliver entirely to business lines, create entirely new lines of revenue out of nothing just based on their ability and order of magnitude more effective in deploying actual features of product to production. Kind of going through those and seeing what kind of transformative value this has had in their team right they say you know what I kink we want to unlock this for every company, we want companies and engineers to feel more productive and not to be tied down by process and just kind of a status quo as it is right. The company that they start is called Armory, it’s something that you’ve heard at this point we’re happy to have your interest in us. What I want to talk about is how Armory can help unlock some of that transformative value for you and your company or all of our customers. When I think of how to achieve twenty four hundred releases a month right it really just starts with eat developer and kind of a platonic idea of what they’re trying to do. Now a developer is typing into their laptop and at the end of the day what ends up happening whether you are at four releases a month or you are at twenty four hundred releases a moth is that there’s a bunch of steps at process and nonsense that you have to go through before your actual code that you type and the editor and the ID gets into the cloud and production and eventually it will hit someone’s mobile app or web browser in the form of a running service of some kind right. Now in order to hit these twenty four hundred releases a month or more and what you’re going to see is that there is a lot of automation here but what ends up happening is that you kind of hit this magic point where the developer stops caring about this, right. You are at a point where this is a fast and rapid transfer and it’s safe right and if it’s not safe and you’re not getting anywhere with it you, need a developer to be able to get commit and get push and knowing that that code is going to get to production and the worst case the code is going to be kicked out of production if it needs to be and that’s where Spinnaker comes in. When I first started using Spinnaker I kind of experienced this. All I want to do is push my code up to the version control service and the next thing I know five ten minutes later magically what happened it fell ahead of its time right, you’re dealing with a system where this is basically from my point of view where I thought cloud deployments were going to be five or ten years from now, that’s kind of how we think of ourselves at this point a little bit ahead of the curve in terms of how deployment should work. Now the reason why a lot of stuff in here, the reason a lot of stuff in here I think its important thing to note when I think of the ideal continues delivery stack is that we’re automating as much as possible, I’m not going to get to these numbers without automation, the stack I think the kind of my ideal stack that looks like this you still need a version control of some kind. I’m going to use GitHub here as an example right so the developer still is going to be able to get commit and get push right. You’re still going to need a unit testing right, typically Jenkins is a very common solution here, and you can swap that out with whatever system you’re comfortable and familiar with. The role of this of course you know for continuous integration is your running your unit test on every commit, you doing things like packaging. Now what you’re not doing is you’re not using continuous integration tool for deployment or delivery right. That’s kind of, I’m not going to call it an a square picking around hole but you’re not using the tools to its strength right, the tool that Armory is built around is called Spinnaker, I’ll write Spin for short on the white board my handwriting is that great I don’t want to submit you to any more of my atrocious letters than I have to. The ideal Spinnaker stack is that you’ve got a Spinnaker kind of on top controlling a set of environments right, the typical environments that you think about, you know you you’ve got your div you’ve got your test, staging and prod of course right. Each of this tends to be you know an ideal case a Kubernetes cluster and a Kubernetes cluster of course is going to manage a handful of Docker containers, you know some number of Docker containers right and by a handful I mean tens, hundreds, thousands of Docker containers in a given cluster at some point in time deepening on your situation. Now Spinnaker has got a flexible, pluggable architecture so you could replace Kubernetes cluster with an auto scaling group and replace Docker containers with rocket containers or VM images or anything like that. So it is flexible in terms of that layout, Kubernetes is a Docker, I consider the ideal stack because it’s going to be one of the fastest, the lightest way set ups you can do at this point in time. Now the technology here is not kind chosen arbitrarily, it is one of those things where we want to have the right tools for the job right. We believe Spinnaker is helpful because it thinks for things like load balances and clusters and cloud and cloud platforms as first class a very native thing, it’s not something, you’re not writing a bunch of glue code or custom scripts and you know that maybe fragile or require maintenance in order to keep your bill running smoothly right. So Spinnaker has got a very high level knowledge of how the cloud works and the ways to architect and put it together soundly right. Kind of the notions that are important Spinnaker from our point of view really starts to keep the abstraction at the right level right. You know when I say abstractions I’m talking about why we chose this technologies right. You think of a technology like Docker right, Docker is important and core technology because it is kind of the first technology that allowed a developer to abstract a way, the web service or the app they are building away from the OS. Prior to Docker you think about how a Rubi on rails of a jungle app is tightly coupled with the OS in terms of the right version of right version of python and the right libraries and all that stuff installed and the right version of Rubi for example right. Kubernetes has got a strong abstraction that we really like because it was, it allows us to abstract a way right, the cluster from the actual underlying VM’s that your running on. If you’ve got a bunch of Docker containers right and you don’t have orchestration right basically you say ‘oh I’ve got twelve VM’s on which of these twelve VM’s do I want to run each of these twenty Docker containers or more right. If you’re talking about hundreds of thousands of Docker containers you can’t actually manage that manually anymore so it’s kind of a cluster orchestration is a strong abstraction that we’re kind of taking advantage of. Spinnaker kind of kicks it up a notch right, your talking about a higher level abstraction right, Spinnaker is technology that allows you to abstract a way right, the environment away from the data center or the cloud provider right. With Spinnaker you’re not so much thinking about ‘oh is this an amazon o
r an Azure app or anything like that, you’re thinking about things, environments such as dev and test and production and what not right, the way it’s working again with the pluggable infrastructure, the pluggable architecture of Spinnaker right it doesn’t matter if your deploying to Amazon, you can kind of swap out you know your deployment target you can use Google cloud, you can use Azure, you can deploy to a handful of different clustering orchestration clusters you know like Mezzos or Kubernetes. We link Kubernetes but you can make a reasonable argument for any of this as long as they hold up some of the core capabilities that we expect and cluster and technology right now. Spinnaker itself is kind of where you go to set up you know these production delivery pipelines, you can customize them, you can make it and what you get at the end of the day is that you get a process where your able to eliminate a manual steps, your able to eliminate fragile shelf scripts and your allowing your team, your developers right to focus on writing code and committing and then seeing when it gets to production, you know a well configured Spinnaker is going to pull stuff back right, if things are failing smoke test or things are causing issues in production and an undo a roll back as necessary and that’s how you maintain velocity. The cost of mistake is reduced because the system is going to automatically pull back for you, so you get velocity and safety without necessarily having to sacrifice one or the other because you’re not going to get here, you’re not going to get to twenty four hundred releases a month if you know one out of every ten is going to take down your system and affect your SLA’s. Armory itself right it takes the open source Spinnaker and adds and enhances it right, if you want to go ahead with open source Spinnaker your happy to, I think Armory here is happy to support and promote Spinnaker the project but Armory the company is here on behalf of customers that might need something a little more right, we help you run and maintain Spinnaker SLA’s, we’ve got a whole bunch of enterprise level features and add-ons for Spinnaker. If your managing a thousand engineers for example your needs are different from a startup which is just a handful of people and I think we want obviously we want our company to succeed and we think we’re in a good place to do so and we’re definitely invested in the future of Spinnaker as well. From my point of view as a developer who has been doing this for quite a while I feel like Spinnaker is again you know ahead of its time, it’s one of those things where you know ten years from now the vast majority of deployments will be going through Spinnaker in some way, shape or form, if you have any questions about it I’m happy to, you know we’re happy to chat with you at any time and we look forward to what we can do together, thank you very much.