 Hey, thanks everybody for coming to our session here. We know it's a Friday and it's one of the challenges of competing with all of the different tracks here. A lot of interesting stuff. Thank you for attending our session here. My name is Cornelius Mendoza, Senior Platform Architect with Pivotal. I've been spending the last year working with a lot of our large enterprise customers moving their .NET workloads to Cloud Foundry. Jenny? Jenny McAloughlin, I'm a Senior Platform Architect with Pivotal, have been working with .NET customers and helping them become thought leaders on their cloud-native journey. So that's what we're going to talk about today is deploying and operating cloud-native .NET apps. In the cloud-native, here are three core components. Continuous delivery is all about having consistent automated environments where each and every environment are close to identical as it possibly can be. So as a .NET developer, you can quickly move your .NET applications from environment to environment to meet your business needs. And also you have a high degree of confidence that when your application, its production is going to work because it has gone through all the steps of continuous delivery. And DevOps is about bringing DevOps and DevOps together. Its set of practices help remove the friction between the teams. It enables the overall ownership and allow the teams to do what's the best for the application and therefore what's the best for the business. Local services are all about loosely coupled services with bonded contacts. So they can be managed, deployed, evolved, scaled independently. So as a .NET developer, the main question is why do I care about cloud-native? Why do we care about those practices? What can it do for me? At the end of the day, it all comes down to business outcome. As a developer, I want to be able to effectively use my time. I want to be able to deploy new features to production, like to say daily or hourly. I want a faster feedback, try out my new ideas if I have to fail. I want to fail fast. I want to be able to focus on business outcome instead of individual activities such as adding a schema in a database, things like that. I want my components in my application to be loosely coupled so I can upgrade them independently. And from operations perspective, I want my operation team to be able to do more without incrementally increase the size of the operation team. So they need to provide us automated self-service middleware runtime, and they need to be able to help us horizontally scale our application really easily and absolutely no application downtime. We don't want to get up in the middle of the night just because of some sort of OS level patching or security patching, things like that. I want to make sure my system, my application is highly available, and if any components fails, it can be automatically resurrected. And that's huge value. So all these promises cannot fully be delivered if we only talk about the cloud native practices. They also require a cloud native platform. So if you look at the evolution of the cloud services back in the day, everything used to run on bare metal server, Windows IaaS server, and that's all been there. Then VMware came along, infrastructure as a service became really popular, and folks started to move their network loads to the cloud, AWS, Google, or Azure. Well, if you think about it, you're changing the fixed cost of the data center to the fixed cost of Amazon or Google, and you're paying them the margin. And then containers have become really, really popular. Containers have significant advantage in terms of density. Not only that, it really fosters microservice architecture as well. It's probably the best environment to run your microservices. That's why there was an open container initiative launched back in 2015, and there's container orchestration tools, manage your containers, and put them in the right place if they die, bring them back up, things like that. But if you just deploy your application to a container, such as Docker container, and deploy it somewhere, you're going to have to take care of everything within that container. We're going to talk about what's exactly, in that container, you need to take care of shortly. And eventually, Cloud Foundry, that's the structured cloud-native application platform. This is where, as a developer, we can truly focus on our code. So we care about, and through each phase of evolution, you can see the increased, the abstraction. You requirements, and your responsibility to configure different pieces within the software is getting smaller and smaller, and that's the direction we want to go. That's the whole point of cloud services. They're designed to do more. So as a developer, we can focus on delivering business values. We mentioned containers many times. What exactly is a container? So containers use operating system primitives, and it allows us to separate out set of processes and make them pretend they're in their own operating system. So that's ultimately what containers are about. It's to virtualize, virtualizing the operating system layer. So each container thinks that it has its own copy of operating system. It has its own file system, registry, network address, namespace, disk, CPU, memory usage. People know that is not true. So what's really going on is Windows Server 2016 containers provide application isolation through a namespace and process isolation technology. So many isolated environments are set up for multiple applications, and they can be executed in the same system without impacting each other. And containers are light. Instead of having a copy of a kernel stand up for each application instance, now we just put every application instance in a container and share the same kernel. We're talking about seconds to spin up a container as opposed to if you want to stand up a VM, you know, have your own copy of kernels and all that, that's minutes. Any production, you can't afford that. You can't afford waiting for minutes to add another application instance, because that could mean hundreds of thousands of requests getting denied. So at the end of the day, container saves the day. And if you were to build your own container and deploy it to some sort of container platform, you would need to bring your own source code. You also need to identify container OS image, and of course runtime, libraries, DLLs, those kind of things. Wrap them together, put in a container, and deploy to the targeting environment. And on day two, you're responsible for the lifecycle management. Bug fixes, upgrades, those things, you've got to redo, repackage everything and redeploy to the targeting environment. As opposed to if you deploy your application to Cloud Foundry, your application platform, all you need to worry about is your code, because the platform takes care of patching and upgrading for you. And if you think about it from the security perspective, it's kind of weapon of control. It doesn't allow you to have root file access system as a developer. You can't open up ports, because those activities can cause some compliance issue in a lot of organizations, and that's why federal government and US Army and Air Force, they like the platform build approach, because you can't touch anything underneath, and you can repay it all the time. So it all comes down to how much you want to deal with, right? And if you have a Greenfield or Brownfield application you interact with on a regular basis, absolutely go with Cloud Foundry. This is where you can just worry about your code, let the platform take care of the whole stack, because that's what the platform does, other than your code. But if you have some sort of libraries on the OS level, or you have a lot of states you need to take care of, Elasticsearch Cassandra, you will need to build your own container. So we're not saying that platform build container is for everything, we're saying choose the right tool for the job, still focus on business values. Options to deploy and operate the network applications currently we have these options all the options on the market pretty much fall into these three categories. Either we deploy them to VMs, either on-premise or in cloud, or you can deploy to public cloud services such as AWS Elastic Beanstalk or Azure Application Service, or go with the containers route that we have been talking about. Build your own Docker container and deploy it to a Brenda AWS Elastic Container Services or Azure Service Fabric, or do CF push and let the platform build that container for you, right? So Cornelius, would you like to talk the details of the options? Over the years, we've had a challenge in the .NET side in terms of deploying our .NET applications. If you've ever really focused on the web or the web services side, we all know that it wasn't a very easy path to production. And so day one deployments typically with .NET, if you were on a traditional VM, you would have to take care of all of the networking, you would have to take care of all the security, you'd probably have to spend about eight hours patching that VM before you could actually deploy your code onto the platform. And once you get that there, then you've got to get all of the other pieces in place for productionizing that application. If your application needed certificates, typically now with the need for a lot more security, we're finding a lot more customers are using certificate-based architectures as they deploy their applications. Then there's the opportunity to deploy on Docker containers. This is still very immature out there, Microsoft's moving towards that path of being able to deploy .NET applications straight onto Docker containers onto their platform. But right now there's not a lot of tooling that will help you get legacy applications moved over from your legacy environments over to Docker today. That might change over the next couple of years, but for today there's a lot of challenges in getting those containers deployed because you're still responsible for IIS, you're still responsible for security, and you're still responsible for networking. There's also, I've run into, as customers running on Elastic Beanstalk, there's just as many challenges on deploying on Amazon these .NET applications. But at the end of the day, what you get out of Amazon is still a virtual machine. So Elastic Beanstalk under the covers deploys a virtual machine that's running your .NET application. Finders Microsoft, and they've done a really great job over the last year making Visual Studio very adept at deploying .NET workloads into the cloud. But it's still not as simple as you want it to be. You still have a lot of responsibilities around security and networking as well around that. So the responsibilities as a developer is increasing as we move to these new platforms, not decreasing. And that's not the direction, especially for me as a .NET developer, that's not the direction that I really want to go. And it doesn't have to be hard, especially with our latest release of the Windows 2016 stem cell. We now support a lot more types of legacy workloads on our platform than we ever have. And this is really going to change things for us on the .NET side and can really become transformative. A lot of the customers I've been working with have really been surprised at how easily a lot of their .NET workloads have moved over with a simple CF push command onto the platform. But it's not just about day one. It's about the continuous operation and how much we as developers have to be involved in managing and maintaining these .NET applications. A lot of times what we find with non-cloud foundry implementations is that we're finding a lot of fragile automation, can't be modified or else things might break, or a lot of people have things that have been built many years ago and just afraid to touch anything because something might go wrong and I'm the one that's going to get blamed for it. And that leads to a lot of the reasons why is because there's a lot of complex and customized configurations that we've done to support the business workloads that we've had to deploy in our careers. Another thing is what we're finding is a lot of these customers are still doing these maintenance windows and very challenging to keep their uptimes 100%. And this is one of the opportunities here with Cloud Foundry is really the focus around the autonomous parts that we developers don't want to be really involved in ultimately. We want a platform that's enterprise ready. We want it to be able to repair itself, repave itself anytime it needs to be able to do that. We want it to take care of the networking for us. We want it to be able to have some inherent security so that if I do something with my code that ultimately that's not the primary source of that exposure or that surface area attack, I need something that allows me to deploy with zero downtime, which is what most of our business customers are now demanding, especially with a global economy. We have to stay up 24 by 7. And on top of that, you want a platform that allows for high availability without a lot of custom coding on our part. And that will allow us to ultimately get to where we want to get to with no downtime upgrading and patching. One other thing that I've been finding with a lot of our customers is it's not just about technology. It really is about transforming the organization. And with this transformation comes a lot of new tools. And these tools are for us .NET developers have been very foreign. I've run into a lot of .NET developers that have not really worked through a command line interface. Are they capable of handling these new technologies? How much time do I need to spend on educating and training my developers to be able to get up to speed? And is that going to impact their ability to be productive during that time? The other piece here is network and security. I know from my perspective, I just want my application to work. Open those ports up, let's get this application working. Ultimately, when it gets to production, I don't want to have to worry about all of the networking and security on the actual platform. I just want to be focused on my code. And as long as my code conforms to the policies of the organization, I shouldn't have any issue. And lastly, on the developer side, I think there's a hidden cost to developing with these new technologies. For example, with Docker, if you've started working with Docker on Visual Studio, you know that you need to have Hyper-V installed, you need to have a lot of other pieces in place before you can actually start deploying your first container. And even when you deploy that first container, you don't even get to production at that point. That's just deploying on your local machine. So those are the things that we have to learn and we have to adjust for. And on top of that, operators also have to be involved in this whole transformation. Operators, do they really need to know what they're running? And that's one of the things that I've run into several operators who've been throwing workloads over the wall and they say, we don't know what's exactly in these things. How are we supposed to know if we're actually doing the right things, especially in regards to patching and upgrading these workloads? The other thing that operators have been really challenged with is the need for a lot of these services, new services and provisioning these services in a way that allows them to keep their sprints on track. You can't wait six weeks for a database when you've got two-week sprints. So Jenny, you want to talk about this? Thanks, Gaurn. Since we are moving toward cloud-native and microservices direction, a lot of distributed computing problems have been exposed while, you know, if you were still with monolithic applications, avoided those problems. So Netflix came up with really good solutions to address those distributed computing problems that come with microservices and make microservices highly available in cloud. We package those up in spring cloud services and we give to Java developers. We also develop the steel-toed framework and give the .NET developers the same capabilities, just make our life much easier, which is, you know, we can develop cloud-native .NET applications super easily. So I can leverage the same patterns such as circuit breaker for preventing cascading failure, service discovery at runtime, and a bunch of configuration capabilities. So steel-toed supports modern .NET framework versions as well as .NET core. Its open source has recently joined .NET foundation. We also added a library for you to be able to interact with Cread Hub API easily to manage your credentials, such as passwords and certificates. And one more aspect I would like to address for, you know, developing microservices is that it's logging and metrics, because now we need to be able to monitor interconnected microservices instead of just one application, right? When a higher number of components in your system, it is more difficult for troubleshooting. So distributed tracing and correlated logs are must to have to be able to narrow down and troubleshoot your problem. Of course Cloud Foundry has a lot of insights about your application and you can easily join the information to third-party APM tools such as AppDynamics or Neuralic to troubleshoot. Or if you run your applications on Pevito Cloud Foundry, PCF metrics comes out of the box and provides those capabilities in terms of distributed tracing. Makes your life really easy. So, you know, these are the exact stories. Don't take our words for it, look at T-Mobile, once they adopted Cloud Foundry, they were able to develop much faster apps with more frequent changes and fewer incidents. Comcast was able to deliver 120 releases a year instead of they used to only be able to deliver 18 releases. Now they have much better time to market and with more resiliency and skill. But we all know that Cloud Native is not going to happen overnight. If you look at this Cloud Native maturity model and think about where your applications are at today, so if you still have legacy applications on-premise somewhere, our recommendation is for you to move those legacy applications to the Cloud Foundry platform first. Because the platform puts very little restriction in terms of what kind of applications you can migrate to be cloud ready. Things like you can go all the way back to very old.net services such as ASMX services, that forms those kind of old cranky services with minimum code changes. You should be able to migrate them to Cloud Foundry and enjoy all the core cloud capabilities. Then you can start from there and go up the Cloud Native maturity model to start to adopt 12-factor app design principles, add more resilient designs, API-first design microservices architecture, things like that. So the idea is that to do as little as possible to be cloud ready first and then take your time to make things better. But you are moving toward a better way of building and operating your .NET applications and our job is to help you become the thought leaders on your Cloud Native journey. Yes, as Jenny was saying, the idea here is move and improve. Take advantage of the benefits and the productivity of the platform and then start to take advantage of the additional tooling that's available to improve ad resiliency to your application. But ultimately what you want to do is focus on the business outcomes as developers. As developers, we don't get really paid for our ability to deploy SQL server or deploy .NET code on Azure. Visual Studio actually allows that to make that really easy. What we want to do is focus on the business logic, focus on isolating our business logic in a way that makes it reusable and we're not building legacy 3.0 as part of our efforts as developers. The other thing that makes a lot of sense is make your code 12-factor compliant. 12-factor is not a cloud principle and that's one thing that I wanted to make sure that a lot of my customers understood because they hear this 12-factor thing. If you look at all of the things around 12-factor, it really is just best practice around development and having a common code base would think that'd be a good idea or having the same environment to test all of your applications throughout its life cycle. The other thing is buy versus build. I spent a lot of time with organizations that decided to try to build their own tools and we ended up outside of our core competency. That's one thing that you end up spending a lot of time is keeping up with the market at that point because after a while the market's going to realize that there's some value to what you're doing, they're going to probably introduce some capabilities there and you're going to end up on a snowflake on your own with your own implementations there. The other things is don't write code to be platform specific. This is another mistake that I find a lot of customers making is they're writing specifically to Amazon or they're writing specifically to Azure and then all of a sudden the business says we need to bring this inside and they don't have an option for those bringing that code back inside to the organization. And so if you protect your business logic once again, focus on the logic, isolating that logic, build the abstraction layers for your code and try to separate it from the platform. The logic is where the value is, the business logic. And then the other one is deployment methodologies. I hear a lot of conversations now, oh, should we do container? Should we do VM? Should we do bare metal? Don't write your code to any of these specific deployment platforms. Make it platform and deployment agnostic. So you're not writing so that if you're specific to containers and all of a sudden you need to deploy on bare metal, now you have to refactor your entire application around on bare metal. That's not the best way to leverage the productivity of development. So ultimately for me, this is one of the things that I gravitate towards. Now this used to be a very generic thing, but for me it's here's my .NET code, run it in the cloud for me, and this really should say I should not care how. That's all we have. Any questions? We'll be happy to take some.