 So we can start. OK. Hello together for the last slide and last talks this day. Today, I hope you enjoy the last talk of the summit, as well as we do. My name is Christian Riecker. This is Janneke Rehmert. We are from Iwola, and we're talking today about providing service access with service keys using HAProxy and floating air piece. And like Julian, we wanted a full slot, got 10 minutes, so we decided to let the floating IPs part out of it because it's not the main reason we want to talk about. So what problem do we want to address? If you looked about the open service broker API talk of Alex and Matt today, you get to know how service brokers are enabling the Cloud Foundry ecosystem to use data services out of some point, but do not care about where it is deployed or where it's running, you only get to know how to use it. And what it's doing is if you have your user and you're accessing your cloud, your service, you're going to the Cloud Controller using the CFCLI and saying, I want a new service and I want to bind an application to it and with a CFBindService command, and then the service broker is called by the Cloud Controller, gets some access to your service, which is deployed. I don't know, I don't care in case of the Cloud Foundry, and then sends credentials to your application. But in some cases, you come to the trouble problem that you have to access that service directly, maybe for troubleshooting, a database or something. And then how to get that? Because you don't know where is that service deployed to and how to access. So there is in the open service broker API that trick called service key. You can, instead of create service binding, you can say create a service key, which means that the Cloud Controller goes to the service broker asks for credentials, but instead pushing that to your application, it pushes to you. And there are some problems with it, which Janik will talk about. So it may be that the service instance is only deployed in a private network, and you can access it with a service key, and then you can come to the great idea to give your service instance a public IP, but the next day your CTO calls and doesn't agree with your great idea, and you have to go back to this. And again, you're thinking about a way to get connection to your service instance from the outside, and you can't access agent to an application instance and go on from there, or could deploy jump hosts. But it's all a big hassle, and nothing seems to really be a good way to connect to this database. So we came up with this, which is basically we gave our service broker a remote control to an HA proxy config. So now if you create a service key, in addition to creating a new user and password on the service instance, we also talk to our HA proxy back end. We provide this HA proxy back end with the internal IP of the service instance, and the port, which is service instance, is running. And the back end pushes a new message into an RabbitMQ, and a Python program called the HA proxy agent gets this message, updates the HA proxy config, and after that, you get back the public IP of this HA proxy and the part that is binded to your service instance. And now you have a public available service instance without the service instance being accessible directly, and after you delete the service key, the accessibility is also gone. One interesting thing with this also is that it's because it's an HA proxy, it only has one public IP for many services maybe, and you have also the possibility to use access controllers to manage who's able to access it. So maybe only you can access this with your personal computer because the IP address of your personal computer is the only one who can access it. It's also something you can do up within the internet instead of an internet thing. So no other user in your internet is able to access your database service or something and such. Also, what you can do with a setup is think about not managing one HA proxy, but a cluster of HA proxies, for example, or you can make some distribution calls like you have groups of HA proxies and you can manage it. There are several HA proxies with the same setup because we have some kind of agent management thing about there. And what you can also do is use this setup for several service brokers at the same time. So you have one managing system for the HA proxies, which can be called by several service brokers at the same time, so you have the possibility to come across that central infrastructure point for several services. And you save public IP addresses because in that old setup, you had to make public IP addresses up for every service instance. Maybe for one service instance, several IP addresses. In this setup, you can share the HA proxy IP addresses because you can use port forwarding there. You're managing ports instead of IP addresses. And you can do HA setups in front of to manage load balancing things in the access from the outside. And the cool thing is it's all open source. You can access it. You can look into it. We are happy for your contributions, your inputs, your ideas, and where we're happy to hear about it from you. And that's the thing. I hope you had a fun CF Summit. We had it. And maybe see you next year on the CF Summit in Boston. Travel safe.