 Hello, my name is Pino Reznik. I'm CRO of Container Solutions, a cloud native consultancy. Today I will talk about continuous improvement in the context of cloud native in the context of a fast-changing world. So, what is cloud native? Of course, most people, when they talk about cloud native, they mean microservices, containers, dynamic orchestration, lots of other technical things, which is correct, and I wouldn't argue with that. But that's not the topic I want to talk about today. So, what I really wanted to do is to start from why. And for the Simon Sinek advice, start from why and how and what, and then figure out what actually is the purpose of cloud native, and why it exists in the first place, why all those technologies came to life and useful. So, why cloud native? So, most of the people who are building software or other things in the world used to build things to last. So, better quality, stronger the house, stronger the software system is, better it is perceived by others. Everything is optimized to last for ages. In this photograph, this is a palace that exists for the castle, that exists for four or five hundred years and we know many different churches, so there are other buildings that they are just amazing and they were built to stand for thousand years or even more. Now, this is how we want to build our houses and also this is how we want to build our software systems. We build them once and then refine, build another piece of it, another piece of it, and until it becomes really, actually, improvement never stops, but the general idea is longer the house stands is better. And the way it would build a house in this world is like this. So, you, let's say you have an idea, you have a house in mind, you want to build your own house, your own building, and you go to an architect, you tell the story, you explain what's going to happen in five, ten, twenty years, what you expect to happen. Architect translated into specific blueprints, specific structure of a future house, creates the blueprints, you sign off, then they're handed over to a construction team and let's say about a couple of years later or a year later, depending on the complexity of the house, you get this fully finished house that is ready to be used. So, this is totally fine if you're new exactly what you wanted to build, what kind of house you would need for the following ten years, because normally you would live ten or fifteen or twenty years in the same house. But unfortunately, the world is not as predictable. So, what happens is basically, after two years, you get exactly the house you dream, you dreamt to have two years ago. And you have to live in it for ten years, because you spend all your budget, all your money on actually building this house, it typically took a bit more than you expected, it took a bit longer, a bit higher budget, so you basically left with no money, and that's it. And if the house is not perfect fit for the following ten years or your plans have changed, then essentially that's what it is, and you still have to live in it. And this was fine in the world that wasn't changing too quickly. But we see that the speed of change is just increasing all the time, it's exponential. In the past, major innovation happened once in a generation or even hundred years. Now we see new things happening every week, every month, every year, all the time. So, there is no, and it's not just a lot of innovations recently, but also the speed of innovation is increasing. You can see, I can bring dozens and dozens of charts like that, showing that even in the last decade or two, the speed is increasing. Here, for example, you see the density of unicorns in the tech world. And also within cloud-native ecosystem itself, the maturity of the cloud-native landscape is getting bigger. Every month, I look at it, there's another hundred boxes in it. Now you can think of it as a scary thing. There are so many tools to know. There are so many technologies to understand how it's even possible to adapt all that, choose the best ones. That's true. But you can also think about it as an opportunity. The world is changing and the world is giving you hundreds and thousands of new options to choose from. And if you choose right, if you do your best, then you have so many more options to grow in different ways, to build value for your customers in better ways. So it's not just a challenge to adapt all those technologies, but it's also an opportunity to grow faster and better and build value in a better way. So there is a very significant challenge in adopting new technologies. And this is very well described in the book called Innovator's Dilemma. And generally, the idea is that the blue line, this is the old technology and sort of it's incrementally improving. You always invest in a bit of features. In the beginning, it's the value growing slowly. Then you get most of the value, but at some point it becomes old and heavy and no one wants to use it. So then the value is increasing. And then you want to switch over to a new technology, but then your value production is decreasing. So consider like airplanes and moving from propellers to jet engines. There was a couple of decades of difficult switch. And also today, when you consider switching from VMs to containers, adopting Kubernetes, it's difficult in the beginning. You basically accept the hits in performance in the beginning, and that's as an investment into future technology that will hopefully help you to grow faster in the future and go further. But the real challenge is not just one innovation dilemma, Innovator's dilemma. Because in the past, we only experienced in a way Innovator's dilemma maybe once in a decade, maybe once in 15 years. The real problem is that disruptive innovations that lead to Innovator's dilemma are happening more and more frequently. Not every 15 years, not every 20 years, but every two or three years, and soon even faster. What it means is that if in the past, you could spend two years moving to virtual machines, and then enjoy 15 years of benefits of using that technology. Now, you need to switch from business to Kubernetes invest in three years. So you really cannot invest two years or even a year or even half a year in adopting new technology. You need to optimize instead of optimizing for long term for longevity, we need to optimize for change for speed. And to optimize for speed, the main challenge is to be able to quickly adopt new technologies. So the why is because the world is changing, because it's just too fast to invest too much in switching from one technology to another or stay with all the knowledge technologies. Because others will do it anyway. So if not you, then somebody else will do it. And then how can we do it? What we're going to change it to basically the idea is to switch from build to last into build to change. And so instead of optimizing for long term, and quality in terms of how long the same system will will work. And we all been in these situations when you build a software system that is there, some cobble systems that are still 40 or 50 years later, they're still surviving and bringing value to mainstream banks. This is amazing, right? And this is great. And those were amazing investments that brought a lot of value over a very long period of time. But this is not sustainable anymore. What we want is to to optimize for change. Really want is instead of building these castles, and you can imagine a software system that is like a castle or a cathedral and switching to this kind of things that no one cares about, just quickly patch together, they still could be very high quality. But the whole point is that no one cares what's inside. Basically, instead of investing a lot in the beginning and gradually improving, those things are just gathered and started to new, right? So once you're done with this, this kind of construction, like this one, this is a food hall in Amsterdam. This kind of holes, they're all over the world. And it's an old trams depot. And now it's a full food hall and offices. And once that is not working anymore, they will just remove all the all the walls inside and rebuild everything in some in some different way. So those things, they're, it's very easy to just stop using them the way they are. And with very easy adjustments, just move on in a new direction. The reason this this is possible is because basically, the main story is that the bigger the bigger parts to the slower changing parts of the system, they are those who dominate the speed of change. What I mean by it is, consider a house, right? So the most important thing is foundation that defines the size of the house, but also the inside walls, the construction of the of the building itself. So if you have a supporting wall in between, it's very difficult to remove. It means you will probably not do it. So the most important parts for the change are foundation, the structure, and everything inside can be changed over time. So what it means is that, like this food hall, an example, it's a massive hole, it's a massive hunger that has no walls. That's, that's why you can feed it in anything you like, you can remove anything that you have in there, and you build it again. I have another example from my own house in, in Holland. So these are traditional Dutch houses with what rectangular three stories building. The problem is in the first floor, there is supporting wall. And we wanted to build an aisle in the kitchen, but there is no space for that. Unfortunately, to, to to create space, we need to remove supporting wall, which is very expensive. What it means is that basically, we give up on the change, and the house remains the same. And more than not, we even stop investing in the house, because we know that one day we will need to move to another place, because that's what we want. Right? So basically, the moment you cannot adapt to the future, or satisfy your needs or desires, then you stop investing in the system and the quality degrades. That's why it's very important to invest in the structure and the foundation of the system over invest and make it support any future needs. And everything inside can change later on. So the way you build a house in the more dynamic world is different. So first, you go to an architect, and instead of saying, this is what I expect 10 years from now, you say, I don't really know, but I have some guesses, I have three, four, five guesses, maybe I won't have so many kids, maybe I will work there, maybe I will need an office, maybe not. Those are the different things that I mean. The architect still goes, creates different scenarios. And still, there is a blueprint of a real house, but the general idea is to build strong foundation that support in the future, any house you will want, right, any direction, any of those future scenarios that you can could imagine, could be built on top of that foundation, because if you don't have the foundation to support future houses, then it's more or less impossible to add to foundation later. Then you build a basic house, the sort of MVP of the house, you can live in it, but it's not big, it's just just the minimum you really need it, need for moving and you really don't want to spend more than 20 to 40% of your budget on this, because what's what happens after that is continuous addition, continuous improvement of that house. Basically, you start building piece by piece. You can imagine also a software system, build the same way. First, you build a very strong foundation, which would include typically a jail, I will talk about this later, but typically it's a jail processes and strong plot from and things and continuous integration and deliver things that will really be needed in the future that will really be your foundation for the future. And then reason every small house on top of that, but then you continuously improve it, continuously build more and more things, you never stop building your house essentially. The benefit is that you always live in the house that you want in that specific moment. And if you're not happy, you can always add more. And a very important element here is also the maintenance. People forget about maintenance. When especially these days, people think I will build this amazing massive building that is beautiful and directly into the photograph directly in the in the architecture journal. But is it easy to maintain? Because if it's difficult to maintain, it's expensive to maintain, then there are all the incentives to reduce the investment in maintenance later, which means that the quality of the system will degrade much faster. So what happens with those things that let's say a software system that you spend two or three years building, and then there are no way, no ways to improve a consistently maintenance that is just so sort of falls apart immediately after. So it's very important to include the ways to continuously maintain the system preventive maintenance is, it is sort of boring, right, but it's essential to prevent system from falling apart. So the how is, if the why is we want to adjust to the new fast changing world, the hell is to build outside of outside foundation and strong structure first, build the MPP on top of that, and then allow continuous change. The whole purpose is, of this, of this approach is to say, everything we're building can and will change over time. And we need to be prepared for that. So every piece of construction, every piece of software that we're introducing in the system is not permanent, is just one element that can be replaced to improve. So then what are we going to build? Cloud native, finally, cloud native. Yes, we want to build cloud native systems, because this is exactly the set of technologies and practices that allow us this fast change. And cloud native, yeah, most people say that cloud native is mostly technical set of principles like containers, microservices, and dynamic orchestration. Of course, it has to come also with organizational structure with the right culture with the trial processes and everything else that will actually allow you to get the maximum out of those technologies. So again, if we want fast change, if we want to allow fast change, it's not just about adding features to Kubernetes or installing parameters or things like that. It's also being able to release features the value to the customer quickly. It means that if you have no agile processes, so you have no culture that supports this kind of fast change and looking around and identifying new opportunities and going after them immediately, if you have no such culture, then Kubernetes will not really help you to go faster. So we see this as three major areas. One is technology, of course, cloud native technology, then agile processes, and dynamic strategy. The dynamic strategy is as versus static strategy when static strategy is when you say, we cannot force house, you say 10 years from now, I will need this. That's why those are the next five steps that they need to take. This is totally fine in the world that is not changing too frequently. Right? That's why you can define your strategy and go for five years and build the product and after five years, it is still relevant. But today, this is not what happens. So what you need to do, you still need to have some sort of idea what you want to do five or 10 years from now. But then you need to spend a lot of effort looking around every day, seeing new opportunities, new threats, new changes, and always reevaluate the strategy. That's why it's dynamic. And once you identify new opportunities, you need to really adjust and change. And it's very important to continuously adjust and change. And that's why we want to use future scenarios that just as planning. So when you plan something, it's based on predictions, right? You sort of make a guess about the future, and you're always wrong. We are all always wrong, especially in the world that is changing fast. Alternatively, we want to talk about different scenarios. Five years from now, those are the scenarios. This is the range of scenarios I can imagine. That's why we have strategy, which means we're choosing where to go, but we are ready to adjust. Plan is not adjustable, and you have no need to look around. This is an essential element of of cloud native is dynamic strategy. And technologies, again, technologies will allow you to make changes on technical level on the product level. But if you are not talking around that you are not identifying the change happening around you, there is no point in that. The next thing is agile processes. There's no much to say agile is quite well understood and adopted in many companies. Unfortunately, most enterprises don't do proper agile. They do sort of a child, a childish thing, sort of waterfall pretending being a child, not really delivering all the time. But it is very important to reduce the speed of the time it takes to get feedback from the customer. And also in traditional scrum, you have sprints of one or two or even here two to four weeks. But these days, you don't even want to wait for that even not as long. You want to deliver things constantly every day, dozens of times a day to get the feedback from the customer and reduce dependencies across different teams. So a giant cloud native world is becoming even way more important, but also way more extreme. There is no waiting for anything just constantly pumping out the value to learn from customers what's going on. Releasing the value is the best way and looking how customers respond is absolutely the best way to learn what's going on in the in the industry in the world and your customer with your customer base. And based on that improve and adjust your strategy. And of course, the last one is cloud native technology. And as I said, I'm not going to go too deep into that. I mean, I started using containers. Since Docker wasn't even called Docker, the company. And since then it became obvious that things like containers, microservices and Kubernetes, they can allow you to go bigger and faster. So at the end, what we're building, we're building cloud native cloud native means dynamic strategy, a geoprocesses and cloud native technology. And the last part is, so how can you become cloud native? And this part is mostly based on the book cloud native transformation. By the way, this book is now available for free. You can download it from Container Solutions website for free. So they're trade-offs, they're always trade-offs. So those cloud native systems, they're distributed by definition containers, Kubernetes and everything else microservices. They're not cheap, right? They are very expensive and difficult mostly because they require much more coordination and they're very difficult to control. So the change to cloud native is not obvious. You have to be ready to pay the price and understand the value in being able to respond to change in the environment. And the way we typically see it is that this diagram is based on the book about design thinking where there are three distinct stages of any project. The mystery when you don't really know what's going on, heuristic when you're sort of getting the idea but not fully yet, and an algorithm like McDonald's, right? McDonald's in the beginning, then four restaurants and then current set up when you have a book, How to Run a McDonald's restaurant. So, and we see companies go through this before they start, they sort of stand there and afraid and they're looking for a guide and who can help them to take the journey faster. In the mystery stage, you have to make mistakes, you have to go in all kind of different places. That's how exploration looks like. But eventually get to a great mix stage when everything is just working. And this is basically this dynamic house thing, this is exactly what you want to achieve. It's essentially create very strong foundation, build an MVP house, but then always improve it. So if you once you have the MVP house, it means that you have the skills and the basics and the structure in place. From that point, the build part is about always building more and more and more. The cloud native platform never, the development of cloud native platform never stops. You add more pieces, you improve pieces, you replace them, you refactor it, it's always getting on and on with you always keep building your house. But as important is the maintenance, the run pay side. So once you have a system in production, proactive maintenance and continuous improvement on the infrastructure level is as important. Otherwise, the system becomes outdated and non maintainable. So the way we would typically do it is start from a stage we call sync. That's where we understand the current stage to understand where the company is, is currently, how advanced it is, is it a mystery stage and heuristic stage or before even started the cloud native transformation and generate the idea is to really map all the future scenarios, what the company wants to achieve, what what are the goals and future possibilities. And moving to design stage where you acquire the knowledge and build the foundation. That's where you do typically public or private cloud, you use standard, standard APIs to make sure that you have at least some stability in the future. Definitely introduce agile processes, CI CD and acquire acquire the knowledge. All those and more, they are the foundation and the structure that will help you to grow later on. And then there is endless build stage. It's basically, it's always about improving always, gradually bringing more teams and more introducing more features and just always investing in building more and more pieces. It's just, it's just endless process of continuous improvement. And as important, you have to have a very strong maintenance structure. So the things need to run. So if something falls apart, of course, you need to fix it, but it has to be beyond that, you have to push the quality up and up because the scale of the systems is always getting bigger. And there's always higher demands on the cloud native systems. So what you really want is the maintenance team needs to push the development team so continuously investing in new products, always push them to increase the quality, always push them to invest in more testing, in more automation, in more everything in refactoring, reducing the technical depth and everything else to make sure that the quality of the product is continuously improving. And at the end, it's not about Kubernetes. It really is, is just a tool that can be used in certain circumstances to help you to achieve your goals. The goal is really is to be ready for change. And you should really, if your cloud native transformation is successful, you will never again be afraid of change. And again, you can download this book and on that website listed here and contain our solutions. And thank you very much for listening. And if you have any questions, you can find me on LinkedIn or Booker meeting with me on our website. Thank you very much.