 Hi, everybody. So I'm Sandy Cash, and the smarter half of us is Dan Levine. And we're here to talk to you about a new feature that we helped design and implement over the last year in Cloud Foundry called isolation segments. And hopefully we're going to do it justice. If I had half of Jules Witt, you might be able to make the connection between Stad of my yard and Garden, but I don't. We're going to talk about the motivation, what led us to design and try to get the feature implemented. A little bit about the approach. We had a couple of, I guess, interesting or at least challenging design decisions we had to go through. Then Dan is going to give you the really interesting part, which is an actual demo of how you use isolation segments. We're going to then move on and talk about a few use cases. The use cases for isolation segments tend to be riffs on a theme, but we're going to go a few through those and talk about how you might apply them in your environments and follow up with some links to further reading. And then hopefully we'll have time for some questions at the end. So why do we need isolation segments? In Bluemix, and I suspect in a lot of other Cloud Foundry deployments, there's often a wish to isolate workloads. And the boundaries along which you might want to isolate those can vary. They could be alongside a 10 if you're a provider, like Bluemix or Pdubs. It could be your tenants. It could be that you want to isolate along the sides of, say, dev and test, or you might have just organizations that you want to keep from bleeding into each other. There are a lot of different ways in which people want to do this. And there have been a variety of solutions for this over the years. One of the primary motivations here is security, though that was really sort of the early use case for this. We had clients who had come to us and say, well, we want to be able to do things like PCI, and things which have very strict requirements on being able to segment the environment. And you have to be able to prove that things are segmented in a certain way. So that was one of the things that kind of got the ball rolling. We also prevent compute resource sharing. You think of it like a noisy neighbor, for example, or just, again, security variation. And the other things, they all relate to sort of security, but they're all at least what we find a lot of times is when you get into security, sometimes it's about the technical stuff and sometimes it's about the emotional stuff. It's about being able to point to something and you can tell people till you're blue in the face, they can't break out of the container. And if they break out, or they can't break out of the app, and if they break out of the app, they're stuck in the container. And if they break out of the container, well, then they're stuck in the cell, and someone will say, yeah, I know, but I got to be isolated. At least that's been our experience. And the last one is also key. We wanted to provide a solution that was flexible. I mean, we don't want to lock people into one model of deploying Cloud Foundry just because we've come up with something that we think works. And yeah, this is sort of obvious. But previous, before isolation segments, Cloud Foundry didn't really have any support for workload isolation. There had been proposals that had come forward. Most recently, before isolation segments, a proposal had come forward for what you may remember is Diego elastic clusters. And there had been other things like placement pools had been a proposal at one point in the community. So there've been a number of proposals brought forward for this, but nothing had ever really gained its sufficient traction or effort to make it real. I think we all know this, all cells or previously all DEAs, it's one big fat pool of compute resources and all the go routers have the routes for all the apps. So everything crisscrosses and everything lands in one big pool. So CF isolation segments, they're your new friends. Again, two big things we wanted from the get go was simplicity and flexibility. From the very start, we wanted to make them as easy to use as possible. There were a lot of things we could have done, but as we were going, as we were exploring them, things got complex really fast. It's really easy to come up with a rushing nesting doll type solution that just is unnecessarily hard to use. And we also wanted to make it flexible and we're gonna talk a little bit more about the flexibility in a couple of slides. They're really creating an isolation segment is honestly is almost trivial. It's one post request to actually create it that creates an isolation segment in the CCDB, just an object. And then you just put resources into it by, I'm gonna paraphrase here because it's actually slightly more complex for go routers than it is for Diego cells. But if I just limit the discussion Diego cells, you simply attach a tag to each cell that you wanna be in the isolation segment, do a Bosch deploy and away you go. You now have an isolation segment with cells. Yeah, so it's really essentially two steps to get stuff into your isolation segment, have resources available for deployment. So it's fairly trivial. And if you wanna remove them from isolation segment, remove the tag, redeploy it. If you wanna move them between isolation segments, if you wanna resize an existing isolation segment, change the tags, redeploy it. There's a theme here. And the resources associated with isolation segment, they're only going to host traffic for that isolation segment. It kind of seems kind of obvious, but I just wanna underscore that. So the isolation is very strict. There's no sharing. All the cells within an isolation segment, they'll only host apps that are pushed to that isolation segment. A couple of sites will show you what the path is by how the isolation segment gets assigned. How does an app know where am I going to land? And likewise, if you have go routers that are tagged for an isolation segment, they'll only be able to route traffic for apps within that isolation segment, and they will not be able to route apps that are not in that isolation segment. Last point is a point, the second to last point, is really one of the key points that we wanted to pursue. I mean, early on, we looked at a couple of ways for the UX. We wanna make this CF push dash segment or something, but almost by accident, we kind of landed where we did, which I think is really the best possible place is the app developer doesn't need to know isolation segments exist. They have no need to know they're there. A CF push today is a CF push tomorrow. Whether you got zero segments, one segment, or a thousand segments, a CF push is a CF push is a CF push. And I'd like to pretend that this was some plan of ours from the start, but honestly, we kind of backed into it. By happenstance, I think it happens to be the best possible approach. And then the control plane, and this is one way in which I think we differ from the previous solutions, is that the control planes all shared within a single foundation. One thing that people have done, we've done it, and others have done it when they want to have resources dedicated to, let's say, a tenant or to an organization. They've deployed multiple foundations. So they'll deploy a Cloud Foundry Foundation for over here for this organization. They'll deploy one over there for that organization. You know, this becomes expensive and complex, not just in terms of the resources used, but just operationally, it's hard. So we wanted to share as much as possible. So we've pushed the shared control plane as deep into the stack as we can. At the end of the day, really everything but cells and go routers is shared. So just to make this clear, you know, before we had many foundations, and then we had one control plane with isolation segments, and you can tell because the boxes are smaller that they're much simpler. That's a direct correlation, known fact. Okay, so the other thing that we kind of like, I mean, I'd like to, there are things I like about this and things I wish we could have and should have done differently, but one of the things I really do like is the flexible model. And then a couple of ways. One is the independence from physical topology. Talk about that in a moment. The other one is the flexible way in which you can actually use isolation segments. So the sort of the primary role that, primary use case that most people think of is I have organizational tenants, you know, I have multiple organizations, and I will give each one an isolation segment that is their resources. And that's definitely something you can do. You can give each organization an isolation segment and they'll only ever push to there and nobody's stuff bleeds into each other, but it's not the only way you can use it. You can give one organization many isolation segments and let them choose how to use them. You can have an isolation segment that, for example, represents a certain tier of service. Maybe it's got faster compute nodes or something, and you can share that among organizations willing to pay for the privilege. You're not locked in any of these models and the fact is you can actually mix and match them within a single foundation. So nothing locks you into one way to use isolation segments. We kind of like that. And then the org managers, once they've got an isolation segment, once they have access to that from their organization, they can then choose how they want to use them. All the admin does is, he says this organization is entitled for it. And that gives that organization access to that isolation segment, but it doesn't force them to use it. It doesn't mean that's the only thing to which they have access. The org manager can then decide, do I want to sign isolation segments at the level of spaces? Do I want to have something that's in my organizational default so that any space that I create that doesn't have a specific isolation segment will just land there. Once again, it's a mix and match model. Different organizations within the same foundation can choose how they want to use them and they're not locked into it. I mean, it's pretty flexible and so we kind of like that. And again, now this statement, I will just give you the caveat up front. It's more true of compute isolation than it is of network isolation. When you get into go routers, you get into having create networks and you do have to worry a little bit about VLANs and your address space. But for cells, this is completely true. There is no tying to physical architecture. So one of the questions that we get periodically is, well, what do isolation segments have to do with available building zones? For example, the answer is nothing at everything. You can have your isolation segment span all of your availability zones. It could be one isolation segment. On the other hand, you could take an availability zone and chop it up into isolation segments. Or you could have an isolation segment that spans parts of availability zones. Again, it's a completely orthogonal concern at the compute layer. At the network layer, again, I don't know if we're gonna demo, do we demo? No, we're not gonna demo this, but we can discuss it with you afterwards. And I'm sure Shannon would be happy to talk with you for hours about it as well. When you provision an isolation segment that includes network isolation, again, you do have to worry a little bit about the topology because you have to create a network in Bosch and then attach the go routers, have to be in that network. And it's not as easy to make it completely independent. But it is somewhat independent. All right. So, whoa, there was supposed to be groovy animation on this slide and it said you got everything at once. So apparently I really suck at PowerPoint. News flash. Okay, well, I'll just talk through this anyway. God, I was really disappointed because I spent a lot of time on this slide. In any case, so you have an organization. And what I was gonna show you is you have this, God, I'm really bummed. So you've got, what we start off with, I'll pretend it's animated, I'll talk as if it were animated. So you begin with an organization and you begin with some cells. And the organization has spaces. This is the way the world works today. And if you push to a space, could land in a cell, you don't know which one ahead of time, unless you're smart enough to be, to fully understand in real time, the way the Diego does scheduling. But having said that, it's just gonna land on one of N cells. But then what you could do is you could come along and you could assign a placement tag to that cell and do a Bosch deploy. And that cell that exists today, all of a sudden becomes part of an isolation segment. Now, you don't actually have to have created the isolation segment using the CC API. But once you tag a cell, it will only take pushes, it will only take apps rather that are carrying that tag with them. The tag is assigned within the cloud controllers as part of staging and starting. But once it, so once we put the tag on that cell, if you haven't actually created that isolation segment, no apps will ever land on that cell because the isolation segment doesn't exist in the cloud controller yet. So the second step, and it doesn't matter, the order is to be honest is not important. You can tag a cell and do a deploy, it'll just sit there idle and unused until such time as you create the isolation segment. So there's no strict ordering here. You go along, you create your isolation segment in the cloud controller and then boom. Now you've got an isolation segment contains a cell. No one will be able to use this yet because you have to entitle somebody for it. So thus imagine that orange line springing into existence, that's entitlement. So I entitle an organization for it and now I've given that organization access to that isolation segment, but still nothing they push will actually land in the isolation segment, not yet. All I've done is given them the rights to use it, but they haven't actually made a decision to use it. So the next step that would be that the org manager for that organization would come along and go, you know, I've got some developers and I want them using that isolation segment. So what he would do is he would assign that isolation segment, I won't say what he would do, but what he does in this case is he assigns that isolation segment specifically to space A1. And now any space developer who pushes, who targets and then pushes to space A1, that app will land on that cell and only on that cell, never on any other cell. And no, and any app pushed to another space like space A2 will never land on cell one up here. Now, one day he comes along and says, well, you know, I need some more stuff I've got. I wanna have 50 spaces, but I don't wanna assign individual isolation segments. I just want them all to go in an isolation segment that's mine and mine alone. So as the admin, I come along and I have another cell that happens to be lying around. I tag it with Y, I create the isolation segment. And then once again, you can imagine that bottom orange line springing into existence as part of the animation that doesn't actually exist. And now I've entitled the organization for that isolation segment. But once again, just as before, no pushes will actually land there, not until the org manager does the step of setting it as its organizational default. So that's actually an operation in the API. I think it's a patch on the organization. But we also have, I believe, CLI support now, which we did not initially. So Dan and I were doing all of this via the API originally when we were developing it, but I believe now there's actually pretty robust CLI support for it. So he would set the organizational default and then any space, such as space A2 or any space created subsequently, any space that already exists or spaces that he creates subsequently, pushes to those spaces will automatically land the apps in cell number two. And once again, all the developers doing is he's targeting, as far as he knows, all he's doing is targeting a space and doing a CF push. He doesn't actually have to know that all of this stuff, all this plumbing exists under the covers. And at this point, Dan, all you. All right, thanks. All right, so for a quick demo, I figured just kind of go through that process of seeing these isolation segment cells and actually making sure that things land where we expect them to land. So currently, I have Diego deployed with two cells. And we take a quick look at our manifest workspace. All right, so if we take a quick look at our boss shambles for Diego, we look for the cell properties. We see that we have cells E1 and it currently has a placement tag of nothing. So this in turn, essentially saying this is a shared cell that any spaces or organizations that aren't tagged, all the apps are able to land there just fine. But if we go and we look at cells E2, we see that it has a placement tag called demo segment. So for this example, to actually use this cell, I'll have to create the demo segment, isolation segment, and then go through the entire process that Sandy was talking about earlier. And kind of to coordinate all these different spaces and organizations, I created a little sticky and just kind of write down a few notes as we go along because switching around, right, there's a lot to look at. So cell two has got a demo segment in it. And we can kind of just close that. Let's make that a little bigger too. All right, so before we get started, let's take a quick look at our Bosch VMs, right? If we wanna know where these apps are gonna land, we gotta know the IP addresses of the cells that we're taking a look at, right? So cell Z1 is there and two is under it. And so we got an IP address of 10, two for four, 16, four. And the other one is 18, two. All right, then we'll kind of bring that back up to the top. So right now, there should be a fresh deploy with really nothing there. So we're gonna go ahead and create an organization. So just see if create org, let's call this no, isolation, segment org. And we'll just tag this as well. All right, target that org. And then of course, right, we need a space as well. So CF, create space, kind of be pretty verbose on that naming, but it makes it so each, you know, shouldn't be getting lost. So no, isolation, segment space. All right, and there's no isolation segment here. So if we were to just push an app and my current working directory is everyone's favorite app, Dora, that's been used many times for many presentations. So we'll just do a CF push after I target. CF, oops, why is it create? That's rude. Okay, there we go. All right, so CF push of Dora. And I think it should be pre-populated. So Dora should be pushing pretty quickly. And once it comes up, we should be able to verify that the app lands on this first cell. Currently for all of this work for isolation segments, I don't believe that there's a way to actually see if apps are placed properly, unless you kind of know the IPs of the VMs that you've gotten with like these tags. But if you're getting the dedicated resources, right, hopefully maybe they could give you the list of IPs and how things are tagged. So if we take a look at Dora, we're gonna curl it. So CF curl, B2. Apps. And then in here, let's get the GUID for Dora. And if we look at the stats, we can see by this line for the host's IP, we can go back to our little cheat sheet. And we've noticed that it's been pushed to cell one properly. So that's pretty nice. We can guarantee that, right? And so the same should be true for any cells that get these isolation segments. So we're gonna just go through the process again. So of creating our orgs and everything. So CF, create org. So create my org, create my space. I don't, that's different. So you have target, yes. I could probably copy that. Those quotes probably shouldn't matter. All right. So with that, all right. So now we got isolation. All right. And now we actually have to go through the process of creating our isolation segment. So it's pretty simple. Using the CLI, just much nicer than when we were using straight curl. So we can just CF, create isolation segment, I believe. And we go back, I called it demo segment. So sure, demo segment. So all right, we've got our isolation segment created. It's not currently attached to any orgs or spaces, right? So now as an admin, I'm able to come along and actually enable it, which is this guy. So I'm going to call CF enable isolation segment, right? And I'm going to give it the actual organization name first and then the depth segment. And so this is now allowing the organization to use that isolation segment. But if we were to do a push right now, we would notice that our app would actually land on cell one, which is not what we wanted, simply because it's enabled, right? It's not being used. So we either have to update the default or set the space. So we'll just go ahead and set the space to use this isolation segment. All right. So just like the set org, set space, now just takes the name of the space in the segment. And if we were to do another push, see a push, ISO Dora, we would notice that Dora lands here. As part of this, there's this note that comes up from the CLI, which is pretty important, where if you already have running apps in that space and you've now enabled and set an isolation segment for it, you have to go through and manually restart your apps. Because if you don't, they could be running where you're not expecting them to be running, right? So this is kind of why when I was doing this, using the sheet, right? Can actually look at the stats endpoint for your apps to actually tell where they're currently running. And we'll just give it a second as it comes up here. So cool. We got our second Dora app up and running. And if we go back to our curl, we can look here now for ISO Dora as our new app. And if we look at our host line again, we'll notice that it's at the 18.2 IP address, right? So it's been on cell two, right? And so this is kind of the way you can guarantee where apps land and kind of a way to check that you know where things are actually running, running where you expect them to. Unfortunately, we're running out of time, but if you were to then create, another scenario would be if you create a bad isolation segment, you shouldn't even be able to get to this staging process if you have a space that's using it because staging and running guarantee that these segments place them properly for all the running components. And with that, I'll hand it back over to Sandy. Thanks, Dan. So there are still some things that are not yet there. And you heard Dan talk a little bit about one of these. I'll just jump to it. It is a little tricky once you've pushed an app to divine, did it actually land in my isolation segment? Or the sort of the other side of that coin is, if I have an isolation segment, what apps does it actually contain? You can piece the information together from existing API endpoints. It's definitely doable. And it helps if you actually know the IPs of the cells, as Dan demonstrated. One of the things that would be nice somewhere down the road, maybe, and I don't know how doable it is, is to actually have atomic endpoints where you could actually query for this. But there's some limitations on that. For example, we don't actually persist the isolation segment as a field on the app. It's just something that's carried in the message when the app is sent to Diego for staging and starting. So, for the time being, we kind of live this limitation because as Dan demonstrated, you do have a way to get this information. It just isn't the most straightforward. But I think that's one thing that I wish, I think we wish we were a little more straightforward, but it's doable and doable is better than not. Jumping back to the first bullet, originally when we brought the proposal for it, the idea would be that we would have, sort of at all three tiers of the runtime, we would have isolation. We'd have compute, network, routing, and at the logging tier. We still, we haven't gotten to the logging. Shannon and his team did a great job getting the routing stuff done. That was only GA'd recently after having just incepted on it a few months ago. So I was really stoked about that. Probably one of the next steps that we'll do is sit down and have a conversation with the logger gator team. And probably until today, they weren't even aware this conversation was gonna happen about, can we possibly look at some point at doing logs isolation? And one of the reasons why this had to get sort of kicked down, this far down the road, is that it actually had a dependency on getting the other ones done first. So those are some of the things that aren't there yet that they would like to do. Touched on these use cases a little bit beforehand, and as Dan said, we're getting a little short of time. So just gonna jump through them a little bit. Tenet isolation is sort of the obvious one. That's the one where we started. Tiered offerings, again, if you're a provider, have an isolation segment where there may be as better service, faster compute, whatever. Solution tiers, platforms, I mean, there are a lot of things. I wanna have my, this may be a little bit artificial, but I'm gonna have persistence here, or I'm gonna have web front ends here, and I'm gonna have business logic here. Again, I may be pushing the boundaries of edge cases a little bit, but use your imagination. But one that we like is also dev test promotion. For example, I'm only gonna give my developers access to here, and then if you have this kind of pipeline where you've got different organizations that have access to different test environments, it's pretty easy to stand those environments up as isolation segments. And having said that, I don't think we got a ton of time left, but yeah, we have almost, maybe a minute or two for questions. Oh yeah, I jumped ahead, but yeah, so these are the doc URLs for both managing isolation segments. That includes pretty much everything you need for compute isolation segments. Is that that URL? Literally just about everything. And then routing the deltas for that or in the second URL. And we're just about out of time, but let's see if we've got time for just a couple of questions. Yeah. Are there any? Yeah, so that would be some of the loggergator components eventually. But again, those, we haven't even, when we first started, we kind of, we all, I mean, all of us knew. I mean, we had two inceptions. We've had two, one for the general proposal, one for the routing. There was kind of an unspoken consensus, the room that this was a little bit more complicated than the other two. So we really hadn't even done deep design work on that yet. But the next obvious tier is logging, because a lot of customers, when they want this, they also want to know, they may log some fairly sensitive information. They want to know that that logged information is not going to be commingled with somebody else's. That's the next obvious one. Yeah. By managing you referring to the adding or removing of capacity from an isolation segment? That's right. I mean, I mean, I don't know. I'm not sure by normal. I mean, it's the way it works. And so I guess it, yeah, it's normal because it's the way it works today. Yeah. I mean, for now, for, I mean, for now, that's the way we do it. But right to do it the other way, right? Essentially doing an API call, right? You'd essentially have to have some way of either being able to talk to CC and then it communicates to the Diego cells and tells them what to do, or you would be able to maybe publicly expose the Diego cells. But that's also, that's like a weird concept, right? You wouldn't want to do that. So I don't know. This way it just seems. Right, you'd have to have, right. I mean, one of the things, so remember, we, you know, we tried to start off as sort of, you know, working from a KISS model. And so we wanted to put as little information in, for example, into the CCDB as possible. The only thing that's there is there's an isolation segment. It's got a good and a name. That's all it's got. And what we didn't want to do is end up sticking things in there. I mean, you're right. You could sort of proxy the call through to the BBS, you know, as far as in have some sort of mapping in the BBS. But, you know, we haven't gone there yet. I mean, for now, it hasn't been a real problem to have it be a deploy time consideration. You know, it's not, you know, you just do a redeploy. It's not really that much of a pain. And once you, you know, the other thing to think about is how often are you really gonna be doing these operations? And once you've stood up an isolation segment, sure you might add capacity to it from time to time. But I would venture to say, at least in my experience, 90% of the time you're doing stuff through the CC, you're doing the enablement, the entitlement, and the assigning to spaces and setting up defaults. So that's kind of where we focused as far as, you know, what we want to have in the CC. Good question. Yeah. So it's at the level of, it's basically at the level it is today. So what forces the developer to push there is by virtue of, if you had a developer and I went, that developer will only be able to push to this more secure space. I would only make them a developer in the space that was assigned to that secure isolation segment. As long as that's the only place that they can target, that's gonna be the only place they can push. Let's go to the right side of the room just for a sec. Well, I mean, if the developer knows which spaces to target in which cases, sure, I mean, if I'm a developer and I've got, you know, I have access to two spaces, no, not today. Yeah. I think the thing to keep in mind is that we didn't actually implement a new permissions model for this. We simply used what was already there, which is, you know, it's determined by your role within an organ of space, determines what you can do. You know, we didn't add anything to that. We simply said, well, oh, there's a space. We'll associate an isolation segment with it. So if you can push to a space today, you can push to it tomorrow, whether or not it has an isolation segment. So we weren't actually trying to change permissions model. I think that having permissions by apps would be something that might have scope that would extend beyond isolation segments. I think that's potentially a more fundamental change to the whole cloud controller permissions model. So that, I mean, that's not, I'm not saying it's not a discussion to be had, but I'm saying I think that's something that's potentially bigger than just isolation segments in terms of the impact. So that's, you have that today. So what you do is the developer has access to two spaces. Each space points to an isolation segment. Mm-hmm. What about the publication? Okay, yeah, I mean, you know, once again, you know, the ability to say, to have the developer target within a space, again, I think that it goes beyond, again, we were trying to keep the same, the existing user experience. You know, that would be something I just think that's, again, once again, it's one of those things that's an interesting thing to discuss. It just has impacts that go beyond isolation segments. Yeah. Yes. Yeah, you have to have the ability to update an organization's properties, which is an org manager thing. I think we're well over time. So I think I hate to say it. I'm gonna call it quits to questions so we can hand things on, but thanks you all for coming.