 Hi, everyone. It's 2.45, so we'll get started. You're here to hear updates from the CF Networking team. It's a project update. We'll be talking over the next half an hour about what we've been doing and what are some of the new changes that you can expect from us going forward. I'm Usha Ramachandran. I am the staff product manager at Pivotal, and I am the PM responsible for CF Networking. I'm joined here by Angela. She's an engineer on our team and the current anchor for the project. So none of this would have been possible without our team members. This is just our current team, but we've had many people who've contributed to this project, some of whom are here today. So it'll be exciting to share what all we've done so far. What we have on the agenda today is basically just do a very quick recap. None of this should be totally new to anyone around the networking challenges that we have today with Cloud Foundry, and then how we've solved those with CF Networking, and then we'll do a deep dive into how things actually work under the hood, and then a demo, and then we'll talk about upcoming features and what it looks like in the future. If we don't have time to get to questions in the session, please feel free to stop by after the session, or we have office hours tomorrow at 11.55 as well. So let's start with the networking challenges that we set out to solve for. So if you look at the legacy Cloud Foundry networking model, it basically uses a host mode networking where every single container basically just uses your cells, IP address, and traffic going out from an application is basically netted out. So what this means is that your traffic really, you've lose all your app identity as you go out. In addition, there's no direct communication between any containers. It always has to go through the load balancer and the router. So this means that if you have private microservices, you still need a public route. And so this may be a security hazard for some environments. In addition, you can't really apply policy at app B, which is your destination, because you don't actually know where your traffic came from. It just appears as if it came from the router. So those were some of the challenges that we saw, and that's why we started working on CF Networking. Our idealized stage was basically to have direct connectivity between containers, where you didn't have to go out through the go router and come back in, making the traffic path more effective, and also have policies that are basically app-to-app policies, so not have application security group like policies where you have an entire org or an entire space basically being able to access things based on IP. So that's kind of the vision of where we want it to be, let's have apps talking directly to each other in a policy-driven way. So that was maybe a year or so, maybe a little more than that since we started working on this. Today, we basically have CF Networking 1.0. It's been out since about June, and there were a few things that we delivered on, which is, firstly, every container now has an IP address, so there's direct C2C connectivity. And we used the container networking interface, which is a standard, and I'll talk more about it in the next slide, to implement this, mostly so that we could allow third parties to come in and plug in like a more sophisticated SDN vendor, for example. For our batteries included solution, we developed our own CNI plug-in called Silk. We started off using Flannel. Silk is very similar to Flannel, but it uses MySQL or a SQL-based database as its back end. The other core feature that we wanted to deliver was to move away from IP-based policy to have app-to-app policy. So as an app developer, or as a network admin, I can go in and say, hey, I want this app to talk to this other app, and it should apply dynamically, as well as be completely driven by application intent and not be like IP-based. So you now have the ability to configure, either through a CLI or an API, a policy. And it's completely self-service, so you can either have a network admin who does this, or you can grant safe space developers the ability to configure their own policies. And we'd love to hear if there's one model that works better for you or the other. There are some things that we didn't change, but these are things that we would look forward to changing in the future, which is how can we make application security groups better. We also didn't change the traffic path through the go-router or the traffic path going out, so both of those traffic paths still use NAT. And those are things also that we are looking at to see how we could improve those traffic paths as well. So I'm going to spend just a minute talking about CNI and why we adopted CNI. So CNI is an industry standard that lets any container runtime delegate its networking responsibility to a CNI plugin. So it defines a standardized interface. And so by adopting CNI, you now have the ability to run any networking stack that you want on Cloud Foundry. So you're no longer bound by how Cloud Foundry only offers this type of networking. So that's basically why we chose CNI. For our batteries included CNI plugin, we went with a very simple model. We use a VXLAN-based overlay network that gives every single container an IP address on it. And the way it works is that there's a whole big range. It defaults to a slash 16. Every cell gets a slash 24. So that's about 250 containers, 250 cells. You can tweak that around if you want more or less scale. The idea here is that all your container communication is on this overlay. And all your container to external communication is on the underlay. So there's actually no mixing of traffic between these two layers. In terms of policy, we made a conscious choice to actually define policy at the app layer. So as a user, you would go in and say, I want app one to talk to app two. And once you configure that, that policy is applied and they're able to talk to each other on the overlay. So Angela will be doing a demo showing you how this actually works. As your apps move around as they're like brought up, brought down, the policy is applied automatically. So this is the advantage of not having an IP-based policy because your IP addresses are going to be ephemeral. So that's the policy aspect of what we've built. That's the policy config. We recently got into this main CFCLI. So that's really exciting to us. Before, I think, September, you had to download a CFCLI plugin and then use the networking commands. Now you can just go to the CFCLI and these are the commands. They're very simple. I just want to call out a couple of things. One is that you can use TCP as well as UDP. So if you have UDP use cases, you can now enable those with container networking. The other important thing is you can use any port that you want. You can use multiple ports as well. And the policy will enable you to configure multiple ports within a single policy. So it just opens up the doors to having many different types of applications that can run on Cloud Foundry. So let's talk about some use cases. Why would you use this? There are two key use cases we see. The first one is just building more secure microservices. So if you have microservices that you don't want to expose to a public route, you want to enable direct East-West communication for maybe improving latency, improving performance, and also the ability to configure fine-grained app policies gives you a lot more control over which microservices talking to which other microservice. So it's not a broad, like, hey, allow anything to talk to anything, but it's really, I want my front end to talk to my building and nothing else can talk to it. The second big use case we see is for apps like Acca or Hazelcast or some other applications that need more of a clustering mode where you need to know every other instance that's part of your app. So that's another use case that you can leverage with today's solution of container networking where you have to bring your own service discovery. These use cases are a little bit more cumbersome, but we are working on new enhancements that should make that pretty easy as well. And again, here, the ability to communicate over TCP or UDP really helps you out. So I'm going to shift gears a little. This is a project update. It's not specific to the CNI implementation or the new container networking stack, but we did make a lot of enhancements in how traffic is logged on Cloud Foundry. So one thing we kept hearing was that I have no idea what happens to my deny packets. So we added the ability to log denies. We basically allow you to enable global logging, and so you can get a full view of whatever is going on in Cloud Foundry with respected traffic. The other enhancement we made was around just adding the app, space, org information to these traffic logs. I don't know how many of you all actually look at traffic logs to be able to debug problems on Cloud Foundry? OK, not so many. OK, so we've heard from operators that not having your app information in the logs makes it really difficult to actually be able to take a log and trace it back to which app actually sent out that traffic. So with this feature, we hope that it'll become a little bit easier. So we're going to now shift into looking at how this all works, and I'm going to hand it over to Angela. Awesome. So now we've seen all the features of container networking, and you might be wondering, how does it actually work under the hood? So here we have lots of boxes. This is an architecture overview of the control plane with CF networking. So the colors are significant in this case. Everything that's blue was a control plane component of Cloud Foundry prior to the introduction of container networking. The components in green are new core components of Cloud Foundry, and the components in red are new swappable components in Cloud Foundry. And so the distinction between the red and the green is mainly that third party vendors who might want to bring their own CNI plug-in solution will need to integrate with the green components that can ignore everything in the red. So if you wanted to bring, let's say, Calico or NSX to the platform, you would need to integrate with the green but not the red. So now let's actually dive into this. So the workflow now in the control plane is when an app pushes an app, the app's information gets sent to Cloud Controller, which passes it down to Diego. Diego then decides we're to schedule the application and sends that information along to the rep for the given Diego cell. The rep then calls Garden Run C using the Garden API in order to create the container that the app will run on. When the container is being created, Garden Run C will call out to our new core component, the Garden External Networker, via the Garden External Networker API. And so the Garden External Networker is doing a couple things. It's doing port mappings from the Diego cell to the application port. It's also doing some mounting of file systems. But most importantly, it's taking the information past to it from Garden and is transforming it into information that abides by the CNI API. So this is how we're able to have swappable components. So the External Networker will call out, using the CNI API, to our CFRapper CNI plugin. CFRapper CNI plugin does two things. First, it sets up legacy rules. So it takes care of everything relating to D NAT, SNAT, and application security groups. And then it also calls out to Silk CNI, which is what is actually setting up the container's unique IP. So how does Silk CNI know what unique IP to allocate to a given container that's creating? Well, Silk CNI calls out to the Silk Damon, which is a process running on the Diego cell. And the Silk Damon will call out to a controller. The controller will let it know what cider range the cell has. And from it, Silk CNI could determine what IP it can give the container and set that up. Now, when you actually want to configure policies, the app dev can call out to create a policy, either via the CLI or API. This policy information gets stored in the network policy server, which is another new core component. The policies are actually written on the Diego cell via the policy agent. So the policy agent currently pulls out to the network policy server in order to find out all the policies that are applicable to apps on the cell. And it knows what apps are on the cell because it receives that information from the CNI wrapper plugin. The policy agent will then take that information and write the relevant rules in order to allow traffic between apps that policies have been created for. So that's the control plane. But how do packets actually flow? When I have app A and app B and I configure a policy, how are we actually applying that policy? How are we making sure that traffic is flowing from app A to app B? Well, we can look at this case here, where we have two apps. In this case, on different Diego cells, but it could be on the same one. And we have app A sending out a packet to application B. This packet has the source IP and the destination IP as the container IPs, so the ones that were uniquely allocated to each container. Then the packet gets encapsulated before leaving the Diego cell. And it gets encapsulated in a packet that has the source and destination as the source and destination IPs of the Diego cells that app A and app B live on. When this packet arrives on the Diego cell of the destination container, we then check whether or not this packet should be allowed. And we do so using VXLAN GVP headers. And we assign tags in each of them in order to know whether or not it's allowed. So we're using IP tables rules that are set up by the VXLAN policy agent. Assuming it is allowed, we will pass it on to application B by de-encapsulating it and letting it take its normal flow. If it was not allowed, the packet would then be dropped or denied. So with that, we're going to do a quick demo of how you can use container networking with Eureka. So let's see if I can set this up. So in this case, we have two apps that are currently deployed. We have a homeowner and a visitor. The important thing to note here is that the homeowner app has no external routes. So it's only reachable via the container network. You can't reach it from the public internet. And the visitor, however, does have a public URL. If we look at CF network policies, we see currently that no policies are configured, which means that when we look right here and we refresh, we see that on the visitor page, no one's home because there's no policy configured. So now if we add a policy, a network policy, from the visitor, so the visitor is a source, and the destination app is the homeowner, over a protocol of TCP and a port of 8080, which is the default application port, then we should see that we can now enter a visitor's name because we've allowed access from one to the other. So if I say, Angela, you get some nonsense. That really doesn't mean anything. But we demonstrated here the basic functionality that a source app can talk to a destination app that's not publicly routable and is using container networking. And this is done with our service discovery method of using Eureka in case you were wondering how it knew what IPs to hit. So let's just underline implementation. Oh my god. And with that, I'll pass it back over to Usha, but I don't know where I am. Awesome. Thank you, Angela. So that demo basically showed us how container networking works today. And it was deployed on PWS where we have a service registry that's been deployed, that's been bound to this app. And so all the apps basically register with Eureka. So what I'm going to be talking about next is basically what are some of the upcoming features and how are we going to enhance container networking. If there's something that you'd like to see here that you don't see, we'd love to hear about it to see whether we can prioritize these things. So before I get into what we're building next, I'm going to talk a little bit about the timeline. How many of you here are hearing about CF networking for the first time? Great, no one. OK, good. So then you must know that we have been working on this project for a while. We released our first version in November of 2016. We were called Netman Release at that point. And we used Flannel as our overlay network. And as Angela mentioned, we used group-based policy for enforcement. We deployed to pivotal web services and also went beta with PCF in version 1.10 of PCF. And we found that there were some operational challenges that we faced when we were using Flannel. And so that led to us actually implementing Silk. And we also thought that, oh, we don't like the name Netman Release, so let's just rename ourselves to CF Networking Release. So we are now CF Networking Release in May of this year. And we actually go GA in June with the 1.0. And we also made it the default stack for PCF 111. It could still be disabled, though, if you wanted to go back to your host networking mode. So fast forward to September. We are now out of incubation. So that was a big milestone for us. We are now part of the core active projects. And we're also shipping. We're still GA. We're now the only option on PCF 1.12. So starting from almost nothing a year ago, we are now pretty much ready for everyone to use. So what are we going to be working on next? Some of you may have seen a feature proposal from us that was sent out a few weeks ago. And we're working now on an initiative for actually providing platform service discovery. And what does this mean? So in the demo that we just showed you, we saw that the visitor could find the homeowner just because it had this external Eureka server that it could use for a lookup. But without this external server, applications have no way of actually knowing where their destinations are and how to reach them. And there are two different use cases with slightly different requirements. One of them is the microservices use case, which is basically what we saw, which is that I have a source app. Connect me to any instance of your destination app. I don't care. You should do load balancing for me and maybe do some more advanced features for you. The second is clustering apps. So clustering apps usually need to know every instance and need to connect to specific instances. So that's basically the two different types of requirements that we're trying to fulfill with our current feature. So what does this look like? And we are looking for feedback on this. So if you have feedback, please let us know. This feature is still under development. So our short-term goals are basically to give every single app in Cloud Foundry what's known as an infrastructure name. This infrastructure name is currently the app GUID dot some internal domain. So in the example here, it's like the building app GUID dot CF internal. To start with, we're not trying to make this configurable. Every app will just get this name, and then you can look up your app using that name. In addition, every instance of the app is also going to get a name. So you would have a zero dot building.goid, building.tld. So that's the short-term goal. But what we've heard from users is really that they would like to expose the concept of a service similar to how external routes work, where you can register multiple apps with the same external route. And so that way, you can do things like blue-green deploys or deploy different versions of your app and then load balance across those different versions. So that's the next phase of what we're building. We're going to give developers the ability to configure an internal route for their apps, very similar to how you would configure an external route for your app. And then that route is only visible to internal applications. Longer term, we are looking at integrating with Istio. So the CF networking team, the routing team, as well as Diego and Cappy, we've all been looking at how we can integrate Istio into Cloud Foundry. And so one of our goals is to actually have our service discovery mechanism feed into Istio's pilot. How many of you here have heard of Istio? OK, quite a few of you. So for those of you who haven't heard of it, Istio is a new service mesh open source solution that has a lot of people that are working on it, including Google, IBM, and Pivotal is also starting to invest in it a little more. So that's kind of the polyglot service discovery piece that we're building. Going to take a slight diversion here and talk about third-party integrations. This slide is specific to an integration between Pivotal Cloud Foundry and NSXD. But the idea here is that you could actually have any third party come in and hook into Cloud Foundry. And the benefits that you get from that are basically that you have native container networking on an existing SDN solution. You also have a common operating model for all your traditional apps and your cloud native apps. And you don't have to redo any of your processes or things like that. So NSXD is one integration that's underway. There are other integrations possible as well, of course. So things like Cisco ACI, things like Calico. Anyone who has a CNI plugin should be able to, using our hooks for CNI, come in and integrate with Cloud Foundry. So I'm going to conclude with just a link to a few resources. Our GitHub page is Cloud Foundry, CF Networking Release. We have a whole bunch of examples on our GitHub page. And as we start adding the Polyglot Service Discovery, we'll be adding some more examples to those pages. And then you can always reach us on CF Networking Slack. We're very friendly. And we'll welcome any input that you have. And then a couple of blogs just for you to understand a little more about the feature. That's all we had. I'm not sure if we have time for questions, do we? I think we have time for a couple of questions if anyone has any. If anyone has a question, feel free to ask us. So you discussed connectivity between the apps and the instances. Is there any thought about connecting to a specific instance from the public route? So I mean, let's say you want to develop something. You connect to a public route, and then you want to reconnect to the same instance, not to share the state or for efficiency reasons. Would there be any kind of mechanism that you can discover which instance you connected to and that you can connect straight back to that instance? Yeah. So you can do surgical routing with the go router today. So there is a feature that you can use to continue to connect to the same instance. OK, that's good to know. Any other questions? Does it also work for cross space communication? And since my applications don't have unique names, how does it work then? Yeah, that's a great question. And one of the things about our policy is that it works across spaces, orgs, anything. So you configure it based on the app name on the CLI, right? So the CLI today is only for the targeted space that you're in. But we are looking at ways to enhance that, to also enable you to configure cross space policies. Using the API, even today, you can configure across spaces and orgs, because you just give the API your app good, and that's unique across everything. Are there plans for using also the manifest somehow to do this kind of configuration? Yes, we do have plans to support some sort of declarative policy config. We're looking at it as not just simply adding it to the app manifest, but perhaps a more generic policy across many microservices. So it's still too early. It's something that's on our radar, and we've had a lot of people ask us for that support. It is something that will be upcoming. Any other questions? Great. Thank you all for attending.