 My name is Jay Schneif. I'm the Director of Product at Liberty Mutual. I run the Secure DevOps Platforms product team. So, sorry. Do you have a lab or any mail? No, it's fine. I'll stand here behind. It's being recorded. Sure. Okay. Nope. So, no problem. Should I start over or just keep going? You go first. All right. I'll just keep going. This is going really well. Thank you all for staying in the room. I appreciate it. So, the Secure DevOps Platform team is everything that we run at Liberty Mutual on the cloud. So, it includes our cloud providers. It includes Docker as well as Cloud Foundry. We also are starting to investigate Kubernetes. We have a team that runs our software delivery platforms. So, that includes both Jenkins and Bamboo, as well as Git and our Jira and the rest of the Atlassian Suite. But really what I want to focus on today and talk about is our developer experience, because we take that really seriously. As the central organization at Liberty Mutual that provides those services, those platforms to consume, it's really important for us that the developers have what they need to move forward with the tools that we offer. So, real quick about Liberty Mutual. No surprise here. Over 100-year-old company. We have almost 5,000 employees. And we're really looking to build our technical organization. And we do have a focus right now to move a significant amount of our workloads into the cloud. I wanted to start quickly just to give you an idea of what our foundations look like from a Pivotal Cloud Foundry standpoint. So, we do use Pivotal. We started back in 2013. And if you were able to join the keynote this morning, we started in 2013 because we had a fit-for-purpose need to move our web services into Cloud Foundry. When we were looking to build out our WAAS environments to support that from an HA perspective, it took forever. So, we brought Cloud Foundry in. And we've really started to mature it over the years. We're now able to deliver our support consistently. We run full parity across all six of those PCF platforms. That's 13 different foundations across three local data centers within the United States, as well as three AWS regions. So, I'm going to shift into the developer experience and really talk about how we started. So, when we first started as a small team of maybe eight developers, we wanted to go fast. But we also knew that as Liberty Mutual, we had to be secure in doing it. So, what we looked to do is we abstracted the CLI and delivered this website to our users and to ourselves, even. This, what we call the PAS portal, allows us to start and stop applications. It allows us to delete instances if you have the appropriate role. So, again, as I spoke to this morning, we really are looking for more granularity in our role management. We look for least privilege across the board in all of our implementations for all of our developers. So, this is how we manage it through this platform. So, not everyone will see all of these restarts, all of these stop-start deletes. It depends on what environment you're in and who you are. So, this was great, right? We're like, yes, look at how we can do this. Now, everyone can use it, and our developers came back to us and said, we need more. We don't know how to start, because not only are we super concerned about security, we're super opinionated about how you get into the cloud. So, we did a lot of user research. This is around 2015. We actually started to partner with Pivotal, and we had our first dojo, and we went and did research. How can we help? How can we give more? What do people really need to do? And we went down with a lot of hypothesis to Boston, partnering with one of them, I think it was like a six-week engagement. We thought we were going to continue to expand the Passport, but we just thought there was more from the CLI that we can pull. But what we ended up finding out is, people needed it to be easier to start. So, how do they start leveraging Cloud Foundry, especially when from an opinionated standpoint, we're enforcing the use of pipelines. So, again, because we have abstract the CLI, everything needs to be pushed to Cloud Foundry through a pipeline. So, we created the pipeline provisioner. This provided an easy template to use to get started with Cloud Foundry. And we're like, this is great. We have nothing left to do. We have absolutely nailed it. And then our developers came back and said, we need all the things. So, back in 2018, we really started to look at, we were expanding. We were offering Cloud Foundry. We were offering Docker. We started to talk about Kubernetes. AWS was huge, and we were starting to not only put PCF out in AWS, but we started to look at Azure as well. And we started to think about, there are developers that aren't just exclusively using Cloud Foundry. There aren't developers that are exclusively deploying their apps into AWS. Because some of these developers are on cross-functional teams, and they may have one application that runs in Cloud Foundry. They also have an application that needs to run natively on AWS. So, we started to hear some thematic problems that we could really help solve. We needed foundational knowledge. We needed to share with our developers these advanced practices and principles. We were really fortunate to have support from the top, and our senior executives to say, we're moving to Agile. We're looking to do transformation. This is where we want to go. So, we had that support. We started to do things differently. We needed to increase awareness. Teams knew that what Pivotal was, but they didn't know how to use it. There were teams that wanted to leverage Jenkins. We needed to provide awareness of what we had, what we were even supporting as a first-class citizen, if you will, versus what's up and coming, what may be a little bit harder to use, but you can still use it, and we want to support it. We really needed to unify the experience, because again, there are developers across the organization that are using all the different platforms, and we wanted to provide them a single place to go to do all of their work. So, we centralized everything into one place, and we really started to talk about communication and how we pushed that forward. So, we developed a single platform for managing all platform resources. So, the Cloud Forge Console was born. Cloud Forge is what we call all of the platforms in that environment, so AWS and Docker and Cloud Foundry and Azure. Everything comes here. There's a tile for it. Teams can simply go in. They click Create. They're walked through the process of creating your build pipeline, your deployment pipeline, your template for a Cloud Foundry application. Now, there's still work on the backend for teams to do to actually deploy their application, because we're not deploying it on your behalf, we're simply providing you the tools that you need in one place to get it out in the environment. What's really great about this, and as we really started to look at what we were able to do with it, we were able to create consistency around tagging, around cost, and everyone was doing things the same way, so it was much easier to manage. So, yay, we put in all the things. Now what? Well, those weren't all the things. Those were all the things that we managed, not all the things that people would need to use in order to deliver their software. So, we started to think about what else do teams need to consume in order to deliver into the Cloud. And as you see, the single value stream across the top are those items that we call from the Cloud Forge perspective. Those are the pipelines. Those are the deploy processes. Those are the hosted version controls, and obviously the Cloud Runtimes at the end. What we were missing, and what we've really started to focus on now is general security tools, how we embed security into that deployment process so developers don't need to think about it. Secrets. Secrets are run and managed by a different team. Secrets need to be consistent across the organization from a Liberty perspective. We can have several different secret management tools. Key manager and KMS, and we consolidated onto one. And then other data services. How do we make that consistent? How do we make monitoring a learning consistent across the board? And that's really where we're starting to focus now is bringing those tools, breaking down those silos, and providing a way for our partners to deliver into the same platform that we use and that customers have come to anticipate and expect. So, where are we on our journey? When we started about two years ago with the agile transformation and started to look at how long does it really take to get something into the cloud? We were looking at, I'm going to say, two weeks was generous. You got your IDs from your IT security standpoint. You got your secrets. You reached out to DNS so you could get your vanity URLs. And by that time, you had your template and you had figured out how to put your app in it and you'd been able to deploy through non-prod. So, I'll give it two weeks. We are now down to 20 minutes. So, we can now develop end-to-end development to production in 20 minutes. And that's a new user. That's a text, what we call text art, are ITAs that come in from college. 20 minutes they can get on the platform and deploy into production. So, not only are we enabling them to have a preferred platform to consume, but we're really looking at the ability to deploy with confidence. They know when they deployed, it's going to be secure. It's going to pass all of the right concerns from the end-to-end perspective and they're not missing anything. So, I wanted to share because... So, the Cloud Forge console came out in early 2018. This is where we ended 2018 from a Cloud Foundry perspective. So, again, we're running about 14,000 app instances across those 13 foundations. We're running, if everyone remembers, the Meltdown and Spectra release of... What was it? Was it 2017? Late 2017, I think. We went three weeks from the release of the patch into production across all of our foundations. We're running these 12 foundations with only eight FTEs. And a significant amount of their time is not necessarily spent on improving the platform. It's on education. It's on teaching and helping the application teams that want to consume this platform to consume this platform. Educating on if an AI goes down, your application is not down. There's just one instance of it that's down. So, how do we help educate them and their business partners on the value and benefits of the Cloud Foundry platform? You know, we're really proud of the fact that from a development experience and what teams are really looking to do, our development teams, our business-to-line development teams are spending 100% of their time on business value and not infrastructure. And that's really important when you start to look at moving teams up the value line and focusing on delivering software that sells insurance. Because that's how we make money. That's why we're in business. So, what's next for the team? So, we've consolidated everything. We're breaking down silos. So, where are we really trying to go? We need to continue to improve the experience. We can't be so bold to expect that we know exactly what the teams need. So, we continue to ask. We continue to have those conversations to talk about what does it mean to be the preferred platform and have everyone come to us. We need to optimize usage. We have teams, like I said, we have the option of using Docker containers or Cloud Foundry. Ensure that the right contextual knowledge is available to users so they're making the appropriate decision. There's not necessarily a wrong decision. You can certainly run spring applications on Docker containers if you chose to. But really having that usage information available from a cost, from a security, from an ease of use standpoint available to developers so they can make that choice if they so choose. Definitely looking to reduce costs. We recently introduced what we call curfew. It's a service that we actually built ourselves to reduce our pivotal licensing costs. And we've saved about $500,000 since 2018 when we introduced it by just shutting down instances that weren't running. So making an aggressive push to be good consumers of the Cloud and shut things down when they're not in use. And then as an industry that's highly regulated, we continue to look at ways that we can enforce security. So when people ask me, how did you get there? What did you do? We simply ask, where are you struggling? What problems are you having? And how can we help? So we did that through empathy and constant feedback. The console probably went through seven or eight different versions before we got to where we are today. And we're not done. We don't have everything in there. It's not as easy as it should be. We recently introduced a general navigation bar. It's not right. It has most things. It doesn't have everything. Constantly asking our customers, what do they need? How can we help? And how can we get them there? Is our number one priority right now? And that is my entire presentation. Question. So Clayton, do you know Clayton? I don't know. Oh. I remember the one guy that went through. Yep. Okay. The question was, are you open sourcing now? They try. Right. They have to shut down by open sourcing. We are. We've been talking about it a lot. I think we are having the same concerns from a legality standpoint. Are we able to do this? I think last night, yesterday, I talked to the Comcast team a lot. And really, you know, there's also that balance. There's the legality piece of it. But then there's also the impression and the assumption that people will spend more time on the open source pieces and not focus on the work that we need to get done. That being said, the curfew service, for example, needed to get done for us, but it also needs to get done for others. So really, when we're prioritizing work, we can still prioritize work that we can deliver to others as well as what we need ourselves. So we're definitely looking at it, having active conversations in it. I think we need to start getting there, in my opinion. Other questions? So like from a Cloud Foundry perspective? We certainly influence them to leverage Cloud Foundry. We don't dictate. So again, if they want to put a Spring App into Docker, they're more than welcome to. We offer both options, but we certainly want to encourage what I would call appropriate use. What's more cost-effective? What's going to be easier for the team to maintain? And there's more appropriate places to put things, but you could still put a Spring Boot App on AWS if you wanted to. We're not going to dictate that. Yeah. Yeah. So the question was any help on breaking down the silos? So two years ago, we started almost through the bottom up. We knew that there were problems. We knew that we saw blockers when we started to reach outside of this kind of the value stream that I talked about a little bit earlier and getting into the identity and the security tools. And we saw that we weren't the only people going to that team. Other teams, obviously, through different consumption models, were going to them as well. So we started to pull together the right people at the ground level and said, we need to talk more. We need to figure this out. We can't all be going to this one security team every single time. So encouraging the teams to get out there and talk to the teams they need help from has been really, really helpful. I think anything you can do without escalating adapt to senior management is also helpful, educating them on the blockers that you have, the additional time it's taken to get something done is certainly helpful and they can help from that perspective. But I highly recommend just finding people that care enough to reach out across those silos and start there has been really helpful. Anything else? Awesome. All right. Well, thanks, everyone. I appreciate you coming. Sorry about the late start. But I still nailed the time.