 My name's Greg Turnquist, I work on the Spring team at Pivotal. I'm the author of Learning Spring Boot, and there's actually a video based version of that coming out this fall. So if you wanna find out about that, I'll shamelessly plug, go to my website, greggalternquist.com and sign up to find out about, to hear about that coming. So I wanna jump in and say, what do you do if you need to deploy something like 2000 commits a day? That's the volume about, that's the velocity that Netflix does today. Because they have over 2000 commits a day. What if you've entered into the microservice space and instead of having one big monolith that you're deploying, you have a lot of different complicated services. And you need to do stuff like scaling, different times of the day. You need to ramp up or ramp down based on traffic and things like that. Now, your team may have gotten really good at building artifacts, either using Jenkins or perhaps using Travis for doing build jobs. But there's more to deployment than just building artifacts. Maybe you could be in a shop where you have some complex deployment procedures. Your QA team has written a 23-page acceptance test procedure, something I definitely faced in my previous job. And everybody today wants options, options, options. Maybe some of you are using Pivotal Cloud Foundry, some of you could be using some of the other Cloud Foundries that are out there. Maybe you're using Amazon or some of these other Cloud providers. And everybody wants flexibility, but you want to be able to use essentially sort of the same tool suite. So your investment in building a deployment strategy isn't something you have to rip up and throw away if you're gonna migrate to a different Cloud solution. I have a little math here. I went and did some computations, cuz I actually didn't realize the scale of what this is. I once worked for a company where we got a deployment out about every three months, and that we had to bring in the whole team. It was an all night job, but that was no big deal. But you go into microservices and maybe you start doing 10 services. And you get once a day, cuz you start to get into continuous integration and stuff. Well, the scale factor becomes 900 times whatever that effort was. And if you start to move it up to say, maybe you get out 10 times a day. It goes up to 9,000. And even if you have some 20 different microservices and developers are pushing out all these tiny changes, it suddenly comes an enormous scalability factor when you're trying to do deployments like this. At some point, somebody's gonna say that 23 page procedure that QA wrote for us two years ago is not cutting it. And we need a way to get our arms around it and figure out where are the inefficiencies in our process. The solution to that, of course you could guess, was Spinnaker. This is kind of a quick summary of what it is, what it has. There's a lot more depth to go into. Either we're not gonna cover. But essentially, it's a pipeline-based engine for doing continuous deployment. It supports deploying to multiple clouds in the same pipeline. And by that, I mean, I've got logos for all the different supported platforms that it handles with Cloud Foundry at the top. But you can recognize some of these other clouds. You can have one pipeline that, in one step, could be deploying to OpenStack, and in the next step, can deploy to Cloud Foundry. It's that flexible, so it's all in one place. So there's no sense of, I need Spinnaker over here to talk to Kubernetes, and I need another instance of Spinnaker to talk to Amazon Web Services. It has things like various triggers. Like you can have it triggered by a Jenkins CI job. That's what Netflix happens to use in their shop. But a lot of people are picking up Travis as a popular tool. So they can also trigger based off of a Travis job and some other things. Some of the stages they have include what they call baking images or finding images. And that's where, if you need to take a jar file and bundle it up in a Debian package and stuff it inside an Amazon machine image, and that's what your deployment artifact is. Or if you're using something like Pivotal Cloud Foundry, all you need to do is get the jar file and push the jar file out to your target deployment environment. There's also things like manual judgments. There may be certain steps in your process. You need the pipeline to pause and go for human intervention. At this stage, go to QA and tell QA to go run their 23 page acceptance procedure, and then come back and bless the pipeline to proceed. And a big thing, definitely in this day and age, that a lot of people have had to hand cobble together in the past is absolutely zero time upgrades. Anytime I go talk to government contracting and stuff, you start talking about five nines of availability and this kind of stuff, where you need uptime, uptime, uptime. Spinnaker definitely supports that kind of stuff. And a big key feature is it has notifications. You can have notifications over a whole pipeline or over the individual steps, where you can have email, SMS. I added Slack support because we moved to Slack about HipChat. So that's enough for a quick speed up introduction, but let's go and jump over to an actual deployment that I have. So I'm going to, here I have a copy of a pivotal CF running, and over here in my dev space, I actually have all the modules for Spinnaker deploys. I'm actually running this deployment on PCF, which means my deployment does not depend upon a conference Wi-Fi. But I actually have a couple of spaces over here, a staging space and a production space. But I'm not going to actually run it from a PCF and said I'm going to go over here to Spinnaker. So here's the UI right can look at. I have a demo that I built on using Spring Data Rest. I'm a Spring developer, I like to write Spring apps. So I have a demo app here that I have installed into staging and installed into production. And what I want to do is go and look at the pipeline definition that I have here. I have two different pipelines, deploy to staging and deploy to production. Now what I'm going to do is I'm going to actually launch this because the entire installation procedure is going to take about 10 minutes and I want that running in the background while we can go look at it. Now normally I would be triggered by some kind of build job but for demo purposes I'm just going to manually launch the pipeline. So what is it doing? Well, while that's running let's go take a peek here at this pipeline definition. It's a series of chain steps up here and it starts on the left hand side with a trigger. This says GitHub, you can be triggered by a GitHub event if you want to, but you could also just as well pick Jenkins. Down here you could pick Jenkins. I don't have the Travis stuff flipped on in this configuration in particular but you can also have one pipeline trigger and another pipeline and that's what my second pipeline actually does. In this pipeline what it does is it deploys my app into staging. So if you're familiar, I'm assuming a lot of people in this room will probably use Cloud Foundry to some degree. It's essentially like doing a CF push job. So push it up into my staging space. The next step is I want it to go and disable what's called the old server group. In Spinnaker we refer to these instances of server groups so disable the old ones so all the traffic is going to go to the new one. And then the idea is I want QA to go out and actually do their test procedure against that. Now over here we have run your QA acceptance test procedures. This is what's called a manual judgment. It means the pipeline will pause at this point and somebody needs to come and run it. I don't have notifications switched on for this demo but this is a great opportunity to have a notification like on a Slack channel publish it to the QA Slack channel and say, hey, somebody needs to go out to the lab or they have access from their desktop and go start running the acceptance test procedures and then come back here and check Gay or Nathan, Pastor failed. Now they can fail it right there and then that's the end of the pipeline and it's deemed a failure if they say it doesn't pass the thing. So they can go back and report to the development team, hey, there's a flaw, go fix your code. But if they say it passed, in this case we're going to say since this is just staging we only need to keep the latest copy around in staging. So go ahead and destroy the old server group. So let's go back up and look at the one that's in progress. So right here we get a nice little indicator bar for each of these stages. I can go click on one of the individual steps for deploy to staging and it tells me it's succeeded here. I can zoom in here and it tells me that it's created this version of the app. The name of my app is called SDR demo and that's short for Spring Data Rest demo because that's one of the projects that I work on with the Spring team. But in this case I'm deploying an instance of SDR demo but it's in the staging space. So I've branded it as staging and here's a specific version number that it's rolling out. If I go over and peek in the staging space I get another perspective of this. What we hear we can see is there's two copies of the app, there's version 10 and now there's version 11 that's going out. Version 11 has been enabled, version 10 is disabled and this is how we implement what's called immutable infrastructure. One of the powers that Cloud Foundry comes with and there's talks and blog articles about are blue green deployments, the idea that I can push out this version and then this version and I can keep alternating between the two by pushing up to the inactive version and then switching the route back and forth. The idea with Spinnaker is you take blue green deployments and you take it to the limits as far as you want to go but instead of pushing and updating a current app you push out an entirely new app. You do not go back and update existing stuff because that would be a immutable infrastructure. So instead go push out version 11, if version 11 turns out to be buggy and stuff roll back to version 10, delete version 11 and then later on when they roll it out push out version 12. So it completed step two which was disable old server group and that's where we were able to see peeking at Pivotal Cloud Foundry. And I got a lot of details information. In the deployment step I zoomed in and saw version 11 was being deployed. I can zoom into this disable step and see that it went to disable version 10 for me. Now we're at this next stage which is in yellows. So this is the message we would post out through our notification channel is go and run your 23 page test procedure and then come back here to indicate whether it's pass or fail. This is what I call a demo of. This is a semi complex pipeline because probably in reality if you're doing this kind of stuff you would probably have multiple manual judgments. For example, the first manual judgment maybe once it's out to staging the development team needs to go out and run a smoke test against it. If the smoke test passes then go have another manual judgment for QA. If QA says it checks out maybe they need another manual step to route it through CM. And maybe QA, NCM are operating in parallel to go complete their check mark paperwork forms whatever. And then they might send it back to some other team. But you get the idea you can have the pipeline pause for you and track this stuff. I like the idea of having email notifications for this kind of stuff so management can look at this and say QA teams gotten 20 emails in the past two days about going and running tests. That's either an indication that our procedure is too laborious and we need to go make it more efficient and we need to trim out unnecessary stuff or that is exactly the oversight that we want to do. The procedure is doing what we want it to do and let's management keep their arms around what is happening while still letting you get some of the benefit of continuous deployment. So I'm gonna say I ran the test procedure and went great. So since it's good, it's going to go on to the last step of this pipeline which is destroy old server group. And so they have rules in here. Some of the other stuff that they have support for is you can put, rescale the app, scale up, scale down. Another big feature that a lot of people are interested in is canary testing. So what have you got to production and we're like well we need to run 10% of all the traffic to the new copy let's keep 90% of the traffic going to the old copy for a certain amount of time. You can definitely put in the steps into your pipeline today with like Cloud Foundry where you say let's scale up the old copy to nine instances and run just one instance of the new copy and because they're both mapped to the same route in Cloud Foundry it's gonna load balance 10% of the traffic to the new copy. So you can get some canary testing right there and then you could put a manual step in there to say come back after three hours and verify that it worked out okay. And if it did okay let's move along and scale down and destroy the old copy. Sorry. That pipeline's finished. So we had a successful deploy to staging. If I go again, recheck now, got rid of version 10 so now we're up to version 11. What I have is down here I have my deployed a production pipeline. It has two different, it has two steps in it. The first step is called find image and it says I'm not gonna specify the artifact that needs to be deployed because instead I want it to go find the latest copy in staging. Whatever version you just deployed to staging is the copy I wanna now deploy to production. So what it'll go do is look out and say here's all the metadata that was associated with that copy in staging. In this case it was a, my artifact was hosted in S3. So go give me the details on that and then carry them over to this deployed a production step. So earlier we saw SDR demo dash staging dash v011. This is the production copy that we're rolling out. This one has a slightly different strategy on deployments and we can go into the pipeline to see what it's doing exactly. So if we look at the top here, starting from the left we can see what it's trigger is. In this case it's triggered by a pipeline and this says it's a pipeline, it's triggered by application SDR demo and the pipeline is if deployed a staging is successful then kick this off. So find the latest copy from staging. So here I've entered in here's the description so people can understand what it means but it says go into the staging space or the staging account, pick this particular cluster name and go find the newest copy for me. There's other rules like what do you want? Do you want the oldest? Do you want the largest? Do you want the failing copy? It's they have options for that kind of stuff. So go get those bits of information and then now let's go to deploy to production and run that. Here's what's the, this is the information about what gets deployed. If I click this edit I can look at the details here. So this says you're gonna send it to this named account production which in my configuration of Spinnaker is pointing to the production space I have in PCF Deb with the necessary credentials. And it's, this is using what's called a red-black deployment strategy. That's just another name for a blue green deployment. So essentially it says and here I get to specify how many total copies do you want for us to maintain, for you to roll back. And I say two copies, one active and one predecessor. But you could type in 10 and it will keep the last 10 copies. And in any time you can go into Spinnaker and say I need to roll back and it'll pop up and say which version do you need to roll back to? And it will essentially do all the operations you would be doing by hand through something like Apps Manager. There's other settings in here if I need to declare the services that I want it to bind to. In this case this is a Cloud Foundry specific deployment step. So these are Cloud Foundry specific parameters like service to bind to, environment variables, build pack overrides. But if one of my accounts was AWS I would see a AWS specific set of collection of settings all from the same tool set. So it's actually in the time span that I was talking about it. It actually completed this release. I can go and I can zoom in to see what version did it publish out here. It finished with production v0.11. I can actually click on this link and it's going to take me into this view and it's gonna show me sort of a filtered down view of what's out in my PCF spaces. So it's just showing me production and this particular instance. Now if you notice there's a lot of integration between the various cloud providers and you'll notice this is a little bitty Cloud Foundry icon with a little top clipped off of it showing with a nice green health status. But if you're using something like, if you're deploying to Kubernetes you'll see their little icon in there too. So you can tell what kind of instances are running. But if I go and clear, if I clear out all these settings, we get, so I'm gonna clear all these filters. Here I'm able to flange down on this is the application. Here's in production I have two copies running. The current one active, the previous one disabled, staging I have one copy. And this is the kind of view where if you get into a microservice based solution where you've deployed five different microservices you can filter down on something like only show me production or only show me staging, things like that. Versus if I was looking at this view and I had actually 10 different microservices with three different versions. I would have 15 rows here and it would be a lot harder to see what the relationship was between all the services. This is some reference information I put into the slide deck. So if anybody wants to look at the slides later you can, it helps kind of explain some of the Spinnaker terminology that we have to map on each of the cloud providers including Cloud Foundry. So they talk about things like applications and clusters and server groups and load balancers. And you have to understand the language to be able to make sure we're speaking about the same thing. Because a Spinnaker application does not map to a Cloud Foundry application when we're talking about Cloud Foundry apps when we're talking about Spinnaker server groups. And one other key thing that I wanted to be sure to cover in this talk is the fact that we now have a one click deployer built. So I've been working for about a month on building this application so that if you're using any Cloud Foundry I know this has PCF Spinnaker deployer on it but you can actually point this app at any Cloud Foundry that's using the public, the certified APIs. And you can come in here and fill out the settings that you need to configure it such as the instance of Redis that Spinnaker is gonna talk to. And you can come down here and click our big deploy all button and it will install all of Spinnaker into your PCF environment. So in that sense I can put Spinnaker into PCF so it can in turn deploy to PCF. And then the big goal is to take this app and actually install it into PCF. So that's three layers of indirection and we're definitely in getting into inception. I don't have any questions. One thing I didn't wanna point out here if you couldn't see is I do have some Spinnaker stickers to give away. You can come see me after the presentation and you can get a Spinnaker sticker. You can put it on your laptop. If you don't wanna do that like me then go put it on your children's toy laptop so they can be cool and hip with their friends and get the kids talking about Spinnaker. I did wanna throw in here for if anyone's got questions but we are, I'm gonna be talking about this again at the spring one platform conference which is in the beginning of August. I have a few links here if you wanna go look at it. I don't know if we had any questions because I know this is a different audience than from what the last time I gave a Spinnaker talk to and so I didn't know if anybody had questions about this. Could you repeat the question please? Do I have a time for Spinnaker on PC? Tied? Oh, tile. Okay, so the question is is there a tile for deploying Spinnaker to PCS? In short, this essentially is our solution for a tile. So this is actually a Spring Boot application that will install Spinnaker and this is what we're doing to build instead of a tile and so this is the, I'm making sure this operates. Tiles are really critical stuff if you have to do a lot of under the hood magic or something with installing stuff into PCF but in this case, Spinnaker is really just a handful of Spring Boot applications to deploy so it's actually much more rapid for me to build this tool for installing it and this is where I'm working with my program managers to exactly how we're going to hand this out to the community like are we gonna list this artifact on network.pivotal.io for people to pull down and push into their system or not. Or do we need a basically bare bones tile that will wrap this app up and push it for you? So that's the idea is to have this one click deployer be able to be pushed into your PCF instance with little effort. Okay, so the question is is the Redis involved with Spinnaker is that part of doing the deployment or is that something that's outside of the environment? Basically Spinnaker needs one external dependency to do its job and that's a Redis server so right now you have to go into PCF in this case my dev workspace, create a Redis instance and then I need the name of that typed into here to bind to it. So that's something to tackle is do we need to actually add support to say go type in the name and have the deployer actually create the instance for you if it's not there that may definitely be a feature that gets added to it. So I think I saw a question back here. Yes sir, how do you integrate with concourse? Okay, yeah, how do you integrate with concourse? So I've had been asked that question I think two dozen times since I got in here. So there's definitely overlap in what, if you look at the big picture, what does concourse do, what does Spinnaker do? So concourse, I haven't directly used concourse but I've been able to look at it from a high level so you can use concourse to essentially build a pipeline of operations that you're gonna do. So you can use it for CI or building an entire pipeline for release. So I think there's merit. Some teams like to build with concourse. I've heard people that revel in using that. I've also seen a lot of teams that they look at Spinnaker and they say I love the look of that thing and I'm all in favor of let's move to the pipeline that you like best but let's get away from using tools like Jenkins and trying to engineer pipelines inside Jenkins because that's not what Jenkins was built for and a pipeline deployment strategy is not what Travis was built for. So if down the road if 80% of the software development community is using Spinnaker and 20% is using concourse or the other way around I think that'll be a big improvement and let's see what comes out of that. It's possible to add support to Spinnaker to go if you wanna use concourse as your CI tool to do your build jobs and do we need Spinnaker to pull concourse to get artifact to be triggered by that to then do deployments. We have not added support for that yet but to my understanding that's probably not too hard to go code up. But I'm curious to see customers. Is there any customer demand for that yet? I haven't heard that demand yet but if it arises we can add it. So the question is let me see if I got it right are what all types of applications are people using Spinnaker to deploy? The circle of influence that I've roamed in has been typically Java based applications but Spinnaker's not confined to only to those kind of applications. Essentially with the Cloud Foundry support you really point to a repository location like S3 and say go get that artifact. I'm grabbing it in this demo I'm grabbing a jar file and pushing it and I'm letting the actual CF push job go and look at the artifact and deduce what build pack to use. So it deduces oh I need to use the Java build pack but there's nothing that doesn't say I could be grabbing a Node.js bundle grabbing that and pushing that and letting CF push deduce that I need to use the Node.js build pack on that. So I mean it should support, should be Polygon support any of the platforms that the underlying platform will support. I haven't actually used the other cloud providers because Cloud Foundry is the best platform to go to but so I really can't comment on precisely what their support level is. So the question is, Spinnaker is based on Cassandra? Is that what you were asking? Okay, so the question is to your understanding Spinnaker uses Redis and Cassandra. That was an accurate statement about a month ago but I actually invested effort to make the storage engine optional. You can pick Cassandra or Redis so that in this configuration I could say we're not going to use Cassandra, we want to store everything in Redis so we have one external dependency. So you can actually go in and configure and pick that and there's other shops that actually wanted to move away from Cassandra as well. Okay, so the question is exactly what does support does Spinnaker have when it comes to building or running scripts or what have you based on triggered events because in this example I showed a trigger being get, Spinnaker does have a script engine available so you can have it run scripts at various stages so you can definitely have it and one of the other steps is it can run a Jenkins job, you can command it to run a Jenkins job along the way. So those are two avenues to do it. They do have explicit Docker support in there to essentially bake a Docker image if that's what your platform is going to actually deploy with. But the fundamental build an artifact thing with the CI solution is it's definitely in the corner to say I'm going to monitor, I'm going to pull Jenkins for built artifacts or I'm going to pull Travis for built artifacts. So if your build job is covered by that paradigm very smoothly, I mean that would be my first recommendation before handwriting scripts that would do the same thing. Okay, so the question is, is you're talking about like scaling up in the sense of pipelines running or it absolutely is built to handle, we're running 100 different pipelines simultaneously. There's a check box setting in your pipeline to say whether or not this pipeline can run concurrently. Do you, does this pipeline need to only run one at any one time? And you can have hundreds of pipelines to find for your infrastructure. So any one of those can be triggered and you can go into the UI and you can quickly flange down and say well I'm only interested in these particular set of pipelines because they're for me. There's a feature over here called projects where I can click on this. This is my dashboard for CF Summit where I can say I'm only interested in this particular app and if I had hundreds of other pipelines and groups they would not be shown on here. So it gives me a quick UI to look at what I'm interested in. You can really, the question is, is like can I combine all the apps into one pipeline? Do I need to have multiple pipelines? It's really any way you want to slice and dice it. The, if I go into like this configuration pipeline, let me pull up the pipeline definition. The deploy step here. This box right here defines what's being rolled out. In this case I'm gonna have one thing but if I can have like a four piece microservice where I need to deploy all four components in here, I could either list all four items in here in this single deploy step or I could actually have four different deploy stages and I can have my pipeline fan out and then have it fan back in if I wanna do it that way. And I can give them each a different strategy. Like in this microservice I wanna keep two predecessor copies, this other microservice I wanna keep one or if I want to I can break them off into, I can have different pipelines for different apps, maybe different, some of the apps need to go through more complex procedures like with QA or something like that. So it's really very flexible on how you wanna define your pipelines. Was there another question? Yeah. So the question is, is this just for PCF or is this for open source? This all works with any certified Cloud Foundry because it uses the public APIs to interact with Cloud Foundry. So I'm showing it on PCF, talking to PCF but this one click deployer would work on any Cloud Foundry, it will install Spinnaker to any Cloud Foundry and it will deploy to any Cloud Foundry. Oh, that's an excellent question. When you build a pipeline can you have a text-based representation and that is something I love very much which is, well, I'm a big fan of stuff like Travis. Anytime you go into the pipeline, I like the UI version of this thing I can look at but there's actually under here I can pull up the JSON representation for it and we actually show steps of, I'm gonna migrate all my pipelines from Cassandra to Redis, I can run a curl command to pull it down on my pipelines and it's a fistful of JSON that I can turn around and push into Redis through the Spinnaker modules. So this is actually an editor, I can go in and hand edit this like this directly and it's not actually that hard to figure out. So there's times when I, there were definitely like, I've encountered bugs in the UI where it goofs something up and the UI didn't work and I just pulled up the JSON and corrected it directly. So to me that's kind of a best of both worlds in my opinion. Okay, so the question is what kind of access controls are there? It's like is everybody able to access everything? And right now in general that's yes because that's kind of how Netflix operates but there's developments underway as this is being pushed into more enterprise shops and stuff where that solution's not gonna fly. So there's actually, they're working on making sure we have proper security controls around all the modules. I've chatted with a handful of people that are like we need to go put in some controls and say this person's authorized to work on these pipelines, that person's authorized for that because there's definitely shops that need that kind of stuff. I think I need to wrap it up because I've overused my time here so I need to let the other person get set up but we can keep talking about it outside here and you can come up and get your stickers, all right? So everybody thanks for turning up.