 Hi, I'm Dormaine. I'm with Pivotal. How many folks here are running Cloud Foundry, whatever distribution, but running Cloud Foundry in production right now? Okay, good. I will assume that the rest of you are either looking at it or testing it or lost. But, you know, congratulations on getting past security to get in here and being lost at the same time. That's an accomplishment. So, this is a continuation of actually what all started at Cloud Foundry Summit North America last June, which was my first Cloud Foundry Summit, and I started writing some observations of patterns that I noticed that some of these users that were in production and getting really nice results, what were some of the things they were doing? Maybe we'll just have the slides go blank. That's fine. Here we go. And then, actually, a year ago at Sea of Summit Basil, I gave a lightning talk, just 10 minutes about these takeaways at the Unconference the day before. I got some nice feedback, so I started to kind of keep pulling on that thread and finding some new patterns. And just for fun, I call them all secrets because that makes it sound really exciting and exotic, even though they're all really things that have been shared publicly in public forums and whatnot. But, you know, I just, I really love secrets, so I'm like collecting all these secrets and then sharing them back out into the world. So, yeah, not that I'm going to use them to blackmail other people. Like, I was voted most likely to survive prison on my team. That was an interesting thing to learn. So maybe, like, red, I'll do fine someday. Anyways, just to recap, where we've covered so far, has anyone here seen any previous coverage of the seven secrets? Any of my secrets talks? Okay, well, that's good. So, you know, I can reuse some old jokes and it'll be fine. So I'm not going to go through these because these are all pretty well documented already, but you may have heard, I have confirmation bias. I'm sure everyone else in this room has it as well. But I always hear things like earlier today at the, I think it was at the Talas talk. They highlighted how they started with the dojo. I was like, oh, secret number one. Picking an application, having focus and not trying to, like, sprinkle fairy dust and magically have all the applications suddenly running on Cloud Foundry. So having focus is a good one. Feeding developer grounds well, actually doing some enablement for your developers so that they know what they need to do. Measurements and metrics, I see a lot of these now. Value stream mapping has become quite the process de jure and so everyone's value stream mapping everything. Selecting the team carefully. Actually, the Pfizer talk kind of had an interesting twist on this was another reason to mix up the team is just so people don't get bored. That's a new one, but I'm going to take it as an example of picking that team carefully. Embracing tests and release automation is definitely reinforced all the time with the amount of investment and test coverage. Again, the Pfizer talk that just happened. Being bold, going, kind of trying to take on a bigger challenge. These are the kinds of things that, whenever I listen to users speak about their experiences, I hear little things that reinforce these seven, but there were a couple more that have started to emerge for me. This is starting to be like a collect-a-mall series. You can go to content.pivotal.io slash secrets and decks and recordings and the articles that have gone with them that will explain the first seven secrets. You can find those there. When it first went live, it went live as Dormane's secrets because the ticket I put in with the marketing team, they were like, we don't know what these are so we're just calling them your secrets. It was kind of funny for a while, but I figured we should probably change it because it's not really about me. I also want to reinforce what do I mean by successful because these are the secrets of success and so now we have to define our terms. This is an example. This is actually speaking of value stream mapping. This is an aggregate of some value stream mapping work that some of our teams have done at Pivotal and you can see the basically number of studies here is 15 so it's a small-ish sample size if you're trying to get this published in an academic journal but we're not. It's just a good sample size beyond at least one customer to see, okay, they're provisioning a lot faster. They're getting technology into the hands of their developers as fast as they can get started on day one. I think, again, the tallies talked earlier this morning, talked about how it took on the main stage you heard, Nikola talk about how it was taking four months and now they can do it in 24 hours. It was spending more time coding so in his breakout session, Nikola also talked about how the developers are now, they've got about 50 developers on the platform and they're spending 80% of their time coding so it's nice uptick. Releasing 61% faster and so the time, we'll get into this more but just the time between when things are really done and actually in production, there's a surprising amount of lag of course that people face there, I'm sure everyone here is familiar and then of course on the day two operations side keeping things up and running, keeping the lights on but having it take less time. This is what I used to use for defining success. That's a lot about speed. I had to kind of scribble over the Garmin numbers because 10 months later they were doing 3,000 deploys instead of 1100. This is another kind of recent one that I liked so this was a couple weeks ago in Washington D.C. the development bank of Singapore just to get a little bit of geographic diversity. I was sort of new to the story of what they're doing and so you can see how they're getting their major releases out faster, they're provisioning instantaneously and they've been running for two years without downtime. So there's a lot of great examples of success and these are kind of nice numbers to throw around but now it's figuring out how did they get there so that we can repeat these patterns. So I mentioned the first seven that I've kind of been sharing for a while. This is one that I think is starting to become more well known. So the whole platform is product thing. How many folks have heard that mentioned? I mean even today it's come up in multiple presentations. So I might be a little bit late to the party on being able to claim it as a secret because the secrets sort of come out and I picked Apple because everyone likes to pick on Apple as like the best product company out there. But I thought it might still be useful to spend a little bit of time thinking about what do we mean of having it as the product and the whole as a product's mentality. And I think some of the things that are really important and some of the hallmarks to look for, certainly that I look for so that I can tell ah, this user's, they've got the product mindset. When they've got a clear understanding of who their customers are and it can be a couple different groups. I had one user kind of describing to me how their developers are certainly one of their important day-to-day customers but they also recognize management and their infrastructure team are other customers that they as the platform team have to cater to and they have to understand their requirements and making sure that they're putting their requirements meeting those requirements with what they put into their backlog. And then another thing that I noticed is kind of, and maybe it just stands out to me because I'm in product marketing is sort of the product pride. And so the branding and the trappings that go around really treating this as a product you actually start to see folks really treated as a product. And if you were to imagine yourself at some Silicon Valley company launching a product wouldn't you want all the packaging and the launch and the marketing materials in order to have your product be successful? And so when folks are really kind of getting into it you can tell because they're actually doing all of these things for the platform that they build. So this is kind of an interesting validation of this concept coming from an analyst at Forrester Research Margo, Visitacion, I don't know if I'm saying her last name properly, but I was on a lightning panel, lightning talk panel with her earlier this year and what I really liked is her emphasis on these internal customers and shifting that whole mindset. So she wasn't calling it X, Y, Z as a product but she was describing exactly what these platform teams are doing at some of the most successful adopters of Cloud Foundry, they're doing this and they have this internal mindset around how do we make sure that we're meeting their objectives and we're helping them and we're delivering value and satisfaction. I recommend checking out some of her work. Another example of this that I heard earlier this year at CF Summit in Boston was just an example of solving some of the problems around the platform. At Liberty Mutual, they had the platform up and running and they were noticing that it was taking 22 days for a new developer who was hired by the company, it was taking them 22 days to actually get on the platform. And so they followed the pain, right? They really leaned into that pain and systematically worked through all of the identity and it was mostly identity kind of issues that were delaying how long it would take for a developer to get on the platform. They also had measurement around this, right? So they knew how ugly it was before and then when they were able to get it down to, you know, a developer joins the company and they're on the platform the same day. This is the experience that they want folks to have. And so this is great giving you here plenty of companies who are here talking about like, and we're hiring. So if they're doing that right, they're going to be onboarding developers and so what is their developer onboarding experience like? How much are they having to wade through, you know, just getting credentials on various systems just so that they can get on the platform? So J.Schnipp is kind of the product platform owner at Liberty Mutual and, you know, just an example of how they really, they focus on their customers. Their customers in this case, the developers, they need to get all the pain out of the experience so they can get them on the platform. To the notion of product pride and the branding, there was a great talk. This is actually a couple years old now. I've folks seen this talk from Matt Curry. Okay, so this is because I was a history student. So things all the way back from 2016, I'm going to just keep dragging out to the present so that, you know, the lessons of our ancestors don't get washed away in the sands of time with the turning of the tide and the seasons. I'm sorry, I could keep going with flowery language. It's kind of a thing I'm into right now. So this is one of many things, but he talks extensively about the logo that they built. He also talks about, hey, these are the tools that we're using and this is the whole experience around Cloud Foundry that is ultimately our platform. It's a super set of Cloud Foundry itself. But he gets into the t-shirts and he talks about iterating on the t-shirts. The t-shirt experience is important. And it sort of seems silly, but they've actually found these types of efforts are really important for raising awareness internally at Allstate, so Composed is actually sort of its own division within Allstate, the insurance company. In order to attract developers onto the platform, get them excited, it's actually totally changed the game for their recruiting. And they've pretty much drained all the Cloud Foundry developer talent out of the Chicago area. But nonetheless, like, things like we've thoughtfully designed an icon and branded ourselves, given ourselves a different name just so that we can kind of have an identity for this platform, this product that we've built. Some things that I think this kind of extends beyond just the straight platform experience, but the notion of taking that product mindset and applying it to some of the different challenges that we keep running into. Cloud Foundry has solved a lot of really interesting challenges around deployment and scaling and stability of the application, particularly stateless applications, but then I'll often hear from folks like, oh, but what about the data? And yeah, data adds a lot of interesting challenges on its own. I've seen some really interesting work done out of the HCSC team, Health Care Services Corporation, with what they've built in terms of exposing APIs to their developers and kind of behind the API curtain, they're doing all the data engineering to clean up master data management issues and to address aggregations that need to exist between member data and claim data and whatnot. And so while they're not calling it, like, oh yeah, we're building these internal data products, I step back and look at it and I'm like, well, that's kind of what you're doing. You may not be at the point where you're calling it that and you're branding it, but they actually have done a lot of interesting work to expose APIs, cleaner APIs for either the, you know, I need to read data or I need to write data, and that's helped improve the developer experience. Security is another one, right? Security is another one of those kind of gnarly areas that like, ooh, you know, like how do we solve that one? And again, listening to just my own colleague, Molly, talking through how she kind of built up these security practices to not just shift security left and bring awareness earlier in the process, but start to kind of increase the empathy and facilitate writing more secure code earlier in the pipeline. Here we're just talking about cloud foundry engineers working across the entire community of contributors. And, you know, again, she doesn't call it like, hey, I'm building an internal security product in order to, and I'm trying to sell to my developers to get them to kind of use my product. I keep using air quotes, not only because I like Dr. Evil, but it's a little bit less tangible than even the data stuff here because at the end of the day, they're really, they're not even showing up with like, oh, here's something to plug in. They're showing up with, let's workshop how you can make your part of cloud foundry more secure. And so, but I think there's some lessons we can learn from this in some of these other disciplines in order to change what has otherwise been a high friction relationship between two entities. And so the relationship between Dev and Ops, obviously, is kind of, we're easing that friction with things like a platform that's designed to kind of cater to the needs of the developers. That helps that previously challenging relationship. It's like, well, now let's look at all of the other, you know, family dysfunctions that are going on in the organization and see if we can try and reuse some of these tricks. Okay, so that was number eight, applying the product mentality. This is another one that I think once you kind of hear it, you're like, well, yes, of course. It's a little bit of an extension of investing in test automation, but I specifically am trying to go beyond just that. I think it's increasingly well understood how important having test coverage and automated tests are so that you can confidently make changes to your code. But I started to notice that really there's all these other folks at the dance party between code complete and in production. And so some of these other folks at the dance party are folks like compliance, some of the security checks that need to happen. And then there's the whole notion of like, have we made this whole pipeline shorter, we collapsed it, which is sort of coming back to secret number four. I know you all have memorized the first seven secrets already. Secret number four all about measurement, but it's important to, I think, bring it back here. So if we look at, you know, what folks are doing, I like this setup from Kyle Campos, who was previously at CSA Insurance. He's recently moved on from there, but there's very like almost like Lord of the Rings kind of feel to this valley he's illustrated with, you know, okay, so there's the code commit and the CI, right? Like we got our CI there. But now it's the change request and the change approval and the change window and the change validation and the pre-prod environment. And you know, there's a lot of twists and turns and slippery corners to take at low speed. And so it's a nice setup and sort of the contrast is that the punchline he gets to in his talk is really about, you know, wouldn't you rather fix a problem that you kind of did 38 minutes ago versus three months ago? Which I actually think it's great if we're talking about, you know, something that you only did three months ago because a lot of folks, you know, have also been dealing with, well, you know, I wrote that code nine months ago, like I can't even remember, you know, what I ate for breakfast. So how am I supposed to improve on something I did three months ago or nine months ago? And it's a good, I liked it. It was a really visceral way to remind ourselves of why these tight feedback loops are important. So I recommend checking out his talk from the Boston Summit. But this is kind of one of the first ones that I saw last December that I thought was really interesting when we're talking about compliance. And so CERNR is a, they create medical software so they're subject to a lot of compliance standards. And in this case they were talking specifically about concourse. Are folks in here using concourse? Okay, it's really popular certainly on the platform, like, you know, doing your cloud foundry installations and updates and whatnot. We obviously advocated a lot in Pivotal. But even on the development side, obviously there's been a lot of tools that already exist for the developer CICD. But what's interesting is concourse is particularly nice around kind of these very open workflow concepts. And so being able to plug in different steps in a workflow, it can handle that with relative ease. And so they're an ISO 9000 compliant company. They actually have to do cumulative releases because they're not allowed to release software more frequently than every two weeks. So they've had to kind of tweak their whole pipeline in order to fit with their compliance needs. But you know, when it's time for someone to do a sign-off, that just gets added as a resource in concourses. You know, okay, it's going to open the JIRA ticket and the JIRA tickets close, the rest of the pipeline kicks off. So seeing that there are ways to kind of break through these barriers and actually turn what are otherwise these high-friction steps into an API call, to me is really encouraging and I think an emerging best practice. This was another one that was just a couple weeks ago, Matt Rule from Liberty Mutual, who's actually on the security architecture team. He's really great. He's based out of Indiana and a lot of the folks for Liberty Mutual are in New Hampshire. Folks not familiar with US geography. This is a full-time zone apart. And so we were kind of getting together stuff and he'd never met these colleagues. So they work for the same company but meeting them for the first time. He's been out there really working with a lot of developers in order to help them write more secure code. And so I'm sort of showing the punchline slide here. I recommend checking out his full talk. But they're using things like injectable secrets management and really trying to pull forward a lot of... and automate a lot of these kind of security best practices. What's interesting up in the corner there, you see kind of some of these cloud security guardrails. Basically, they're starting to get a lot of clarity around the responsibilities they want to give to developers for security. And I think clarity is the key word here. Just being able to tell people, hey, you're a developer, this is what you're responsible for is kind of a first step towards actually being able to build a healthier relationship, right? Like I have a strong hypothesis. It's not quite a thesis yet, but a hypothesis that most domestic relationships break down over dishwashing situations. Do you load the dishwasher right away? Do you rinse the plates first? How do you load them into the dishwasher? I mean, does anyone else experience this with like a roommate or a spouse? I mean, I'm pretty sure divorces happen over how you load the dishwasher. So a clear set of expectations of this is how we're gonna do it or I basically leave the loading to my husband because I don't really want to put, especially when you get to the end and you're trying to squeeze in those last couple of dishes. I'll do the regular ones, but those last couple of dishes, I'm not touching those because I know that he's kind of got strong opinions about how he wants to do it. So wherever you can get these clarity around what are the responsibilities that you as a developer have, you as a domestic partner, what are you doing at the dishwasher or are you actually encrypting your data? These things, they're not so different really. So security, again, putting security as part of that pipeline and automating that as much as possible so you reduce the friction. Also, great thing he highlighted about when you start to get to these distributed microservices, it's not physically possible to do the manual reviews. There's too many services to look at and they're trying to get them out so quickly. So you have to move to a more automated system, but pulling it forward and getting that relationship with developers up front and then a lot of automation into your pipeline can really help with that. I'm just going to do a little time check. Okay, this was another one that actually I didn't catch. It was during the keynote at spring one that was delivered by the U.S. Air Force and Andreas actually caught that there's an OWASP step in their pipeline. This was in their keynote. They didn't talk about it at all, but if you looked really closely at their slides, they had that. Now, I don't really know what that means because like I said, they don't really explain what it's there, but I was like, nice catch Andreas because yeah, there's some kind of security step happening in this pipeline, which is not surprising given that it's the military, but just another example that I wanted to call out. So I'm going to come back to that 38 minutes into Kyle Campos' talk because Kyle actually was explaining how he's... They've instrumented their pipeline. They're somehow using Datadog in this whole architecture, but they've instrumented their pipeline to the point where they can now measure from the time when the build is ready to when it's in production and they regularly monitor how long that's taking and they have certain thresholds and service level objectives around that. And they know if it goes over 150 minutes or something like something's really broken. But 38 minutes is kind of, I guess, I don't know if that's their top time or their average time or kind of what they like to aim for. It's certainly in the green. Now that they have clarity around it, they have visibility into what... Because they're measuring it and they've instrumented it, they can really understand that path to production. We've automated it. Is it working? We interviewed Kyle on the podcast that I co-host as well earlier this year. And he had a really interesting stance about every single group that was kind of coming and saying no when they were trying to move towards a fully automated system of delivery. His answer was basically, you get me an API and we will pull it into the pipeline and really kind of putting an onus back on different groups that were blocking and saying no and saying, okay, you have that responsibility to us in the development organization to provide whatever check you're trying to do, provide that as an API. And so it seemed like that was kind of an interesting tactic to kind of motivate folks to actually collaborate in a way that they could use for automation. So this now, I had to make the font a little smaller because now the list has grown to nine from seven. I was thinking it would be nice to get three and then I'll have a nice round number of 10. But you know what? I was like, these are the two that aren't on the list that should be on the list and I don't want to force it. And so maybe there'll be a 10th or 11th someday. I'm here taking a lot of notes. But this is kind of where we are now and I'll add some more resources to the URL I shared earlier. So I also wanted to highlight, there've obviously been a lot of great talks already. There's a couple more talks coming up at the conference here that sort of looked a little bit like they were going to be continuing to validate and provide more insight into some of the secrets that I just shared. So in terms of that path to production, there's a panel discussion later this afternoon with a number of different security vendors. And so security being kind of I think a big challenge in terms of trying to fulfill the rest of that automation beyond just your unit and integration tests, make sure all those security checks are happening. So there's a couple of vendors that have been building integrations with Cloud Foundry in order to help shift that burden more left. So those would be good to check. In terms of the platform as product, a couple of sessions, one later today and two tomorrow, you know, the Terraform one isn't really explicit about the whole product mentality, but the reality is like it's clearly for that operations team. And it's from the group at Orange, who I know from some of their other talks are definitely operating in that mode. So I would imagine it's going to be useful for folks who are trying to adopt that platform as product mentality. Then there's a talk that really is explicitly platform as a product from Paula Kennedy, who's worked, she leads the team out of Amia that basically helps get this started with a lot of pivotal Cloud Foundry customers. But you know, this is something that the idea is, of course, they're all being shared here with the community, so I encourage you to check it out. And then finally automate all the things from the Reichspotterstadt team. Again, later tomorrow, you know, the way this team is operating is very much in that platform as product mode and this kind of mentality of automating all the things. It's sort of a crossover. It's a little bit platform as product. There might be a few things in there about kind of automating the full path to production, but I sort of felt like it was going to be in favor of platform as product, so I put it in that group. And with that, I think I am just at a time, or there might be time for a question or two, or happy to chat in the hallway. Thank you.