 So I'm here to talk about operations and development. So I'm going to echo a lot of the themes of the last talk. And about how these things relate together and how a lot of the tools that we're building together help to improve the processes in the way that teams work together. If you rewind the clock two years ago, the set of breakout sessions and the things that folks were talking about were quite a bit different from what we're talking about today. There's a ton of excitement. Oh, something happened. My other slides didn't advance here. Let me see what happened here. There we go. All right. All right. So if you rewind the clock and you take a look at the stuff that we were talking about two years ago, it's very different from what we're talking about today. And there's a ton of excitement about a lot of these new technologies. But I think it's important to take a step back and really take a look at why there's so much excitement. And it really comes down to the relationship between how people develop new applications and how they actually push those applications into production and operate them. So development plus operations, that's DevOps, right? Well, honestly, I don't know. I don't know what DevOps is. I bet you don't really either. Kelsey Hightower, who's now a developer advocate at Google for Kubernetes over drinks one time, told me that DevOps is group therapy for large corporations. I think we've all seen this dysfunctional organization where really it's one team's from Mars, one team's from Venus, I'm not sure which is which. And they really don't get along. And so you hire some expensive consulting firm and you do some trust falls and ropes courses and everybody's happy again. But I think, and it's easy to make fun of this because there's just so much hype out there. But there really is a kernel of real utility here. I think the relationship between these two functions are changing. And the tools that we're building actually help facilitate that change. It is no longer acceptable for a development team to not care about how their stuff runs in production. Similarly, it's no longer acceptable for an operations team to just let something happen and then just say, oh, well, put that in a playbook. We'll deal with it next time. They have to take their knowledge, their learnings. And they have to plow that back into the development cycle so that the application becomes more and more operatable over time. OK, so let's shift a little bit and talk about microservices. I think after the last talk, you probably have a pretty good grounding in what microservices are. One thing that I do want to actually bring up is that I don't think there's much new here. I mean, like so many things, there's really nothing new under the sun. We did microservices in some form several years ago with service-oriented architectures, except then we had XML, now we have JSON. So it's all different. But so these concepts are fuzzy. But I think over time, we actually build better tools. And you do these things over and over again, and eventually it's going to stick. And I think this time, we actually have an opportunity for this stuff to actually stick and be widely deployed. And so at the root, microservices are building blocks. As software engineers, we attack big problems by breaking them into smaller problems, solving those, and then bringing them back together. This is how we build libraries. This is how we build object-oriented software, whether you're a fan or not, that's the idea. And then we find a way to reuse these building blocks. Microservices are the same idea, except we're extending that from something that gets packaged up at link time to something that actually gets assembled across the network at production time. So one way to think about it is that your discovery system, your naming system, is really a dynamic linker. And that is a fundamental change. And the reason why that's a fundamental change is that it actually lets you scale your organization. Not only can we have small teams that work well together, we can have those teams partner with their operations organization. And so the real value here is not about horizontal scaling of making systems handle gazillions of requests per second. It's really about being able to have small, tightly knit teams that have mind melded that can work together to solve a problem. So now Jeff Bezos has this saying that if any meeting is so large that you can't feed everyone with two pizzas, it's probably too large. So that's the two pizza rule. But a lot of folks, and I think it's a good idea, have also applied that two pizza rule to development teams. There's an n squared issue. As you add an extra person, you have more relationships that you need to manage, more lines of communication to keep open, and it's more difficult for that development team to gel and be effective. And so it really makes sense to keep those teams small, keep those teams independent. And with microservices, we have a new way to do that, and a new way to actually extend that, not only at the development process, but also out into the production world. So the end result here is really one of velocity. We want to make it so that companies and projects can move faster, ship more solid, more functional software faster. That's the end goal here. And we've all been on that experience when you start a new project. Everything moves really quick. It's incredibly liberating. But as that project matures, as more and more stuff happens, everything kind of grinds to a halt. With these new development practices, you can find the natural ways to cleave that project into and then start bifurcating those teams so that they can unlock some of the velocity and continue to move fast. Now I think it's worth taking a second to look at different types of services. And I think that there's really a spectrum of how people approach services with something like Serverless and Lambda on one end of the spectrum, in terms of super-duper small things, to services that are actually relatively heavyweight and actually carry a lot of weight. But there's another type of spectrum, which is how widely shared these services are. And so at the first step here, we have a service as an implementation detail. So you have a monolithic application. You break off a piece of that. You run it as a service. That service has one and only one consumer. It's essentially an implementation detail of a larger application. And that's great. You're going to unlock some velocity there. But you're not exactly highly leveraging that service across your organization. The next step here is shared artifact private instance. So this is the most analogous to shrink-wrapped software. And I think a great example here would be something like a database, where you have one team. Hopefully if it's a database, it's probably not your team. But you have one team or one company, one entity that's producing that database. You have multiple instances of that running. And so you're leveraging the code, but you're not actually leveraging the operational overhead widely. The next step is a shared instance. And this is where you start seeing the ideas of multi-tenancy come in. And obviously when you think multi-tenancy, you think of something like Gmail, where you actually have lots of end-users all in one big heavy-duty system. But within an organization, you can do this in a much lighter weight way. Having a central organization that's running your database for you and having lots of teams and lots of project actually use the isolation features inside of a database would be one example of this. But I think there's a lot of other places where this might make sense. When I was at Google, Google is, for a long time, their core competency is really around machine learning. And obviously it all relates back to ads, because everything at Google often relates back to ads. But one of the things that you might do with machine learning is take a chunk of text and categorize it. What is this text about? And it turns out that that's a distributed system that can use a lot of memory. And it's expensive to run in one of these things, yet that's an incredibly useful service to provide across the company. So being able to provide that to lots of different consumers leverages not only the infrastructure cost, but the operational overhead of running that service. Something much simpler, though, might be, I can look at my bank. And it's obvious looking at the bank that their site is actually tons of different applications on the back end. It's a hodgepodge of different UI. They try and paper over the seams, but it's very clear that they didn't do it all the way. So one of the things you might want to do is actually have a common navigation bar across all of your sites. You can do this, and by the way, each of these sites may be written in different languages, hosted in different ways. I mean, enterprise production setups end up being very complicated. You can take the code that renders that navigation bar, you can put that into a shared service, and then you can have each service call into that shared service and then composite it into the HTML as it's being rendered and actually delivered to the consumer. That's a very simple way to actually centralize a function and share something that is a hard problem by using something like a microservice. So the last step here is what I've been calling big S services, and this is what you generally think of as services over the internet. So something like Twilio or SendGrid or what have you. And the difference between this and the previous example is now you have to deal with, essentially, people over the internet that may be trying to break you. You have to deal with billing and logging and debug services and an administration UI. Whereas if you're actually keeping it within your organization, you can cut corners on a bunch of that stuff, and if somebody is trying to, is using you the wrong way, you can call them up and say, hey, stop doing that. So the overhead, even though these things on paper can look very similar, the overhead of offering a service to the rest of the world ends up being pretty darn high. And there's not a clean line here, because you might offer a service to partners, but in addition to your internal stuff, but not offer it to anybody on the internet, but there's definitely at some point a huge cost to offering this stuff widely. Now if you do this right, you move from a tree of services to a network of services. And as you find these things becoming more and more useful, this network becomes more highly connected. And you move from a very useful service having a couple of consumers to having lots and lots and lots of consumers. Now, here's the problem. Operations. All this stuff sounds great, but the cost of running a hello world service is not zero. Every new service that you add, every new service that you want to run comes with a cost. And so if you go from running one thing in production to running 50 or 100 or 1,000 things in production, you got to up your operations game. And so one technique, and we're starting to see this evolve, is this idea of operation specialization. Now some folks, they think about DevOps, and one interpretation is that everybody should be in everybody's business. If you're going to deploy something, then you own that thing, soup to nuts, you have to worry about what version of the kernel you're running. That's a huge bar. We're not actually leveraging specialized expertise here. So one of the ways to think about this operation specialization is cloud, public cloud, public infrastructure cloud. I'm a huge fan. When I was at Google, I started Google Compute Engine. And we call it infrastructure as a service. But I think a better name might be hardware ops as a service. Essentially, we're taking the guys that are rack and stack and servers doing capacity planning, all that hard stuff, and we're putting it behind an API. And that's a natural thing to do, because that interface is at the hardware software interface. It's relatively straightforward for us to think about that. But we kind of stalled there for a while, because we essentially had very chunky tools for dealing with all the stuff that was going on inside the VM. Now, there's a couple of organizations that have done a great job of using the cloud to its fullest. But most folks still continue to treat computers as things that need to be managed like physical hardware. So the first step here in terms of specializing operations is OS operations. There's a specialized team within Google that maintains the image that runs on all of Google's production machines. And we're starting to see that same idea mirror itself outside of Google. Things like CoreOS, or Snappy, or VMware Photon, or Project Atomic, all of these things actually concentrate on the function of getting the machine up and running so that all that gunk, that primordial brain, that sort of lizard brain of the machine, dealing with that stuff. Most traditional OS distributions actually have a whole other thing that they do, which is package management. But we're starting to break those things out. So now we can look at the OS as getting to the point where you have a kernel up and running and well support it. And then we have other systems for dealing with package management and application deployment. The next level here is cluster operations. This is the idea of, OK, one machine is great. Lots of machines are better. Can we offer an API? Can we offer a logical abstraction? Because with VMs and VMs as a service, we're still dealing with physical abstractions in a lot of the baggage that we import from that. Can we move to this idea of a logical abstraction? Now, this is the type of thing that we've done in the data space for a long time. You can't go into a data center and point at a database table. I mean, maybe you can point at the machine that it's at, but that abstraction of a database table or an object store bucket or what have you is a very logical thing. We're finally moving to the idea of logical concepts for compute with things like containers and orchestration. And so cluster ops is this really great line where you can have somebody maintain this really nice, clean, logical API and then offer that up to a ton of different users in a highly leveraged way. Inside of Google, that team is called BorgSRE. They're my heroes. I love those guys. And they support with very few people tons and tons of computers running everything from Gmail to Search to Ads to Docs to Google Cloud. So what this enables is this final thing, which is application operations. If we've removed all this other crap that folks have to deal with, and I apologize if you work on that stuff for calling it crap, but if you remove all this other stuff that people have to deal with, you're left with the level of operations that are most closely tied to the application that you're deploying. And now it makes sense to actually say, well, the same folks can actually operate their application that write their application. Or if you actually have an organization where you have a separate application operations team from the application development team, this organization is going to be a lot healthier because the incentives across these teams are going to be so much more tightly aligned. So what are we all doing here? Well, there's a formula here in terms of the cost of operations. I don't know what that formula looks like. I've tried to pencil it out and sort of hand-wave it. But it's probably something with a constant for each service, and then another term that actually scales with, like, say, the square of the complexity of that service. And so what we're doing here as we build these tools, and I think orchestration is just the start of it, I think that there's a whole host of tools that we're going to have to build to be able to actually get to the point where we can manage these things well, is we're working to reduce the constants. It's going to be a while now before we can drive the cost of the Hello World service down to zero. And there are some platforms where you can do that, but they're relatively narrow. But we're going to be working to actually drive those constants so it gets much, much cheaper to actually deploy lots and lots of services. And I think that one other thing to keep in mind here is that you're all familiar with the Gartner hype cycle. A lot of this stuff, we're at the peak. Everybody's excited about this stuff. It's awesome. It's going to be great. There's a lot of work ahead of us. And we're not there yet. And there's going to be some hard times as people realize that we've solved some problems and we've created a bunch of other problems. But I can tell you, I'm confident that this group and that the communities that we're building here are up to the task of filling in those gaps, exiting the other side, and building a platform that both enables developers to work faster and for operation teams to take the weekend off. And so this is what I'm calling the operations dividend. If we make operations that much easier, that much less work, and we make those teams that much more efficient, you're going to have excess capacity. And it's up to you to decide what you want to do with that capacity. You can give your operations team two days a week off. That'd be great. Or what you could do is you could tell the development team, hey, go hog wild. Run more stuff in production. We can take it. And that'll make the development team happier because they can actually shift some of that burden from compile link time into the operation side of the world. So with that, I'd like to thank you. And I won't stand between you and the beer that's going to come after the keynotes. If you want to talk about this later, please come find me at the party afterwards. And thank you very much.