 Up next, I want to invite some folks up that they have a very interesting story about developer experience. And it's not going to be your normal Cloud Foundry developer experience, but they are going to talk about how to use some of the Cloud Foundry technologies in a really unique and novel way. So I'd like to invite Andy Rosequist and Holly Moody from Zipcar to come on on stage. Come on up. All right. Please, please. After you. Thank you, Andy. Thank you, Holly. Absolutely. So they walked here from their office. They walked here from their office. So I kind of teased it a little bit and said, you know, you're using something that's perhaps a little bit different than what most folks in the audience are using. We love experimentation and different ideas. And so I want to hear about that. Okay. I want to hear about that. So the gist of it is that we essentially really liked the Lattice project. We said, you know what, let's see if we can take that and actually run it at scale. And so it came in at the right moment in our platform journey that it was what we needed in order to scale. And we were really focused on how can we enable developers to work with a large constellation of microservices at the same time. And so Holly will get to some of that in a little bit, but first I want to give a picture of sort of what our tech stack looks like. So I have this. This is beautiful, by the way. Yeah. Probably the best slide of the day. I'm pretty excited about this. And every time I show this to my team, they're like, no, no, put another X on there because we don't have that one either. So we really love concourse. We really love Bosch and we love Diego and Garden, but we don't like the cloud controller. We don't like that stuff and we rewrote our own. You have a different opinion. Exactly. Yeah. So some of the folks yesterday were talking about, you know, Kubernetes versus Cloud Foundry in terms of Cloud Foundry has more opinions than Kubernetes. We're hyper-opinionated in that sense. And so our sort of deployment orchestrator is all around Docker and it's all around taking all of our services at the same time and letting engineers work on a few of them, but then orchestrating across multiple different deployments. So the facts that I like is we're running 12 Bosch directors and 6,000 container instances in multiple different clouds running three different, completely different products using about half of the same services in the middle. Very cool. I mean, you mentioned hyper-opinion. So let's talk more about that. Sure. So we, in addition to all of the pieces that we love about Cloud Foundry, we also did a bunch of work to build our own SDK that exposes some of the Diego primitives and some of these other bits directly into the application. So if you use our internal SDK, you can get up and running and integrated into this microservice mesh within minutes of starting to write something and it is already able to run in production and deliver value. But that only works if you use RSDK exactly the right way. And so we had to build a lot of work and concourse to make sure that all the things are fitting together in the way that we want them to. And so we, I would say we abandoned a few of the factors of the 12 factor model in order to. I like to think of them as inspirational or aspirational. I mean, the aspirational stuff, like Holly can talk more about some of our continuous delivery maturity stuff. Yeah. So it's wonderful to have the ability to deploy stuff when you want to. But you've got to actually transform a team. And one of the things that we used is a tool called a CD maturity model. And you can find this out on the internet. We just took and lifted that and modified it based on reviewing with the team and having them accept what they want the maturity model to look like. And it's basically a matrix that's a checklist. And it's got things across the horizontal axis of the different stages with the target stage. And then on the vertical axis, there are things like testing, data management, culture. Disaster recovery, all these things. Yep, service management. And so there's different items there that you just sort of check off as you go. And if you get to the target area, then you're in pretty good shape. And it has helped us to be able to have the 100 plus developers deploy apps when they're ready to deploy. So we develop it, we test it. There isn't a separate team. The whole team works together. And we push, you know, an app out to production when it's ready to go. What was the process of kind of rolling that out through the development team? Is it easy? No, change is never easy. We just started it. You build a few champions that believe in it. We as a team, a Zipcar team have still a legacy architecture that is very painful. And so there was motivation to try and transform into something better. And so I think that that's been the biggest thing is being able to have that motivation and to transform into something better. That makes a lot of sense. So one of the things that both of you talked about is how Zipcar is kind of like a, well, you're part of a larger corporation. It's true. Tell us a little bit about that. And this whole multi-cloud buzzword thing has something to do with it. Yeah, so we wanted to be able to operate, to continue to operate like a startup. So Zipcar has been around since 2000, 2001. And we were acquired by Avis budget group in 2013. But we've still maintained a lot of independence in how Zipcar the business works. And so we've always been an agile organization. We've always been doing that type of software development. And then colliding a bit in different ways with parts of Avis budget, we've been able to help demonstrate like opportunities for future for our larger parent organization and as well as take on projects that really fit well with the kind of culture and tech that we've built. And so by using Bosch at our underlayer, we're able to portably move our workloads depending on what kinds of, whether it's regions of the world that we need to support or whether it's contracts that we found, oh, it's really cheap if you can run in this cloud. Okay, well, let's figure out how to do that. So the story that I like to tell is that there was a point when we were running in three different VMware environments and one of them was really bad. And I won't shame why, but it took us two weeks from the point that we said, you know, this is so bad, we need to get out of it. We moved an entire production stack into AWS and we're up and running things to Bosch and then building everything right up. Yeah. So last night, you were talking a little bit about one of your troubleshooting techniques. Yeah. Sometimes when easily like the second or third option that we do is just burn the whole thing down and rebuild it. Give it half an hour and then everything's better. And redeploy all, you know, 50, 60 services, redeploy all of the cells, just everything. It's sort of like when you call up a help desk and, you know, they say, well, have you tried turning it off and back on again? Exactly. We're just reboot the whole div environment. It'll be fine. That's really interesting. It's really interesting. So I actually kind of wanted to dig in just a little bit more into the idea of this, you know, this hyper opinion. Because, you know, I brought you up, I was talking about how developer productivity is sort of the general theme of the Cloud Foundry ecosystem. We're very focused on developers. And the fact that you're hyper opinionated is interesting. Now, it's going to be specific to Zipcar. Exactly. How does that play out? I mean, what's the process of a new developer coming in and learning what opinions they're supposed to have play out? Yeah. So I think that as a team, we pull people onto a team and collaborate. There's a lot of pairing that goes on. But as far as, you know, sort of developer productivity and ease within our environment, we have a couple of tools that were built up. One primarily is the ability for a developer to work locally on an app and be able to debug it. But because it's a microservice architecture, you have to connect to a bunch of different microservices. And so this part of our, we call it a Savannah architecture, is able to, you are able to start up your app locally, debug it locally against services that are deployed in a Savannah instance somewhere else. Very neat. And just to work clear, Savannah is the aggregate kind of platform. Yeah. So Savannah is essentially our replacement for the Cloud Controller and the CFCLI. So we have a Savannah CLI called SAV and we have a Savannah API that basically fulfills the role of the Cloud Controller. And one of the opinions we have is that all of our RPC between microservices goes over messaging queues. And so because we have this messaging queue that allows all of the RPC to happen in a developer environment, you can tear down the sort of data center hosted instance of the app that you're working on and connect your own laptop into the message queue that that instance was running in so that your teammates can then go and browse to the thing that's running on your laptop via the data center and get all of the other 50 services running there. So you don't need 50 services running on your laptop and you don't need to build the smaller mocks there. You can say, you know what, I'm just going to connect into all of them and get a full suite of everything that's running exactly as it is in production. But just my thing is different. I think that's the reality of microservices architecture. It's both really powerful, but also kind of make things a little bit more complicated. You think about more moving parts and we need the right tooling in place. It's fascinating to hear about that. And that's actually part of what the CD maturity model was about was, what kinds of things you have to put in place. And testing is a very large piece of that in order to deploy something reliably out to production. You've got to have multiple layers of testing and the CD maturity model talks to a lot of that also to the infrastructure as software, which allows Andy to do what he's talking about. Burn it down, start it up again. But testing and I wanted to talk about, I talked about the developer testing, but there's one other kind of testing that we do to validate that our apps are viable out in production. And that's called journey testing. And we actually run these tests out in production. And the idea of these particular tests are to validate your primary money making paths. So you don't test everything. You're actually doing business as Zipcar, right? Right. And so you want to be able to validate that your production architecture is running for your users. And you want to find a problem before your users find it. So we have these things called journey tests that run every 10 minutes. And, you know, let us know if there's a problem out in production. That's really neat. And they're orchestrated by Concourse because we love Concourse. Yes. Very cool. Very cool. So this is really has been a fascinating story to hear about, in particular for me, because it's been inspiring about how you're using components of the architecture. You're achieving very similar goals to most of the organizations here. You just happen to have a hyper-opinion, you know, hyper-opinionated approach. But we're really happy as a community that Zipcar is getting some value out of the Cloud Foundry software. So I want to thank you both very much for coming. Well, so if you want to hear more about what we're doing. Yeah. So 1205, I think it is Concourse all of the things at all of the times. Is our quality engineering manager talking about how the way that I put it is that how we achieve a CF push like experience, but using Concourse to build containers that we then run in Diego. Very neat. Yeah. Very neat. Well, thanks again. I really appreciate you both coming. Thank you. So about a round of applause. Holly, Andy, thank you so much for coming. Thank you very much. Cheers.