Now what? Beyond Kubernetes and Cloud Native | Kelsey Hightower

[Kelsey:] How many people want to be here? [Laughter from the audience] A lot of conferences your boss sends you, are like, - go to this conference, I've paid for it already. The last time I got asked this question - about the future of our industry or software, I decided to retire. 42 years old, I had surfed a lot of the waves, the DevOps wave, - configuration management wave, the container wave, - the Golang wave, the Kubernetes wave. I thought they wouldn't stop. There's the saying that it's not a race, it's a marathon, - and that's wrong. You can't run forever. It's a relay race. You need to figure out how to pass something off to someone else. Usually that someone else needs mentoring. Ideally you do that in a way that they get a running start. You don't want to pass the baton when you're dead tired. So at 42, I decided that I still had - a lot left in me, but I would pass the baton. I'm lucky my daughter is one of those people to receive it. She's 17, she's in college for computer science. She texts me all the time; Dad, I love this database class I'm taking. I remind her to keep that energy. You're going to need it, because it's going to be your turn - to run really, really quickly. She does ask me questions. Is this industry still going to be worth going to school for? I have to be honest with her and say, I don't know. Things change all the time. She asks, what should I do? I say, well, - the people who do the best at predicting the future are the ones who work on it. Everybody else is just guessing. That's it. The people building things decide. You wait on them. You can nudge the future, do bug reports, you can complain on the internet, - but it's the people who look at that stuff that actually fix it, they decide. So I've told her that she should learn how to build things so she could decide. She could probably create a job for herself - if she thought the situation was dire. I thought about how I would answer the question, what's the future? The truth is, I don't know. But if I was being very honest, I actually don't care. People say, what? It's very liberating not to care. I think any idea has a shot. I say to a lot of startup founders that anything can work at this point. Execution matters more than anything else. It's the part where I help them solve their own Rubik's Cube - that still has me excited. Whether they solve it or not, whether you like the way they solved it, - is less interesting to me these days. Instead of answering the question, - I'm going to show you my thought process - that I've used over the last two decades of being in this industry. I think it's more useful than me guessing like the rest of them. I'm going to leave a lot of time for Q&A. For the first time in my career, I have nothing to sell you. [Laughter from the audience] I work for no one where it matters what I say, - so you're going to get the most transparent version of Kelsey ever. What I've noticed a lot in the industry is, people... have you ever seen kids play – you call it football here, right? Soccer, that's what we call it in the States. But have you seen kids play soccer? What do they do? They all chase the ball - at the same time, and they just cluster together. All the coaches on the sideline, what the hell are they doing? No strategy, no matter how many games they watch, - no matter what you try to tell them, - their natural instinct is to go where the ball is. I look at grown people in the enterprise, they do exactly the same thing. Any new idea that comes out, they all pretty much run to the same ball. You can't miss it. This thing is coming, you don't want to be a laggard. Then they all run to the same ball. Wow, they've been doing this this long, - and they still don't understand the strategy. I remember, it was around 2004, the MapReduce paper came out. - the whole idea around big data. Some people read the paper and get super excited, oh, this is the future. We read these white papers as if they provide a peek into the future. You want to look at these aspirational white papers that way. Wow, I've never seen this before. This must be what people will do in the future. This is written by Jeff Dean and his partner Sanjay. They talk about how Google was dealing with big data. Most people don't even have big data, - but they still aspire to this problem, which is very odd to me. It's like when you see new medication on TV - and you don't have that disease, you don't want it. I don't want that problem. But for some reason in tech, people see big problems - and they want to have that problem so they can solve it. I'm not sure why that works that way. So, a whole industry, two years later, 2004... you guys remember Hadoop? Some of you are still using Hadoop. Who's still using Hadoop? Someone just signed their contract for their new Hadoop cluster. You think you will do the MapReduce thing. It took a long time to get there. And then... A lot of enterprises are fairly slow in adoption. It takes them about eight to ten years from idea, maturity to procurement. Then you get to try it. In that 10 years time, there was a Google IEO... this was right around the time I joined Google, in 2014. If you were paying attention, in the middle of your big data Hadoop install, - they did this announcement, and not a lot of people caught it. Google talked about this thing called data flow. This is Google saying, we don't do MapReduce anymore. The people are still in your data center installing the Hadoop cluster. Google's like, yeah, we're not doing that anymore. And when I saw that happen, I thought, oh, these white papers - are not a peek at the future. They're a review of the past. Usually about 10 years old, - to the point where you can now summarize it. I remember... the data flow paper comes out, and a lot of people - ran to the same soccer ball. We repeated the process. I remember there was a Twitter post, where Urs was like, - rest in peace MapReduce, Google doesn't even use it anymore. We've deleted all the last remaining components of that code base. In just 10 years, it went from the future to, why would you do that? I've seen this cycle time and time again. Then people ask me, hey, what's the future going to look like? The truth is none of this stuff gets completely deleted. I think the software industry is moving closer to the fashion industry. People say, wow, that's really nice Kubernetes that you're wearing. I was like, oh yeah... [Laughter from the audience] You can get one too. Before you know it, everyone's walking around with their own Kubernetes. Why are you wearing that? It's the summer. I don't know, it looks nice. So it's very fashionable. I remember the first time I encountered this concept of fashion - in the tech industry is when Ruby came out. When Ruby came out, I thought, why do we need another programming language? We already have Perl. You can do everything. Ruby was about the taste, - how the syntax looked when you wrote it. They talked a lot about the way that Ruby looks on the page, - how you read it, how you express yourself, - as if that was the most important component to this particular syntax. These people create programming languages - based on their own style and taste. Then something happens. You get people recreating all the standard libraries, - how to do all the things. What I noticed too, when I was at Google for about eight years, - anytime something new came out, when you deal with the enterprise, - they say it in so many words, make the new thing work the old way. For example, Kubernetes is great, - but you need to work with all the other stuff that we have. You realize that you can't just change everything. I remember one time Microsoft tried to move - the start menu from the bottom left corner. The whole world revolted. Hey, what are you doing? It must stay there forever. So they put it back, - because humans won't allow things to evolve that fast. You have to meet people where they are, then you show them what's next. And so... taste and syntax turn into standard libraries - that then turn into frameworks. Does anybody know Ruby on Rails? Some people still use it. Ruby on Rails is fine, actually, - GitHub IPO using Ruby on Rails. The thing about Ruby on Rails that was interesting - is they took all the chaotic patterns of the day. They gave you one framework that you can install - and get all the practices, I won't say the best, - just get all of them at the time in one framework and one SDK. The reason why I'm showing you all these phases - is because they just keep repeating themselves. New programming language comes out, everyone goes on Hacker News, - same thing as before, but written in Rust. Then we create all the standard libraries, - and then the frameworks show up. Then a new piece of technology shows up. If you're paying attention, you can tell what's going to happen. So whatever new thing that is out today, - more than likely we're probably in the syntax error. What's going to show gives you the standard library error. The people that really know where the bugs are - will create the frameworks. They'll make it actually easy to use. Then the hype will die. Because then it will just work. Once things start to work is when we stop talking about them. They're not as interesting anymore. Anyone been to a TCPIP conference lately? [Laughter from the audience] They don't have those. Because it works. So if you want to know when it works, it's when they stop talking about it. That's when it works. Old software, how long does this stuff last? I was researching it. It turns out - there's the reservation system that the airlines uses from Sabre. Anyone know when this software was originated, when it came out? My mom wasn't born yet. 1960. They still have new releases of this software. So this stuff still sticks around longer than any of us would expect. It's so interesting that... Anyone use the phrase legacy software? I don't know why we say it. Anything that does really well for a long time, we call that Hall of Fame. A lot of my peers are starting to age. The idea that things have a shelf life is starting to backfire. They're on the other side of that table now, and they realize - that younger people are afraid to hire their future selves. You can't be that good at that age. So it has me rethinking the concept of the future and the past. Most people are literally just recreating the past over and over again. It tends to be the ones that don't understand the history that believe - they're creating the future if they would only expand their timeline. Now, the good thing about this is you can nudge their future. This is the thing I like about open source so much. When I left Puppet Labs, I thought, you know what? Configuration management is a dead end. I knew in 2012 it was a dead end, because I started seeing companies - write more configuration management code - than the application code they were attempting to manage. This is backwards. There's no reason for this. So when Containers came out, I built this little project called Confd. It was my attempt to simplify the new world. The idea of creating the future, because I was working on it. I remember going to FOSDEM, open source conference in Europe. I watched someone that I never met give an entire talk about Confd. Never met this person. I'm standing in the back of the room. He goes, hey guys, the future of configuration management is Confd. I'm in the back – Damn, no one told me! [Kelsey and the audience laugh] I watched him be so excited about someone just rethinking the status quo. He just jumped in and started contributing. I'm thinking, oh, this is what it's like to determine what the future looks like. You have to shift something. I tried to do it again So this project got pretty popular. But then the project that got the most popular was the project called No Code. I remember I was a distinguished engineer at this time. A customer was showing me their new microservices stack. I was thinking, this again. They asked, Kelsey, how would you do it? I said, you know what? There is too much code, and I wish the next framework would involve no code. They said, well, Kelsey, how does it work? So I published this repository. Just like kids chasing the soccer ball, people went to the repository - and were looking for the new thing that Kelsey was creating. I'm going to walk you through the tutorial. The pitch is, this is the best way to write secure and reliable applications. You write nothing and deploy nowhere. This is the framework to end them all. You go to the tutorial, it's very easy to write. I have code examples here just to make sure you understand that it's real. You start by writing nothing. [Kelsey and the audience laugh] it's always easy to show the simple applications at events like these, - but I wanted to show you that you can add new features, too, - by basically doing nothing. This goes on and on, and I'm having a good time. Someone asked, how do you contribute? I said, you don't. [The audience laughs] But people tried to, so I had to create this contribution guide. [The audience laughs] All changes are welcome as long as no code is involved. If you run into any bugs, file an issue and explain - how that was even possible. [The audience laughs] then, if you look at the open issues, - [The audience laughs] there's 4,000 issues. [The audience laughs] There's 62,000 GitHub stars. I thought, this is the perfect time to raise money - for a startup around No Code. We can at least ship t-shirts. I went through all the issues. In one it said, hey Kelsey, I'm an engineering manager at company X, - and I would like you to take this repository down. It's causing a lot of distraction to my engineers. I thought, how is that my problem? [The audience laughs] so I went to go look at the issues and see what could people be distracted by? So I click on some... These are new. This is two days... this is 10 years old and people are still... [The audience laughs] If you fork this repository, what are you doing with it? I remember looking at the first issue. This person said, each time I attempt to run No Code, - it says, file not found. What am I doing wrong? Do you consult for dollars on getting this running in my organization? I thought about it. Yeah, that could be a thing. [The audience laughs] I said, yes, you need to upgrade to the Enterprise version. [Kelsey and the audience laugh] I'll get you a contact form. People were upset with me that I was going to have - an Enterprise version of the No Code repository. But then the thing that inspires me the most about our tech community - is the number of people that came in to help. [Kelsey and the audience laugh] This is why I truly believe anything is possible, even nothing. I am going to try to answer one thing that is going to be super important. We've gotten away with a lot as "engineers". We're probably not engineers in the classic sense of the word. All the responsibilities, the training, - all the classical things that true engineers have to do. At Google, I saw something I thought was going to be very different - about how you go about writing software. Open source has been a godsend. When you sit back and think about the nature of open source, - you have no idea who's building the software. Yet you put it in production almost blindly. On your CICD platform you pull everything from the internet until the bill works. Then you scan it with all the security tools you buy. As long as it's green, you put it in production - and give it access to everything. And you will do that blindly forever. Then there was a bad thing that happened. I won't mention the company name. They've dealt with enough embarrassment. The saucer framework was created. It sounds really good on paper, the idea - that we need to have a secure supply chain. What's involved in that is something - that is going to change the way software development happens. I don't know if it's a net positive, but it's something to think about. In the software supply chain, - the thing we've ignored as an industry for a long time is the producer. Who is building the software? Most people don't even use their real names. As long as the code looks good, it gets merged, and off it goes. As long as you have the source code, a lot of our industry has - rallied behind just being open source with the right license. I'll pull it in and I'll ship it. Then ideally we get CVEs, and hopefully the right people do the right thing. I think something's going to change. At some point, - companies are going to want to know who you are. If you don't meet their requirements, - they probably won't allow you to contribute. Will software developers one day require a license - to contribute to large, well-known open source projects? I think that future will come for sure. There are projects like Sigstore, where you sign and verify, - but none of it works unless your reputation is on the line. The only way we can get to your reputation is - people probably are going to force you to identify yourself. I've seen this in some open source communities already. If you're from a certain country, and you try to contribute, - they'll tell you, we apologize, but we cannot take contributions, - because you're a citizen of the wrong country. As software starts to get even more ingrained into our lives, - it's no longer just fun and technology. It becomes political, the way we govern ourselves. Now we're building decision engines, - not just experiences that you click around and move on to the next product. These things are starting to account for more of the things that happen. So, as a software developer, - the professionalism bar is going to have to go way up. That's going to change the game quite a bit. Every keystroke will matter, because your name will be attached to it. What happens if they decide that, like the doctors and lawyers, - we can be sued for malpractice? Will that be a thing? So something to chew on, - we had an extreme amount of power for the last 30 to 40 years. We got away with a lot. I think our field is starting to mature to a point where things will change. So, stay excited. I do think that it will change. This will be taken way more seriously. I, on purpose, left 20 minutes, because the Q&A section is always my favourite. Any question is fair game, I have nothing to sell you - and I promise thorough and honest answers. This is the end of the presentation part before we move on to the Q&A. Thank you. [The audience applauds] [From the the audience:] Hello. On your last point, I'm interested to get your view on - enterprises or large organizations that have - concerns about regulation and the legalities of using open source. Do you see OSPOs being an integral part of how they address that? [Kelsey:] I worked in financial services and when I got there, - I thought, this is the big leagues. There are audits and there's all this compliance. I watched the worst security practices in the world - get a rubber stamp, so they could do business. I don't know if auditors are enough anymore. Most auditors will relax standards so that people can do business. To me, these days, it's more like due diligence. I did enough. We've created a checklist. We bought vendors a product. We used it based on their documentation. Not solely my fault. When I was at Google, this did come up. What if we told the world how bad it was? The problem is, no one has a solution. There's no solution right now. Right now it's like red, yellow, green, make it turn green, right? If it turns green, that's enough to get the due diligence stamp. You are secure as far as you know it. But we know that's not security. That's compliance. The security practice now will involve, - at least on the sovereignty level, who are you? I think that 'who are you' will inform ourselves that - do we even want this software? This is why Red Hat is so successful. Red Hat provides a little bit of t