 All right. First of all, thank you so much for joining me this morning. I am absolutely floored by the number of people who are here to hear about the Fourth Industrial Revolution at 9.30 in the morning. My name is Sarah. I'm the field CTO for MIA with HashiCorp. For those of you who don't know HashiCorp, we're a community-oriented software provider. We do Terraform vaults and our goal is really to provide secure operations and operation provisioning across the board regardless of what kind of environment you're in. So whether that's Kubernetes, on-prem, public cloud, or a mix thereof, our jam is really to make sure that you can get the most out of all of those things without some of the cognitive load on your developers and making sure that that remains secure, particularly as we see the market kind of evolve in that direction. So as field CTO, one of the things that I get to do, and I think I probably have one of the coolest jobs out there, is I spend a lot of time with the Fortune 500 and with the Fortune 500, I help advise them on how to get the most out of their cloud operating models, little tweaks and things that they can do to really make sure that that operability is there. I began my career though as a software engineer and once I saw that there was really quite a large disconnect between the security side of things and the velocity side of things, I put a lot of time and effort into figuring out how we can kind of start to unify those two things, because as we see this market evolve and as we see what's happening just generally speaking in the world, it's no longer possible for the security people to say no, and it's no longer possible for the developers and the engineers to say yeah, security is not our problem. So it's really about how are we unifying those two things? But before I was ever in software, before I was ever in tech, I was actually an opera singer. So I love being up on the stage. I love talking to you guys about what's going on in the world. So without further ado, we're gonna get theoretical. Now I know it's 9.30 in the morning and I'm sorry and some of these things are gonna sound really random as I throw them out. So it's gonna sound like a bad joke, but the question is what does a Franciscan friar, a computer scientist, two military theories have to do with scalability? Promise we'll bring it back around, but keep that in your mind. All right, so let's start with a little history before we move on. What I wasn't aware of until a couple of years ago is actually we're in the middle of the fourth industrial revolution. There have been three precedent ones and what I made the mistake of doing was actually conflating those first two industrial revolutions. So thinking that some of this mechanization, steam power actually was part of that assembly line and moving a little bit more into automotive and things like that. Well, it turns out these two things are very separate. First industrial revolution began late 18th century and is really about increasing the speed of goods, so textiles, things like that, and then dispersing those goods. Oh, steam engines, railroads, things like that. Now with the second industrial revolution, what we saw was the late 18th century and that lasted until about mid-19th century and was really marked by the transition from hand production to machine production. And we see this specifically in the automotive industry. Things like Henry Ford in the assembly line and making sure that all of these things can be a little bit more mass produced and produced at scale. Third industrial revolution, perhaps my favorite and probably then dates me, is about computers, technology, and again, automation within factories. So things like ENIAC, ATRAX, VHS, Nintendo, all those good things. But also then I think towards the movie Willy Wonka and you know the dad who's screwing the toothpaste caps gets replaced by machinery because the machinery is faster, it can crank that all out. So now today, we find ourselves in the middle of the fourth industrial revolution. And that's currently ongoing and we're really towards the beginning of that fourth industrial revolution. And that's the integration of the digital and the physical with biological technologies. So all things AI, IOT, biotech, nanotech. All of these things start fuzzing that line between digital and physical and bringing that together. And as we see that happen, what's happening is that we're changing business models, we're changing adoption models. And so that's also having an impact on how we scale people, how we manage things like smart devices because they have to be connected, but at the same time they're tangible assets that we need to manage. Now the last thing I want to mention about this is if you look at all of these, each one is built on the last. We can't have steam-powered assembly lines without having mechanization. Keep that in mind as we go forward. So next random topic I want to throw at you, is our friend Occam, an Occam's razor. So William of Occam is an English logician, also a Franciscan friar. And he says entities should not be multiplied unnecessarily. So what does that mean? Well basically, it's what we consider to be a practical guideline. It's not a law. It's not natural law. But it's something that we can base how we develop and how we move forward, essentially. We see it a lot happen in science and technology. And it's basically, yeah, if there are multiple explanations of a hypothesis, typically the simplest one is the correct one. So it's important that we note that that's within a particular context. So if I'm operating within that context, I need to be able to make a decision based off of the fewest assumptions possible and take the fewest steps forward while I'm taking into account my environment. And that's most likely going to lead me to the best solution. Not always, but mostly. So advice that I don't take very regularly is that probably avoid over-analyzing situations. Clearly, I don't take that advice. So next up, we have the computer scientist Malcolm Conway. And Malcolm Conway first expressed this idea in a paper in 1968. Now, fun fact, this paper was actually initially rejected by the Harvard Business Review because it said he didn't prove his thesis. This is something that today across software engineering, we hold to be relatively true and we actually call it a law. Now, I'm sure a lot of you have heard of Conway's law. For those of you who haven't, Conway's law says that the architecture and design of a system will directly correlate to the communication structure within an organization. The more complex the organization is, the more that that's going to be reflected within that architecture. If I have a disparate team spread out over many locations, who don't talk to each other on a regular basis and create something that's relatively complex, that's relatively true. We've seen, we see that a lot. I've seen that a lot. If we have a team that's cross-functional, speaks to each other on a regular basis, has good communication and understands the business problems, that lends itself to a simpler architecture, a simpler design and something that's a little bit more sustainable over time. So if we distill this out, what we're actually saying is that while the underlying technology for software development is incredibly important, software development is also Yeah, it's as much of a social process as a technical one. So your next next theory lesson for today, Willow Run. Now Willow Run, for those of you who don't know your American history, shocking, was actually a factory, a manufacturing complex that was located in Michigan. And it was run by Ford Automotive Company to create bombers during World War II. So the problem was that at the end of 1939, there were approximately 1200 bombers left, which was not enough and this fleet had undergone immense shrinkage due to Blitzkrieg, basically, so total war. Roosevelt at that time said, that's great. We have 1200 bombers. I need 50,000 by the end of the year. Oh, and by the way, I need 50,000 the year after as well. Well, at that time, 300 bombers were being produced a year. So That's a pretty drastic increase. So 1939, which revolution? Second. What was the second revolution? Automobiles, assembly lines, Henry Ford in the Ford industry. So they brought in Ford and what Ford found when he came in was that there were no concise processes, that everything was kind of running ad hoc, different parts, different people making different parts assembling things differently, and he said they were producing a custom-made plane together as a tailor would cut a suit of clothes. No two were alike. So then what Ford did as he came in, he overhauled the entire system. It wasn't perfect at first. There were still some major issues, but it was an iterative process and basically by using common reusable parts, specialist functions, assembly lines, see where I'm going here. The plant was able to reduce the speed of creation of a bomber to 63 minutes. That's down from 1,752 minutes for a single bomber earlier in the year. So suffice to say five years later, there were more than sufficient bombers and this has really become representative of what is possible with automation with industrialization across the board. Last military concept of the day, the Udallup. So the Udallup is a concept that was created by, excuse me, first name, forget it. Anyway, Colonel Boyd. And Colonel Boyd came up with this idea that in order to train a pilot and to have them make the best decision, they need to have this loop in place. So it stands for observe, orient, decide, and act. It's a four-step process and it's something that really guides particularly air combat pilots. And the reason that Boyd came up with this was when he was in the Korean War, he noticed that the best pilots weren't the ones that had the best technology. They weren't the ones who had the best machinery. They were the ones who could create this loop and execute on this loop the fastest. So as a result, what they did is they started training the Air Force and they started training the Air Force to observe, orient, decide, and act. Because what we've seen is that in competitive situations, the faster you can complete this loop, if you can complete it faster than your competitor, you actually have a higher rate of success. So now, it's still used in military. It's still used in military strategy. It's also something that we've actually adopted into the business world, particularly in highly competitive situations. And I think this is something that we see particularly with the large CSPs, for example. They're constantly competing against each other, iterating, coming up with different services, products, so that they can be first on the market, so that they can have the larger market segment. All right. But we're here to talk cloud native. It's now 9.45 in the morning. So why am I standing here talking to you about seemingly random concepts and history? Promise, it all ties into each other. So, let's talk a little bit about IT. Now, when I work with different leaders in the industry, what I really see is that we have three common goals. And within these three common goals and these strategies, some are more successful than others, if I'm going to be really honest. We see all ends of the spectrum. We have certain companies that are very on top of it, leading, cutting edge technology, and fulfill all three of these. We have others who are really still trying to orient and figure out how do we approach these different things. So the first one is really about accelerating that time to market. How do we get there faster, and how can we make sure that we provide that ability to do CI CD consistently across the board, so that our app devs are releasing business logic, and being able to really augment our position as a company and our deliverables. Now, one thing to keep in mind, this becomes incredibly important during a time when we have an economic retraction, because what has been our bread and butter up until now, if we look currently, say, we have a 10% inflation, basically everything just got 10% more expensive, but we're not making more money based off of it. So what we need to take into account then is that we really need to innovate at that point, because we can't rely on what's currently in place to maintain that structure. So that time to market becomes really important, particularly during a recession. Then we have security and governance. I think none of us are probably shocked to hear this, particularly as we see more attacks, we see, you know, it's in the news, large companies, everyone's getting hit. It is a reality. You have an attacker on your network. So then it becomes a question of how do we enable security teams to set policy and set policy as code, so that the rest of the organization can run within those confines, within those guidelines, and make sure that they still have that time to market. Then last, but certainly not least, is about improved operational efficiency. By improving your operational efficiency, you maintain that consistency and the other two then can do what they need to do. You have the security, you have the time to market. So all of that rests a little bit on your operational efficiency. So let's go back to Occam's razor. GCP, they list a hundred different services and products in their service catalog. Azure says over 200, AWS says 238. So I'm a mom. I have two girls. They're 9 and 11. If I give them five choices, it's already chaos. If I give them 238 choices, I promise you all of us are gonna be in tears. They're gonna be in tears. I'm gonna be in tears. I'm gonna guess the dog's gonna be in tears because they're gonna want to choose what's shiny. They're gonna want to choose what tastes good. They're gonna want to choose what they think is logical in their context. But that's not what's logical in my context. I don't want to have to clean up somebody, you know, because they have a stomach ache or they didn't make the right choice because in the broader context, which is where I'm coming from as the parent, we don't see it the same way. So if we want to translate that to the IT world, how are we enabling developers making that simple for them to make the right choices so that they can support the business value and by supporting that business value and making that more simple, we're providing more room for innovation, but room for innovation that's gonna mean something that's gonna hold value down the road. Now, if we're talking simplicity, let's also talk about Conway's Law because you know what? These two things actually tie together. I need things to be simple on the tooling side of things. I also want things to be more simple on the people side of things. I have a colleague. We affectionately call him Aquaman because he looks like Aquaman. And one of the things he always asks his customers is if you had one wish to change your organization, technical, people, anything, what would that be? Now for me, without a doubt, without a question, it would be to solve the people problem because that is the most complex problem that exists out there. Now, if we put in Conway's Law in place, what we're seeing is that yeah, it becomes a strategic and an executive decision. So how can we create some of these multifunctional teams? What we know anthropologically speaking is that humans are capable within any particular context of about a hundred relationships. If I look at some of these organizations, which are hundreds of thousands of people, we need to figure out how we can boil that down so that we have the correct relationships and these cross-functional conversations, because we also know that cross-functional teams are higher performing teams, and that also reduces that complexity in terms of people, which means your organization is going to become simpler. Willow-Ren, I'm just going to say it, you can't scale a unicorn. You can't make a unicorn on an assembly line. So why are we trying? It seems silly to put the fate of an organization in the hands of a couple people who are creating bespoke tooling. When we know that the current attrition rate is 23 percent and we know that there are more jobs on the market than there are people to fill them. Make it a conveyor belt. Make it possible so that when that person leaves, your business isn't left high and dry and you aren't including more security risk, velocity risk, complexity risk, and again, if you do this, that gives your unicorns the opportunity to innovate and do that in a way that is then consumable for the entire organization. Udlup speaks for itself. If I'm focused on the outcome, if I'm focused on complexity, getting through these political conversations with all of these different people in all of these different places, because Conway's law says that that determines my architecture, this is what I end up with. I end up with spaghetti. I want spaghetti. I want something clean. I want an iterative loop. I want to be able to improve my architecture. I want to be able to improve my development. I want to be able to improve my organization. But if I don't have that feedback loop, if I don't have the velocity of that feedback loop, I can't have that iteration. I can't have that feedback and it makes it a lot harder to drive that innovation as a result. So mostly engineers in this room, I'll step back from theory and give you some numbers. 76% of organizations are multi-cloud. That's just cloud. We're not talking platforms. We're not talking VMs. We're not talking flavors of Kubernetes. Cloud. That in and of itself is an incredible level of complexity, especially if you're looking at those three pillars. 75% of cloud migrations are over budget. Now, if we're looking at, you know, 80% of organizations in the world moving to cloud and 75% are over budget and we're looking at 10% inflation, that gets really expensive really fast. 45%, so almost half of that budget is actually going to change management. Now, I would be willing to say if all of you go back and you look at your change management and the things surrounding that change management, most of that change management can actually probably be automated, industrialized, simplified and you will unleash a lot of that budget in terms of that 45%. And if we look at revenue loss just based off of misconfiguration because people are doing bespoke things within organizations and not following best practices, if we just look in the case of networks, just networks, 9% of revenue lost, that is an insane amount of money. So I'm going to bring you back to this. Time to market, security and governance, operational efficiency. How do we embrace and support these priorities to bring efficiency to the industry? For those of you who know HashiCorp, this isn't going to be any surprise to you. Well, when we start across the board, what we almost see is this tactical cloud experience. Within the tactical cloud experience, we just unleash developers, engineers, loose in AWS, say do what you need to do, develop your thing, go to market. What we soon understand is that there's no repeatability. We don't know who's running what the ecosystem looks like. Security people aren't happy because everything is bespoke. They can't come up with anything to follow everything. It's not scalable. Operations people, very similar. They're saying, yeah, I can't follow all of this. This is all different. How do I use this within my organization? And networking people, they're all like, I'm supposed to do all of this by hand. This is all different. I can't manage it. How do I do this? So, it's not sustainable. It's chaotic. There's no feedback loop. And it doesn't work. So then the next step, and once we realize that we really need to get it together, create something a little bit more packaged and consistent, is to create that cloud platform team. And really the goal here is to create that underlying functional team that can then support the rest of the team. So that when you have your application and development teams, you have an embedding of somebody from that cloud team, to help you make that connection. That simplifies the communication between everyone, and it makes sure that knowledge is being passed seamlessly from one team to another. So, basically, if we embrace that in our specific context, using the most cutting-edge, coolest technology, is it the right choice? Probably not. The boring thing to say. Sorry. But it's the way that we can scale. It's the way that we can innovate, or create time so that later that we can innovate. So basically what we're doing is simplifying the ecosystem and creating a broader cross-functional platform. And that is going to allow us to collaborate and automate, drive out some of those unicorns, and really just help us migrate that digital and physical so that they're kind of more unified. Now, once we've done that with public cloud and what we're used to, then the sky's the limit. We can start doing this with whatever we want to, because we know it scales, we know it works, we know it starts driving out some of these bottlenecks as well, and you have that collaboration, that iterative loop. The simplicity is there. The collaboration is there. It works. So, bringing this back. We talked about Conway's Law. We talked about Occam's Razor. We talked about Willow Run. We talked about the Ooda Loop. All of these things boil down into simplicity. Communication. Standardization. Automation. And agility. You know it's easier said than done. But as you go through your development practice, as you as teams, platform teams, app dev teams, start looking at your best practices, what you're doing, what your day-to-day looks like, start thinking about how these things are playing into that development process. How are you simplifying things, making sure that it's easy to pick it up, that things work logically? Simplest answer is usually the correct answer, remember? How are your teams communicating? Do you have an open line of communication with your platform team, with your app dev team, with your SRE team? How does that work cross-functionally? Because again, high-performing teams are teams that communicate, and the trust is there. Standardization. How do you make sure that you have that cookie cutter? We saw with Willow Run, that's an immense gain. 63 hours down from 1,752. Imagine what you can do if you kind of take some of that time out of your development process. Then you can really start to innovate. Then you can really start playing with the cool stuff. And then once you automate that, have it go down that assembly line. Wow. Then you, you know, the sky's the limit. Then you start playing with the fun things, and you get the candy. And then making sure that agility is there, that feedback loop is critical. One thing that Mackenzie says is there's a direct correlation between the speed of iteration and the performance of a team. So the faster the iteration, the higher performing the team. So I'll leave you with those today. Thank you so much for joining me. I look forward to seeing you again. Now, thank you very much, Sarah. That was fantastic. And just for the records, I do love some spaghetti. So it was great to get theoretical with Sarah. I would like to let you know, guys, we have, we are running off schedule. Two in the, sorry, three in the organizations are Italian. So we have Italian times. I will, we are going to, we were supposed to have a 15-minute break to get from downstairs. We want to go downstairs, and we want to stay upstairs. We have a talk happening at Tempa 10 downstairs. And we are going to have another eight minutes, eight minutes break. And then we are going to speed with the highs about GRPC. Thank you.