Hello everyone. I'm Michel Moto, but everyone call me Mitch. I'm a developer advocate at me platform, and today I will talk about platform engineering and AI and cognitive lots. I started to work at 2004 and I become a developer guy in 2015. I love to share knowledge about platform engineer, developer experience in cloud native, but also about sustainability. I'm one of the organizer of cloud Native Days, Italy, a conference related to cloud native topic here in Italy. And I founded a couple of community. I co-founded a couple of community one, it's developer life, it's Italian community to help people to join in our field. And the second one, it's Green of Italia, a community related to green software. I'm ACF Ambassador and. Advisory board member of Dev Network. I talk about these kind of topics because it's part of my daily work, but also a passion. I love to help people to reduce the complexity and also improve the developer experience. And I think that better developer experience can create happier and more productive developer. I want to start with this chart. The first date in this chart, it's the 2004. I started to work in 2004 and when I started to work, my profession was webmaster. I'm not know if it's an international world, but at the end it's a person that can create application website on internet to create the application you need just to know a language like PHP. HTML and CSS and after that you need just to create your software drag and drop your folder from local to the server and you are deploy at your application. Online was very different. During the time there are complexity to manage all the staff increase, and our ability to manage the complexity is low than the complexity. This is why in the last 15, 20 years, there is a lot of new job position and job roles because the before in 2004. You need just to know a language and you can do all the stuff by yourself today. You need the other people to manage the design, to manage the front end, the backend, but also the cloud, the automation, the pipeline, the testing, and so on. I love this sentence, but I think that is not true. At the end I think that Kubernetes, of course it's complex, but it's not too hard to understand because at the end it's just a tool. The real complexity to create application today. It's for example, the scalability that we want to have, the distribution, but also the data that we use, the integration, the interoperability, the user experience. But also the security and the privacy and the AI and machine learning now and so on. If we look in the cloud native, we can sort this maybe, it's the CNCF landscape at the end. It's chart with a lot of different technology inside. When you want to create a new cloud native application, you can find a lot of open source project in this landscape and you can choose it to create stuff. Just an example, if you want to have a new a PA gateway, you can go here in the right session and you can find 20 different API gateway. Of course, it's not easier. For you understand. The different between 20 different project. And for this season, you need to study. After that, you need to choose. And after you choose our right project, you need to improve your knowledge about the tool. If you want to create an application today, you need to know a lot of different tool and you need to have a lot of different knowledge. In the left side, in the list, I put also the automation and the SCI and CD tools. Some of you can say that is not a tool to improve the complexity, and I agree with you. But of course if you want to have automation or continuous integration and delivery in your project, you need to know new tools, understand it, and after that use it. It's part of the cognitive law. When we talk about cognitive load, we talk about the mental effort required to process information and complete that task. There is three different type of cognitive load. The first of one, it's intrinsic. It's at the end that not really complex of a task. Some tasks are hard. You need to have knowledge to do that, and that's it. You can reduce without any kind of trick, this kind of cognitive load. Of course, if you study, you improve your knowledge, you can reduce using structured learning, but in other case, it's part of the work. The second one, it's related to the cognitive law that you use to improve yourself. For example, effort that you use to learn and understand better a task or to learn new stuff. To complete that task and this kind of cognitive load can be good because I improve yourself. For example, if we talk about CICD, that we look in the previous slide if you want to know how to create a pipeline and manage all the automation, your application. This load can be a German load and this could because you after study can understand new tools exp explore new stuff and expand your knowledge. The last one, it's all the cognitive law, not related to your knowledge and the tools and let me say new tools that you want to learn, but it's related to unnecessary effort. For example, coset by port tools, ENT processes, and so on. Of course systems are not intuitive or process with. Too many step or unclear workflow or tools with operate UI or a lot of information, unclear docs can increase this kind of cognitive loans. And our goal is try to reduce this kind of cognitive load because it's the only one that we can improve without any kind of fish. Just to do a very clear example. As a developer, you need a new environment. 20 years ago, you can create by yourself and with a drag and drop, you can upload your project and your done. Today you need to ask, in the majority of the case in a structured companies to our colleagues in ops team, for example, and it can it have the permission and the knowledge to create the environment for you. After the request, the ops guy can create the resource configuration. The configuration of environments, for example, variable seeker and so on, create the right network, set up the security set up and many others. After that, it can provide to you analysis and you can out your application, but sometimes is not the upper in the same team or in the same desk or in the same room. You need to ask this kind of with a request on Jira, Asana and other system. And of course the answer is not very fast because the ops team, maybe in the meantime other stuff do, can be on vacation and so on. And of course this is, it's part of a poor. Develop experience. For this reason, we can introduce the platform engineering. When we talk about platform engineering, we can say that it's a software engineering discipline focused on the development of self service, tool chain service and processes. It's based on these six keywords, let me say. The first one, it's try to centralize all the stuff. For example, manage all the project and all the source of your project in a single place. The second one, it's try to automate create automation about all the stuff, industrialize and automate the entire DevOp cycle. The third one, it's simplicity. Try to solve complex task and integration, for example, with the cloud in a very simple way. And the four, the efficiency. Try to avoid bottleneck to organization like the stuff that we saw before. But also try to improve the quality because of course if you put in your application completely automation, you can insert in the pipeline, for example, quality check and also order stuff that can provide to you a good and improve the quality of your software. But all this stuff need to be self-service. The developers need to use all the stuff in our cell service mode. At the end, the idea about platform engineering is try to reduce the complexity of your application because in this way you can have the ability to manage it. When we look at platform engineering, the majority of the people looks just at the internal developer portal and the orchestrator just for the infrastructure. But I think that it's more than that. For example, in the left side, you have your internal developer portal with a new I-O-C-L-I or API or maybe ai with a different feature like the software catalog store scorecard dashboard, and so on. In the middle you have the platform orchestrator that can help the people that use the internal developer portal to manage the right side. In the right side. We have in the bottom, of course, the infrastructure can be, for example, cloud services, but also AI provider. And the infrastructure platform can be, for example, Kubernetes, but also container managed services or functions or so on, and the DevOps platform. In the DevOps platform you have, for example, GI, but also pipeline, the tracing, the monitoring, the testing and so on. But I think that there are very interesting part on these images. The yellow part, the application assets and possibility. For example, the poss ability to have out of the box API gateways or a API portal or Evans portal system to manage a automatization and authentication, but also microservices, a PI or Evan or cast. Software or marketplace, let me say software catalog or marketplace, but also system to create and manage microphone and so on. Of course, the data, it's a very important part, and have a data control plane can be good with system like fast data, but also data catalog. Also, crowd systems can be very good to improve the velocity and reduce the cognitive loan. And of course the AI. When we talk about ai, for sure, we talk about LLM, but also speech, ai, multimodal and other system like the AI agent to manage all the stuff that you can need. This kind of architecture that we saw in the previous slide can open a new, very powerful concept. The concept of circular economy. They, it's very simple. Let's imagine a team that need microservices to make payments. Of course there is no microservices around and they start to develop the system from zero at the end of the development cycle. They have a system based on talker, for example, to create a manage payment. You can call API, this API can get, I don't know, the credit number the card credit number and after that he can make payments. After that, he, they do the work in this way. If another team need to create the same system, they need to start from zero. But if they create a good documentation, they can be create a general software that can be reused. They can put this service in a marketplace or software catalog. Another team that need the same stuff can get this component and use it without use effort. Of course, sometimes the new team need to. Change stuff, add new possibility, add new functionality. And of course, if the functionality it's related to the payment, they can change the code, update the documentation, and release a new version, for example, to support PayPal. But if they need another functionality, like a system to create invoice after the payments, they can get the payment system from the team one. After that, create the system to create invoice and put together and use it. Another team, of course, can get only the payment system, the invoice system, but or get some stuff and after that, create new stuff or improve the stuff that already used exist. Of course, this kind of circular economy can be very good for your developer because the this kind of system can reduce a lot of the community load inside your team because they don't need. To create from zero each time the stuff, but they can use and reuse stuff created by orders. Of course. To do this, they need to have a good documentation and a good product. Okay. Of course, when we talk about ai, we need to talk about some stuff that can help the developer to reduce the cognitive load using the ai. Of course we look a lot around and there is a lot of different tools that can improve the ai, but for example. AI assisted devs can reduce the manual task and all your developer to have a focus on their creativity. If an AI can manage some task for your developer, simple task, can repetitive task. The developer are free to create other stuff. For example, in this kind of of AI example, we can talk also about code generation and debugging. The developer can use a tool to create code for computation or debugging and to reduce the cognitive load. But another important stuff, it's related to let me say documentation. Okay. For example, a developer can ask to AI to have information about functionality, documentation, and so on. Of course, this kind of system can be created by a rag power AI system, and we call it conversational dev device. If you have all this stuff in your system all interconnected, you can have assist devs in real time using conversational direct. DDI is if a developer need to make some manual task, he can ask to an AI and AI can do the task for your developer, or if a developer have problems with some stuff, can ask to the AI and so on. When we imagine this kind of plaque for my image, this kind of very simple draw. In the top, we have the platform. In the right we have the AI. In the left, we have the person that want to use this kind of of system. In this example for example we can talk about a couple of different stuff. The first one, it's if a developer need to have information he can ask to ai r inside the AI Iraq you have for example, LLM, but also all the documentation related to your application and your platform. And of course the AI have context about your technology, your feature, and so on. And he can. The AI cannot answer to your developer. Of course, we can add to the AI in the rug also the logs in the specific configuration of your platform. Of course, if we have all the configuration and all the stuff centralized and in the platform, we can provide all this configuration to the ai and with the documentation the AI can understand. What your platform do and all the stuff related to your platform. Just an example, if you provide all the documentation with all the code error about your services to the ai, and after that you provide all the logs to the ai. A developer can ask, you can find in the logs of my platform any warning or any error, and of course they, I can say yes or no. If yes, you can ask, okay which kind of error or warning you find in the logs and how I can resolve it. If you think about that, you can think that the AI have all the information about the Earth that happens. About why it happened because in the documentation you have all the information and can be a very good system to reduce a lot the cognitive load of your teams. Just a practical team. Of course, this is a theoretical talks. I'm hope that you enjoy it. But of course you, we need to understand how we can start with platform engineer and ai. The first one, it's the first question that you need to do. It's why why you need to adopting a platform or why you need to adopt. AI platform of course, which kind of problem you want to solve, what problem you want to solve. Of course, if you work in a very large company, you have different business unit. Different business unit have different problems, and of course you can start to solve all the problem together. You need to choose the a couple. You need to create priority and choose the problem that you want to solve in this case, for example what capability should my platform have in the beginning can be a good question, and of course how this kind of change can impact your business. Of course, you need to understand if you already have metrics. Choose metrics to use and of course, try to understand if your platform, initiative and AI initiative can improve your metrics. When we talk about metrics as suggestion that I get from Graziano cast is try to not define at all the metrics because, for sure if you write code, if you have a company, you already have the metrics. For example, in the case that we saw in the beginning of this presentation, a metrics can be if a developer need a new environment, how many minutes, hours, days. He need to wait a new environment. That can be a good metrics and you don't need to define new metrics. It's perfect for you if you define that. The reason to adopt the platform initiative can be create the environment very fast. And the first stuff, it's permitted developer to have. Self service platform to create a new environment. This is, its geometric of course. When you start this kind of initiative, you need also to talk with all interesting people to understand. All the company that can have benefit from your initiative. And of course you need to find methods that can be used by the world company. It's just not deployment frequency. You need to find the right way to use the right metrics. And of course you need to evaluate the progress of this metrics during the time because sometimes new technologies can improve in the phos period the productivity and reduce the cognitive load. But in the long run adding new functionality and modify out this kind of new technology work, that metrics during the long time can be less than the beginning. Of course, your goal, it's try to look at the metrics during the long run. And try to look the metrics for the technical part, but also identify business value because, the business is part of our job in any case. Okay. A couple of general suggestions. Try to invest time to sell service experience for developers related to platform, but also to ai. Try to align your technology closely with business objective. I know sometime it's hard because if you are a tech person, you look at tech part. If you're a business person, you look at the business part. But the best companies work. When tech and business align it, try to support the change because the people, not all the people are ready to change, and sometimes you need to be patient and try to create tutors and guidance to help these people to change with you. In any case, it's related to platform ai, but also if you don't use this kind of technology I think that the, one of the majority stuff, it's try to include the collaboration because when the people work together, you can avoid common pit fails and try to create, solution that the people can enjoy using, because I think that the most important part, if you look at developer experience, if you look at platform engineer, but also if you look at ai, the first goal, it's try to create a good ecosystem to the developer and try to improve. The quality of the tool that the developer use to create stuff. Of course there is a lot of resources. The first one is the platform model. Maybe you know it, there is link here if you don't know nothing about platform by suggesting it's starting from here. But another very interesting to blog post. It's this expanding that all of the platform engineering. You can find the link here. I use a lot of ideas about this blog post in this talks. But in the blog post, you can find a lot of good information. And that's it. Here you can find my, for me, if you want to leave a feedback I love read it and try to improve for the future. Of course, if you have any suggestion to improve the talk or to add new part, please let me know. You can feel free to add me on LinkedIn and Social Network. You can find me as a Mission Mohabi or Mitch Moha or on GitHub. If you have any question, I here for you. Thank you and bye-bye.