 My name is Vilgini Gram. I'm product manager at Diagrid. And in this talk, I will try to quickly tell you where the circuit breakers and other related features in your applications are heading to. And what's the opportunity for cloud native really in here? So let's get started with really the basics. I would say everything we do in software is about more efficiently using the infrastructure primitives and expressing business logic. For example, we have different programming languages which are good for different things. We have Go, Rust, and C++ which are good for infrastructure. We have Java and .NET which are good for backend applications, Python for data processing, and JavaScript. And then we have different frameworks and runtimes to use those. Then we have different kind of data stores which are good for storing data for different use cases for retrieving data. For example, there is database for transactional processing, columnar databases for reporting. There is key value stores, document stores, graph databases, and now vector databases, and so forth. And then as developers, we have to use different clients to interact with these different types of data stores. And the more applications we create, the more granular they get, such as microservices and functions, there will be more networking. So there are different communication styles, such as request, response, publish, subscribe. There are different data formats, REST, RPC, GraphQL, and so forth. And the more data storage there is, again, we have to talk to these different data stores. And I would say this kind of gives us an idea of different trends. I would say going forward, there will be even more polyglotism multiple languages. There will be applications that have to be deployed on different clouds that have to use different storage mechanisms and will have more distributed apps. But we are at CNCF, so this is not the news. Everything at KubeCon is about polyglotism, multi-cloud distributed apps. How is that related? Think for that, we have to look at how applications have been evolving. So not so long ago, we had monolithic applications where the business logic and the middle way capabilities, the repetitive capabilities we need would be in the same deployment unit. So then we got microservices, we got FAS and Lambda. And today we are at the point where we have distributed applications that are composed of modules of different size and shape. There are a combination of functions, microservices, micro-monoliths, services that are not so micro and so forth. And they are all written in different languages, deployed on different places in different shape. And I would say the same way Kubernetes and Knative in the past helped the ops by abstracting the infrastructure. There is an opportunity now for Cloud Native to create new abstractions on top of these repetitive developer needs, which were called middle way in the past, and expose these needs on top of polyglot APIs that can be used by all developers on any cloud. Really, that's the point. So if we look at there, what are those needs? For the purpose of this talk, I grouped them in four categories. I would say every application interacts with other things, and those are either around lifecycle interactions, talking to other services to third party endpoints or some kind of state storage. So let's go into each of these. Today, if you are a developer, once you implement your business logic and you package it in a container, I would say there is very little left to do around the deployment and lifecycle, other than implementing a health point and exposing some metrics, everything else is taken care by the platforms such as Kubernetes and Knative and the Ops Team. So the platform will provision resources for you, it will find the right node, it will start your application and even scale it. You don't have to do anything, so all that is taken care. If we go to the next category of interactions, let's say service A is calling service B. And there are a number of things that can happen in the middle that are completely transparent to the application. Developerism doesn't have to be aware. For example, that networking traffic, that request can be routed to different services, that service discovery. That traffic can be routed to different service instances, that's load balancing. It can be routed to different service version, that's the A-B testing and kernel releases and so forth. The network in traffic can get resiliency properties such as circuit breakers, timeouts and so forth. It can get additional security properties with encryption and access control. It can get, we can observe telemetry. Basically, we can get all of these things without changing the application in any way. And the common way to do that today is with service mesh technologies. We don't have time to go into details of this, but we can briefly see how this has evolved, starting with language specific libraries from within the applications and moving into SideCard to not proxy and going deeper into the operating system. And the point here is that these transparent responsibilities, you don't have to worry about those within your application. They will go outside of your application and even to the core of the operating system. But there are other things that developers have to care about. In this example, I have a service A that's calling, talking to some kind of third party endpoints. And in such a scenario, sometimes you have to perform repetitive things such as connecting to an endpoints. You would need some kind of connector that has to do protocol conversion from one protocol to another. It may have to do transformation of the message or it has to do some kind of content based routing based on the actual message or topic route that to specific application. So all of these things today, they are primarily done from within the applications with frameworks such as Camel and Spring, that's in Java. But what's happening here is that these responsibilities are moving outside of your application in the frameworks such as DAPR, Knetit and they are becoming available to any language. So they're not moving to the platform but moving outside of your application. And the last category, I call them stateful interactions. And the whole point here is if we have two services that has to communicate, and when service A sends a request and that request is stored in some kind of medium between service A and B. Typically that's a message broker where the message is persisted but the same semantic applies if the message of that request has to be persisted to a workflow engine or it has to be stored in some kind of database and you can use change data capture and outbox in order to deliver that to second service. Other patterns here like item potent filter which needs to store requests into database to filter those and so forth. And the point here is previously these responsibilities were done within the application with the language specific frameworks such as I have here conductor, cadence but even those frameworks now are adding support for other languages and these responsibilities are moving outside of your application becoming cloud native with frameworks such as DAPR. So why am I telling all that? That's the key takeaway. I would say that two kind of changes that are happening with all of these repetitive developer responsibilities. On the left hand side, we have transparent responsibilities such as lifecycle, low level networking that are moving into the platform even down to the operating system but then there are other responsibilities that you need to develop to do that impacts the application and the business logic. These are explicit interaction, state tool interactions and they are moving outside of the application into polyglot APIs that you can call from any language that you can call from any cloud and any shape of your application and that's really the opportunity for cloud native to address these responsibilities and offer them to all developers. That's all, so enjoy the rest of the conference and thank you.