 Hello, and thank you for watching this presentation. I'm Sergio Concardanos. I'm the proud leader for Monaco here in KubeShop. I'm going to be talking today about implementing tool chains in the cloud native area. Kubernetes has a wide spectrum of tools. There's more than 2,000 tools that you can use. We think of Kubernetes as one thing, but actually there's a lot of components in different places that need to be put together. And that's the reason why you have so many 35 distributions and you can have different ways of doing the same thing. What we know is that writing configuration for application in Kubernetes is a complex process and is prone to errors. We know that security concerns slow and delay rollouts. In the last red hearted state of security of Kubernetes, 2,022,53% of the respondents were actually doing that. And in the same survey, 93% has encountered some security incidents in the Kubernetes environment in the last 12 months. Only 7% didn't have any problem, why at least 53% were having misconfigurations in the configuration. So being able to understand what you're deploying and how to configure it, it's really important. Because as the application grows, the complexity grows with it. Maintaining an application in Kubernetes that is scaling, it's a big problem. Why? Because there are many ways of provisioning components and connecting them. For instance, you can use a database internal or external to Kubernetes itself. And there's very good ways of connecting your application to your database and making it persistent. For instance, you could use an auth proxy in a sidecar container. Or you can connect directory to your database using an IP address that you need to somehow use inside your application. Also, we know that there's only a few uses in Steam that are expert in Kubernetes. HumaneTech was a marketing study in 2022 was saying that in our conversation with users, we know it's the same. That has two problems. The first one is the operation engineers that know how to deploy and create the configuration required. It's a bottleneck. So all the people will have to ask the Jamel guru to know how to do the things. The other thing is because it's so complex, you can mess it up in so many ways that even the people that know how to do this will stop and will be scared of making mistakes. And so that comes again to the additional lead times and to the bottlenecks of the actual DevOps, Ops, or platform engineers. And that's a problem because when you're facing with a bottleneck and you have something as complex as Kubernetes, you tend up to make the minimum possible. So copy and paste from the internet, reusing some of the configurations are things that we are seeing a lot. And let's not forget that Kubernetes itself evolved. So there's deprecation of APIs with each version. So it's few months you will have to review and you will have to take into account all the changes that have happened in the last version of Kubernetes. And in some cases, big things get deprecated of new solutions that are more flexible and more performance are out there. So it's good for you, for your cost or for your business to have all of that in your mind. So there's a lot of tools, but we know there's some tools that you must use. The first one is Kubernetes itself. All the configuration in Kubernetes is written down in manifest. There are JSON or Jamo, even though some tools use other versions like JSON net, but what the Kubernetes manifest do is that they specify the desired state of an object. So instead of telling the steps to do, to do something, to do a task, what you tell Kubernetes is, what is the desired final state? And Kubernetes will make everything possible to change the state, the actual state to the state defined as decided state. You can have different manifest in a configuration file or you can have one manifest in each configuration file in any case that many versions of many ways you can manage that. Manifests are used any place, but specifically I'm gonna be talking about a couple of things that every single instance of Kubernetes normally have. The first one is Helm. And Helm, it's an application that it's widely used with Kubernetes that use templating to package application into charts. So a chart consists on three things, metadata, the definition of the chart, a set of manifest, actually templates of manifests that are gonna be deployed and configuration violets that will be mixed with the templates to provide all the resources and all the final manifest that would actually be deployed. Helm is really important because most of the third-party content it's available right now as a Helm chart and it's distributed using Helm repositories or OCA-based registries. But normally anybody has used or it's gonna be using Helm in the future because that's the easiest way to use deploy applications. Of course, there's other advanced use cases like operators, but Helm we have found is mostly used in most deployment because it's really, really, really easy to use. Helm solves the problem of installing and updating applications, but sometimes you need to customize that. The labels use the different configurations are different if you are in a production environment that you are in a development environment. So there's an alternative that is actually part of Kube-Cuttle that is called customize. And customize what it does set to have an templating environment. What it does is gets the based manifest and it will changes. What it's called overlays or patches just basically gets your base manifest and it will apply a patch. We will modify it adding or changing the values inside to produce the final manifest that I deploy that. It's very powerful because you don't have an additional instruction even though you need to know how to do the modifications. But with a few files, you can easily deploy different configuration in one environment or in the other. Or you cannot add the configuration and the data that you are missing or you have to enforce when you're doing that. Actually, help and customize can be used together. So if you think of the application as the package of the application and the manifest the resources inside it, the configuration of all the environment variables, that's really fits into help because that's something that you know beforehand. So you can define in a values file all the different aspects of this and then deploy it. But also many times you have the runtime configuration like security context or the seal secret that your application needs. And for that customize is actually the best place to do. Actually that is so true that tools like Flux or Argo include ways of using Helm and customize in the workflows. If you are using Cloud, you mostly will be using continuous development because if you want to get all what the Cloud offers you as a business, you need to be able to deploy easy and you need to be able to scale and change the application as soon and as fast as possible. And that's the other tool that you should be doing or you must be using. That is one continuous deployment tool. Some of them are the old time, old days like Jenkins, but Argo and Flux are great for Kubernetes because they are Kubernetes native. They have been defined and they work flawlessly inside Kubernetes and with Kubernetes. And all of that at the end it's gonna be supported by JIT and JITOps that is also a huge trend in the market. Is this enough? Of course not. Which said there was 2000. There's a lot of components that has not been defined in Kubernetes and you need to choose by yourself. Talk about Helm and customize, but in order to deploy something using continuous deployment you need to create a container. Tools like Billpaks allow you to automatically create the containers or build that. It's another alternative for that. But also because there's so many pieces in Kubernetes some other people prefer to go to instructions and define application in a higher structure layer. Kubernetes an example of that or generating sub to avoid all these problems and all these decisions. Internal development platform like Backstage are really used around and they are very powerful for your cloud definitions. We talk about Argon Flux for continuous deployment but also you need to do things like testing. And if you wanna continue to deploy something it is well done if you think of testing it before you deploy it automatically. Tools like TestCube or K6 allow to do testing and allow to do everything you need to make sure that your tests are running as close as production possible. The small pieces that you need to define how storage is gonna work, how do you use Longer, as you're using Rook, how you're gonna connect to your network. CNI, all versions of network connectors, Cilium, whatever you do there's a lot of decisions that will impact how your application grow, behave, scale, and work with the networking. And let me tell you networking is a huge problem when you go to distribute the system because it's underlined, underpins everything you're doing. So any problem with networking will mostly become a problem with the storage, communication services and everything that is there. In many cases, as we said, you can work to make your environment more secure and Kubernetes out of the box is not secure by default but you can use specific version of Kubernetes and you can install pieces that will make those things work better. Like Open Policy Agent on Kverno to make sure that some policies that are being used in your environment or think like third manager that will automatically create and upgrade your certificate so you know you can use HTTPS and you know that your users will be safe without having exposed documentation directory to the internet. There are more things around Prometheus for storing metrics, Flavium D to store logs, Open Telemetry to know what your application is behaving on the different steps or cross-plane to communicate your Kubernetes cluster to third party services. There's a lot of decision to me take but anything you do, you need to take into account some steps to make sure that you're taking the right decision and everything is working, unexpected. So first, design it to fit to your development workflow. Don't try to go around, don't try to get all the things it has to be something used. You don't want your developers going away of the workflow to be able to use any of the tools you choose. In many cases that mean forgetting about that tool that everybody likes because it doesn't adjust to your specific workflow and what your company needs. Another thing is helping them. Well, we know that's not all developers are Kubernetes experts. So reduce their cognitive loads, use tools, use things that will basically reduce the cognitive load will put what they need to take the decision that will reduce the number of decisions they have to do. Related to that, of course, is automation. Is there something that is core to the developer? Then let them do it. Is that something that is a task that they don't really need for the day-to-day work? Automate it. And automating that is gonna help them both taking out something they need and just making sure it's always executed in the best way, even though automation itself is a huge task. The other thing is taking into account that you're going to scale. Your tiny application is gonna become more complex as your application grows. And Kubernetes, it's also getting more complex when there's more than a few nodes working. So take into account that when you're designing your teams, when you're designing your workflows and when you're designing the type of Kubernetes deployment that you are using. Because at the end, even if Kubernetes can do so many things, you will have to integrate into your tool cell all your tools and all your services. There's always things that you didn't take into account at the beginning or things that you need. Think about third-party tools for support or billing or any of the tasks that you know you will be needing. But they don't make any sense either because they are a sus and you need to call it outside or because they don't belong into a Kubernetes environment. Happy to say that almost everything can be deployed then but not 100% of the workloads can be in Kubernetes. And of course, make security a priority. Don't think that you can drive and create security after the fact that has to be part of your workflow. So everybody is aware of what's going on. So we talk about Manifest. Let's talk about how do you configure these old tools? And basically, there's a lot. And traditionally, what happened is that you had a lot of tools to do this. BS Code, IntelliJ, you have a lot of sources of information that allows you to define what is going to happen. But the first thing you need to understand is what's going on? What is actually in your environment? Can you know the details? Can you know what is working? Because as we said before, because you are running into continuous deployment pipeline most of the cases or because you basically manually change something. Knowing exactly what you have in your cluster is not a straightforward tool. Task, in many cases, you have to go in deep into detail to understand what happened. And in a world where a lot of people do copy and paste from Stack Overflow or from any other place, this is a great thing to have, some tool that's allowed you to inspect and know what is there. The second is because you change something. Something breaks. You want to know why. And having a history of what's happening and being able to go back and compare and know what's going on, it's something very important. Of course, right now, almost everybody use JIT or some JIT-based tool, but any SVN, any source control system is going to help you do it. There's one thing here, is that when you compare the history, normally you compare the configuration files, but that doesn't mean you can compare data tree what they mean. A configuration file will basically create resources. What you're trying to compare is those resources, not the configuration file. And in some cases, like when you're using Customize, that can be different than you expect because Customize can go and modify the things after you do that. If you can go and generate information that is valid the first time, that will be optimus. So why not use templatings and things used to generate the configuration? Using CLI tools or any other tool, but reducing the time it takes. And if you can change those templates, so they are specific and defined specifically for your company, that will be even better. We talk about OPA and Kubernetes, so the next step will be validating, both in the cluster and before the cluster, that all the workloads are following the standards, following best practices and following any policies that you have installed and enforcing in your company. So you can basically deploy knowing that things are behaving the way you want and reducing the time it takes. Anything that you can do before deployment, it's gonna reduce the time you need to understand what can go wrong. And sometimes it takes a lot because if you generate a change and that's actually have to change the configuration that can take some minutes. And you don't want developer to spend minutes waiting for an answer, whether their configuration is valid or not. How can you speed that? Use templates, dedicate time to select the right tools, the tools that you need. Use some editor, there's a lot of editor available, Monocle is one of them, of course, that is Kubernetes aware and can help you to reduce cognitive load and make things easier. And use a standard like Helm and Customize. There's other tools, there's always new tools coming to the market stating that they can reduce the stress and the cognitive load needed with a new instruction that is easier to use. In a lot of cases that's true and having a new tool will basically make easier the work of many people, but in many cases that will introduce additional complexity not at the beginning in the shiny path, but the moment you have to debug something you will have to go back to Helm and Customize and the manifest and you will need to understand how Kubernetes is working. So don't think that any of those tools will take out the burden of knowing what's going on. But they will reduce the burden of defining it in a way that makes sense. Check everything and you see ICD tools so it's completely automated. And of course always verify that what you have after all the tool chains and all the steps taken to deploy is a sector what you were expecting in production. I hope this helps you and I hope you have thought of new things and new ways of improving your deployments and your configuration and your tool sets. Thanks for listening. You can find us in our Discord or in GitHub. You can go to our web page. There's a lot of conversation like this we will love to have with you. So good luck and I hope I see you soon.