 All right. Hello everyone. Thanks for coming to the last talk of the day before the keynotes. We really appreciate it Hopefully you're here for real-world Experiences with cloud foundry on Windows. If not don't run away. It's going to be a great presentation promise. I Promise it's gonna be great All right quick introduction. I'm Matthew Horan. I'm a software developer at Pivotal. I worked on the greenhouse project, which is garden windows and Bosch windows their deployment tool for About a year. Then I worked on steel toe, which was an initiative to help developing cloud native applications for cloud foundry easier and I am Steve Medario. I'm a strategic product owner at Pivotal and formerly the product manager for the greenhouse project Working on Windows and dotnet support and kind of the whole end-to-end story so Dotnet development before we jump into kind of lessons learned Around deploying dotnet and and PCF or cloud foundry on dotnet. We want to talk about kind of the state of the world with dotnet development So let's take a quick poll. Who here is running dotnet applications in production today? All right, we got a couple hands. Who here is interested in running dotnet applications? All right a few more excellent I won't necessarily ask you to raise your hands for the rest But I want you to think about how are you managing those application dependencies today using new get or using Maybe something directly tied into TFS How do you troubleshoot production issues on the server? Do you remote desktop into the actual web server? And and kind of affect what's going on on that production machine. Do you know the names of any of your web servers? This is all like really common patterns that we've seen particularly in the dotnet and the windows development world and Some of them have started to fade out in the Linux development world with tools like cloud foundry But we're bringing windows kind of kicking and screaming into the future And that that's part of what we've been working on with the greenhouse project So this is a this kind of summarizes it Great job configuring servers this year said no CEO ever And so this is this is kind of the value of cloud foundry, right? Is that you can focus on developing applications and driving value? to your customers Rather than worrying about the configuration and all of the underlying things Underneath so cloud foundry to the rescue Except that's only for Linux, but wait. It's not so About two years ago pivotal undertook an effort to Fully support windows on cloud foundry before we started on that effort There were a number of partners of pivotal that had begun some work on that effort Early efforts there included iron foundry, which was a port of the DEA to support windows and Once we started on our effort to rewrite the execution agent Diego We we made sure that it was Abstract enough to support windows and so we undertook that effort Thanks to mark here in the audience for kicking that off So two things were required to get us there garden windows, which was the implementation of the garden API for windows specifically and Bosch windows so we targeted developers first and garden windows was that effort to Get cloud foundry in the hand of our developers as quickly as possible And that was really an MVP approach, but we got it out there We were able to get it deployed and we had a number of large-scale customers actually successfully deploy that and run production applications on windows from cloud foundry and Since then we've been focusing on the operator experience and Bosch windows is the operator experience So we'll touch a little bit more on that To get everything running all you had to do was port the Diego components rep metron and the console agent to windows and that was really easy because that's all go and We were able to target Windows and just build a binary and implement garden windows, which was not too complicated So why is Bosch so so awesome, right? There have been a few talks about this I think and hopefully you know this by now But Bosch is the way to deploy cloud foundry the open source CF releases are all Bosch releases And if you want to know how to deploy CF you need that Bosch release So we initially started with pretty cumbersome Windows installer process MSIs that you had to configure and set up and get running on windows Then we moved to the Bosch release Bosch is great because it enforces immutable infrastructure. So Stephen touched on this earlier you might Have a lot of snowflake servers that are individually configured and you know It took a lot of time and a lot of different people to get those servers together And maybe some of those people have left your company and you have no idea how that server was configured Bosch makes that impossible You can rebuild those servers forever and ever and ever and whatever you want You can do what we call rotate repair and repay that's gonna be covered on another slide here But basically instead of keeping these servers around forever and letting them get infected with viruses and worms and all sorts of fun stuff like that just blow it away and stand it up again and This allows you to have a cohesive deployment process across all cloud foundry So instead of having this kind of wonky windows installer process for windows you can now just Bosch deploy all the things so to kind of summarize the state of Dot net on cloud foundry today Windows support for cloud foundry was GA in October of last year So it's been about a year now of kind of GA production ready support and The the deployment as as Matt just mentioned is a little bit different It was a little bit wonky with with an MSI installer Still automatable and certainly we've seen a lot of success with our customers using this process But we're working towards now This Bosch windows, so it's currently in beta and so it's pretty much done But maybe not ready for for for production quite yet In addition to that we have dot net core a real exciting project from Microsoft Which is kind of a rewrite of the dot net library or the dot net? Framework from the bottom up to be cross-platform So you can write a dot net core application They can be deployed on windows on Mac or on Linux And so we already have a build pack from the the cloud foundry community that supports dot net core on Linux And then we have the the recently kicked off steel toe project Which Matt was talking about before and we'll talk about a little bit more which provides a framework similar to spring cloud services for Dot net developers and to that to that effect. There's there's also a book Written by some of our colleagues at pivotal about writing microservices for dot net So this is kind of the state of the world today And we're gonna continue talking about what we've done with this world So when you're targeting cloud foundry, there are some important things to keep in mind one of the core tenets is 12 factor so I'm not going to read through these bullet points here And you can read more about all this on 12 factor dot net But if you're just getting started with cloud foundry I recommend that you check that out if you already know 12 factor and you have some dot net apps And you want to put them on the platform It's important to keep all of those ideas in mind when you're targeting cloud foundry for example, where your logs going, right? So think about that Building microservices is still probably a good thing with with dot net And so the steel toe project helps you do that when you break down those large projects And you can push them up as individual components that both scale independently and then have their own Resources tied to them. That's a much easier infrastructure to manage From the developers point of view even though it complicates the overall software architecture it's a lot easier to reason about and All of this allows you to have continuous delivery and continuous deployment through some sort of continuous integration pipeline And you might use maybe concourse for that or something like that So What have we learned? I want to emphasize here like this is the part of the talk that you're all here for Right. This is this is the thing. This is what we've learned from our experience in deploying and battle testing cloud foundry on Windows So over the past year and a little bit prior even before GA We at Pivotal been working with our customers to deploy this in production This isn't a toy. This isn't this is production stuff and lessons learned from kind of running up against the issues in the field and so we're hoping to share those with you here So that you can avoid some of those same issues Our biggest customers are running dozens of Windows cells We have hundreds of a app instances in production across Two continents, I think maybe three So all over the world. We've got we've got customers doing this and doing it successfully And so we're here to share some of this this learnings with these learnings with you And in fact, some of the several the dotnet applications are working together with services provided by spring apps on Linux so once again the dotnet on Windows and the dotnet or the Sorry dotnet in cloud foundry works well with Linux in cloud foundry as you might expect great, so one of the first problems that you might run into is database creation and Authentication how do databases get created in your organization? Do you have a DBA? Do you send an email to some IT team and magically like four weeks later a database shows up, right? This is like a typical pattern and in fact actual example from a from a customer who When they worked on the dotnet applications at that company before they were enabled with cloud foundry This was actually a customer that had started putting things on CF via By a Java and they were utilizing Java and CF, but they hadn't yet had dotnet deployed So whenever they had to touch those dotnet apps, you know, it was weeks and weeks and weeks of lag between Getting that application code finished on a developer's machine and then hooked up to production database and so That's a problem, right? How do you get those things? Sometimes these databases and the networks are configured such that every machine on the network is completely trusted So you have a front-end web server that has complete access to the sequel database Windows domain authentication is built in and free and so not only are the database credentials non-existent You're just trusting the network But it's really easy for developers to utilize Windows authentication to authorize requests to the application and so Not always not always a great practice So what do we do about that cloud foundry service brokers? Has anyone here used a service broker? Yeah, all right, we got a couple so so service brokers are the answer here, right because they manage the creation of Databases and credentials and then the credentials are provided to the application seamlessly so In this way you get you get kind of the the security as well as kind of all the benefits of the cloud foundry ecosystem This also helps with defense in depth. So if a particular web server is compromised We've seen scenarios where Simply like machine name authentication or machine authentication via Windows domain would give you access to a sequel database somewhere So if the machine was compromised And you didn't notice about and didn't know about it Then now the the attacker has full access to the database And so that's not the case here as much and it makes it much easier to rotate credentials This comes back to something that Matt touched on earlier rotate repair and repave Which are the three R's of security that we've been talking about a lot of pivotal lately Our director of security Justin Smith has a great blog post about it. I recommend you go check it out But rotate credentials very frequently repair Any any issues or any vulnerabilities that you find in your code or in your ecosystem and repave the machine? So if if a VM is ephemeral if it only turns on or a container only turns on for for 24 hours at a time if a if an attacker gets into that machine It's going to be blown away in a couple of hours. And so there's a limited amount of Damage that they can do in that time. So the three R's really come in to effect here So the next problem might be implicit application authentication. So I kind of touched on this on the last slide But it's really easy to use Windows authentication to protect your application But maybe that's not a great idea. It's really tempting because you get that domain controller and LDAP integration and super easy, but with Windows cells and the security mindset that we have with cloud foundry and deployment of cloud foundry Maybe it's not a great idea to domain join those cells if we're going to rotate repair and repave them and so you can't use Windows domain authentication with Windows cells So the solution here is use UAA for application authentication Refactoring application to use OAuth Is is a great best practice because not only can you still use UAA which can be backed by LDAP So you can have the same same authentication Same credentials that you had before But using UAA allows you to make this app more portable more global Sorry, not not using UAA using OAuth allows you to make it more global and you can support things Perhaps a client that is not necessarily Windows domain joined. So the next problem is unknown app dependencies So we had a customer who discovered there was a security module that was required by their machine config They had no idea how that module got there on the system Turns out it was injected by the security team via a group policy, right? And so this is kind of the norm we've found in interacting with some of our customers basically Not all the dependencies of applications are known either at compile time or at deploy time so not using Nougat or other dependency management systems for dependencies means You just don't know where they come from, right? DB2 drivers are pretty notorious for this So the solution here is to use a dependency management system Nougat is great, but Realistically it can be anything you want Use one of them Bin deploy everything so store all of your configuration in a single place And and keep your configuration together And some dependencies don't actually support being been deployed so DB2 is the canonical example there That we've run into in a number of places Work with your vendors to get those dependencies updated so that they can be been deployed Or else work to migrate off of them would be would be our recommendation because this type of thing can really throw you for a loop Sessions store so Sessions are great. They're pretty important When you have a stateful application and so you might be storing that session Local on your server and if you're doing that you're probably relying on sticky sessions of some sort to make sure that every incoming Request gets routed to the same app instance Something like that isn't going to work great in the CF Infrastructure because CF instances are ephemeral and so you really don't want somebody's session going away when you Restart an app instance while you're deploying code and of course the the solution here is to use database for for session storage It should be pretty easy to configure something like my sequel or Redis Both of them are available for pivotal cloud foundry And you can use them for for session state and kind of ephemeral storage like that Really if you're building a modern kind of 12 factor application, you shouldn't be storing anything locally So logging right everyone needs those logs. There was a great talk about tuning logger Gator earlier today and We support logger Gator, right? However applications need to be tuned to work with logger Gator But why does this matter right? Legacy applications typically use the windows event log just log to the windows event log It's really easy, but have you ever tried to search through two gigs of XML? It's pretty tedious You also don't know what? Instance your application is running on particularly in a distributed system So cloud foundry is going to leverage all the windows cells that you've deployed to support its infrastructure You really don't want to have to go connect to each of those and search through the event log And of course the solution here is to use a configurable logging framework log for net is a great example The it has a console appender as one of the one of the output options They just writes to the correct place and gets picked up by logger Gator and everything is great And then logger Gator, of course brings all of those logs centrally So that you just need to type use a developer just need to type CF logs And you can get access to all of them regardless of which cell is Potentially misbehaving or you're trying to find an issue or troubleshoot or diagnose something All right next up So we had a customer that had written a bunch of custom ISAPI handlers They're great because they really empower developers to do anything For example, they were generating PDFs of Receipts that were being passed from an application, which is cool Except that they didn't really work well with quad foundry And that's because they rely on IAS and some legacy aspects of IAS and shared memory and all sorts of scary things when you're running multi-tenant multiple applications on scaled back ends right so With great power comes great responsibility So there's a very simple solution here Don't do that Custom ISAPI handlers can because you can do anything they can cause lots of trouble So use them warily if at all We don't really recommend it at all because you can run into a lot of issues when you're trying to migrate to a cloud-native system like like Cloud Foundry There are plenty of other ways to generate PDFs Configuration sprawl so we touched on this a few slides back, but You can really get pretty confused about where configuration bits are coming from you've got machine config You've got app config. You've got multiple layers of app config web config all these things come together to make a configuration and developers might be leveraging that for like cool things for example Local development versus production development versus wherever staging It doesn't really Work well with this model of I just have an application and I and I want to push it Especially see I push it right and it's definitely not a 12-factor approach so in line with 12-factor Recommendations store the configuration in the environment so using environment variables or Cups custom user provided services for your environment configuration And and don't snowflake your your servers if you know the name of a web server of a server that you have It's probably been around for too long if it has Specific characteristics like I know that Tabasco takes a long time to reboot because it's got spinning this instead of SSDs That's that's terrible So so get all of your configuration Provide it in a single single place and and don't snowflake those cells because you don't want something unique on One server and another server. I have all the configuration a single place and you can easily rebuild that that configuration as needed or that that environment and Just to touch on that in a couple more more slides one of the things that steel toe provides is Mechanism for abstracting that config out of files and putting it in a git repo. It's pretty neat So some some extra gotchas Cross-cell encryption right particularly interesting if you have That session cookie, right? Maybe you're encrypting some data on the client. You want that to come back trusted? Wait a minute. If that's going to go to any back end that's running on a Windows cell You need to make sure that the same host key is configured on each of those systems So you can override that by the web config the global assembly cache Another thing that's not going to work. Well, so if you have assemblies that you need to put on your systems You don't want to go touch a single server and then forget about all these other Windows cells that you've set up Then when your application boots up on another cell, it's going to fail to start So we just recommend against that back to the dependency management and using something like nougat or whatever and then network shares and persistent disk so We have come across a few examples with our customers of applications that have hard-coded UNC paths They're trying to reach out directly to network shares again going back to this trusted environment We trust every system that's out here. Wait a minute. You trust a public-facing web server with access to all your back-end storage so Don't do that, right? Try to leverage other services either see if service brokers or something like that and If you do write to that local disk remember is going to get wiped away So what could be better the future right? We talked a little bit about steel toe So what we bring you our spring cloud clients for ASP.net and ASP.net core We support both four or five plus and core Unfortunately Not all things support both languages quite yet. We're still waiting on a number of missing features from Microsoft and the Foundation the dot-net foundation to finish some of those connectors. So basically Four or five and four six are fully supported but core is not fully supported yet But basically you have the spring cloud config service. That's what I touched on about removing that config from being splattered across your disk Service discovery with Eureka So if you have multiple applications that need to talk to each other they can discover each other by Eureka and this is going back to that customer who had the Spring applications talking to their dot-net applications talking to their spring applications. They're utilizing Eureka for that service discovery Spring cloud connectors, which I'll talk about in a second and this works with both open source or our Productized spring cloud services. So spring cloud connectors, right? We support sequel server and EF six EF six is where the challenge comes from dot-net core. We just don't have it yet MySQL, Redis, Rabbit, MQ and Postgres just came out relatively recently So continuing to look at the future We get a bunch of questions. What does the future look like? Well, here it is Windows 2016 was announced actually just this week was the GA was announced and it's going to be available on MSDN shortly Windows 2016 is supported today By the cloud foundry bits that are available in garden windows Open source in the foundation, etc improved container isolation and network virtualization is coming soon in in server 2016 and then the Bosch windows GA is planned to come soon As was improvements to steel toe, but we've talked about that enough So Bosch windows will be GA relatively soon as well and that'll be really exciting So as we've gone through this journey of bringing dot-net To becoming a first-class citizen in cloud foundry Today we talked about a lot of the lessons that we've learned from from actually deploying this and running it in production with a number of customers dozens of servers We've gone through and and live this pain so that hopefully you don't have to And we've brought these lessons learned But Bosch windows is going to come very soon to simplify this experience And then dot-net core is now fully supported so dot-net core is available on Linux as well as on Windows and we think You know imagine this world where where you're strangling this dot-net monolith that you have that you've had for years And you you pick it up and you move it over to cloud foundry And then as you you strangle it and you take apart the different pieces you start writing New parts new microservices that you want to write in dot-net core so that it can be ready for the future But you're not quite there yet because not all the pieces of dot-net core are there So you start writing in dot-net core. You're using steel toe to connect to your Eureka server And because you're using dot-net core on Windows you can use legacy dependencies that still run on Windows and Windows 2012 2016 and as you're ready as those dependencies get replaced or rebuilt You can move you have the flexibility to move to dot-net core on Linux so There's a really great story there that you can do all of that within cloud foundry you can Bosch deploy all of your servers Your Linux and Windows side-by-side you can see if push all of your apps Linux and Windows side-by-side And you get all of the logging and monitoring in the same place And we're really excited about this story and about bringing dot-net to a first-class citizen within cloud foundry So on that note. Cool. Yeah, I just wanted to give a shout out to everyone who's contributed to the open source support for garden windows, so the current team is comprised of Some folks that are based in Pivotal's New York office But we had previous contributions from CenturyLink and HP and I want to call out our friend Sheffan over here who spent some time with us in New York and really helped us Make garden windows awesome. So thanks to everyone for helping make this successful So we have the standard. We're hiring slide get please get in touch But outside of that I think we have about two minutes for questions if if anyone has any questions All right. Well Thanks for coming. Hope you enjoyed it