Armory Spinnaker Features & Demo

Jan 1, 2018 by Armory

The founders of Armory give a demo of Amory Spinnaker and explains how this company can help you accelerate your business.

Transcription of the video is available below:

DROdio: Hi I am DROdio the CEO of Armory, in this video will show you features and do a demo of Armory Spinnaker, we’re not going to talk about the open source project, and we’ve got other videos for that. What we are going to show you is how Armory can help you accelerate your deployment velocity from being a stage one company still in data centers all the way through being a stage five company doing intelligent deployments. So to get us started I’m going to kick it off to Isaac our chief technology officer.

Isaac: Hi how is it going I am Isaac Mosquera I am the CTO of Armory, today I’m going to walk you through enterprise Spinnaker. So Armory Enterprise Spinnaker is made up of five different components, you’ll see them here, one is the installer, light house, composition, certified pipelines and barometer an automated canary service. So before we dive into what Armory and Spinnaker looks like I want to walk you through the architecture, so in order to have an architecture that is redundant, high availability and doesn’t cost you a fortune to run we offer this architecture for Armory Spinnaker. We have polling and non-polling instances, for the polling instances these are instances that are going to be querying your AWS or your Kubernetes clusters to figure out the state of each particular resource. Resources like instances or pods, load balancers, security groups, the information that gets back gets stored in cash and redis and when we run it inside of Amazon we use elastic cash with multiple instances so that it does have fail over capabilities and we are also continuously taking snap shots of the elastic cash redis instances. In addition to the semi transit information, we also store your application information inside of S3 now if we want to configure to be multi region so that you can handle a region failure, an entire region failure we can configure that for you as well and what Spinnaker will do for you and Amazon will do for you in the back end is copy over application configuration from one region to another. So if ever there is a region failure you can move over your users to the additional region. At the top we expose two interfaces or two elastic load balancers, one is the user facing load balancer, this is exposed to your users and there is only two ports that are actually opened up on that load balancer. One is just port 80 which allows just standard http communication with an application called Deck which just serves up html and the other one is 8084 which is essentially the gate into all of the other subservices that compose of Spinnaker and we also have an inter service ELB as well. What the inter service ELB is responsible for is inter service communication and we lock that ELB down so that nobody else has access to it with the exception of these instances here and that allows you to have a very secure deployment of Spinnaker so you can make sure that only the right people have access to the right resources. Once we have Spinnaker up and running configured, Armory gives you guys a boot strap installer so that you can get the architecture up and running and that’s a great place to start but the next question you have is how do I upgrade Armory Spinnaker, how do I get new versions deployed to my instances in a safe manner that doesn’t cause down time and allows me to guarantee safety to my customers or my users that are using Spinnaker so they feel comfortable and confident with Spinnaker and what we do is we develop a pipeline that has zero downtime and it effectively allows Spinnaker to deploy itself. So here you’re looking at our internal version, this is Armory’s internal version of Spinnaker and we actually use Spinnaker to develop Spinnaker itself. So what kicks it off is a commit to a master pipeline insider of Jenkins, once that is built and the package is available to be deployed, we then kick off the pipeline. We have a pre bake Docker composer MI that we use across the entire company that we put Armory Spinnaker on top of. This could be replaced with other MI’s it doesn’t have to be the MI that we give you, it could be used with Ubuntu, Red hut, [inaudible 04:39], the Amazon MI, so whatever your base MI is within your company that guarantees security and safety we can use that as well and what we do is we bake Armory and Spinnaker on top of that package so that it remains consistent with the rest of your deployments and the rest of your company. We then bake a configuration on top of that base image with Armory Spinnaker and the we deploy the pre pod, so this brings up an instance that is effectively like a staging environment or an isolated environment that doesn’t affect prod and this is really critical because what we don’t want to do is create a whole bunch of configuration, apply it to the machine send it right to prod because that could have catastrophic effects, it could literally take out the entire system and it will take time for you to roll back so we instead deploy the pre prod and then we run a bunch of integration test against that. To verify that our configuration or accounts, everything that Spinnaker depends on is working well together. So what we do is actually use Spinnaker to task Spinnaker by configuring a bunch of pipelines that do things like roll backs, Canary deployments, baking an image, transitional deployments so this is while other deployments are happening we’re actually testing the upgrade capability to confirm that there is no downtime and this provides the confidence for us to move to production. When we move to production we deploy a red-black strategy which is also known as blue-green, what this will do is that it will create additional ASG in the background or auto scaling in the background, you can actually see us deploying right now V007 is the old one V008 is actually coming online. Once V008 is available what Spinnaker will do automatically for you will disable V007 so that there will be no downtime and leave it around for a period of time so that if V008 happens to have a problem I can easily come back here and roll back to that previous version and to give you an idea what that looks like I literally would click on, we actually clicked on this already, okay rollback and I would select V007 or even go back to previous server groups that have left behind. So I go back to six and five if I felt like I needed that and that gives you the safety and the guarantee you need in order to operate Spinnaker especially at scale when your running into large enterprise problems with developers all trying to deploy at one time.

