 I'm Danielle. I'm Danielle Cook. I work for Fairwinds. We are a security and governance software company and had put together the Kubernetes maturity model, which is why I'm on this panel now talking about this book. Hi, I'm Robbie Glenn. I work with John at Accenture and we individually also put together something of a maturity model and we have worked with Simon and Danielle to combine them. And I'm John Forman from Accenture. I'm a director in the Google practice, and I'm the global lead for Anthos and Kubernetes. So today we wanted to introduce our new book, Admiral Bash's Island Adventure with Phippian Friends. So why did we create another book? Right. We wanted to, just like the other books in the series, we really wanted to convey a complex topic as simply as possible to really be able to be accessible by children. If it can be read by a child, then it can be read by a C-suite, right? We hope. We hope. That's the goal. That's the goal. So so we actually developed a framework for understanding the maturity model, or understanding the landscape. The CNCF landscape has exploded over the past couple of years. How do we navigate it, right? How do we bring our organizations, large multinational organizations, to really achieve the landscape, right? So we wanted to divide up actually the tools and technologies and experience, the journey, into five phases, which we are calling our maturity model. And if you wanted to get involved, we have some slides later about how to do that. But you can check out our maturity model on GitHub. We have released it and we are looking for some help to improve it. And we are looking for feedback on how we can grow it and maybe how we can make it more, even more accessible to you and to your teams. All right. So how did we get here? Good question. Can I ask a question? So over the last five years or so, there's been a journey to many different things. First, if you guys remember, there was a big journey to the cloud. Everybody was flocking to the cloud. But when they got to the cloud, they realized we need to develop stuff as well. So then the whole DevSecOps journey began. How do we do DevSecOps the best way in a cloud environment? And by the way, that's what complex because now it's multi-cloud. How do I build a DevSecOps pipeline in a multi-cloud world? It's challenging. It's difficult. So it ended everything. Then there's Kubernetes Big Bang. Kubernetes became the operating system of the cloud. So now you have three journeys going on in different, three different work streams, where people weren't going to the cloud. They're trying to figure out DevSecOps in the cloud. And then this is another thing called Kubernetes. How do we do all this? How do we make a true multi-cloud world with these different tools? Well, that's where the world changed and shifted to cloud native. So today it's not a journey to the cloud. It's not a journey to Kubernetes. It's not a journey for DevSecOps. Today it's journey to cloud native. Next slide, please. All right. So the aim of the kind of graphics working group, I said it correctly this time, is that we want to be able to build a framework for the world. When you look at DevSecOps, going to cloud and Kubernetes, how do we take the trail map and the eyesore of CNCSIO, where you see a thousand icons of all these amazing little icons, Prometheus and others, right? But how do you map that to something real? That's what the framework was created. This way the average user and developer on the street can take all this information and do something with it. So I speak with many clients on a daily basis and I'm constantly reinventing the wheel for every migration that we do, every journey that we do. I'm like, why are we doing this? So that's when Robby and I got together and we began to map out a framework to build on, to mature. And over time it became very mature to the point where we met our great friends over here and created for you this working group. The aim that we want to achieve is we want to work not only with the CNCF, but with you also. So it's working with inside the CNCF in the ecosystem with Syra and other friends out there, along with clients and customers, to help us achieve this goal. This is something that's early stages. Over the last 10 months, we built what you see today and it's a lot of blood, sweat and tears, both of love. But the main point is that on a journey here, and we're not going anywhere, in this, you know, the long haul, if we want to work with you to make this real. I think everybody in this room and across the world and internet sees the value here. Let's hope you do. Because we definitely see a strong value to do this. Yeah. So as John mentioned, we had three work streams kind of simultaneously working on these maturity models and this framework in which to break up this journey, right? So what we did over the past eight months or so, we have combined the models into a single framework. And one of the really great things that came out of this was we actually focused, instead of just focusing on tools, on tooling, tool sets and just the landscape, we wanted to focus on things like the people, who's actually going to be developing this stuff, who's actually going to be planning this stuff, right? Again, the C-suite, the VPs, the sales people. How do the sales people talk Kubernetes, right? We need them to. So the goal here is to be accessible from a lot of different audiences within the organization to really convey this complex topic and break it up again into multiple years so that it can be achievable. It's not, you know, how do you eat an elephant? You have to do it bite by bite, right? So what we did to actually come up with this, each one of us had worked on a maturity model. So as I said before, we had the Fairwinds, Kubernetes maturity model, which looked at everything from starting with Kubernetes all the way through to what, you know, the ultimate goal was. And then Simon, who is presenting there, he had worked on one that looked at what's the journey from your legacy systems all the way to Cloud Native. And then Robbie and John had put together a maturity model as well. So we took all of these maturity models, worked on them, went line by line through them and came up with kind of the five stages that we saw of your Cloud Native maturity. So the first is, hey, you're building something, you're not in production, but you're playing around. Then you move to when you're actually going to operationalize your Cloud Native infrastructure and your applications, you move on to scaling, which is level three, which is when, hey, it's time we need to do more with this, we need to make sure that the organization across can use all the Cloud Native tools and process we put in place. Then you move to improving it and optimizing it. So there's five levels of the Cloud Native maturity model. And then as Robbie mentioned, we divided it when we were going through it, we looked at it and said there's some themes coming out here. So we have people and what happens with people because it isn't just about the technology, it's about how do you change as an organization? We looked at the process that you have to put in place, policies you have to put in place, like how does that look from level one all the way to maturity? And then finally we did look at the technology. So we have that throughout the maturity model. And then we have, but we do have a number of resources, so as I said on GitHub, or as one of us said on GitHub, you can look and you can see exactly how we did it, what we did. We have a prologue, we have each definition of each stage. And we also have a master spreadsheet, so you can look through all of our workings and see how it came to be. Now we have the bit that we really wanted everybody to be here for, which is the book. And so we're going to, Simon's going to read the book to you and then we're going to go through what it actually means. So we've talked about the Cloud Native maturity model right now. The book represents the model, so we're going to do some interpretation of the book for you afterwards. And everybody has to copy the book on the chair. And the book will be worth a lot of money because it's signed by the authors. So make sure you keep it and frame it. Okay. Well, hello everybody and welcome to Admiral Bash's Island Adventure with Fithian Friends by Simon Forster, John Foreman, Robert Gleane and Danielle Cook. Great. So it's brought to you by the Cloud Native Computing Foundation. And welcome to our adventure. The Good Ship SS Legacy was sailing the high seas, crewed by Admiral Bash and his team of penguins, looking to settle an uninhabited island. Suddenly Admiral Bash came under attack by pirates. Weighed down by his heavy mainframe, Admiral Bash could not manoeuvre away from danger. So the lifeboats shouted Admiral Bash as the SS Legacy started to take on water. Captain Cube, a fellow explorer, was able to evade the pirates and watched in safety from submarine. He followed the lifeboats to shore. After the SS Legacy sunk, Admiral Bash and his crew were washed up on shore where they were met by Captain Cube and his friends. We'd better start settling the island. We need shelter and water and we need to replace our mainframe to run the island. Let's draw up full plans and then we'll start building. If we wait to draw up the plans before building, we'll waste time. We must get shelter and water quickly. Let's start, inspect, and adapt as we go. We'll cover the basics and change direction quickly and when needed. Let's use our experts across teams. Admiral Bash agreed with Captain Cube and the team went to work. Admiral Bash's crew had written all their software for their mainframe computer. But after the pirate attack, it was lying on the bottom of the ocean. Goldie and Captain Cube were there to help. Goldie knew that the regulator Ravens used their eagle eyes to keep order and would wave their police badges if they spotted little gaps in security. Assemble the basics, shelter and water supplies, and get the computer available. And Admiral, we need to think about security. We need to make sure we avoid more pirate attacks. You've already been attacked once and we need a protective barrier. Security should be woven into everything. I'm tired of the regulator Ravens swooping down on me and we're all responsible for security. Goldie helped some of Admiral Bash's Penguin crew set up a basic installation of Kubernetes with Cube ADM. To get familiar with Kubernetes, the crew deployed a mapping application by hand with help from a friendly cube cuttlefish. The mapping app was small and scaled well and showed how Kubernetes could help the penguins build the settlement. Admiral Bash's busy crew got into the swing of things quickly. Goldie taught the development penguins how to work with Kubernetes and they took to it by penguins to water. The crew built an application to control the settlement's water supply and even distribute water to some of the houses. New island settlers came to help. Beavers and moles joined forces using the penguins applications to excavate and build a new dam to improve the water supply, getting it into even more homes. Settling the island was definitely a two track activity. The Beavers and moles were creating its infrastructure and the penguins were building the applications to support them. The build was happening so fast that the regulator Ravens started swooping down on the team. The Beavers and moles complained to Admiral Bash that the regulator Ravens were getting in the way. So Admiral Bash decided to write a set of policies and bylaws to keep everyone on track. The island settlement was working out brilliantly. It was so successful that the penguins were creating new applications like crazy as the Beavers and moles demanded more and more. With so much going on, Admiral Bash needed a better way to track usage. So Goldie introduced the penguins to Prometheus and quickly built a dashboard for Admiral Bash and his crew to monitor. Prometheus to the rescue. One of the nice things about the settlement's new applications was that they'd been turned into microservices. Goldie showed the penguins how to release new components without having to take them down. Admiral Bash loved this new way of working. In the past, every time he wanted to upgrade the legacy mainframe or the programs running on it, he had needed to take it down. The penguins were eager to learn even more. So Fippy and Z found themselves busy teaching Admiral Bash's crew new lessons. Fippy taught them how to write YAML and Z ran classes on security and policy management. While the development of water and shelter was coming along nicely, the island lacked communication. The penguins decided to set up a basic phone system made of lengths of rope and cans to allow clear communication. Fippy was very invested in this. Fippy's long neck made him the only animal able to hang the phone lines. But unbeknown to Admiral Bash, the pirates who attacked the SS legacy had discovered the island. Never missing an opportunity, the pirates started phone freaking using high-pitched whistles. They were an ever-present threat that no one was paying attention to. Now the penguins were confident with the new technology. They built more and more applications. But Admiral Bash and his crew started struggling with repetition. The penguins had even reinvented the wheel. Hazel, the helm hedgehog, noticed they keep repeating steps, which was very time consuming. So Hazel helped them to simplify everything. She created charts listing each component for the penguins. These templates mapped out exactly what was required for an application deployment. I've got penguins going off and reinventing many of the same tools again and again. What can I do? Community focused cows, Esmeralda and Margarita, saw an opportunity to sell the different components that penguins needed. They opened a store that sold wrenches, pliers, sores, get and even some standard applications and policies. To make life even easier, Hazel's charts were available at no more wheels. Esmeralda was very happy with herself and everyone flopped to no more wheels because it saved so much time and effort. It was a no-brainer. Welcome to our store, no more wheels, we stock everything. Flying high above the settlement, one of the regulator ravens spotted an eavesdropping pirate and swooped down to warn Admiral Bash. Luckily, Linky the Lobster had a plan. Linky had their team of lobsters write messages on shells and encrypted code. Then a Saharan silver ant collected the messages and transported them to another lobster who decoded them. That stopped the regulator ravens from complaining and stopped the pirates from eavesdropping. These cans don't work. Linky was so happy with the results that they continued to help. When a beaver wanted some messages to be diverted from the blue lake to the green forest, where the moles were starting to dig, Fitney helped Linky's team of lobsters and ants string a new line and divert the messages. Linky's mesh allowed Admiral Bash to test new lines and connect new homes and buildings easily. The penguins loved Linky's approach and decided to use the same technique with their Kubernetes deployments. As the settlement grew, Goldie created a machine to help the penguins build well-crafted applications. The penguins could put their code and dependencies in one side to be built, tested and scanned. Now the other side came little containers that were delivered to separate Kubernetes clusters by conveyor belt, with each cluster having a different role for development and testing. At the end, there was a production cluster that hosted all applications used by the beavers and moles. It worked beautifully. Goldie added a scorpion gatekeeper to control admission to each cluster and taught the regulator ravens to write policy. If a package didn't comply with the policy, the scorpion rejected it. A curious thing started to happen with Admiral Bash's penguins. Rather than lining up in ranks and moving together, sometimes after delay, there was always one laggard. The penguins now worked in little groups. They'd stand together in front of whiteboards for 15 minutes a day and then work in their own little groups. The penguins loved it. They worked on one thing, yet as a whole, they completed big projects. Captain Cube's model for the crew was definitely working. Goldie helped the penguins engineer flux spots to deploy their applications. They really helped speed up getting the applications into Kubernetes and meant the Cube couple fish was able to have a rest. Also, the bots were a lot more accurate. Z clocked the time it took for the penguins to release software, counting the number of successful releases. The faster, the better. The beavers were very close to continuously building houses, save for the foreman sign-off. And on the code side, now that all the application tests were automated, all FIPI had to do was approve each code release. Everything was continuously delivered up to that point. The flux spots were very popular. The penguins used them to speed development by quickly testing their applications, including their deployments, simply by checking and manifesting to get. The penguins watched as the flux spots deployed them and looked to use them for production. The regulator ravens were happy as it meant the Cube couple fish couldn't make ad hoc changes whenever asked by a penguin. The ravens were always taking a hard line. The feedback loop got stronger. The penguins got feedback out of their deployment pipelines and put it straight back into their code. The beavers and moles found small building defects and logged the issues as they repaired them, learning on the job. The regulator ravens refined the policies based on what the penguins, beavers and moles found. The ravens made sure the policies were available at no more wheels. This made it really easy for everyone to get hold of new policies for both software and buildings. Reduced defects and guardrails were in place, increasing the quality of everything. Many of the items at no more wheels were free for everyone to use, and improvements were welcomed. Admiral Bash noticed the crew was experimenting a lot more and had some new ideas for the beavers. Everyone has become much more comfortable experimenting. The community is actively contributing, said Captain Cube. Esmeralda and Margarita started an online marketplace for no more wheels to make it stock even more accessible. The teams were working so smoothly that when a penguin left to visit family, the team continued to work effectively. That's a load off my shoulders. Suddenly, the ever-present threat returned. A pirate attempted to sneak an unauthorized package onto the conveyor belt. The penguins used Goldie's machine learning algorithms to predict when load would increase or decrease. Admiral Bash's existing clusters scaled easily. Excitingly, new clusters were created automatically when needed. Admiral Bash was in awe. The machine handled the deployment of packages with lots of measurement. The regulator ravens took close note of how to tighten policy and paid special attention to what was deployed in Kubernetes, including documentation on exactly what was in each package, its dependencies, and where it came from. Each package was signed off against its software bill of materials, like the beavers' own lists of materials for their buildings. There was a lot of scanning security was universal. Because the pirate package wasn't signed off, it was rejected. The sneaky pirate plot was foiled. Goldie was pleased. Our applications match our platforms. The old mainframe monoliths had been broken up, and the applications were now loosely coupled. The crew was able to update parts of the applications much more easily. Admiral Bash exclaimed, this is what we wanted. We've come so far since the pirates sunk our mainframe, and we settled this uninhabited island. With that, the chair went up. Hooray! Thank you, Simon. So, there are some meanings behind all that. Obviously, it's just a perfect book to read to children before bed. They will understand all of it. First up, we talked earlier about how people were a big part of the theme throughout the maturity model. Really, it's about the organizational change. When you adopt Cloud Native, it's not just, hey, here's some technology. It's how are we going to work? How are the people going to do it? What skills do we need in-house? We represented this in the book with Admiral Bash talking to Captain Cube. We're going to plan. We're going to do this. We're going to do that. We're going to take a long time to put it together. Then Captain Cube was like, no, no, no. We're just going to start doing it. We're going to change as we go. That was our representation of that one. Okay. Well, at KubeCon, it's safe to say that open source is dear to everyone's heart. It's also close to the hearts of our community-focused cows, Esmeralda and Margarita. They are our most obvious symbol of community and open source in the book, but fair shot, no more wheels. But look a little deeper and we can pick out other things that map to people, process, policy and technology. First off with people you'll have noticed early in the book that there's a focus on working together with our friends Captain Cube, Fippy, Zee and Goldie, all lending a hand to Admiral Bash and his penguin development team. We see that everyone can contribute no matter their skill, location or situation. Whether you're a penguin just starting out and getting lessons from Fippy or a rock star like Goldie, you can contribute. And policy, at a high level, is the company decision whether to go with open source, either adopting projects or allowing your community contributions into your own products. We saw Admiral Bash adopt CNCF projects and Hazel the Helm Hedgehog give a chance to the nearest cow. Then there are the technical policies you can implement with Oprah and Coverno and publish those policies on GitHub, Artifact Hub or send them to normal wheels. And then we have process and think carefully about how you can avoid reinventing the wheel and what practices you can learn from or contribute to the community. GitOps is a great example of a delivery process that's grown within the cloud native community and it has the technical tooling to match. And we saw Admiral Bash and Goldie adopt Flux. Finally, and most obviously we've got technology, you can adopt CNCF projects whether directly or through another product or of course contributing. And all the technology and Admiral Bash's adventure is open source except perhaps for the mainframe at the bottom of the sea. Okay, security. Security was weaving through the entire book as well as the maturity path model. And if you notice from the book, security is mentioned in the early part of the book. Just like in real life, security is always a first thought, right? Well, maybe not, but it should be. And so we want to show that within the maturity path model as well as the book, how critical that is. So last year, I worked with the Linux foundation when I created the Kubernetes certification program for security. So all the lessons learned that we learned from that is we've the framework as well. Security is throughout the entire life cycle of a maturity path model as well as the book you just read. We just read for you. So within Kubernetes, making security first class citizen is critical. When you think about attack vectors in Kubernetes, there are 10 attack vectors in any cluster, right from the container down to the network. You got to make sure each one of those 10 layers is fully secured. Otherwise, guess what? There's a gap in security and somebody will get an XED and if they are, game's over for the cluster and they could blow it up. So we want to protect that entire vector as much as possible. We do that by using hygiene, right? Security hygiene, what is that? Well, it's a good question. It's how do I properly hygiene my security model within my containers to probably secure them by shifting left as much as possible, right, to that entire life cycle. Also images, images can be very bloated and very fat and very large. An image will only be a couple kilobytes, but I see them in megabytes. I've even seen in gigabytes, believe it or not. They're so bloated with drives and libraries you don't need. If I'm creating an application, the applications containers should only have within it the libraries and jobs that I need to run that specific task and nothing else. I've seen containers with HP3 drivers in them and HP3 printer driver in the container. Why? That's a tech vector for a hacker to get into and expose. So when you develop a container, you want to have minimum images. Anything you don't need, take it out. Do not use it. Have it shrunk as much as possible. If you do that, your tech vector is reduced and that brings you proper computer hygiene. Also, for God's sake, please, your developers ever download anything from Docker Hub. That's a big no-no. You want to have your own repository that's fully secured that you control and only developers can go to that repository to build on. Because you know they're hardened, they're unloaded because you took out all the drives and necessary things out of them. So your foundation, anything you develop, is going to be a pure container that's fully secured and only hygiene and all the goodness and all the garbage you have is in that. I've seen this too many times where people get attacked. Why? Because they let their developers just go wild wild west. Develop whatever you want. Go crazy. We have to stop doing that. We have to really be smart now. Rensomware is on the rise. Why? This is why. Now we can build an anti-pattern for ransomware very easily with CNCF, open source. It's very easy to build an anti-pattern against these things. But you've got to be smart. We've got to stop doing the old way of doing things. We've got to do the new way of doing things. Next slide, please. So we talk about Service Mesh. One thing you'll notice in the book is that we wanted to really focus on, again, the journey. Like you're not going to be throwing away old infrastructure, right? So we built our lines. We built our network, right? Fippy hung the lines. They have cans on each end of them. They can talk to each other. That's great. Well, how do we repurpose that, make it more secure? We have little Silver Saharan ants carrying these shells that have encrypted packages that they can run along really fast using their little sneaker net technology to get it to where they want it to go. Then we introduced things like blue-green deployments using the very same infrastructure that we set up earlier in the book. That's exactly how these kind of journeys work, right? You're not throwing things away. You always want to be adding to it, building on to it. So you have to start with that secure foundation. Otherwise, you are going to be throwing it away, right? You are going to have to re-engineer it. So, oh, it's me again. So another thing we see, actually we call it very specifically as helm. We want the ability to not just build something once, maybe have all these one-off things, right? We're maybe creating networks all over the place. Why don't we just create a single resource, CRD or something that we can apply in all of our environments, right? So we created our shop, no more wheels, so that we wouldn't reinvent the wheel every time, right? We can just go to the store, buy the wheel that we need, put it on the vehicle or whatever. So in terms of policy management, so when you start off using on this cloud native journey, you're not going to have a lot of policies in place specifically for cloud native. Now, you'll have a ton of policies for other legacy systems and whatnot. So it's like, how do you get policy throughout your journey to maturity? So in the book, we represented this by showing the beavers and the raven trying to, this is what we want, this is what we don't want. We have the conveyor belts that showed like, hey, you have a package, it's moving through and oh, it's rejected because the policy says no. And then we have policies that are being donated to the store so that people can use those in the community. And that's really all about showing how you're going to start off with limited policies, they're going to evolve, you're going to keep working on it. And the goal is to achieve full policy maturity. And that's where you're actually not just putting policies on a piece of paper, but taking the policy, making sure that it's included in your CI CD pipeline all the way through production, you're enforcing it automatically, your developers know what they need to be doing. And if something doesn't comply, it's not going to get into production, and you're going to be able to tell your developer, hey, here's your remediation, this is what you need to do. And the little beavers on this have hats because my daughter wanted hats on the beavers. So that's a little fun nugget for all of you. And my wife wants scarves on the penguins in case you're wondering about that as well. So another thing along the line of building on top of infrastructure that we have, we have these admission controllers which allow us to apply these policies or rules or whatever we want at runtime and throughout the process. So it's actually the end of our deployment, it's admitting it to the cluster, but it also is continuously checking against these things. So in this case, our admission controllers are these represented as the scorpions who see a malformed package or something dangerous and throws them away. Supply chain, CI CD, DevSecOps, my favorite topic, right? So if you read the book and if you read, I'm sure everybody read it by now five times, right? Awesome. And if you go through the maturity model that we built, right, secured again, shifting left, first thought, the process here that we built a consistent workload, a system container that's consistent. And again, I talked before about having that consistent, you know, repository, right, to be able to do that. That's correct when you do these things. As you go through the life cycle with this, it's about a pattern. So when you go through the maturity fifth model, we give you a pattern on what to do. We don't tell you what tools to use, okay? But we tell you the pattern to use. So this is about choosing your own adventure, which is kind of the theme, underlying thing in this book is choosing your own adventure. So what tools do I want to use to build this adventure? That's up to you guys. So what you do with the right way, the smart way, you think about it quite a bit. Whether you want to be pure open source or mixed with enterprise open source, it's your turn to do that. But you must follow, but I recommend the pattern we have here is the glue. That's the magic source, the secret source, if you will, of the training model is how we do the pattern, right? There's many tools in the market that do similar things, similar patterns, so it's just picking and choosing the best ones you have to build it out. At the same time, there are gaps. There are many security gaps in every tool you use. So when you do these things, you want your assessment of your tooling for this, you know, when you assess the, you know, the framework, as well as the, the patterns. We work my gaps. So one tool, for example, we do everything, but one time security. Well, if I don't have one time security, that's very bad. So maybe not any two front top security. If I do that, now all my gaps are filled in. Like I talk to clients again very often and we do this assessment, we see gaps everywhere because nobody does this. It's just, don't think about doing this. Just because you buy a tool and they tell you it does everything you need, don't believe them. Check for yourself and go through it, you will find out you have gaps and those are the gaps hackers will find. I promise they do it every day. So it's your job, you know, to find those gaps and fill them in at every single segment of the pipeline. Also, when you build the pipeline, I recommend six quality gates to the entire process as you're building it out. Each quality gate, I'm scanning again. I'm doing my smoke screen checking. I'm checking for my vulnerabilities at every step of the way. Each quality gate. Like many, many people I speak to. John, guess what? I'm full of security, man. I scan my images. Okay. What else do you do? What about the security? They have no idea what the event is. All right. Also, sign your images. Please sign your images. Nobody does that. I don't know why. We know how to do that. Do it. If you don't sign your image, guess what happens? Somebody will hack that image and you won't know it's being hacked. I spoke to one customer. They had a Bitcoin operation going on for six months in one of the clusters. They had no idea it was happening. All right. So we've got to get some more of a security, please. And I'm hoping this Petroleum 5th Model will help you get there further and faster. So we've had a blast putting this model and the book together. Our imaginations have really run wild, but yet there's so much more for us to do. A repo is on GitHub under the CNCF organization. So please do check it out and come join our meetings. We meet every second week on a Tuesday and we would love to have you come and see us and join us. So what we're working on, now we're socializing the maturity model amongst the tags, projects, and end user groups of the CNCF. But the charter of the group means that we can work on more than just the cloud native maturity model. It allows us to put together tools to help the community navigate the ever-changing cloud native landscape. So right now we're collaborating on a landscape guide with the business value subcommittee and we're really interested in new ideas, new artifacts. So come along and see us and join the Categoricals working group. Thank you all for coming and attending our session. And if you all have the book to take a copy and there's signed copies there. So if you have any question for us we're happy to answer it. Otherwise, thank you for coming. And I want to see everybody on the next work group session please sign up. Thank you.