 Hello everybody. I have the shortest talk of the day where I will give you few pointers on how to make your applications portable and cloud agnostic on the cloud. So there are different ways to split applications across clouds. For example, if you have a hybrid cloud setup that is composed of your private data center and a public cloud, for example, you might split your applications based on the different tiers. You can have the back end on-prem and the front end on the cloud or you can slice them based on the maintenance needs. Have the legacy on-prem and do the Greenfield development on the cloud. It can be based on criticality or data sensitivity or operational concerns such as whether it requires burstable capacity or steady capacity whether it's a, you know, business as usual operational mode or disaster recovery mode. If you have a multi-cloud, right, that is using multiple public clouds, you might slice your application workloads based on cloud strengths and cost, right. You may pick a cloud if it has a good offering in analytics, another cloud for compute, or you might run the workloads on parallel clouds. Really the point is you as a developer may have to run, create applications that has to run on more than one cloud. Not only that, these applications can be in different languages and you also want to run on the most important cloud. That's your local developer machine. And how can you do that? I suggest looking into a few areas. The first thing is look into the compute portability. So you may have applications of different granularity like functions, microservices, different types of monolith and you can run them locally, right, and you can run them on specific clouds. But from portability and cloud agnostic point of view, your best options here are to pick containers that are with open container initiative spec or Kubernetes that will give you the best portability. These applications also need to interact over request reply, right. For that, you need service discovery, you need security, you need resiliency, and you can use various libraries. Here I pick a few from the Java ecosystem, right. If you go with that approach, there are not many cloud services that give you, that can back up these libraries. And in terms of portability, there are not many common standards, right. The best options are from the security space with OIDC and O2. Now, there is another approach. And here you can use sitecasts. For example, you can use a service mesh or something like Dapper and most cloud services will give you a service mesh as a service based on envoy. And that can be your portability layer. In terms of observability, there is a clear winner here. It's the open telemetry, the project and the protocol which gives you the best portability and most cloud services provide support for that. Now moving forward, your applications, they might be also using asynchronous interaction, whether that's based on traditional messaging or some kind of message queues, right. If you're looking for portability here or cloud agnosticism, language agnosticism, the best options are maybe to pick a protocol such as NQP, which is language agnostic or Dapper PAPSA API, which can abstract various message brokers. Or maybe you're doing event streaming, right. Here the best, the most popular option is Kafka, whether that is Apache Kafka or different implementation, you can find the Kafka on different clouds or cloud services that provide you a compatibility with Kafka protocol. And in some cases, if you're doing event streaming, you want these events to be delivered to your application in a push format. So if you have a lambda or some kind of function and you want event to be delivered, you need an event bus. Event bus in addition to advanced filtering, routing, it can also push the events to your application. And while every cloud has an event bus, right, if you want something that is portable or your application not to be tied to that event bus, you can use Knative eventing for that purpose or Dapper PAPSA. They both will deliver events to your application in a cloud events format. Moving on, I would also consider here something like a change data capture and outbox pattern. Really, that's the ability to stream changes from data sources to your application. That's becoming a quite popular way of connecting applications. And almost on every cloud, you can find the data stores that can even emit events. But these events typically have, you know, different format, different semantics. If you want something that works consistently across different clouds, the options are the debisium project, which is change data capture or something like Dapper that can emit events consistently. Moving forward quickly, there are different type of data stores, right, that are good for different purposes. For example, relational data stores is good for transactional processing, key value store for fast access to data, document store for a search of structured data object store for large files. And every cloud has offerings around us, but the ones that are probably most portable and cloud agnostic are Postgres, where you can find most implementation of relational databases that are compatible with the Postgres protocol. Even AWS S3 as an API, you can find compatibility with that API across other clouds and Redis and MongoDB, respectively, in their fields. And lastly, what about synchronous interactions? So if you want to schedule a task that runs periodically, for example, there are different projects and cloud services. The common thing around them is that they all use Chrome as a syntax, right? And for orchestration of service interactions, you need something like a workflow engine where you can implement a saga pattern. While there are many implementations available in Java and in other languages and cloud services, there is not a common standard that is portable and that's a de facto standard. JVPM was such a spec in the past, but it's been never targeting developers, so that's not an option here as well. So to sum up, really, if you want portability, right, you should pick cloud agnostic and protocol API, that's de facto standard. And here, containers, Kubernetes, and OpenTelemetry are great examples of what can be done. In other areas, projects such as DAPR, Kafka, cloud events, you know, Postgres and others are becoming de facto standards, and there is not a good option for a workflow engine that's a standard today. And really, that is not only portability of an application, right? It's also portability of your skills when you change languages, when you change teams, you can carry with you. That's all. Thank you.