 Hello, and welcome to this on-demand webinar from the Cloud Native Computing Foundation. My name is Jamie Dobson, I'm the co-founder and chief executive of Container Solutions. Container Solutions is a professional service firm that specializes in cloud native and cloud native transformation. We are of course members of the CNCF. Before we begin the webinar, let me just bring your attention to the CNCF's website. It's here that you can find out different information about certification projects and of course all the amazing open source projects that are governed by the CNCF. If you look down here, you can see the Sandbox Project, the Archive Project and of course the Cloud Native Trailmap. If you're interested, there's also the interactive landscape. The CNCF is a force for good in our community. It brings together both end users and individual contributors. So without any further ado, let's now move from that little plug for the CNCF and this wonderful website of theirs and get into our webinar over here on the left-hand side with a different set of slides. So what are we going to be doing today? Well, we're going to be talking about cloud native, but we're also going to be talking about cloud native transformation. By the end of the webinar, you should have a better understanding as to what cloud native is and a better understanding how you can begin to get there. Specifically, we're going to be looking at three things. We're going to be looking in the beginning at a fictitional company called Wealthgrid. Wealthgrid is actually an amalgamation of all the companies that we've helped to become cloud native. Wealthgrid makes some classic mistakes on their journey. If you're on your journey or are about to start your cloud native journey, you do not need to make these classic mistakes because Wealthgrid has made them already for you. After that, we're going to look at what is cloud native? Can we settle on a definition and can we look at cloud native, not just from a technical point of view, but also from a cultural and a teaming point of view? And finally, the third thing we're going to look at is a number of different tools that will help you on your cloud native journey. So on the one hand, this talk is philosophical, but on the other hand, it's also hugely practical. So fingers crossed, you can learn a little bit about what cloud native is and pick up some tools, techniques and tricks that are going to help you get there with your team or with your company. All great literature is one of two stories. So said Tolstoy, a man goes on a journey or a stranger comes to town. So the question is, which story is the story of Wealthgrid? Well, let's meet them, shall we? Wealthgrid is a mid-sized firm. It's profitable. It's a nice place to work. It's probably about 20 or 30 years old. Maybe it's a bit conservative. Maybe it's a bit stuffy. But they've got product and service market fit. So all of the startups out there would love to be where Wealthgrid are today. Wealthgrid is made up of a cast of characters. On the one hand, we've got Steve, the chief executive. Now, Steve cares about a few things. One of them is getting features into the hands of their customers reasonably regularly. Recently, Steve's learned about a new acronym or a new phrase called time to value. That's the time it takes from an idea to come into his head or into the head of one of his products people into the hands of one of their customers. So Steve naturally, don't we all, wants to shorten the time to value. Without a doubt, Steve has seen what cloud native applications look like and he thinks to himself, well, if those companies can do it, why can't we? However, it's also 2021. And nowadays, we are pretty unforgiving when it comes to systems going down. If you serve customers and especially if you work in the financial sector, if you serve customers online and your system stops working, this can very often be front page news. Steve wants to stay off the front page news and he wants to stay out of the headlines in the evening. He definitely wants to avoid being having system failures pointed out on social media such as Twitter and LinkedIn. Now, Jenny shares a lot of Steve's ambitions and goals. She definitely wants to shorten time to value, right? Unfortunately, or not unfortunately, but put a different way. She wants to sort out time to value. She also wants to stay off the front page of the news, but she's also got a different set of duties because she also has to help her engineers developing their careers and reach their ambitions. And of course, she needs to help them satisfy their curiosity to explore new technologies. The engineers exactly like Jenny and Steve also care about time to value. They've also heard about this thing called the cloud. They've heard about Kubernetes and their curiosity is super peaked right now. Together, they think that cloud native could be a way to shorten time to value and to stay out of the newspapers. In the background, there is a lingering concern. There is a stranger coming to town and this is starting to bother Jenny. Who is the stranger? There are three types of stranger when it comes to cloud native. The first one is the incumbent. This is the dominant company in your space that decides to move with cloud native early. The best example of this is ING Bank in the Netherlands. They moved to what we would call DevOps 10 or 12 years ago and then nowadays very active with public cloud, Kubernetes, containerization, what we would call cloud native. ING knew what everybody knew back then. They knew that the internet and cloud technologies would change the way we produce applications. The differences ING acted on the strategic insight. By doing so, they managed to win two separate wars. The first war that they won was the war for users. Their digital products, their mobile app, their tablet application is absolutely beautiful. Once they started to produce these amazing digital products, all of a sudden they started attracting users and new customers. All of their competition were playing catch up. The second thing that ING did was win the war for talent. If you wanted to do DevOps 12 years ago in the Netherlands, where else would you have worked? And nowadays, if you want to do cloud native, where else would you work? So for the competitors of ING, the competitors of ING now have two series problems. They're losing the battle for users and they're losing the battle for talent. Naturally, Wealthgrid and Jenny and Steve are worried about the competition in their area of the world because if they move with cloud native, they will gain a competitive advantage. The second thing that's bothering Jenny are the digital upstarts or the challenges. So Starling Bank right here in the city of London with me are an awesome cloud native company. As a matter of fact, I'm a customer of Starling Bank. Everything I need from a bank is right there on my cell phone. What's remarkable is they went from having no bank in January, 2016, when they raised 70 million in funding to having a fully functional bank only one year later. They were of course able to do this for numerous reasons, a strong vision, a powerful executive team, but they could build on cloud and cloud native technologies. They could consume the public cloud. And by doing that, they could get the scalability and the reliability that they needed to launch. The third type of stranger that really scares Jenny and Steve is the stranger they cannot see coming. So for example, Kodak, the film company was not destroyed by main competitor, Fujifilm, but rather Kodak were destroyed by an alternative way to share photographs. MySpace, email, and then later Facebook, Twitter, and WhatsApp. It's the competitive threat from outside of your industry that you do not see coming. What happens when one of these large tech giants comes to play in your space? This is what Jenny is asking herself. What happens if Amazon decide to provide the same products and services that wealth grid provide? Amazon have already got a banking license. Nobody knows what we're going to do with it. So these three competitive threats have really, really got Jenny worried. We must do something. Cloud native seems to be a good thing to do because all of these competitive threats are also using cloud native. So what does Jenny do? Well, she of course makes her first classic mistake. This is the mistake she makes. She grabs a load of things. Let's call them cloud native tools. Gets a credit card out, starts to use AWS, uses Kubernetes, boxes upload of different services into containers, throws them on the cluster and throws them up into the public cloud. She does this through the normal way of working. Six to 12 months later, but in reality, it's often more like 18 to 24 months later, they're stuck. The backlog is still quite full and these cloud native tasks or tools are actually still in there with only a number of features and new parts of the product becoming cloud native and moving over to the delivery, the delivered side of their work. What's happened? It was a little bit harder than Jenny originally thought. Okay, this is the second wake up call. This stuff is not business as usual. This is not the same as changing from one programming language to another, but it's a whole other way of thinking and a whole other way of working. No problem, Jenny knows how to deal with this. She works with Steve. Steve was a little bit miffed about the first failure, but okay, we've learned lessons and we're moving forward. Together, they come up with a more structured plan and the structured plan says something along the following. We're gonna build a cloud native platform team. We're gonna take some of our most creative and productive engineers and pop them into a cloud native platform team. They will set the rules and build the platform that the other teams will live by. The idea is as we build the platform, in parallel, we will begin to containerize our applications. We'll start to use cloud native tools and even though we're gonna split our workforce, the productivity gains that we make with the platform will easily make sure that we've got more time to spend on features, thus giving our customers what they want. In time, every time. Okay, six to 12 months later, but in reality, it really is more like 24 to 36 months later, we have a problem. The building of the cloud native platform was really a lot harder than anybody could have imagined. Now, because the platform stalled out, so too has the feature backlog. Not least because the creative power of the engineering team was split into two. So it's not just that this new way of working was difficult, but the engineering capacity has simply not changed. This was the second classic mistake from Wealthgrid and Jenny and from Steve. Why is this so difficult? Well, simply put, they've never done cloud native before. This is what most people think of when they think of cloud native. They think it's somehow to do with architecture. So for example, a company might have a tightly coupled monolith. In the last 10 years, they might have broken that monolith up into a range of client applications, each consuming similar services. So the mobile application might consume the same backend services as the web application. And it's a logical progression to think, hey, we used to have a monolith, now a client server, we're surely only one step away from microservices. And if we're one step away from microservices, then we're only one step away from Kubernetes, from managing our clusters. So people view this as technical, architectural. I think it's something to do with architecture. It's something to do with provisioning and infrastructure. In other words, they think that cloud native is a technical challenge. Continue as your app, chuck your containers onto a Kubernetes cluster, and chuck your Kubernetes cluster up onto a public cloud. Unfortunately, there is so much more to cloud native than just the technical elements. So if we start up at the top of the maturity matrix, you can see something along these lines. You have, excuse me, sorry. If you look at the top of the matrix, you see that we collaborate along. What does this even mean? Well, in cloud native, we collaborate very differently to how we usually collaborate in large organizations. So for example, different teams might look after one or a collection of microservices. Now, other teams will consume what comes out of your services. Now, what they can do is, if they want changes or if they want updates, they might submit a change request to you. Alternatively, they might submit a pull request. They might actually fork your repo, build it, and then submit a pull request back. Alternatively, if they're really not getting any service from a team, they might fork the repository and manage their own version of it. In most large organizations, duplication is something to be utterly eradicated. But actually, organizations that go cloud native take a very different view. Duplication is not as evil in such organizations as it is in more traditional organizations. We also design our products differently. So we're not just thinking about feature-driven product development, but we're thinking about data-driven product development. We do things like A-B testing. We test a version of a feature on one set of users. We test a variant on another set of users. And whichever variant works best is the one that we integrate into the product. This is one of the ways in which products live and evolve along with users' needs and aspirations. The way we build products and we design products is radically different in cloud native. And because of this and the way we collaborate, it's extremely powerful. This collaboration model and this design, the way we design products in cloud native is, of course, supported by the technology, Kubernetes containers, and those methods of rapid software development. If you only focus on the technical stuff, you leave a big part of cloud native behind. Then, of course, you've got all the processes as well. Usually we have platform teams and we adopt either a DevOps or an SRE mindset. This is radically different. This is what Wealthgrid discovered. The same type of people who used to build products at Wealthgrid and not exactly the same type of people who would build products in the new cloud native Wealthgrid. They have got missing capabilities and they've got a missing mindset. For most people out there, for example, here in London today, most people don't want to run what they've built. They want to build it and let somebody else run it. But this is different when it comes to cloud native. As a heuristic or rule of thumb, we say the following. If you build it, you run it. All of these different practices, heuristics and technologies work together to produce what we call cloud native. It's not as simple as containerizing a few apps and chucking them on a cluster and chucking them up into the cloud. Finally, Jenny gets an ultimatum. You've got to start delivering or else. Now, Jenny does something different this time. She doesn't come up with a quick plan, but instead she starts to investigate the possibilities. At the top of this webinar, I took you through the CNCS website. Maybe Jenny went there and maybe she started to understand all the different elements of cloud native. If she came to any webinars, she would have certainly have learned almost immediately that culture is as important, maybe more important than the cloud native technologies themselves. She's got to do something else. And this something else is about thinking. Now, she might have read our book. This is not just a plug for the book. She might have read our book. Our book is pretty clear. This is a copy of it here. It's pretty clear that cloud native is broken up into many, many different elements. But she could have got this from any book. Any different, any number of books are out about cloud native and cloud native transformation. But the main point is, is she starts to think differently. She might have also discovered our cloud native transformation patterns. So what we've done in the last five, six, or seven years is we've been studying companies that both filled with cloud native and who succeeded with cloud native. And it turns out there are over, at least over 110 different patterns. These are our patterns collected on cards. This one is a proof of concepts. This one is about no regrets moves. How do you make a move in the cloud native space or with your cloud native strategy that yield no regrets? And it turns out that these patterns reoccur frequently. Often they come from making mistakes. So all of a sudden Jenny starts to view cloud native transformation radically differently. She understands that there are these things called patterns and she understands that patterns have come from classic mistakes. And she's starting to get a vague notion that culture is really important and she's getting an even more concrete notion that cloud native is not just about technology. So what does she learn about patterns? What does she pick up here? Let's talk about patterns for a few minutes. So a pattern language is essentially a collection of design decisions. So you can think of a pattern as a word in a dictionary, table, chair, sofa. These are words that for example were taken from a furniture pattern language. Now take a look at the left. All three of these things are instantly recognizable as tables. And yet they're instantly recognizable as being completely different. This is one of the unique features of patterns or design patterns. They've got this very strange and peculiar feature baked into them that something can be obviously something, a table, whilst being obviously very different from other implementations. In that sense, patterns are implementation free. They don't say anything about how you should implement them. When you bring these words together, you have a language. This is a furniture language. The language in our book is a cloud native transformation pattern language. And you build designs by writing stories. So for example, there is a square table with four chairs and a sofa in a room. This is the design of a room based on the furniture pattern language. Now I did say that patterns were implementation independent. This is correct, but they're not context independent. The context of when and how you should use a pattern is really, really important. So in summary then, what is a cloud native transformation pattern language? It's very simple. It's a collection of design decisions about cloud native practices and technologies and the context in which they work, right? That's really, really important. Patterns are a bridge between experts and novice users. And the bridge comes through the context. So for example, there are contexts out there where public cloud is not a suitable pattern. You need to understand both the pattern and the context in which it works. Let me explain this just a little bit further. All patterns follow the exact same structure. They follow the same structure because it makes it easier to understand and easier to read. Remember, I said that they were shortcuts, they were heuristics from the expert user to the novice or new user. We have a definition. Then we have, in this context, it will actually help if I show an example. So let's just pop over to our first resource or our first tool that I wanted to share with you today. This is the companion website to our pattern language. It's free, it's also open source. So you can copy this and use it for whatever purposes you have. The first page just gives you an introduction, no problem. Let's now pick a pattern. Well, in the pattern language, it turns out that there are four key categories, strategy and risk reduction, organization and culture, infrared and cloud, development and design. The categories are not so important only to tell you that this stuff is reasonably complicated. Let's just pick a pattern. It doesn't matter which one we pick. Let's pick strategy and risk reduction. Now, here you see a number of different patterns, big bets, learning loop, objective setting, and of course the classic business case. So here you see the structure that I just shared in the main slide. You see an introduction, before launching a cloud transformation and enterprise leadership must make sure the initiative is needed and the benefits justify the investment. And then we keep scrolling down. This pattern works in the following context, therefore and consequently. The context in which this works is cloud native transformations are a big commitment and they require significant investment and budgeting time. Too many organizations get caught up in the hype of cloud conversion. If you are caught up in the hype of cloud conversion or if this context speaks to you, then the business case, cloud native transformation pattern could be useful for you. So by exploring the cloud native transformation pattern language, Jenny now starts to get a much deeper understanding of what cloud native transformation is all about. And she does discover that technology is important, but she discovers also that it's only one quarter of the whole cloud native landscape, which has also got something to say about processes, business strategy, evolution, and indeed how to onboard different teams to become cloud native. Let's now get back to the story and find out what's happened so far. So the first time Jenny tried to do this was as follows. She split, she put Kubernetes, cloud native, and microservice onto what we could call the proficient or business as usual work streams. This was the first failure. The second time Jenny did something different. She reversed this. She put a lot of energy, she took a lot of her creative people and put a tremendous amount of creative energy into building this cloud native platform. The idea was that that creative thinking would lead to a platform that was easy to onboard to. And therefore the productivity gains from the platform would be reflected in business as usual and features would come out at exactly the same rate or better still even quicker than they used to. This was a second classic mistake. The third thing she does is discover cloud native transformation patterns and now she starts to see the world very differently. She thinks or she starts to see that she can design the transformation by using patterns. That's exactly what she does. What does her transformation look like? It looks a little bit like this. The first three patterns that she discovers are the transformation champion, business case and executive commitment. These three things are what are needed in order to create the right leadership alignment on a wealth grid side. They've got nothing to do with technology. That's very important that we noticed that. What they're actually doing is showing the cloud native transformation for what it is, something radical. So when we talk about change, we think about changing one thing for another. Cloud native is not a change to your organization. It's an utter transformation in how you think and how you work and how you build digital products. This is why it's so hard. You cannot go through a transformation like that unless you take it seriously. So the first three patterns are all about taking this seriously. The next part is all about the strategy. What's the vision that we want? Where do we want to be as a company? What do we value? Do we value safety? Do we value risk? Do we value learning as we go? Do we want to hire the right people? Or do we want to train our own people? All very sensible business questions that must be asked and they must be answered. On the back of this, we get something like a transformation strategy. I'm not wanting to make the same mistake that they made earlier. Wealth grid now think about their world in two different ways. They think about the proficient use of their people and their technologies, but they also realise that to do something transformative requires great creativity. Down on the creative side of their work, they're looking into things like exploratory experiments, proof of concepts, minimal, vital products. These things do require creativity, but they all serve a wonderful purpose. They drive down risk and by driving down risk, they drive down the cost of change. These risk-aware processes and practices help us to stack the odds of success into our favour. Up in the proficiency side of things, we're doing slightly different things. We're preparing for onboarding. Of course, there is a connection between these two workstrues, but when we onboard our applications to the cloud, we want to do it repeatedly, safely, and in a way, where we learn as we go. Onboarding to a cloud platform can be mechanical. Together, these two worlds start to come together. The platform evolves, our proficient teams know how to onboard to it, and then we start to gradually bring different applications and different teams onto the cloud-native platform. We do this with gradual onboarding, or at least that's what they did at Wealth Grid. Why do we do this? Well, every time you onboard a new application to your setup, you're going to make a mistake or you're going to find problems. So by gradually onboarding, you're learning as an organisation how to do this properly, and you're shaking out any problems in the platform itself. Gradual onboarding is once again another pattern that helps you reduce the risk and therefore reduce the cost of change. Now, you'll notice that this is very systematic. This is not the type of mature, quick ramp up to the cloud that's often followed by a quick ramp down. This is systematic, this is planned, this is careful. And when the rubber hits the road, it's gradual and it's iterative. Finally, the last thing that happens at Wealth Grid on their transformation is the monoliths that they used to have are slowly strangled, and eventually the remaining landscape is lifted and shifted onto the cloud infrastructure. This is not done at the beginning. You cannot get your credit card out and move your landscape to Amazon web services and say, now we're cloud native, because you're not. All you've done is moved a load of applications over here to a load of applications over there. You will not reap the benefit of evolutionary design and you will definitely not reap the benefit of these amazing tools, such as Kubernetes and all the tools that you'll find up on the CNCF's website. How does this happen practically, right? So you were like Jenny, you wanna get cracking, what do you do? Well, this might sound low tech, but actually you grab the cards and you throw them on the table and you talk about it. What should come first in your organization? The transformation plan or the transformation strategy is not setting stone. It's a way to discuss what might happen. Traditionally, one second please, I'll show you something. Traditionally, this is called scenario planning. So this is a text that some of you might recognize. It comes from first year business school. When you plan different ways of working or different futures, you're doing something called scenario planning. And what you do then is you look at the scenarios that are most useful or most probable and you throw the other scenarios away. It's in exactly this way that we can plan with the whiteboard or on the table in one hour what some companies take one year to discover on their own. So when it comes to strategy, you must never, ever spend tag building and planning scenarios and discovering scenarios what you could have realistically discovered on a tabletop with a bunches of pieces of paper. This is the section of the book. This is known as scenario planning. For anybody who's interested in strategy and strategic execution, you can Google that. Now unfortunately, scenario planning with the patterns, even though it's very cheap has been quite difficult to do during the pandemic. So let me now introduce you to a new version of this tool which is our interactive platforms mural whiteboard. So you will once again see all the different patterns. The first set are around strategy and risk reduction. And there we can see our friend again, the business case. There he is right here. I can select that business case and to the right of that vision first objective setting for all of you who work in business. This will all look extremely familiar. And of course, we have got infrastructure and cloud patterns. They're down here, production readiness, dynamic scheduling, continuous delivery and continuous deployment. And if we zoom out, what we can now do is start to build the transformation up by dragging the right cards. As I said earlier, the strategy you produce is not set in stone, but it lets you and your teammates reason about effects and build a strategic plan that works for you and your cloud native transformation. By doing this, you can avoid the expensive mistakes that Jenny and the team at wealth grid made. Back to the presentation. So where are we now? Well, the third time Jenny and the team at wealth grid got it right. So finally, we see a balance between creativity and what we might call business as usual or proficiency. It's about 80 to 20. 80% of all engineering effort is on new features and testing, engaging with users. But we still dedicate 15 to 20% of our time on creative ideas, A and B variants and new concepts. We use design thinking to get inside users heads. But because we have linked the way we design products with this amazing ability to rapidly deploy new features, all of a sudden we start to see cloud native for something completely different. It's not just about users needs and meeting them. It's not just about reliability and scalability and serving millions of users simultaneously. No, we've now got a system of innovation. We've got a way to understand users, to meet their needs and to do it quickly. So when you zoom out far enough, you start to see cloud native, not just as provisioning and containers, but it's a whole system of innovation when it comes to digital products. It's this that makes it so exciting. And it's this that will give wealth grid an amazing competitive advantage over their rivals in their space. This is why cloud native is remarkable. And this is why cloud native has captured the imagination of millions of people all around the world. So then what is cloud native? Can we answer the question? I think we can answer it. It's a system of innovation for digital products. And it uses cool technology, but all of these technology and processes serve the same master innovation. So if you would like further tools or tricks or tips to help you, you can sign up to our newsletter here. You can of course, sign up to the CNCS newsletter too. You can subscribe there or click the QR code and every month you will get delivered to your inbox, new ideas, new concepts, and they're all designed to do the same thing, avoid you making classic mistakes. You can also grab the patterns. They appear on our website and they also appear in our book. And speaking of the book, you can now get this for free. It's available on our website or by scanning that QR code. Everything we discussed today is freely available at the companion website or through our website, which you can follow down to the left or follow by clicking on the QR code. Now that you know what cloud native is and now that you know the tools you can use to make the most of it and to reduce risk and thus stack the odds in your favor, you are ready. The stranger is coming, but you are ready now. Thank you for listening. I hope you've enjoyed this on demand webinar from the CNCF about cloud native and cloud native transformation. I hope to see you all again. I'm best of luck with your journey. I'm best of luck with whatever comes next for you during the pandemic. Stay safe, wash your hands, wear the mask. Bye.