 These slides will be shared, but here's Anthony Shaw shared some great little tips that really kind of boil down into three things. Have nice documentation, don't make security so obnoxious that it's difficult to do, and just sensible use of HTTP. It sounds kind of simple, but you would be surprised at how many people get that wrong, and the Cloud Foundry guys did a great job of getting it right. Other things that are helpful, obviously having a nice testing and a mock framework for some of this stuff, and again, the anti-Cloud. Have a local Dev environment so you can cycle some of that stuff really fast, makes a great deal. We'll be doing, Apigee will be doing a deeper talk tomorrow at 10.55. I'll be doing the same demo without a misstep and maybe a little extra fun in there, just a teaser for that. And of course, if you want more info on the services stuff, again, what a great URL, right? Docs, obviously, and then slash services, it's terrific. So that's all I had. Thank you. Okay. Thank you, Carlos. We're going to switch gears a bit and we'll talk about TCP routing. Until recently, I mentioned earlier, Cloud Foundry supported HTTP workloads only, but there is so much software in the world that depends on non-HTTP TCP protocols, and Cloud Foundry is a great place to develop and operate them all. As I mentioned earlier, all of the benefits Cloud Foundry provides ultimately reduces in higher developer velocity and minimizing time to market. With the introduction of TCP routing, we significantly expand the range of workloads that can be run on Cloud Foundry. If you're involved in the Internet of Things, supporting the Internet of Things, your workloads depend on non-HTTP protocols. With the introduction of TCP routing, we can now bring legacy workloads to Cloud Foundry that depend on those protocols. We can even run non-persistent TCP services. Also with the introduction of TCP routing, you can terminate TLS at the application. Here's a look at the user experience of TCP routing. Again, thanks for the CLI team for helping us deliver this. The first step in the developer experience is to discover a domain that supports TCP routing. Here you see the response for CF domains. We have a domain that supports HTTP routing and one that supports TCP routing. After that, it's as simple as pushing your application and specifying that domain. With the use of this random route option, the platform has generated and reserved a port for us and created a route based on that port and domain. How does it work? The management plane, we've introduced a few new components as part of a new Bosch release called the routing release. This is deployed alongside Cloud Foundry and the Diego backend. The emitter component is listening for events on Diego, looking for new routing configuration associated with applications and sending that data to the routing API, which is a new central source of truth for routing configuration for all routers. The new TCP router is listening to the routing API for its configuration. The application data path is much the same as it is for HTTP routing with one exception. That is that the TCP router is making its routing decisions based on ports, not on host names. The domain that a client is sending the request to is used only for resolving DNS to the IP of the load balancer. After that, it's just IPs and ports. The TCP router maintains a dynamic mapping of the route port to backend host IP and ports for application instances. With that, I'd like to welcome Atul Khursagar to the stage from GE. He's going to share with us some of the reasons GE has been interested in TCP routing and give us a demo. Please welcome Atul. Hello. My name is Atul Khursagar, I'm with GE. As Shannon just explained, GE has a lot of interest in TCP routing. In fact, I was here at CF Summit last year talking about why and how we will do TCP routing in Cloud Foundry. It's just great to be back to actually do a live demo of a fully integrated TCP routing feature in Cloud Foundry. Thank you. It was just awesome to be part of the Cloud Foundry routing team for the past one year to actually develop both route services feature as well as TCP routing feature. I'm incredibly happy that this has all come together very nicely. Last year, I presented this picture when I was talking about the motivations GE has in order to get TCP routing in Cloud Foundry. I'm not going to get into the details of this picture this time. All I want to highlight here is that like in any other IoT use case, GE also has interest in multiple non-HTTP protocols. You can see a bunch of non-HTTP protocols listed here. Some of them have fallen out of favor over period of year, even in GE, but some of them are still valid. Let me quickly mention a couple of use cases where GE would be using TCP routing feature that we have built. As you all know, GE already has own platform called Predicts. It's built on Cloud Foundry, and one of our main use cases is to actually ingest data from devices at a very high scale, at a very high volume, using multiple IoT protocols. Now, we are going to use Kafka to ingest, do all the ingestion. Now, Kafka doesn't have support for all IoT protocols, and what we will do like any other team does, is going to build a protocol adapter on top of Kafka. Now, the first time that we are going to build is the MQTT adapter, and we want to develop this MQTT adapter as a CF app, deploy it as a CF app. Why? Because CF is great. It manages my app very well. I don't have to worry about it, but I don't care how. That's why. So that's one use case. And there are a bunch of GE businesses who need to deploy their applications on Predicts, which needs support for proprietary protocols. Now, TCP routing comes in very handy for that, and we will be able to utilize TCP routing to support these non-standard workloads on Predicts. So without further ado, let me get into the demo. This picture just gives a highlight of what I'm going to demo here. And I'm going to try to do a live demo and hope that it works. What I'm going to do here is I'm going to push an MQTT broker, Mosquito, as a CF app. I'm going to create a TCP route. I'm going to bind that TCP route to our MQTT broker. And now using this TCP route, we can use our MQTT publishers and subscribers to publish the data and subscribe the data. Now I'm going to have a web app. That's going to be an MQTT subscriber. And it's going to get the data from the MQTT broker. And I'm going to have an Android app on my phone that is going to publish the data to this MQTT broker. And you would actually see the changes that I'm going to publish from here. Actually I'm going to publish the y-axis acceleration changes of the device to the broker, which would then stream it to the app and which you would see on a nice graph. So let's get right to it. So I have already targeted my CF to our CLI to our CF deployment. And I have created an org and space where we are going to do this demo. I have already deployed an web app, which is going to act as the MQTT subscriber. And that's running here. So we are now going to push MQTT broker, Mosquito, as a CF app. But before I do that, I'm just going to show you the domains that we have created. And you would see here that we have a TCP domain that's been created. Now the way you create TCP domain is very similar to the way you create your regular domains. The only thing that you have to specify is the TCP outer group. And you can see the outer groups that you have in your deployment by using this command, CF outer groups. It lists the outer groups that you have. With routing release deployment, you are going to get the default TCP outer group. And that's the only one that we have that can grow in future. Now we are ready to actually push our MQTT broker. So I'm going to push the MQTT broker using Docker image. I'm going to create a route. And I'm going to bind that route. All that in one command. Any guesses? It's only one command that can do it all. So here it is. I'm going to push an MQTT broker. I'm using the Docker image for mosquito. I'm specifying the TCP domain. And as Shannon mentioned, I'm asking the system to create me a random route. So what this is going to do is that it's going to obviously pull the Docker image from the Docker hub, deploy it. But also it's going to go ahead and reserve a free port from the outer group. Create a TCP route and bind that TCP route to our app. So those steps are nicely logged here. You see that we have created a random route. In this case, it happens to be port 60,055. And it's bound to that MQTT broker. And we have our MQTT broker running as a CF app. It's going to serve MQTT traffic. So now we will shift and try to see how our mosquito brokers and publishers will work. I'm going to run a CLI subscriber as well so that you actually know. So I'm going to use mosquito sub. So the host here is the TCP domain. And we'll specify the port that was allocated to us. It was 60,055. So I'm going to put this side by side. This is our MQTT subscriber app that's expecting the same host name and port. Right now it's not either our CLI or our charts are not showing anything until I put this in my Android app. And as I move my app, you are going to see you have a device talking to an app in Cloud Foundry over a non-HTTP protocol. This is TCP routing for you guys. Thank you. And back to Shah. That was cool, especially for those of us who have spent so much time working on it. For more information about TCP routing and the routing release, Bosch release, here's a URL. I'll post it again at the end. I have a couple more slides to share with you. I wanted to share with you a little bit about what the routing team is currently working on and what we're thinking about working on next. We're about to dive into exploration into performance of the routing tier and looking for opportunities to improve performance. We have a little bit of technical debt we've been punting on for quite a few years. The Cloud Foundry community would really love to get rid of NATS, which is a message bus at the center of Cloud Foundry. We believe that the only remaining use case for NATS is route registration. And we believe that the routing API we've introduced with the routing release has the opportunity to replace NATS. So we'll be looking at doing that this year. We also believe that the routing API as a central source of truth for routing can enable a bring your own router operator experience. We've received plenty of feedback that TCP routing is great. What about all of those UDP protocols? We believe that a great way to provide a new extension point in Cloud Foundry and scale the kinds of workloads that can be run on Cloud Foundry can be done with a bring your own router workflow. We're also looking at weighted routing, which would provide a developer experience such as send 90% of my traffic to version one of my application but 10% to version two and then allow the developer to turn those knobs and cut their traffic over. So that's all we have for you today. If you'd like to get in touch with us and we'd really love to hear from you about the creative use cases you have for routing, please see us after or get in touch with us through our Slack channel. We have an office hours today in lounge number two at 4.15. And here again are those links for more information about route services and TCP routing. Thanks very much.