 Appreciate you guys coming on time, we're going to get started. Again, won't take too much time as you guys know, no formalities here. We have Mitchell who's come all the way to this conference. How many people here are aware of Packer? I'm sure you guys have looked up his profile and seen all the great contribution that Mitchell has done. It's been a real pleasure to have him here. This is his first time at a conference in India. It's a real pleasure, won't take too much time. Have you up there? Thank you. Hello. Alright, thanks for having me here. I've been here for tourism before, but this is my first time here for a conference or for work in any sort of capacity. I've had a pretty good time meeting people all day yesterday and today as well. I'll be at the conference all day, so feel free to grab me. As Nuresh said, I'm Mitchell and I'm the founder and co-CTO of HashiCorp. I'll just go through and say just the name of the things we've created, but that's pretty much the extent to which I'm going to talk about our software except in passing today. I like to think that as part of keynoting a conference, I think that it's an obligation to try to be as vendor-neutral as possible. I try to do that. I'll tell you the names of the stuff we've made. If you want to talk about any of them, catch me at the conference. If you haven't heard of them, that's totally okay too because there's quite a few. The things that I've created are vagrant, packer, surf, console, terraform, vaults, and Nomad. The last icon is the icon we use for enterprise tools. Those are all the things we've done. It's well within the DevOps space. The company is four years old, vagrant itself. When I started it, it's about seven years old now. For the past seven years, I've basically been really deep in the DevOps tooling, DevOps process side of things. Especially in the past few years, as HashiCorp has grown into a company that's selling quite a lot of product now, I'm spending a lot of time with companies and learning about their challenges and what they're doing and trends and so on. That's what I actually want to talk about today. The talk is titled Looking Forward, and the subtext is the future of tools and techniques and operations. What I actually want to talk about is what are the trends that I'm seeing. I say future here, and future is kind of a difficult word to use because it's relative to where you are. For some of the things I talk about today, some companies will have probably been doing it for the past two, three years, and you'll say that's not the future that we've already been doing that. But for some other companies, they're still two or three years away from potentially caring or doing things like this, so it is the future for them. I'm going to talk about a bunch of different things that I see, and maybe it's the future for you, maybe it's not, but it's all relatively recent. Before I start, I'd like to mention this, which is that no matter what process, what tool, what change we're talking about, within DevOps, the general goal no matter what is to effectively deliver and maintain applications. We just want to be able to ship applications faster while being safe. Because no matter sort of what tool comes out, no matter what process changes, that's still a shared goal between everybody, and I think everyone would agree that we want to get there. And so that's what the tools we're building try to do, that's what these trends that I'm going to talk about try to do. And I think it's easy as this happens to think that things are getting sort of more complicated or more difficult. And I think that it's going hand in hand with sort of the requirements. So if you look at what's happening 10 years ago, it's easy to say 10 years ago things seemed so much simpler. If I think back 10 years, things seemed so much simpler. But then when I think about it, the requirements of 10 years ago were a lot different. I only had to deploy one application that was PHP, dynamically rendered HTML. The company only had one or two applications and it was simpler. Today, the same company is deploying dozens or hundreds of applications and they're different languages. They're different tech stacks. They have to go to different devices now. It's not just one browser, right? It's not just Internet Explorer or something now. It's multiple browsers. It's mobile browsers. It's a lot of different screen sizes. And so to scale with that, we need better tooling and processes in order to just be more efficient. And that's really the goal of everything here. So we're just going to dive right in to sort of like emerging best practices that I'm seeing. And again, I say emerging and maybe it's emerged already for you. Maybe it's not. But I say emerging really because there are things, and these are things that are pretty well accepted now. They're not cutting edge. I'm not going to come up here and talk about serverless or things like that. They're not super bleeding edge. These are things that are more or less safe to adopt these days. And big, big companies are investing a lot of money into making these switches. And so we'll go through sort of each of them and dive into detail. So the first one I want to talk about is the idea of heterogeneity. And I should also mention that each one of these, you might agree with some. You might disagree with others. That's expected. A lot of these are sort of opinions. They're things that I see on a day-to-day basis. They're obviously biased in a sense of what our company tries to do. But they're the things that I talk about with companies sort of on a day-to-day basis. So the idea for heterogeneity is that there's going to be more technologies in use and not less. And I think the best way to explain this is actually to look at the inverse, which is homogeneity. And homogeneity is the idea that over time in the future you'll be able to centralize on a single or a very limited stack, wherever that stack may lie. So it might be you think that you could fall onto a single sort of like computing paradigm. Like everything is going to be virtual machines or everything is going to be containers or something like that. It might be the actual tech stack, which is that we're only ever going to use Java. Or it might be a cloud provider, which is that we're only ever going to use Amazon Web Services. And the intention of homogeneity is pure and good. And it's the idea that if you can minimize the number of choice that you have, you can become experts in that one thing, and therefore be more efficient, be able to get the most out of each stack basically. And it's a noble goal. And if I believed it was possible, I think I would believe in it. But I don't think it's actually possible. And by striving for homogeneity, we're actually making things more difficult. And so the reality that I see of the situation is that the thing that always happens no matter what is change. So things are going to change. And generally speaking with an asterisk, things change for the better. And I put the asterisk there, which is that there might be some stumbling blocks in between. In the long run, things generally change to become better. So I mentioned that things feel more complicated today. The tooling feels more complicated. There seems to be more things we have to learn. But if I think about it, again, the reason we're doing that is because we have so many applications. We have mobile devices, things like that. And those requirements, I really like. I really like knowing that almost any company in the world, I could get an app and do almost everything from my phone and I don't need a computer to do it or a desktop to do it. I like those sorts of things, but they come with the price of complexity for operations and developers and so on. And so if you agree, though, that things change for the better, then when you look at homogeneity or heterogeneity, it basically means one of these things. If you believe in a homogenous future, it's basically saying that change won't happen. This is more realistically saying change won't happen for us because change is going to happen no matter what. So you're saying that your company or your organization isn't ever going to change. Or more commonly, what people believe, and this is a really common fallacy, is that they'll be able to atomically change. And so this is the idea that, okay, containers came out and were on virtual machines. We're going to switch everything to containers like that, like pretty atomically, and a snap of a finger. And so there is no period of transition. More realistically what I see is that change is gradual. You have the goal of being homogenous, you have the goal of going from one tech stack to another, and you're trying to do that atomically, but what actually happens is you have a bunch of steps in between. So on the path to get from state A to state F, you actually have a bunch of transitionary steps in between. And this becomes more complicated because you think it looks like this when everything I've ever seen for a sufficiently large, which isn't that large, just a sufficiently large organization, is that it's more like this, which is that you're heading towards some initial change. So some new technology comes out. Let's say it's containerization. I won't use any specific tools, but let's say it's containerization. And you're starting to migrate everything towards that. And it's going to take you maybe like a year, which is pretty fast. And so you're starting to work towards that. But then while you're doing that, something else comes along and that something else is, let's say, scheduling or Kubernetes, I mentioned something. But let's say it's scheduling and a platform and that sort of thing. So you're like, oh, wait, instead of going to this one thing, we actually want to go to this next thing. But now you're in this funky place where you have some things that are transitioned to F1. You're trying to move to F2 and so on and so forth. And this happens. And as the company gets bigger, as you get more applications, as you get more servers, that sort of stuff, this is more and more likely to happen. And then of course, no matter what, somehow this always happens, which is that you just have the one thing that never ever changes. I can't count the number of times I go into a meeting and the person's like, oh, yes, we've completed our transition to the cloud. And then I'm like, oh, cool, so you have no data centers anymore? It's like, oh, no, no, no, we have those for the Siebel databases or the Active Directory or whatever. So you haven't actually completed the transition to the cloud because there's these things that are never going to migrate or you've chosen not to migrate. And so basically the transition steps in between are periods of heterogeneity, even if you're striving for a single tech stack. And so you go through these periods of time where there's constantly multiple paradigms. You're going to have VMs, you're going to have containers, you're going to have multiple cloud providers, things like that. And so what I instead try to recommend is to embrace it. Don't fight so hard to try to get so quickly to a single thing because it's actually sort of ironically introducing complexity to try to rush that process. And instead embrace heterogeneity and embrace that things will be different all the time. You'll have multiple things going on. And if you embrace that, then you could choose tooling, choose practices that align with that reality. So instead of looking at the monitoring tool or the scheduler or something that only works one paradigm, if you understand that things are going to change and you're going to get stuck in this anyway, you could choose tools that work with multiple things. You could choose tools that work with multiple cloud providers, that work with VMs and containers and so on. And maybe they're slightly less optimal for your one target or something. But then you're better suited to educate on one tool or you're better suited to adopt the new thing that's coming next, whatever that might be. Hiring is also sort of an important part of this. This is a mental philosophy as well. There's probably people in this room that deeply disagree with heterogeneity. And if you hire those people at a company or an organization that instead is trying to go with a heterogeneous approach, it's friction-full. So you have to find people that also believe in this sort of worldview. But then the last point I'll make is to, when I say embrace heterogeneity, I don't mean to just accept complete chaos. It's not every single text. It's like, okay, if we can't have one thing, we swing all the way to the other side, which is we adopt everything. Instead, it's to be mindful. So if you look at companies like Google since the beginning, they've always standardized on three text stacks. And that was their three for a really long time. And now they're starting to use Go and other languages as well. But if you restrict it to where it's not homogenous but it's still, we want this new thing but there's other tools good for this other job, you could constrain it to where you're heterogeneous but at least it's not complete chaos. The next thing is multi-cloud. And this one is interesting because I think it's more new. It's the trend of the meetings I've had in the past 12 months-ish have been a lot around multi-cloud. And there's a variety of motivations for multi-cloud. A big one is regions. So a good example is a company I went to that was completely all on AWS, which is great, which is fantastic. And they were expanding their business. Their business was growing very, very quickly in China. And AWS has data centers in China, but I think at the time at least they had one or two. And then they looked at Azure and Azure had 17 data centers in China and provided a much higher quality of service to the Chinese region. And so this company was at a weird spot because they really wanted to adopt Azure because it was going to provide a better service to their users, but they were all in sort of on AWS. And so that's a good motivation. Another good motivation is features and this is becoming more and more important. Cloud providers used to just be who could provide, you know, compute the best sort of compute the best instance types, those sorts of things. That's really quickly just becoming a commodity like the it's a race to zero for the price. It's there's not a huge margin on it. It's not a huge business. The big business for these cloud providers now are in the higher level tooling. It's in the databases. It's in the cloud SQL. It's in machine learning, these higher level services that are more expensive. And so they're differentiating there. And so we're seeing a lot of I'm seeing a lot of users that are choosing certain cloud providers because maybe they provide the best AI or machine learning as a service for their use case, but they actually want all their compute to reside on a different cloud provider for price reasons or or region reasons or so on. Pricing pricing is a big leverage piece right now. It's a pretty big unknown of where to land, which is also a big motivating factor for multi cloud. At least in the US, we're seeing a lot of subsidies for pricing. So companies are being given basically millions of dollars in credit on cloud providers if they agree to sign, you know, a five year deal where they'll buy in to a cloud provider for a number of years. We recently saw this in the news of companies like Spotify where they signed a multi year deal to get huge savings on Google Cloud. And some of these companies are not, you know, they're most of them are not dumb and they're thinking, okay, but what happens when that deal is up? Do we get the low pricing again? What if someone else offers us a better deal? How is that going to work? And so we're working with a lot of companies that are coming to us saying, okay, we signed this multi year five million dollar deal with this cloud provider. But we want to invest in this and let's say that cloud provider is Azure, just hypothetical. But there's they're coming to us saying we want to also build a team that could transition us to Amazon in less than a month. If possible, so that when those five years are up, we could go to Microsoft and say if you don't give us this deal again, then we're out in less than a month, like all revenue gone in less than a month. And so pricing is a really interesting point right now. And pricing also varies on instance sizes, so or instance features. So some clouds currently provide much better compute for the compute for the dollar. Some provide much better network bandwidth or IO bandwidth for the dollar. And so depending on your workload, it might make sense to go to different things. I know one company that does all their web, like 90% of their workloads on Amazon, but they do the data intensive stuff on Google Cloud because they found that for their workload, they're getting better bandwidth for the price on Google Cloud. And so they're split that way. And I think that this sort of pricing is going to be really weird because you have some artificial stuff like the subsidies versus as well as some like just feature technical stuff like what you're getting all at the same time. And then the last was lock and avoidance, which I just mentioned as part of pricing people are doing too. Which is pretty obvious is people are trying to find ways where it's not too difficult to switch between clouds just to avoid potential lock in or being taken advantage of it at some point. Pretty straightforward. The other thing is multi tech. So what I mean by multi tech is choosing the right tool for the job. And so this may be, you know, this is sort of goes along with heterogeneity. But basically finding the right tool for what you need, looking at the job market, seeing what's available. This motivates things like a lot in infrastructure right now, for whatever reason, the like hot language for infrastructure tools is go. And so being able to embrace go is extremely important right now for an infrastructure company. It's kind of weird because it's really superficial. But I've definitely we've as a company made deals where the customer said they just chose us because we go when the tooling there are competitor use Java. And it's like so weird because it doesn't really matter. But it's it's just the thing right now that people are really comfortable with multi compute. So I'm still talking about multi cloud here. So multi compute is the idea that you're going to have sort of different requirements for your compute. So they might have performance requirements, like I said, but another big one is security actually. And in multi cloud for security is generally on premise versus off. So the cloud is being shown over and over in general. I say cloud is infrastructure service providers are being shown over and over to provide a pretty excellent level of security. However, there's still certain industries, there's certain types of workloads that people still want to bring into their own data centers or more comfortable with different providers. And so these sorts of requirements usually drive the compute choice as well. Another one is existing knowledge and experience. So there's another company we worked with where there was a whole application that was on this one provider that was pretty legacy. But it was because they're so good and so successful at keeping up time based on those machines and the cost for how much money they're making was completely acceptable. That they wanted to move to something like AWS, but they didn't want to move that one set of that one application is pretty large. And that makes a lot of sense to it saves the company more money in the long run, as long as you can manage those two things with ease. So the challenge of basically all this multi cloud heterogeneity stuff is usually just management. It's usually how do I use these different things and have different APIs have different features without just learning, you know, and different tools. And then the other challenge, which is a little bit harder to solve is like speed of light issues, which is that you can't really use, you know, you can't send data faster than the speed of light between two cloud providers. So you really want to localize your data and things like that. So there's that issue. But there's some solutions here. And so the solutions for the management are usually choosing tools that accept heterogeneity, multi cloud, etc at its core. These are things like Terraform, which is our tool for building infrastructure for any cloud provider. And these are also things like Kubernetes, which is not our tool, Kubernetes, which can schedule workloads on any cloud provider, basically. And the idea is that the you're separating the workflow from the actual technology underneath. And if you're able to make that separation, then you could find tools that help you with the management layer without affecting the technical decisions. And I talked about scheduling next. So I'll show how Kubernetes why Kubernetes things like Kubernetes and schedulers are so important to achieving heterogeneity and multi cloud and all this sort of stuff. And so that whole trend is generally called data center as computer. This is the idea that you could view a data center as a single shared resource rather than a collection of distinct devices. Can you look at your data center as the sum total of the available RAM and compute and IO and network and so on rather than rather than separate machines. And this is best illustrated sort of with just a graphical point of view. So today deployment like generally looks like this, right? Like you have developers on one side, they package things up and then they throw it over some wall for someone to handle. And the way that's handled is let's say you have a bunch of servers. Those servers are generally, you know, pretty special maintained. You keep them up, you keep them running. And then when you have an application, you choose where it goes. So when an operator gets a new application, they say, okay, I'm looking at the servers. The best place for this is probably this set of machines and they put it there. That's all okay. But when it gets the point where it gets really hairy is when things start failing or changing. So let's say one server fails like this server or you add a server. What do you do? And for most companies, it's an event, right? Like it's a thing with a lot of hard work and planning and so on to make this a reality. A good test of whether you're at a data centers computer sort of stage is if I were to walk into your data center, physical or whatever, if I were to walk into your data center metaphorically and I were to unplug random servers, would you continue being relaxed or would that be extremely scary for you? And the goal with data centers computer is to get to the point where it just doesn't matter. Unplug whatever you want as long as it's not more than a certain percentage probably. But just go ahead and unplug things. So the reality that's causing this change is the number of servers and applications just growing at a breakneck pace. And I use the word breakneck pretty purposefully here which is that the number of servers that we need to deploy, the number of applications we need to deploy on those servers is happening at a very uncomfortably fast pace for a lot of companies. And yet a lot of companies, their value today is viewed by these applications. A lot of our customers are banks and a CEO of one US-based bank really broke it down for me when he said that the way he views his business today is that 100 years ago the core value of their business is who could store your money and give you the best interest rate. Who could store your money the safest and give you the best interest rate? It was pretty much like 100 years ago. He said today the business is just who could deliver the best mobile application. That's it. So his whole thing is like the only way this bank is successful is if we could deposit your checks faster, if we could do more from the mobile app, if you go into the branch less, if we could get you a mortgage faster while being safe, that's the name of the game for him today. And this requires just deploying applications. So there's a few choices with regards to this growing number of applications. One is that the growth will slow down, that this is just temporary. We're deploying a lot of applications, but there won't be very much more. It's going to stabilize at a certain point, maybe. A second choice is just to train and hire more people. So you could say, okay, we have 10 times more applications to deploy. We'll just hire 10 times the people and manage it exactly the same way, no problem. And the third choice is actually probably a mix of two and three, which is to lower the cost of what you're doing, the complexity of what you're doing, and hire more people, but allow those people to have more leverage to be able to do more. And this lower cost and complexity is really equivalent to data centers computer, the idea of data centers computer. So going into that, the core idea here is to separate applications from the resources they run on. And again, visually, the way this works is you have an application, and instead of manually figuring out where that application should go, you instead pair that application with a description of what it needs. So this application may advertise to whoever, through the system, that it requires 500 megabytes of RAM, it requires as much CPU, it requires as many IOPS. And using that manifest, that description specification of what this application needs, it could then be scheduled onto whatever server makes sense for that sort of thing. And in this world where you have something, a scheduler making this decision for you automatically, then you have a situation where let's say this machine goes down. If this machine were to go down manually, then you would have some red flags and monitoring. You would put aside what you're doing, figure out how to migrate this application, whether there was any state concerns. It's probably an afternoon, let's say, of recovering here. With a scheduler, the idea is that it views the specification, determines what to do, and just moves it to the next best place at the time. It also usually does balancing in the sense that when you add a new server, you just add it, and then it decides whether or not it should just move an application to better balance things out across your infrastructure. And the interesting thing is this allows for choice in the low-level components. So this separation actually makes a separation between what kind of servers you're running and the application running, and it doesn't matter anymore. So if you adopt something like Kubernetes or so on, then whether you're using AWS or you're using Google Cloud or whatever, the developers are completely separated from that now. The operators only have to install and maintain a Kubernetes cluster and spin up resources. Developers just have to make sure that they're advertising the right things that they require, and then you just deploy, and they get routed and so on. There's a few challenges today associated with this. One is that management of these systems is very complex. Kubernetes is sort of like, someone described it to me yesterday as just another thing that they have to maintain, and I think that that's a temporary thing. They're relatively new, so it's going to take time for these things to become much more stable, and I think over time it's just going to be really easy, not very error-prone to deploy. Another issue is that not all apps currently fit this model very easily, and so an example there is databases, things with state. You can't easily just move those between servers, and so this is usually the first thing someone points out, which is, oh, we can't adopt this because we can't move those things. And then the last one is a thing of trust, and this is more of a human thing, but it's easy to trust, I guess, yourself when you're manually deciding where you want your application to go. There's an issue of trust when you're giving your application to some automated thing and saying, I'm trusting you to make sure this is running, I guess, somewhere, and you can't even see where that somewhere is because it might be moving at any given time. But there's some solutions for each of these things. So the category of software, this is, the schedulers, they're complex. They take a really long time to mature. They're not easy tools to write, but we've seen sort of in the past, I guess, two or three years, like a huge rise in schedulers because I believe it's the obviously right future that we're trying to achieve. So this is starting with sort of things like, well, schedules have been around a long time, but the popularity of schedulers in the past few years kind of started with things like Mesosphere. Now it's Kubernetes everywhere. We have a schedule called Nomad. There's all these different choices that you basically have to get schedulers, and every single day you wait, they're just getting more mature and more stable, so that's the good thing. This state issue is really interesting, which is, how do you do schedulers with databases? I'll use the words that we used to describe how to do this. So we look at state as three, there's three types of state out there, and this is our scheduler Nomad views it this way and makes scheduling decisions based on these types of state that you advertise. You have ephemeral state, you have sticky state, and you have persistent state. So ephemeral state is obvious, it's basically a stateless application, you don't need state. Those are easy, you just move them whenever, you just launch them wherever, really easy. Then I'll go to the other side, you have persistent state. A persistent state is also pretty obvious, which is a database. You have a lot of data attached locally on, let's say, SSDs that is persistent. It can't move usually. These are where you have speed of light issues, like moving it just takes time and you can't do it. And then the third one is sticky, and we describe sticky as things where you'd really like to not move the data, but if you have to you could, and so these are things like EBS volumes, network storage, things like that. Like they could move, it's better if they don't, so you'd like them to stick if possible. And so the way our scheduler takes a look at this, and Kubernetes has their own model that's similar though, is that ephemeral stuff, you just do whatever you want. Persistent stuff is a requirement, like if you have terabytes of data on SSDs local to a machine and it can't move, then you've constrained the scheduler, the application just must go there. If that server goes down, the application is probably down. The scheduler can't really do anything about that because the application is constrained in that way. And sticky is where schedulers are really, really cool because most data is actually sticky that we've been. And so with sticky, it's that if something goes down, try as much as possible for that to come back up and to reschedule it onto that machine, like we don't want to move the data because that'll take more time. Or if we're deploying an update to a machine, then put it on the same machine. Or if we added a new server and we need to rebalance applications, rebalance the ones that don't have stickiness associated with it. Keep the sticky things on that machine as much as possible. Stick them. But if you have to, you can move it, reattach volumes and things like that. So state is a solvable problem. It's difficult, but it's completely solvable. And then the other thing I say is that you don't need to go all in on something. So it's okay to just use schedulers for ephemeral stuff and leave the persistent or sticky stuff just unscheduled and manually done. Because usually there's an order of magnitude difference between the applications that have state and the applications that are ephemeral. So you could still get a huge gain by just ignoring the stateful ones for now. The next thing is declarative. Declarative, the idea is that you have goal-driven tooling where you describe what you want, not how you want to get there. And again, as an example, today this is AWS diagram. This diagram is actually a basic sort of three-tier application. You have a load balancer in front. You have a web tier, an app tier, and then a database in the back. And for any basic web application, these are the resources no matter where you'd go that you'd probably want to deploy if it was going to see any amount of traffic. The issue is if I ask someone, a lot of times if I ask someone today how to do this, the person will start saying like, okay, here's what I need to do and start listing out almost like a recipe of how they're going to make this happen. And starts breaking it down, going with each step-by-step of what's going to happen. And then the issue is that when you have a lot of this happening at the same time, say you're not deploying one of those applications, you're deploying five, in a single day you want to do dozens of deploys or changes, then this recipe approach starts to get really complicated because you have to figure out what order to do things, what priority to do things, will it cause downtime, you start having to think about these things. And so again with sort of the growth in like apps and so on, you just get this complexity that there must be a better way. And so the reality of that, one way to describe it, is that to make a change as this thing grows requires a burden of knowledge that's simply way too large. So with all these people asking you, it centralizes down usually into one or two really experienced people that make the serialization choice of what order do we do things, when does this look good, and so on. And I'll talk about how to get rid of that. So the choices in this world again is to hire or train more experts. You could try to get more bandwidth out of your change by getting more expert people that can make those choices of whether something is safe, whether something can be done. Or another approach is to somehow enable the non-experts to safely make those choices. Allow people to not have to learn as much to do the same job. And this hire abstraction that we aim to do is using the philosophy of declarative tooling. So with declarative tooling, you describe your goal and not the steps to get there. There's no recipe, you just say what you want. And so in this example here, the way we do this is infrastructure as code. And so this you actually want to translate into some sort of specification of text usually, just because computers deal better with text. So you somehow want to turn this into text and use that as to describe what you want. The benefits of this is then you get flexible choices for how that actually happens. If it's goal driven, then the tool itself looks at what currently exists and what you want and creates the dots of how to get there for you. The complexity there is gone from you. It's easier to educate these tools because teaching someone how something works is always a lot more difficult than having people just do it. And some people think that it's better for people to always know how something works. And I agree in that it's nice to know how something works. But even if you look today, the number of web developers that I could pull out of universities or boot camps or wherever, the number of web developers I could pull out and say, OK, write me an OS or actually just write me a page fault mechanism, something like that. Describe to me how your compiler works is pretty low because we're past the point where most people are learning how that stuff works. Maybe you take one compiler's course in university today, maybe. And we're past the point where the how matters. But these developers are still extremely productive, extremely valuable because they're moving on to the what past that point. The what is their application, they give it to a compiler. They have no idea of the how, outcome something that they run and it works. And so this is sort of the same transformation that declarative helps push in DevOps at the infrastructure layer. And then the last thing is complex tasks are easily modeled. It's a lot easier to do really crazy stuff to your infrastructure. It's a lot easier to just say what you want than how to do really crazy stuff. But then there's challenges. The big one off the baddest trust. The thing with declarative systems is that they're choosing how things happen and that's really, really scary. And the last thing is really that it's a difficult problem because something that's declarative inevitably has to basically handle any possibility of now to, you know, here to there. There could be anything. So it's that that system needs to be able to handle anything in the middle and that's pretty difficult. So the solutions here, there's a few declarative things happening. Schedulers are actually one. So schedulers that I just talked about are declarative. You're declaring my application requires a central memory. My application requires this and that. And the schedulers are determining the how of how to determine what solves that, how to place the machine, where to place it. That's actually a declarative thing. And you can see how that dramatically simplifies developers to deploy pretty much anywhere. Another thing is Terraform is our tool for infrastructure as code. With Terraform, you actually just say what infrastructure you want, not the steps to get there. And that's pretty interesting. And one of the things that I've learned about declarative tools, since we've made three declarative tools, is that one of the fundamental primitives to address trust is this idea of a plan. So with Terraform and our scheduler Nomad, for example, you could ask for a plan for your declarative document. And the plan will tell you that given the current state of the world, what would that system do? Just tell me the how. Tell me the recipe that you generated. Don't do it. And it's better than... Some people will say that's a no-op. It's actually better than a no-op because one of the fundamental things we support with our plans is you could save them. So you could say give me the plan, save it, and then you could say, okay, execute the plan. And if for some reason the recipe that you're generating is different from this recipe I gave you, don't do anything. Just bail out. And this fundamental primitive has enabled some really complex trust, basically, complex system trust in our tooling. And it's nice because I said one of the challenges is that there's a huge scope. The declarative tool has to handle basically anything that happens in between. And with a plan, you could quickly see cases where maybe it doesn't. It allows the declarative tool to be less than complete. If there's bugs in it or it doesn't support something, the plan probably will generate something nonsensical or an error, and the person looking at the plan could say, okay, let's not do this, report a bug, however you want to handle it. Okay, let's just move on. I was going to give you an example there, but let's just move on because it's easier to app-level security. So the idea with app-level security is to add security features in the application in addition to the network and server, not just trusting the network and server. And again, to illustrate what that is. So today, or perhaps historically, security kind of looked like this, which is that you had this safe zone somewhere, and then you had a literal firewall or a literal wall, a physical wall in your data center where there was like them versus us. It was like the people outside versus the safety inside. And so you would use firewalls to basically protect us versus them. And you'd do server-to-server sort of security with IP tables, routing tables at the router level, things like that. You would curate these by hand and you would protect against threats that way. Internally, a lot of times you would use unencrypted communication because if you were in the safe zone, you wouldn't really trust that the firewall protected you from these things. And a lot of this is really old-school style of thinking. A lot of companies have changed their viewpoint in the past few years, but it's still really, really prevalent. And so the reality today is that one clouds blur the line. So clouds are difficult because you can no longer physically see the wall. Like you can't see where the fiber is coming into your data center. It's sort of all software out there. And so it's kind of scary. Also, it's just you're basically one mistaken API call away from opening your entire network to the internet, usually. And so there's some fear factor there. Another thing is that, I mean, for the past basically 10 years, we've shown time and time again that most breaches and threats are just coming from within. There are USB keys that people plug in while they're on the VPN. There are social hacks of employees and things like that. They're usually not these sophisticated external to internal privilege escalation type situations. They exist, but they're a lot less common. And again, I've been saying this over and over, there's just more applications. So it just becomes more and more difficult to actually determine what the right rules are to let in and what to let out. And so with security, again, you have this opportunity to just manually curate everything. You can continue to do things the same way and just manually vet each of your rules of what's happening. Or you could start enforcing more security in the applications themselves. And this is in addition to what we've done already. This doesn't replace anything. The app level security is end-to-end encryption for your applications, identity attached to every single connection, and then each API that you export has basically role-based access permissions on top of them. So visually as an example, let's say you have these two applications, you have blue and you have pink, and they're talking to each other. And so blue says to pink, you know, hey, I'm Alice. Pink responds, hey, there I'm Bob. You get identity attached to the connection. Let's join right now. So blue then requests something, which is like, okay, I need to bill this third person, Charles, $34. And then pink says, okay, like, Charles doesn't bill $34. So that's like a successful happy case where you have identity, you ask for what you want. Pink somehow is verifying that that's all okay, like you as Alice are allowed to bill Charles $34, and then makes it all happen. Okay, here's another situation, which is, again, blue says, hey, I'm Alice. But this time pink says, like, no, you're not. Like, you're wrong, this is wrong. This is all happening within, you know, the point-to-point connections between your applications themselves and not trusting it to some proxy, not trusting it to some external firewall and things like that. Another, this is a separate example. Another one is say the identity was verified, like you are Alice, you are Bob, and then blue says I need to bill Charles $34. But then in this case pink says, I know you're Alice, but I looked it up, and you as Alice aren't allowed to bill Charles, so you can't do that. And so, again, just with Apple Security, all connections have identity, all connections are encrypted, and then all requests have permissions associated with them that are checked. And the important thing here is that it enables efficient growth. So the example, and I talked about this with somebody yesterday is I went into a company, a big, like global 500 company in London, and we were presenting our software via IO of this company, and 30 minutes into the presentation, he starts laughing, which is never a really good sign. I didn't feel great at the time. But then he stops and says, all these other people that come in here just talk about how fast you can make our deploys and things like that when it doesn't matter at all. He's like, if we deploy in five seconds, if we deploy in five minutes, it doesn't matter because our security team takes one quarter, two to three months for all changes internally and externally to allow traffic to route the application. So our developers could deploy 100 times a day. It doesn't make a difference because there's no new traffic going to those new instances anyway. And so this was really interesting because the issue they ran into was they had one security team managing security for all their IT and applications, basically, which works when you have one wall that you're protecting. It doesn't work very well because that was about a year ago and they've since transitioned to this idea instead where you have core security that is still doing the same thing, which is server-to-server routing tables, firewall, external, internal firewalls, same thing. You're still protecting there. But now they embed security people directly in sets of development teams. You don't have a security person on every development team, but you have one for a few. You have security people there, and they're just handling app levels. The core security in IT is saying our routers will only allow through TLS connections. You can only use these ranges of ports. We block everything else. But what you do with that TLS connection traffic up there is up to you. We require that they have identity attached to them via this mechanism. We require that you check permissions. And those security people on the development teams themselves are enforcing that. So they're saying, how do we get the identity? Are you making sure you're doing TLS connections? And what this allows is applications to deploy as fast as they're made, basically. You just deploy them. You're adhering to core security, which is a pretty broad set of rules. And then you have more specific fine-grained thing at the app level. And they've gotten a huge gain in security from that because there's more encryption, there's more auditing, and things like that. So like I said, it's done in addition to what we're doing already. There's a few challenges here, which is that TLS is hard to manage certificates. It's not hard to make a TLS connection, but it's hard to manage the certificates to make it possible. And that's generally the way you do end-end encryption. Identity's hard. How do you figure out who somebody is and how do you verify that person? And then modifying applications is hard. Like if every application needs security baked in, if you have a thousand applications, you have to go back and change all thousand. And so the solutions here are, one is to get quote-quote like something to manage this, a server to manage this. We have something called Vault. Our viewpoint on that is there's this saying which is you should put all your eggs in one basket and put that basket in Fort Knox. A security saying. And the basic idea is it's better to really expertly secure one thing than it is to try to distribute the security and do it non-expertly. And so Vault is sort of that thing, which is that it's one thing that stores all your certificates and all your trusts. And it's the one thing you have to trust. But we try and you should try also really, really hard to secure that one thing, you know, monitor everything around that one thing. And Vault in this case can manage TLS certificates and things like that. Then the other thing is schedulers can simplify deployment because they orchestrate, they could orchestrate the actual setup of identity. So if you trust something like Kubernetes when you deploy an application, Kubernetes as the orchestrator could actually say, okay, you applications start here, also by the way, you're Alice. Here's your certificate to prove you're Alice and could actually hand these off. And so that simplifies the deployment aspect. And so Kubernetes actually does that. There's a way to integrate Kubernetes with Vault. And then our scheduler Nomad also does that where you could spin something up and it gets its initial secret off information with it. Okay, last thing I'm going to talk about is just DevOps in general. So the idea with DevOps here, there's whole talks on defining DevOps, that's not what I'm trying to do. I'm just trying to explain why, in addition to these technical choices, the process choices matter too. And so the idea here is that multiple teams in DevOps security must be able to work together to actually streamline everything. It doesn't matter all the tools you adopt in the world if there's these huge queues in between the huge walls that you're throwing things over. And so like DevOps, again, I'm not going to define it. I'm not going to define that in any number of dozens of talks per year, basically. Instead, what I'm talking about is changing this process of handing things off to more look more like this, where people are working together. And by doing so, you could have a bunch of teams happening where work is happening in parallel. So this increases the efficiency through parallelization of work. But it requires both tooling and culture to make this possible. So this is where things get difficult and you get those talks like, convince management to change people to change things like that. And it's not easy, right? You could get some gains through people changes ignoring tooling. You could get some gains with tooling changes ignoring people, but eventually to get the most out of it, you're going to have to work together. And using that most recent example of the London-based company that's embedding security people and development teams now, it's the same thing. They could have adopted Vault. Vault could have helped them make it easier, but if it was still all centralized, you still have a central bottleneck and it didn't get that much better. The actual huge win they got wasn't because of Vault. The huge win they got was because they decided to change their management and process practices to have security people on sets of development teams. And so that's an example where the technology actually didn't matter that much relative to this. So when you're looking at it, that's the other big trend So finally, what does this lead to? Like, why are we doing this? It leads to this future where ideally we have a globally distributed set of available resources just available on demand wherever we want it. This is the idea of multi-cloud and heterogeneity. You want to be able to utilize these resources as simply as possible. I like to use the metaphor double-click to run. It's like, you know, brilliant thing with things like Windows where any application you just double-click to run. It's not that difficult. I remember when I first learned Unix, Linux systems, the command line was just like a disaster when I first started learning because I was like, everything's different. You invoke everything differently. They have different flags. I don't know. Whereas on Windows, which is where I was coming from, I was like, you just double-click things and they show up. Why is it so complicated? And I think schedulers are like that, which is any application with a manifest is just double-click to run. Declared it lets you build and deploy by describing what you want, not how you get it, which allows you to shift to the technology underneath. Above it, the apps are secured with app-to-app level security, which lets you deploy different applications on top of different sort of security, like foundations, but still get a strong guarantee or a promise of security at the applications. And then with the people process, as well as the parallelization of work, you can deploy tens, hundreds, styles of applications and scale it with your organization. And that's a really important piece, as well. So I'll skip that, and I'm going to end there. So thank you very much. Hope that was helpful. Right, that was a great start for the morning. Thanks, Mitchell, for that. Thanks. Quickly, I want everyone to thank Michelle for coming all the way for this talk. Any questions for Mitchell? We have about 10 minutes, so we can take about two or three questions. Put your hands up if you have a question. Great talk. Thank you. So, you know, since we use machine learning, yeah, we damp things, right? So when you look at the whole scheduler and stuff like that, is there a future where self-learning schedulers, self-healing schedulers, something like that are about doing all these things? Yeah, definitely. I think that, I think, so probably there's really advanced machine learning, like what self-driving cars are doing right now. And I think there's a really basic level of what I just call intelligence that I think will separate... It's sort of the prediction that we're making as a company, and what I say publicly is that I think in... really quickly, in two to three years, the things that will separate the really... what will be perceived as basic runtime services and the actual good ones, is going to be the level of intelligence in them. So we're starting to do that with our software too. But yeah, I think that like at a scheduler layer, the days of manually adding and removing resources underneath a scheduler, it's a temporary, it's a band-aid right now that we're used to manually managing servers, so we're just doing it anyway with a scheduler. But I think in less than two years, you'll never launch another server again for the scheduler. Objectively, if you could do that. I know we can, I know we can. Right, cool. Some questions then for me, at least one of the key takeaways from this talk was thinking of data centers as computers, which is kind of a very powerful metaphor.