 All right. Well, we are here today to talk about running.net on Cloud Foundry. You want to jump to the next slide? Yeah. My name is Zach Brown. I work on the Pivotal Cloud Foundry project at Pivotal. And I'm Rita Jang. I'm an open source engineer at Microsoft. So let's dive right in. Cool. So I know a lot of you guys actually came by at our booth in the exhibit hall. And I also talked to some of you guys like just running around. And we get a lot of questions from customers asking, so .net is great. Cloud Foundry is great. How do I actually run my .net applications? Well, this session is specifically to address that. And as an open source engineer, I work a lot with different open source platforms like Cloud Foundry. And what I find interesting is a lot of them are great, but Cloud Foundry is one of the very few platforms that actually supports .net applications. So for an enterprise like yourselves, you probably have the traditional .net applications that you have in your organization. But you may also have... Sorry. How many of you guys have heard of .net core? Oh, great. Awesome. So, yeah. So now that we have .net core, your developers can develop .net applications deployed across different platforms. So you can run .net core applications on Windows. You can run them on Linux, Mac. So with these two different paths, what we're doing here is basically explaining to you guys that there are two paths for you. One is with the Windows 2012 R2 stack. And that basically supports your traditional .net applications. And this came out back in November 2015. So we've been running this for a little while. And it basically supports any applications that is running .net 3.5 and above. And what is nice about this also is if you have an existing Cloud Foundry cluster, all you need to do is add Diego support and you'll be able to push this application to a Windows node that you add to your Cloud Foundry cluster. And we'll actually have a demo at the end of this session so you guys can see what it's like to actually do that. And when you do this, your application then gets pushed to Garden Windows. And Zach will talk about the different containers that we leverage for this. And last but not least, we also have some nice folks at Pivotal who are currently working on Bosch Windows. And that is currently underway. So if you are running .net core applications, the way to do it today is no different from any other applications because it just works on Linux. So what you do, again, you push the application like any other Java application or Go application. And you push it with the ASP.net 5 bill pack. And that is also available in the stack. In the slide later, we'll also show you guys a link to that. So that's a two different path. And to summarize this, so this is a comparison matrix for you. And again, if you're running the traditional .net application, you can do this in your CF cluster running Diego and you can use the binary bill pack to actually push your application. But one thing you need to know is that your application needs to be compiled. So the actual binary of your application is the actual thing that gets pushed down to Windows. And again, this supports anything .net 3.5 and above and is running in the Garden Window container. And of course, as a developer, your development environment is Windows. Now, again, for the .net core folks who have just been playing with RC2, and so if you're doing that, you can actually run in any CF cluster, whether it's Diego or DEA. So with this, again, you can leverage the ASP.net 5 bill pack, which is on GitHub, so you guys can just download it and push your application with it. And again, for this particular application, you'll be using the Garden Linux container. And as a developer, of course, your development environment is anything from Windows to Mac to Linux. Great. Well, I'm going to talk a little bit about the differences between a Garden Windows and a Garden Linux container. Basically, Garden is an API that implements containerization, leveraging primitives that are made available by the operating system. So while Windows provides some similar primitives to what are available in Linux, they're not identical, and therefore the behavior of the container varies a little bit too. So in Linux, we're able to take advantage of things like name spaces, disk quotas, et cetera, to provide that isolation. There are some benefits to it. For example, every container that's running on a Linux-based host has access to all the different ports. So on Windows, we use a few different primitives that are made available by Windows to try to come as close to that in functionality as possible. For file system isolation, we actually create a temporary user account for each container that's running on a Windows host. And then we enforce file system isolation via access control lists. So one thing that you want to know if you are deploying an application onto a Windows host is that any files that you write to the C containerizer directory are private to your container. But unlike Linux, which provides an individual root FS for every container, there are shared parts of that file system. So if you were to write files with sensitive information, for example, out into some other directory, then they could be visible to other containers. In terms of network isolation, applications bind directly to the external IP of the VM of that Windows cell. And if you want to do port mapping, there's some extra steps involved in making that work. There's actually a link to a great blog article at the bottom of the slide that provides a lot of detail around that if you're interested. And then as it comes to memory usage, we use the Windows JobObject primitive to allocate memory to specific containers. So JobObject gives you a handle on an entire process tree, making it easy to control that entire process tree to kill it, for example. And the memory enforcement in Windows is not quite as strict as it is in Linux. So we've implemented another sort of side feature here called the guard. He makes sure you don't break out of the jail. So the guard looks and makes sure that no one actually is able to map memory outside of their allocated memory. And if that happens inside of a container, then that process is killed. It also watches out for any process that tries to spawn outside of the process tree of the JobObject. So inside of each JobObject, we use a hostable web core so that you have effectively your own individual IIS that you're able to run your application in, which gives you a greater degree of isolation than what you have today if you're running on a shared IIS server. So just a brief touch point on some of the things that are supported today in Core that are not yet supported in Core that are supported in 4.6. So in ASP.NET Core, there's full support for Web API, for ASP.NET MVC, but there's no web forms yet. This is as of RC1, although I believe it's true in RC2 as well. There's also no support for SignalR, whereas on the ASP.NET 4.6 framework, you've got a battle-tested, hardened framework that's benefited from years of testing and improvement and supports all of the above. So the question is, when do you choose which? So if you're building a greenfield application, I like to recommend trying a core-first approach. Try to accomplish what you're doing in Core. It represents the future. There's a tremendous amount of flexibility in terms of running your workloads on Linux. However, if you're replatforming or migrating an existing application, you're probably going to end up using ASP.NET 4.x. Ultimately, the dependencies and framework requirements are going to dictate your choice. Here, I'd like to give, just call out a few items that may be not super cloud-friendly, that if you've got an existing applications that you're trying to forklift and upgrade over that you'll want to address. So, for example, reading and writing to the registry or to local disk, those are cloud anti-patterns. Using integrated Windows authentication, it's very possible to replace this with Cloud Foundry's UAA. Pivotal CF has a function called single sign-on that allows you to do single sign-on directly into your application, and both of these are able to use ADFS as an authentication provider. In-process session state is also a no-no. Cloud Foundry does support sticky sessions, which in some cases is useful for a workaround, but again, it's not considered a cloud best practice. So, ideally, you would replace your in-process session state with an out-of-process session state store, such as Redis in-memory key value store or SQL Server Database. Environment-specific config in your web.config, this is a common way to manage multiple environments with different configuration in Windows. Ideally, in the Cloud Foundry world, you're externalizing your configuration into environment variables. You can also use a config server, like the Spring Cloud configuration server. And lastly, when you push an application, as Rita just mentioned, to the Windows stack, that application needs to be a binary compiled artifact. So there's no possibility of also deploying dependencies that need to be installed via an MSI at the same time. I've heard from some customers that the way that they've gotten around some of these things is to, well, for example, in the case of using something like an application performance monitoring agent that needs to be installed in every VM, that they're able to do that at the time that the VM is provisioned rather than the time that the application is pushed. The key is to have uniformity across all of your Windows cells because we're treating Windows servers in this case as ephemeral as your Linux servers and not as, well, as the adage goes, we treat them as cattle, not as pets. All right, so Rita's going to talk to us a little bit about deploying an application to Cloud Foundry. Cool. So we're going to go through two demos, but before I jump into that, I kind of want to explain what's happening in the demo that I'm going to show later. So as we talked about deploying a traditional .NET application to Windows, what is happening is, as you can see, this is the CF command that you will use to push the actual application. It's no different than any other CF applications you push, but the difference here is, as you can see, is dash s Windows 2002 R2. So that essentially tells Cloud Foundry, hey, I'm in Windows application, please use the Windows stack, not the Linux one. And the dash b binary build pack is basically telling Cloud Foundry, use a binary build pack to deploy the application. So what's happening is, when you make this request, Cloud Foundry takes a request, and the auctioneer will say, hey, it looks like you're trying to push a Windows application. Then it talks to all the reps across the cluster. And then the Windows rep says, hey, I'm the Windows cell over here. And then auctioneer says, okay, let me drop this chocolate over in the Windows VM. So now that was the traditional .NET application. Now when you're doing a .NET core application, this is really very, very similar to any other .NET, sorry, any other application you're pushing, whether it's Java or Go or Node.js. So again, you have the dash s option, but you don't actually need it. So because by default, you're always using the Linux stack. And dash b, then you're telling Cloud Foundry, hey, use the ASP.NET 5 build pack. And that is where you provide the GitHub URL to the actual build pack. And once you do this, then Cloud Foundry, again, auctioneer says, hey, it looks like you're trying to push a Linux application. Then it looks across its cells and tries to find the cell with the most resource for that particular application. And then it drops into one of the Linux cells. Cool. So that's... So let's come back to maybe the actual demo. So maybe first I want to kind of quickly show like what are the commands that you will run if you were to run the actual Windows .NET, traditional .NET app to a Windows cell. So this is... Can you guys see? No? Okay. All right. Good. Yes? Okay. Thank you. So again, it's basically what we talked about, but this is the actual command. You tell CF, this is my application, this is how much memory I need, and that's the Windows stack to deploy to, and that's the GitHub URL to the build pack. And once that's done, then you basically say, okay, enable Diego, because as I said before, the... I'm so sorry about this. This is the actual command that you actually enable Diego for this particular application. And once that's done, then you just say, okay, start this application in Cloud Foundry. So let me come back to the actual application. So this is the... I mean, this is basically deployed on... This is the actual application that I was just showing. So this is... This particular application is running on Azure using the Bosch CPI. So in a minute, I'm also going to show you guys what the actual VM, the cluster looks like. But essentially, when you deploy this application, this is just an example app, and we have research to this as well at the end so you guys can take a look at it. But basically, as you can see, this is specifying what is the actual application instance for this application. And as you can see, it's also telling us the environment information for this Windows cell. And what's interesting is also that it tells us what is the private IP of this Windows node, and the application is actually running on this port. And of course, as you can see, this is all the specific Windows-specific information. So as I mentioned earlier, this is the... When you deploy this cluster using the Bosch CPI for Azure, what is happening is you actually get a cluster of nodes, and as you can see here, this is our Windows for Diego cell that we have added to our cluster. So also, if you want to see how to do this, we have a GitHub repo for this, so you guys can follow the instructions to actually push your .NET application. And this actually walks you through how to provision the resources on Azure and how to add the specific Windows VM to your cluster. Okay, so that was the .NET one, the traditional .NET one. Now coming back to... This is the actual command that you will use to deploy the ASP.NET core application. And as you can see here, it's actually running... This is actually running in the cluster. And the specific application is pretty simple. It's just running on this CF, and this is like hello from ASP.NET core. So it's pretty simple, but you guys get the point. Cool. One simple CF push command, and you can push .NET core applications to Linux. You can push Windows applications to a Windows stack. It's very powerful. So a couple of things that we're excited to talk about that are coming soon. So .NET core 1.0 GA has been announced for early summer. That's something we're all looking forward to. A supported ASP.NET core build pack. So currently, there is a community-provided build pack. I think it's written by IBM. It's out there. It's called ASP.NET 5 build pack. In fact, we provide some links to it in the slide deck so that you can play with it yourselves. But I know that Pivotal is looking at pulling that in and making it supported as a part of Pivotal Cloud Foundry. Next, Bosch Windows. Bosch Windows is something that, as I mentioned before, it's currently in flight. It's a project to allow those Windows VMs to be provisioned automatically by Bosch itself as the rest of your CF cluster is, instead of having to provision them manually outside of Cloud Foundry and then attach them into the cluster. And lastly, there's this exciting project called Stealtow, which provides access to Spring Cloud servers from .NET clients. So for example, we were talking about ways to manage config inside of your .NET application. This allows you to consume a Spring Cloud configuration server, and it makes it available inside of .NET as a configuration provider. You're also able to consume the VCAP environment variables, et cetera, using that same methodology. There are some other pieces that are currently in flight there as well, like Eureka Client that's available for .NET as well. So this is an open-source project. There are some pieces of it that are available and that are working today, so please feel free to go out here and play with it. If you're interested, we welcome pull requests. So, yes. Lastly, here's a few more resources on some of the topics that we covered today, and these slides will be distributed so that you'll be able to access these URLs. And that brings us to Q&A. Okay, I think it was in the back, came up first. I'm sorry, say it again. When is it going to be released? I think I heard it was this weekend or something, right? Just joking, just joking. I don't have a date on that. I know that it's something that they're currently working on, but there are some significant challenges that are of the non-technical kind that they're trying to overcome. Exactly. Right up here in the front. That's correct. It's clear, though, that this manual process is the same process that you go through today if you're installing any Windows VM in your environment. And it provides you the ability to have a lot of control over what goes into that Windows image, whereas if you're using an already baked stem cell, then you may not have that same level of control. Are you talking about containers? How long it will be to secure for a multi-tenant environment? Essentially never. Yeah. So, until Windows Server 2016, is that correct? In the back again. It's... I don't know if I'd call it an extension. It's a new project, but it leverages all of those Spring Cloud servers. So, yes, it's related. Any other questions? All right. Well, if that's it, we'll wrap here. Thank you.