Ben: Hey my name is Ben [inaudible 07:21] I’m the chief product officer here at Armory and I’m going to tell you about certified pipelines. So this is a feature that enables teams to get out of the traditional way that they deploy. Usually what we’ve seen at most companies and especially most enterprise companies is a process commonly known as CCRB or the change control review board where for every change that goes to production a team of people or committee needs to approve it, what are your roll back mechanisms, what’s the risk of this change to our customers to our production environments, things like that which is highly manual. It’s all done for safety reasons and what we are proposing with certified pipelines is a way within Spinnaker to define all the things that you care about, the things that create a safe deployment and codifying that within Spinnaker and applying that policy to all or some subset of the applications that should adhere to that policy. So for example what are the things that make a safe deployment, well you want to do testing, unit tests, and you want to do integration testing, smoke test, and performance test. All those things you can require in your policy, other things you may want to do are security scanning, status code analysis, canaries, so there are a lot of different tools that you can use at your disposal within Spinnaker and there are stages within Spinnaker for each of these things just through this UI require the stages that you care about and then apply them to the application within Spinnaker that should have that policy. So this is the UI where you would do that scrolling down a bit this is what the Spinnaker UI looks like and here is a pipeline when the policy is met, so this is a policy called CD approved so when this pipeline has the required stages in the CD approved policy you’ll see a badge appear on the pipeline view so you know that your good to go and you’ve met the requirements for the security team.

Isaac: I’d also like to walk you through barometer our automated canary service and what this will do it will stand up a base line or basically a control group as well as a canary server group and compare those statistically against each other based on metrics and bounds that you configure in this stage, it is a lot safer because one it is not a human doing an evaluation of metrics haphazardly. It’s actual machines doing the computations in the background and in addition we do scan up a control group that looks just like the rest of your server group and compare that with a canary that is exactly the same size and it scales up at the same rate. So we are able to compare these metrics together which is not normally done through a manual canary through a manual canary where it is just one sever and one group. Let’s go through this, so this is the canary stage which you can add into your pipeline, we can configure how long the lifetime of a canary will be, this could be a short lived one or it could be one that lives for three hundred and twenty minutes or three thousand minutes depending on how long it takes for you to get confidence in the deployment. Will select our base line version, this is what we will do to clone what’s already out there, so if you have version 1.4 deployed we will clone version 1.4 and create a smaller server group for you automatically so that you don’t have to orchestrate that on your own and then will also grab the new version of the application that your trying to deploy. So you see that configuration here, you can configure them with different stacks and details as well as different load balances and perhaps attach them to different target groups that’s inside of the application load balancer and then a whole bunch of other configuration objects that you can use for your canary and that will allow you to have a bunch of different canaries scenarios. We can also allow for a warm up here, the warm up here is essentially a time that it takes for your machines to get to a steady state once they are deployed. Barometer also looks at a few data sources and so one we have is data dog, we also have Elastic search as well. So let’s go through what each one will do, for Data dog, will look at three different types of metric comparison. The first one is to the event stream, so if there are any errors that come from the event stream that have the canary tag associated with them what it will do is that it will automatically fill the canary for you and this is good for having absolute balance and things like response time should never go over four hundred milliseconds. The next one is a dashboard, so we create this dashboard for you automatically, so even as your starting to gain confidence in automation the dashboard allows you to still have that manual check, that human intervention to say ‘hey this does look good or not and will show you that in a little bit. The last one is just a standard metric comparison and so we have an algorithm in the background that is checking the canary series data series against the base line data series against the base line data series and from there you can specify as many metrics as you want. Here we’ve specified four of that essentially let us know if the canary is healthy or not but you can specify hundreds or thousands or metrics but what’s really important here is to identify the metrics that do show the actual health of your application particularly from a user point of view, not just from the inside of the application but you can track things like revenue or transactions per second and if those were to dib relative to the rest of the base line server groups then the canary would fail. Let’s look at what an actual pipeline looks like once it’s running, will go here, so this is our canary data dog matric, here this canary was a success and here will show you the dashboard that we configured earlier so if you check ‘create automatically, create this dashboard, you don’t have to do a thing, it will automatically create this dashboard with all the metrics that you were trying to compare and for the given time period so that each individual canary run is unique and this saves you a bunch of time, so you don’t have to go into data dog and manual and build these dashboards each time. So here you’ll see that this is the base line group that’s blue and then the purple group is the canary and so these times series look close or trending together, these also tend to trend together as well as CPU idol which is probably why this was deemed a success. Once it’s a success it will tear down the canary infrastructure so that if this does fail you also have a very nice clean start before deploying into production. So here is a standard deploy and that only happened because the canary was a success. You know as you’re starting now with the canary you can also interject the manual step here again so just you can have a human being check those metrics that you saw earlier and that’s it for barometer

DROdio: Hopefully this video has given you a good understanding of Armory Spinnaker, the last thing that will mention is the way we handle support. Armory has two types of support, standard enterprise support and premium enterprise support, the big difference is that with premium support we offer an SLA on Armory Spinnaker which is very important to various enterprises as well as an on demand access to a solutions architect up to 24 hours per month to help you operationalize Spinnaker within your organization. So we’re happy to chat more to understand your needs and see how we can provide value, thanks for the time.

Share this post:

Recently Published Posts

Navigating AWS Deployment Targets with Armory

Jan 20, 2023

Many organizations look to Amazon Web Services (AWS) to host and deploy their applications in the cloud. However, they’re finding that their deployment tooling, often built as an extension of their legacy continuous integration (CI), is one of the main impediments to adopting cloud services.  Custom-scripted production pipelines built with in-house tooling need to be […]

Read more

Release Roundup – January 2023

Jan 11, 2023

Get the latest product news on Continuous Deployment-as-a-Service and the most recent release for Continuous Deployment Self Hosted, 2.28.2. Welcome to 2023!  Just like every organization, Armory is looking for ways to improve our practices and deliver more value (and faster!) to you, our customers. That’s why our engineering team is working to deliver features, […]

Read more

Learn Continuous Deployment with Armory and Wilco

Jan 6, 2023

Armory is excited to announce we have launched an interactive, narrative-driven developer experience that teaches continuous deployment concepts. And now you can try it out for yourself! Wilco, also known as the “flight simulator” for software developers, allows companies to create engaging interactive developer challenges (called quests) that enable developers to acquire and practice skills […]

Read more