 Hi, everybody. We have our Spinnaker TOC here. So I'd like to introduce you to all of them. I am Veronica Matini. I work for Armory in Sales and Revenue Operations. So, Gopi. I'm Gopi Revala. I'm the CTO of Optimix. And we've been involved with Spinnaker for a few years now. And we implemented various solutions at different environments. And I'm currently, we are currently TLC members. I'm pretty excited right now that Spinnaker is going. Right on. I'm Cameron Motovoslani. I'm a manager over at Armory and on the TLC here at Spinnaker as well. Hi, everyone. I'm Cole DeClo. And I'm an architect and senior principal engineer at Autodesk. And I've been working on our developer platform. More specifically, the deployment side of our platform. And we've been using Spinnaker for a couple of years now as the fundamental tool for facilitating deployments for applications. And I'm David Byron. I work at Salesforce. I've been there for a couple of years. Salesforce has been using Spinnaker longer than that. And yeah, also on the TLC. And yeah, we have a lot of big Spinnaker installations. Great. So if we can talk a little bit about how your organization is currently using Spinnaker and what what value you're seeing out of it today. Maybe David, if you're comfortable sharing something there. Sure. Yeah, let's see how to say this. Salesforce uses Spinnaker for sort of all of its all of its cloud deployments. We target lots of Kubernetes clusters. We target lots of sort of EC2, direct AWS stuff. It's sort of the paved path for everyone that's migrating from you know, first party stuff into the cloud. Everything happens through Spinnaker. So yeah, it's the way and it reduces a lot of friction. That's great. So our organization at Autodesk is focused primarily on increasing developer productivity and finding ways to reduce all of the toil that exists with deploying, managing and operating a cloud service. So we are providing high level abstractions and opinionated ways of deploying and managing your cloud applications. And so through those abstractions, we end up rendering out deployment pipelines in Spinnaker, which facilitate deployments in a standardized way. And so that really allows for application engineers to focus more on providing value directly to their customers and not have to worry about things like expanding to new regions or making sure that they're compliant within our compliance programs. And so we, I think through all of that, we've reduced a lot of toil and allow for them to really operate on all cylinders. Cole, I'm curious what have your engineers said or what kind of feedback have they given? So we, like I mentioned before, we have a lot of compliance programs that we have to adhere to and focus on. And many of those programs have hundreds of requirements. And so our deployment platform can cover upwards of like 90% of those compliance requirements. So most of the feedback is related to that where, hey, we should adopt this platform. They're spreading the word throughout our organization. And here's the real benefits that we're seeing. We don't have to worry about managing certificates or we don't have to worry about ensuring that our S3 buckets have all of these policies attached to them. That all just comes out of the box. Observability comes out of the box. So yeah, that's the big win. Awesome. Thanks for sharing. Cameron. Yeah, we use Spinnaker quite a bit actually internally at Armory. So we are a vendor and we have an enterprise version of Spinnaker. But one thing that we do, which is pretty cool, Matt Gogherly, also another TOC member gave a talk on this or is giving a talk on this about deploying Spinnaker with Spinnaker. So we use Spinnaker to deploy Spinnaker all the time. And it's really cool for protesting proof of concepts, et cetera, spinning up developer environments, so on and so forth. We also use Spinnaker a lot internally. But our primary target platform is Kubernetes. We run it in multiple cloud environments. But we also have some AWS EC2 internally. We are literally a small company. So we don't have a big, large amount of the developer onboarding kind of problems with that. But we extensively use Spinnaker. Great. Thanks for sharing. So I know that we had the really great opportunity this year of meeting a little bit sooner since last Spinnaker Summit. It was only six months ago in Detroit. I think a lot of people here were probably there. What can you share that's been accomplished since that Spinnaker Summit? I know a big focus was around bringing together the TOC and all the SIGs and trying to build out the community about there. Yeah, I think that's, since the last Spinnaker Summit, I think one of the big things is we got together. We've been doing regular meetings and knowing where we are going. Few of the big things that happen are the release process. We have multiple releases since then. And we're also talking about the new features and tech debt. One thing that we also found is organizations built their own systems in the last couple of years when during the COVID, we were not meeting as regularly. And after the Netflix and Google step back a little bit, now we are seeing this huge amount of features that are built in internal organizations. So it will be interesting to see how we can get some of this out into the open source. Yeah, one of the features we released in this last, in our last major release in 130 was more fine grained Azure baking. So we'd like to support Azure a bit more as a platform. And that's the first steps along that route. And I can add to the Azure bit. So Autodesk has fairly recent business opportunities that require us to look at Azure. And we've been partnering with Armory and hopefully providing Azure as more of a first class citizen within Spinnaker. So I think that partnership has been going great. And we are in the process of baking. I think they call them Azure machine images, so the same AMI terminology as AWS. But yeah, we've been looking to scale that out and really be able to support the teams that require it within Autodesk. So there's, I think, new and exciting things to look for there. Yeah, I'll give a little bit of a pitch. I have a talk at 210, which is going to be, you know, specific to what we've been doing at Salesforce and what we're doing soon. But yeah, it's a lot of it's very focused on performance improvements. We've done some sort of more boring stuff upgrading Spring Boot and preparing to upgrade Gradle and Java and so on. Yeah, 210 right here in this room. Along with Azure, I think the Cloud Run, which is a Google serverless model, is also the new entrant to the Spinnaker support. Great. So it sounds like, I think in the last six months, a lot has been accomplished. David gave me a little bit of a preview of that talk. Be sure to come by and hear that. Sounds like really exciting developments there. I guess looking forward at the next year into new focus areas and initiatives, areas that you think might need additional support from the community and things that you're looking to build out. Can you share a little bit about where you're looking to focus? Sure. I think a few of the things that we've been discussing out there are tech debt. Getting the Spinnaker up to date with the latest technologies, or particularly for vulnerabilities and maintainability and things like that. So that those include Java, Spring Boot, and some of the libraries that go with the Spinnaker. There's, I think this is where we're going to the right time to talk about this, but we're, Cameron mentioned in his talk a little bit ago, that we're trying to consolidate all the Git repos into one. I think it's going to make contributing easier and just generally improve the velocity for new contributors and existing contributors. It's going to improve quality. One of the things that we're also working on is some additional testing. When the old build infrastructure disappeared, we had some more testing like that. When we moved it over to GitHub Actions, we lost that, but we are real soon now here to get some back. So we do try hard. When we release a new version of Spinnaker, we're pretty confident that it's going to work and it doesn't break things, but of course things happen. And so we're just like we try to get everybody else doing, we're trying to left shift some of that and raise quality. Yeah, just to tag along there, adding integration and end-to-end testing back to the OSS community and making the results of the testing transparent to pull request authors. So when you make a change to the code base, you want to have some confidence that your changes are working fine. In the past, this was not transparent at all. It was very opaque and you had to be in a certain Google group, et cetera, to see the results of these builds. And we'd like to make that quite a bit more transparent. So when we came together, one of our largest initiatives or goals that we were hoping to target was really reviving the community of Spinnaker, which Cameron touched on in his presentation earlier. And so I guess what we can ask for of the community is let us know what are the pain points, what are some things that you'd love to see from the technical oversight committee and where we should take the direction of Spinnaker. And that'll really help us guide where we want to invest our time and energy. But I know there are certain things like we had mentioned here to make it easier to build Spinnaker locally to contribute back to it. And hopefully those are some of those baby steps that we can take to really revive the community. And I know that we're looking towards graduating from the CD Foundation as well. So there might be some opportunities to help the Spinnaker community in that aspect. Things like fixing or cleaning up some of the documentation, looking at security auditing and how we can improve that process and start to meet all their criteria that's needed to make that graduation happen. To add to that, I think there are two aspects to Spinnaker, what we've been thinking. One is the operational aspect and then the functionality. So most of the focus have been about the operational aspect, whether to run it more efficiently or make it more easy to deploy or build, test the process. So right now, because of the backlog we have, we're very much focused on that. That includes getting to the proper installer that we can recommend to the customers that's easy to use. In the functional aspects, I think some of the integrations with respect to Azure or Cloud Run, those are the things that Lambda is another one, I think that's coming to. And so there is going to be improvements there as well, but there's a lot more focus on the operational aspect. And going back to getting more involved in the community or giving feedback to the TOC in order to see changes that the community would like to see. What's the best way to do that? What's the best way to get in touch with you guys? What's the best way to get more involved to contributing? Yeah, we have a governance repo in GitHub under the Spinnaker org, and it has a calendar of all the SIG meetings that occur. So the Platform SIG meets every other week. The Cloud SIG, I believe, also meets every other week. We also have TOC and SIGlead SYNC, so we chat quite a bit with the SIGleads that do come and join. Yeah, and there's also Spinnaker Slack. So to hit us up ASYNC, we're all there. I don't actually know if there's a TOC alias if somebody wants to send a message to all of us or something. Maybe we need to set one of those up. But I don't know, we're all pretty available. So the Cloud SIG meets once a month. And then the Platform SIG. We used to have Azure separated from Google and AWS now. They're all merged in one. That's a Cloud SIG. Right now we're running once a month, depending on the interest. We could change it once in two weeks. All right, so for anyone that might be a little bit here to explore Spinnaker or newer to Spinnaker, obviously this group, you guys are more experts in the space, what do you think you would like to see in terms of how could we increase adoption or lower the barrier to entry to starting out with Spinnaker? And overall, how do we improve ease of use for the community? Simplified installation is a good start. Having certain reset parameters that they can quickly install and have a first pipeline running. Typically, getting the first one or two pipelines running is the barrier. Making that simpler is one way I guess. Yeah, even like seeding new installations with some pipelines. Right now Spinnaker, one of the strengths is really codified best practices. Each stage has code that does the job of that stage pretty well. That's why we're an open source is we get the best practices from the community and then we codify them. If we do the same with a golden path, let's say, to deploying to AWS in a very simple way, new users could potentially just get up and running and seeing how the whole process works. Yeah, and I'll also add that it's a bit of a kind of a chicken and an egg situation, but we'd love to see those that are active in the community creating demo videos or blog posts or how to types of articles. And that I think will also greatly help lower that barrier to entry, show the power of Spinnaker, what you can do with it, and even interact with newer tools that are coming into the market like Tecton and Argo CD. So definitely encourage folks to explore that space. And it sounds like going back to giving the TOC feedback on what areas you're struggling with for ease of use. That is where the TOC focus is a lot of their time figuring out where to invest. So again, at the end of this, we can make sure maybe an alias is created there to reach out to the TOC, but keeping feedback on what areas you might be struggling with or needing help with can really help give direction to this group. So looking looking at the last six months, what major trends or patterns that you noticed within your organization, the marketplace in general with Spinnaker that might be valuable for this group to know? So for Autodesk, we're very interested in moving to more of a declarative GitOps deployment model. And we're researching and hopefully building out what we're calling a unified control plane. So I'd love to see where Spinnaker fits into an ecosystem like that. I know that we've done some proof of concepts with managed delivery, which is Spinnaker's solution or answer to kind of GitOps there. And in that proof of concept, we quickly realized that Keyanta wasn't quite ready yet for production use. There's still some things around documentation that we need to make sure is available so that folks can use it. We need to make sure that it's also being maintained by engineers and those that are interested in that in the community. And then in addition to that, we also learned as part of that proof of concept that there's a bit of growth that we need within our organization to be ready for something like GitOps. So we are likely going to take kind of baby steps to get there. And I think Spinnaker can be really valuable in helping us achieve those longer term GitOps declarative types of architectural visions. I think you mentioned Keyanta, but maybe you meant Keel instead. These are like individual Spinnaker microservices, but I think people use Keyanta in production a lot and maybe not as much Keel, which is the managed delivery component. Yeah, sorry, Keel. Managed delivery and Keel. Cole, do you mind sharing a little bit if you're comfortable? Like you said that there's things that need to be done in order to get more towards that model internally. Like what for this group might they be looking for within their own organizations of, okay, we're not quite there, but we need to get people ready. And what maybe are you doing to get people more ready for that? Whatever you're comfortable sharing. Yeah, the biggest thing for us is having our application engineers trust the platform that we're building. So we want to make sure that we're offering that delightful experience that we try to advertise and people trust the platform and want to come on board and rather it be more of a stick situation where you're kind of hammering them and getting them onto the platform you're offering carrots and they come to you and say, hey, we want to on board. So trust is certainly something that we're doubling down on making sure that Spinnaker is reliable, making sure all the tooling that we have around Spinnaker is reliable. And we're focusing on providing immediate value for our application teams. And then by earning their trust, that gives us the time and the opportunity to make changes, these drastic changes like moving to something along the lines of a unified control plane or declarative GitOps types of models. So yeah. If I can ask one more follow up question. You said building trust with them is obviously really important. Like what's one example of something that you've done to build trust that other people could try? So one great example right now is we are scaling Spinnaker greatly and we have reached some scaling pain points. And so we're partnering again with Armory to figure out what are some of the best practices around our pipeline architecture. Are there additional ways that we can provide a more reliable stable and fast Spinnaker environment? So like a perfect example was I think there was a pull request that got introduced in Spinnaker 1.28 I want to say around removing duplicate service accounts and those service accounts were I think upwards of a million or two in our environment. And it was causing a lot of slowness and a lot of instability. So we by again working with Armory and upgrading to Spinnaker that particular version we were able to reduce the risk that those had introduced and offer a much better experience through the Spinnaker UI because things were running smoothly. Great. Thanks for picking on you. Yeah. There are a lot of performance improvements coming in Spinnaker. David will talk a little bit more. The other trend we also see is this integrated platform, the control plane that you are mentioning for onboarding users and onboarding applications and providing them a single interface they can go to to get the data on. So this is something that we are seeing more in medium to large organizations where they have some platform that gives a central view on how to get onboarded new services applications in the users. And then the pipeline templates some standard 80-20 rule is generally creating certain number of templates for their organization that go to target environments and having them onboarded through that central platform. This is another trend that we are seeing more often now. All right. So I think Cole started talking about GitOps a little bit. Obviously we are co-located here with GitOps con. So that is a hot topic this week. What can more can we share about what's been done to support GitOps or areas that you'd like to explore that maybe haven't been looked at quite yet? So it was a few years ago actually we had introduced the secret manager into the Spinnaker code base. So that was one of the first steps or I guess I don't know if it was one of the first steps but maybe one of the last steps on the operationalizing GitOps for Spinnaker. What I mean by that is when we added the secret manager to the Spinnaker code base you are able to reference secrets rather than having secrets straight in your configs. So you are able to have your complete configuration for deploying and managing Spinnaker in a Git repo which is pretty powerful stuff. Not having passwords directly in your configs was the last thing that was needed for compliance for deploying Spinnaker in a GitOps model. That is not the same as deploying your application in a GitOps model and so that's the network. So as Cole mentioned managed delivery is one of the ways you can through Keele do the GitOps model but the way we also think about GitOps model is having the Git as your primary source and deploying from there. The second part of it is auto synchronization. So the managed delivery part tries to do the second one but the first part where you have the Git as a source of truth in having that deployed through the Spinnaker and all the facilities that are required for that are there. So even in the GitOps models it's very useful for the operations. So you have something running in production you have the Git that deploys it but there are processes that we have to go through to get to that stage. So they're requiring pipelines and the Spinnaker really works well in creating those pipelines and having those processes figured out and then you can apply that to a Git that applies to production. Yeah I think I'm just going to repeat what Gopi just said. I forget who was giving the talk yesterday morning and there was this sort of like four levels of GitOps and the last one I guess I'm maybe going to oversimplify and call drift detection or reconciliation and this is the managed delivery part that people are talking about but the earlier parts where something happens in Git and you want to trigger a deployment. Yeah Spinnaker has been set up to do that for a long time either via webhooks connecting GitHub to Spinnaker or polling Docker registries when a new Docker image appears or a new Helm chart appears. All of those things can already trigger Spinnaker pipelines and get your deployment happening. And Kubernetes is a declarative environment so it's a very good fit for declarative spec but we have other environments using Terraform bringing up the infrastructure AWS EC2 those are much harder to do so for those again having the Git as a source of truth and something like a Spinnaker deep line to those environments was perfect. And you can also have your pipeline saved as code as well so you can have the operational part that your developers interact with also saved in a Git repo. Great thanks for sharing so we started talking about managed delivery a little bit I think Cole gave a little bit about what it is the gaps that are seen there within Autodesk specifically can we go a little bit more into managed delivery for the group in detail what what we're seeing with it and benefits etc. Yeah so I'll kind of double down on what I said earlier so through our proof of concept with managed delivery felt that it's heading in the right direction but it's not quite mature enough for us to use it at a production scale and one of those biggest things was around documentation. We had to basically read the code to understand what was happening there so in order for I think the community community to help evolve managed delivery we need to make sure that we have proper documentation in place it's easy to understand and consume and then also look towards the future of like where where can we start to use other tools that already have GitOps and declarative solutions in place and maybe offer further integrations or integrations perhaps maybe through CD events or something along those lines. All right so I guess from this group again we've already talked about trying to solicit some feedback on areas that we'd like to see improvements etc. Anything that you all can ask from our Spinnaker community and everybody that's potentially watching this virtually of what they can do to be a little bit more active or help out in general. Yeah please join some of the SIG meetings if you have any thoughts or ideas about how you'd like to see Spinnaker improve. One thing I've seen over time is companies will be using Spinnaker and it might be lacking in some way and they'll they'll come up with a workaround but then we don't hear about the workaround so understanding these workarounds that people are making and getting that back to us would be great because then we'd be able to say hey look there's these workarounds all these people are making why don't we just integrate that into the product and make it better so please please join and give feedback create Spinnaker issues etc. Are there any SIGs in particular that are really looking for additional leadership or contributors or needing help? Oh yeah totally so I would say the contributor experience SIG would would be a great one to to check out as well as the the DOC SIG both of those needs and leads and are some areas that I think would would help greatly help the community. And I guess just for everybody's confidence for barrier to entry like what type of person would be an ideal participant for that like what type of skills or role level of experience etc. Totally those are those are all great questions let's see so I think for the the DOC SIG anyone who's a tech writer or has any experience with technical writing would be a great choice for the contributor experiencing people who are great with well people and have some sort of a technical background more than happy to help anyone who wants to lead lead those SIGs with their efforts so please reach out if you are interested and want any help getting started. Great thanks. And of course you know people who write code we can all use more of that too. One thing I would say is that here we have people who have a lot of experience with Spinnaker running a fairly large large scale so if you are using Spinnaker in issues that this is the right group or SIG meetings in the right place to come and you whatever kind of questions you have most likely you will get an answer so just hearing the problems that you have is also a good start for us. I forget whether it was just before or just after the the meeting in Detroit but there is a weekly in fact I'm probably missing it right now or about to miss it. At 12.30 on every Tuesday is the Spinnaker office hours and it's been let's say poorly attended you know I show up at 12.30 and I wait for five minutes or 10 minutes or 15 minutes and when nobody joins then I bail but I'm sitting there I'm ready to answer questions or talk about whatever anybody wants to talk about again I'm trying to try to make it easy if like you don't know what which SIG to go to like you don't have to you don't have to worry about that just show up and it's totally open forum and we'll get you we'll get you in the right direction. Great thanks for sharing any any other call to actions from the group or anything you'd like to say to the community before we wrap up. The changes that we've seen in the last six months are pretty exciting I'd like to repeat that so performance improvements and scale that people have been running it's amazing so look forward to the rest of the year and see what progress we can make there. I'm also just looking forward to working together across organizations here so we have many different companies that are actively using Spinnaker and active in the community too so it's exciting to see hopefully that momentum of reviving the community come to fruition and if it wasn't clear that we are not the entire TOC there are more folks on the committee that are not here on the panels people from Apple and people from JP Morgan so what Cole is saying is is totally right we've got I don't know there's a lot of there's a lot of momentum I feel like we're we're doing well. Definitely some big strides since last year I think or six months ago not a year ago any insight into the next opportunity the community will be getting together for Spinnaker Summit or look out for more information to come there. Yeah I think look look out for some more info to come I believe we'll have another event later this year but we'll be working with the CDF and the Linux Foundation too to set that up. Great well thank you everybody for coming and again please reach out if there's anything that you'd like to contribute otherwise these guys will be here too and David's got a talk later does anybody else have a talk that they want to all right all right David and Gopi both have talks Cameron do you have anything else okay great well thanks everyone thank you very much thank you