 Hello, my name is Clément Escochier, and I'm going to demo Stork and its integration into Quarkus. Stork is a service discovery and load balancing framework, and in Quarkus, it's integrated with a REST client, GRPC client, GraphQL client, and so on. You will use Stork when you need service discovery and advanced service selection strategies. In this demo, I'm going to reuse the SuperHeroes sample application from Quarkus, and it's a simplified version focusing really on Stork and the Stork integration. So we have the UI, which is calling a fight service, REST API. This fight service is calling two types of services. The first one is a villain service, which provides soups about the bad guys. The other type of service used by the fight service are the aero services, and in this case, I have three instances of aero services. I have one providing heroes from the Marvel universe, one providing heroes from the Star Wars universe, and one providing heroes from the DC Comics universe. This selection and this discovery and selection will be under by Stork. So in the first part of the demo, I'm just going to use a static list, having all the addresses of my three heroes services instances. It's pretty convenient when you have a static architecture or for development time. So let's have a look how it works. I will switch to my IDE, here it is. So the first thing we need to do is to add the dependencies adding the Stork service discovery unit. In my case, I need two. I need the static list, which will be used first and also need console for the second part of this demo. One thing to keep in mind is that if you want to integrate Stork with the REST client, you need to use the reactive REST client, and so you need to have that dependency here. The REST client is very similar to the other REST client you did before. The only difference is that it's used a base URI that starts with the Stork column slash slash prefix. This indicates that every call to that REST client will delegate the discovery and selection to Stork. This part of the URI is the name of the service, which will let us configure which type of service discovery and load balancing we want. So this is done in the application properties part and a file. And here we have corpus.stork.errorService, so the part of the URI. And we indicate the type of service discovery we want to do. And in that case, I want to use a static list. So I set static and I provide the list as a second attribute. This is a comma-separated list of my three instances, so Marvel, Star Wars and DC Comics. Let's see if this works. So I have my browser here and my application running here. So here you have the three hero services which are running. Here we have the fight service and here the villain service. So let's have a look. If I call new fighter, that is, we got new fighters. And here you see we have Iron Man. So we have Marvel. If I call another time, we have Star Wars. Another one, we have DC Comics and Marvel again and so on. This is because as we didn't configure any service selection strategies, stock will use the wrong Robin. So it will just iterate over the list of addresses and go back to the first one when it would be in. The rest of the application works as usual. So yeah, yeah, I don't know. OK, one and one. Let's have a look if we can get an hero winning. How we have this one, we are going to win. So Superman won. So the static list discovery is very useful in development or when you have static architectures, but with the cloud or with more dynamic type of application we are building today, we need something, only this dynamism. For this, we are going to switch to console. So I need to go back to my IDE and because I already added the dependency in my pump file, I just have to come here and say, I want to use console. I don't need to configure anything else. I can even remove this attribute because basically stock will say, oh, no, it's console. It will look up for the services named hero service in console, find a set of instances and do the wrong Robin on this set of instances. If I go back to my application. Here and I refresh it will restart and now we are it's using console. So every time I get new fighters, instead of being the static list, it's not using the one registered in console. That's all I have for this first part of the demo. We will I will come back for the second part of the demo where I will demonstrate how you can use stock in open shift with more advanced selection strategies. In this second demo, we are going to see how you can use stock service discovery and load balancing capabilities on open shift or Kubernetes. So we are going to use the same demo as we did in the previous demo except that we are going to deploy it on open shift. So we have our heroes service instances from the different universes that we have some Marvel, Star Wars and DC Comics. And unlike in the previous demo, they will be deployed on open shift. And so be served behind the Kubernetes service, which will be named rest heroes. Unlike traditional Kubernetes application, where you just reference the rest heroes DNS name from your application and Kubernetes will do the discovery and load balancing by doing a simple one or been between the instances. Here we are going to use stock to customize the service selection. So stock will connect to the Kubernetes service to find which pods are behind. So we will find Marvel, Star Wars and DC Comics. But instead of doing the traditional one, Robin, it's going to use a custom service selection strategy. And that service selection strategy will try to see if we have our favorite universe available. And in that case, use that service instance. So let's see how to do that. So the first thing we need to do is to implement our service selection. This is done using two classes. So you need an implementation of the load balancer provider. And the implementation class will be annotated with a load balancer type. And we say that the type will be arrows. We are going to reuse that arrow's string inside the file service implementation or configuration. We can also define configuration attribute here. We need to have the favorite attribute. Or indicating which one, which of the universe is my favorite universe. So once we have this, we have just that method. So the create load balancer method that will create a new instances of load balancer. And the load balancer adjusts this implementation. It receives a configuration. So here I want to have my favorite universe. And the core of the implementation is this method here. It's named select service instance. Every time we do a service lookup, it receives the collection of instances. So of course, if we have no instances, then we need to fail saying, well, there is no instances. We can't really use or select the right one. Then we are going to traverse that collection and see if we have one matching our favorite universe. In that case, we are going to use it. And unfortunately, if that instance is not available, then we are going to just pick a random one. Something to keep in mind, and that's how it works, is that we are going to use instance.getlabels. Stalk automatically attach labels to service instances. These labels are extracted differently depending on the service discovery technology you are using. So for example, on console, I think it stacks. On Kubernetes, it's the labels and things like that. Once we have this service selection implementation, we build it, we have it as an artifact, then we need to use it. And to use it, we go to our fight-service-pom.xml and we are going to add the dependencies. In addition to that, we are going to use the Kubernetes support from Stalk. So using the Stalk service dependency, Kubernetes dependency. As we did in the first demo, you can also use static list for your local development and testing and just use Kubernetes in production. The error-rest client didn't change his first demo. The only thing that changed is the name of the service. Now it's named rest-errors to match a Kubernetes service name. With this, we need to go inside the application properties of the application and configure the service discovery and selection of the rest-errors service. So our service discovery type is going to be Kubernetes. And our service selection, named LotBalancer in the configuration here, is heroes. Heroes was the name we use for the type in our selector implementation. As we said, we also need to configure the favorite universe using the favorite property. So it's done here and my favorite universe is Star Wars. So with this, we build the file service, we deploy it to OpenShift and you will end up with something like this. So this is a complete superheroes application deployed. But we are only going to look at this here. What's happening here? Normally, if you don't use Stalk, what will happen is that the rest-fight application will use the rest-errors service and Kubernetes will handle the lookup and implement a round-robin. Here we use stars that will do the discovery but also the selection. So if there is a Star Wars application, or the Star Wars implementation is available, then we are going to use that service instance. As you can see, at the moment it's not there. We don't have any pods. We only have DC Commits and Marvel. So if we go out the application and new fighters, we have only the two universe. However, if I go back to my topology and I start an instance of my Star Wars, the service providing heroes from the Star Wars universe, now if I go back to my application and I ask for new fighters, I will only get the one from Star Wars because, well, that's a service selection we wanted. If Star Wars is there, I'm going to use Star Wars. So again, if Star Wars is removed for whatever reason, I don't have the pod anymore, then Stalk will react to that and remove it from the selection and we will use another random between the two other instances. So that's all for this demo. So we have seen how you can use Stalk on Kubernetes or OpenShift, or you can customize a service selection.