Hi, thanks for having me at Conf 42. Cloud native my name is Lian Li. I'm a cloud native engineer and engineering manager at Container Solutions in Amsterdam. We are a consultancy focused on programmable infrastructure and we help our customers move into the cloud. And you can follow me on GitHub or on Twitter at chimney 42. I'm also one of the organizers for serverless days Amsterdam. So we are the Amsterdam chapter of the Serverless Days conference series. It's a global series of community events and we had two conferences so far in 2019 and in 2020, unfortunately online and we also have monthly meetups every first Wednesday of the month. So if you're interested in checking out what this is about, then let me know and I'll tell you where you can find us. Or just Google serverless days in Amsterdam so today I'm here to tell you Kubernetes wont save you. You and now I told you a little bit about me. You might be thinking, well what about serverless? Well bad news, serverless won't save you either. Why? Because it's not about technology, it's about your culture. It's about your culture of problem solving, of adapting to change, building trust and resilience in your organization. That's the crucial thing. And everything I tell you today is based on my experience working in tech for about the last decade. I started as a web developer with PHP, actually moved to front end, then full stack, then DevOps, and now I'm a consultant. First things first, let's take a look at the state of Kubernetes. So originally, if we were in the same room, I would ask you to do a show of hands who has heard about Kubernetes? And even though I can't see you right now, I will assume that most people probably have heard about it. If not, the very brief explanation is that Kubernetes is a containers orchestration platform and it has become quite popular in the last couple of years because it providers to make infrastructure tasks easier to automate and thus cheaper and faster. But as I said before, this talk is not really about Kubernetes specifically. So this is just a stand andor for the popular tool of the month, really. This same principles apply to any kind of cloud native tooling that you can think of. So this image is taken from a white paper written by our CTO Ian Crosby, which in turn is based on a book called crossing the chasm by Joffrey a. Moore. And in that book, Moore takes a look at the technology adoption cycle and his hypothesis is that before any tech is adopted to the mainstream market, it needs to cross something called the, you know, before it's only available or only interesting to early adopters, and then at some point it will cross this chasm and become part of the mainstream. And this image is about two years old when, two or three years when the white paper came out. And I would argue that in fact, kubernetes has already crossed the chasm. Kubernetes has become mainstream. And that is both kind of good and kind of bad. So these are a couple of headlines that I've taken from the last three years that have caused some outrage andor interest in the DevOps community. This is a very interesting story where pivotal was sued by Ford because Ford claimed that kubernetes is the industry standard and pivotal didn't teach them properly to use it. So I guess they alleged malpractice or something. I'm not super sure about the american legal system here, but I encourage you to Google these stories later because it's quite interesting that even Google tells developers now kubernetes has become boring. And that is good. And I think these headlines are super interesting because they point to two things. So first of all, kubernetes kind of the de facto industry standard right now, which generally I think is good because I think Kubernetes is a great tool. But they also point to the fact that people are slowly waking up from this dream that kubernetes will come and just magically solve all of their problems. You have to put actual elbow grease in it, too. So to me there are two aspects why cloud native transformations sometimes fail or don't go as fast as you expect them to. One is the attitude towards technology, towards the products and tools that we use, but also the ones that we build. And the other is the attitude towards people, the attitude towards how we work together and how we collaborate with each other. So I want to start with the definition of cloud native. What is cloud native? Who has good explanation, please put it in the chat or on Twitter. I'd be very interested in your definitions. I find quite fuzzy. If I ask 20 people, I'm probably going to get 40 different answers. To me, it's kind of at the intersection of culture, people and technology. And I'm going to tell you what I mean by that. First, let's look at what the CNCF defines in its charter. So they say cloud native technologies empower organizations to build and run scalable applications in modern dynamic environments such as public, private and hybrid clouds, containers, service meshes, microservices, immutable infrastructure and declarative APIs exemplify this approach. This is a very interesting definition for two reasons I feel so. First of all, it's very technical. It's only about computing. But then again, it also doesn't really define specifically what cloud native technologies are and what they aren't, but more what they do. They empower organizations to build and run things in settings like public, private and hybrid clouds. And then they list a couple of examples that would exemplify this approach. So it's also not 100% clear. It's kind of like just a list of examples. But then also it leaves us all these other aspects, like what but project management? What but your business strategy, how do those change? So this is another way to look at cloud native. This is something that we call the cloud native maturity matrix, and we use it as a tool to assess kind of the current state of a customer, also show them where we could take them and how far away they might be from their goal. And what's important to understand is that cloud native is not just a collection of tools here, but more like a philosophy or mindset or approach around individual aspects, like culture, like architecture, like infrastructure alignment. So when you meet a client for the first or second time, you sometimes do an assessment with them to gauge where the organization currently lies on each of these axes. And this is what it could look like then. What's nice about this tool is that it really visualizes all the dimensions of cloud native. So for example, if you look at microservices, most experts in the cloud native space would recommend microservice architecture. But if you do that in a waterfall culture, it will not yield the best results for you. So you're still carrying maybe legacy processes around you, but only when you couple microservices architecture with an agile and lean mindset. Then you'll be able to leverage all the fast and speed and flexibility and the goodness of cloud nature. So I don't claim that there's any objective truth with this matrix. This is our interpretation of cloud native and we iterate on it and we could make an argument, is serverless really the next level of provisioning? Or is it just another tool in cloud native orchestration, similar to like Kubernetes? If you feel like you want to discuss kind of what we put in there, then feel free to hit me up, because I would be very interested in your definition of cloud native and what it means to you. If you're interested in looking more deeply into the maturity matrix. You can also follow this link and do an interactive assessment for yourself or for your organization and then message me or message us because I guess we would be interested in what it came out for you. So another aspect of how we are solving the wrong problem, in my opinion, is illustrated in this XKCD entitled automation. So in this XKCD, I think this is something that we're all kind of familiar with. You spend a lot of time on a manual task. Annoying, it's boring, it's slow. So you think I should write a program to automate it. And in theory what you're thinking, what you're imagining is I will write some code and then in the beginning it will take me a bit more work and time, but then at some point automation will take over and then actually I will have all this free time because my script is doing the task automatically, I don't have to spend any time on it. But what happens in reality is that you start writing the code, then you need to debug it because it's not working correctly. Then you have to redesign the whole thing and it just takes forever and it just takes on its own life and you don't have any time for the original task anymore. And I think kind of most of us know this problem, some of us might have been victim to this, I know that I certainly have. And this is basically the stunk Andor cost fallacy. So as an example, we had a customer that developed a piece of technology, and this was a camera that had a chip that could do object detection and facial detection on an incoming video stream. And this was a pretty cool piece of software, and it would send that detected face or object to a platform which we were supposed to build. And it should be highly scalable, highly available. So we built everything in microservices Kubernetes. We were partnering with a company that were then on the platform that we built, built some applications to do mood detection, and we used Kotlin and we migrated to typescript in the middle of the project. Andor AI and Iot. It was really, really fun and interesting. As an engineer, it was one of my favorite projects ever to work on. At some point the customer pushed us to deliver for a demo with investors in press and the use case changed, so now they wanted it to run only on one physical server. And we were like yeah sure. I mean we can run a single node Kubernetes cluster. It's not ideal, but the nice thing about Kubernetes is that you can just do all kinds of things with it. It's very flexible. So we can run one instance of this platform on ones physical server andor we can still run a public version of it on GKE. So we were like yeah sure, physical server, no problem. And they're like yeah, but this server also can't be connected to the Internet ever. So what happened was they bought a physical server, they shipped it to us. We installed our application on it on a USB drive. Actually we had a helm shot on a USB drive and then shipped the server back to them by mail. And there's two ways to look at this. So we either were working with entirely different projects in mind, or we did the most physical handover of a cloud application that I've ever seen. But in any case, we already built everything in the cloud native way. And then even though the entire use case changed, we were like we already built it, so we're going to still use it, we're going to still do that, even though in retrospect we could have just built one monolith, one Java application, put it on a Tomcat server and be done with it. The title text of this XKCd by the way, reads automating comes from the roots, auto meaning self and mating meaning screwing. You might have heard of this design principle. Form follows function, which means that the shape of a building or object should primarily relate to its intended functional purpose. Or to put it in a different way, first think but what something should do and then think about how it should look like. Kind of fairly straightforward, but when we transfer this into business, sometimes what we see is that not all companies follow this principle. Some companies will use tech like AI or blockchain or kubernetes, simply because everyone is doing it. And it might be interesting to shareholders or vc funding, but it actually has no added value to the actual product or business. In my mind, tech is a byproduct of problem solving. So the goal is to solve a problem for your customer and you do it by the tech is the means to solve that problem. So you really need to ask yourself whether the tech you're maintaining and building, is it still solving the core problem and contributing to your core business? Or has it kind of begun to have a life of itself? Is it like a Frankenstein monster with an unquenchable thirst for resources that just keeps on growing? Most companies, they don't need to manage their own kubernetes cluster, but somehow a lot of them still feel like they do. One way, if you're uncertain about the purpose of your business is to use this model developed by Simon Sinek, which is called the Golden Circle. And he uses it to illustrate why people tend to flock to companies like Apple because they have a clearly communicated purpose. But you can also use this as a tool to try and find your purpose. And this is how you could do that. You start from the outside with the consistency of what, what are the products solved, the services offers, or your role at work. So let's say you are a company that sells photo cameras. Andor also a community platform where people can share their cameras, where people can maybe touch up images. It's very simple to use and it's great. So then look at the next level, the discipline of how, what are your strengths, what are your values, what are your guiding principles? So maybe you just have great customer support. Maybe your tools are amazing at helping people really express themselves. Because your guiding principle is that you want people to be able to express themselves through a visual medium. So finally, you will then look at the clarity of why? Why do you do this? What's your purpose? What's your cause? What is your belief? Maybe you believe that every person has an eye for beauty, everyone is an artist, and you really want to give every single person on earth the chance to share the beauty of the world as they perceive it to other people. And this purpose, this cause, is something that your customer can really understand, can ideally relate to, and that will then be expressed through loyalty to your brand, to your purpose. This is why companies like Apple are much more like the brand of Apple is much more successful, like has for example, the brand of a thinkpad or Lenovo, because it doesn't have this purpose, this belief that people can relate to. So finally, at the end of this section, I want to share this quote by Tatiana Mack, who's an engineer building inclusive, accessible and ethical products with thoughtful practices. And she says that a solution is only as good as your framing of the problem. Everyone who has ever worked with machine learning or anything like that understands that you really need to understand why your customers are using your business, why you, why not another company that provides the same product? Only when you understand that can you also understand how to best optimize your solution. So your technology, your services. So I spoke about attitude towards tech, and now I want to talk a bit about the attitude towards culture, andor towards people. And a lot of this, what I call the cloud native mindset we probably already know, are familiar with from agile thinking and agile working, for example, the concept of continuous learning. Quite important because we're all kind of new to this. Kubernetes was released six, seven years ago, 2014, if I'm not mistaken. And so we're kind of like, no one's really an expert expert, like a 20 year experience kind of expert. And most, if not all modern paradigms in the tech industry now kind of show the same trend where we're moving away from really stagnant processes that are kind of like trains. If you get into it, you just go straight ahead, and if you want to turn left or right, then someone has to have already planned this, someone has to have already put like a check, but for you to do that, and now we kind of move in much more fast and flexible processes, like a bike, where you can react very quickly to obstacles by just turning left and right, and you don't even need a road sometimes. So instead of planning out our releases for months or years in advance, most companies now follow agile principles of failing fast and early and often. And then they build this process of failing fast and often into this perpetual feedback loop with ceremonies to optimize this failing process with the feedback. And we call this kaizen, or continuous learning. An example of this is scrum, which I think most of us are kind of familiar with. So you have these sprints, which are usually probably two to three weeks, and at the end of each sprint, you have a retrospective andor retrospective. You discuss kind of issues you had that you could improve. And everything is kind of geared towards optimizing your delivery, your delivery of value. And then you take the action items from the retrospective and you try to implement them in the next sprint. Andor then at the end of that, you know, you have another retrospective. So you constantly have this loop forever if you want to do that, if you want to have this cycle of continuous failure, but not burn out your employees, then you need to create a culture that encourages failing and learning from it. And we have to be intentional about these things because failing is not something that we're happy with or that we enjoy or that makes us happy. So to be able to be resilient through these kinds of things, this will require abilities like taking responsibility, self efficacy, so the belief that you can do something, that you can learn something, also being able to handle stress properly. So all of these things tie into this need of psychological safety, why it's so crucial if you work in a sector that is moving very quickly, where you have to try things Andor fail often. So, to illustrate what I mean, we can look at this grid. So you see now that there are two axes the accountability axes, which just kind of means how much are you being pushed to do new things, to grow, to learn to do things that you're unfamiliar with, meet demanding goals and the axis of psychological safety. So if you fail, what happens to you? Are you getting scolded? Is it completely horrible or is it okay to fail? So in a low accountability, low psychological safety environment, no one's really pushing you to do anything. Also, if you were to do something, you will probably get scolded as soon as you do one little mistake. So why should you do anything? This is the apathy zone. This is a zone that is very, very dangerous to productivity because people who are in this zone will also take down the people around them over time if you let them. As opposed to that, if you have an organization where you have low psychological safety but high accountability for meeting demanding goals, this might be pushing you into an anxiety zone because you are constantly being pushed to meet more and more demanding goals. But if you fail, then you immediately, you won't hear the end of it. So this is very stressful and this is an area where people actually burn out a lot. On the other hand, if you have high psychological safety but low accountability for goals, then no one's really pushing you to do anything to move out of this comfort zone. It's comfortable because it's fine. You don't have to be worried about your job, which is a good thing, but you're not learning anything, you're not growing, you're just being comfortable in a setting of cloud native where things change a lot and where you're trying to achieve optimal effectiveness, the comfort zone is not the best zone to be in. The zone that we're trying to be in is the learning zone. And we get that when we have high psychological safety and high accountability, you push yourself. You ask to push yourself. If you fail, it's not a big deal. You just dust yourself off and just try again. And if you're interested in reading more about this concept, you can click on the link and go to the blog post. It's written by our in house psychologist, Andrea Dobson. And the reason why we have in house psychologists is because for one thing, the way that we approach consultants, it's really but empowering Andor mentoring and coaching our customers. So we put a lot of effort to kind of understand how people think and how people learn. And psychologists are great at explaining that to us, but also because we work in these fast moving environments that are very stressful, there's often a lot of money involved. We need to make sure that people are resilient, Andor can deal with this amount of stress. So that's also why we have psychologists in house. Lastly, the factor of collaboration obviously is also very, very important now because everything is distributed, your microservices are distributed, and with it comes often also a split in teams. And the infrastructure team is now kind of can AWS implementation team. So you really need to put a lot of effort into streamlining your collaboration now. And maybe you should think about even not doing collaboration anymore. And what I mean by that is that there's a book that's called Team Topologies by Matthew Skelton and Manuel Pace. In this book, the authors take a look at how engineering teams in cloud native organizations work together, and they have defined these three modes of interaction. There's collaboration. So teams work together for a defined period of time to usually discover new things like APIs or practices or technologies. It's really like a discovery. As a group you have facilitation. One team helps Andor mentors another team, and then finally you have x as a service. One team provides and another team consumes something, has a service. So collaboration is really kind of the slowest way to get anywhere because it can only move as fast, has its slowest member. So if you need any timely results from it, you should try to not do it via collaboration. In facilitation, one team will help another teams for a set amount of time and then ideally the value that's been created from this facilitation will be multiplied further down the road. X as a service actually takes a lot of time initially because ones team probably has to build that service, then moves much faster later because consuming a service can be automated, not as facilitation corporations that cannot be automated. And thus it is the fastest way of two teams to work together with one another. So as an example, if you have something like delivery deployment, you usually have a platform team, can operations team that manages, let's say your Kubernetes cluster, and then you have development teams that will build maybe helm charts, maybe Kubernetes manifests and then want to deploy those to the platform. You could do that through collaboration. You have to send someone an email, give them the thing and they have to then manually deploy, which already it sounds like, okay, there's not a lot of, actually it's quite time consuming. Facilitation would be a situation in which maybe the platform team explains to the development team, okay, if you want to deploy something, these are the steps you need to take you need to do this and this and that, and then you need to do this Andor that. So ideally you have to do these facilitation meetings once every couple of months maybe, and every time you change something on the platform, but then it will hopefully multiply down through the teams because one person will then tell three other people and so on. Finally, in X as a service, the platform team would provide a service, maybe even a self service, to the development team. So instead of having to be there and walk the development teams kind of manually through the process, they just provide, let's say, can API with very clear constructs and very clear expectations. And once the development team has everything configured and set up, they can just automate calling the service. And the speed of delivery will immediately increase in speed as soon as the dev team becomes more independent. So coming to the end now this is a quote that I kind of lifted from the book. Team topologies don't do a transformation because you want to use kubernetes. Use kubernetes because you're doing a transformation because you are transforming. You want to transform your organization to a different way of working and of understanding and addressing your customers. That's when you are looking to choose the right tool for yourself. Andor it might be Kubernetes, it might not be Kubernetes, it could be something completely different. Whatever works for your organisation, as long as you understand the problem that you're trying to solve, that tool will be the right tool. So if you're not too scared of moving into the cloud now, or you absolutely have to, you could take a look at our cloud native transformation kit. It consists of a book written by Pini Resnick and Jamie Dobson, which are our CRO and CEO respectively, Andor Michelle Gino, who's our editor, and this book, Cloud Native Transformation consists of a bunch of patterns to move your application, part of your application to a cloud native state. And these are what the patterns look like. So they really are suggestions and they're intended to inspire you to come up with the right solutions for your problems. And if you want to know more about what we do has a company, you can visit us on Twitter and on our website we have a newsletter, a monthly newsletter named WTF is Cloud Native? In which we talk about, explain, discuss cloud native patterns, technologies, ideas, all of that. So if you're interested, check us out on Twitter or LinkedIn or website. Thank you very much for your time again, you can follow me on Twitter as well or on GitHub. Thank you very much.