 So my name is Zach Brown, this is Matt Horan, and today we're going to talk a little bit about this open source project called Steeltoe and how it helps you build resilient microservices with .NET from .NET, and it's really cool. So let's go ahead and dive in. All right, well this is what we're going to look at today. You can see we'll talk a little bit about the .NET Renaissance. We are in this interesting period right now with regards to .NET, and I'll talk a little bit more about that. Then we'll tell you what is Steeltoe, and then some details on why is Steeltoe, in other words why we built it, and what's in Steeltoe. And we'll talk a little bit about Cloud Foundry, because Cloud Foundry is where we'll run our demos today, and you'll hear us mention it throughout the talk, just so you understand what it is and where we're deploying these applications to. And then we'll give a really cool demo to show some of this stuff, and then I'll follow it up with a little bit of our roadmap for Steeltoe, where we're going next, and some additional resources if you all want to dig in and try some of it out yourself. All right. Oh, before we start, let me invite you, encourage you to be engaged, take photos, tweet. Let's have the dialogue that we're starting here be the beginning and not limit this conversation to the scope and space and time of this presentation. Let's take it on the road. Feel free to follow us on Twitter, and let's keep the conversation going. All right. So welcome to the .NET Renaissance. Some people in the open source world, when you say the word .NET, they automatically think old school, they think maybe it's passe, or that it's not what the cool kids are doing. I don't know what the cool kids are doing. Maybe they're all writing Golang or Ruby or Node.js or something. But lately some interesting things have been happening up in Redmond. There are a lot of changes under foot, and all together they make right now a really exciting time to be a .NET developer. So in case you're not clear what I'm talking about, let me refresh your memory. Microsoft loves Linux. You know, you can run Bash on Windows now. You can run Linux containers on Windows. Who could have seen this coming? A couple of years ago, Steve Ballmer very famously said, Linux is a cancer. And now we've got Satya Nadella up in front of this giant stage with Microsoft loves Linux. I know that I secretly wish somebody from Microsoft would send Steve a big box of those T-shirts that say Microsoft loves Linux. I would love to see him at one of the Clippers games rocking that T-shirt. Right, yes, indeed he is, isn't he? All right, well how about this one? Microsoft loves open source. So this is another significant pivot. It used to be that the ultimate sign of success for your .NET related open source project was when Microsoft came out with their commercial version of whatever you were doing and tried to squash your project. So this is a big deal that they're now fostering a community in community projects. And .NET is now open source. The .NET framework is now, it's part of this .NET foundation. And they're working really hard to foster a community around it. And in addition, there's now .NET Core. This cross-platform set of runtimes and frameworks that run on Linux, they run on Mac OS in addition to Windows. And of course, Visual Studio had to get in on Love Fest too. There's a full-blown Visual Studio IDE that runs on Mac OS now. And there's a new lightweight editor called Visual Studio Code, if you haven't tried it, it's pretty cool. Runs on Linux, runs on Mac, runs on Windows. But wait, that's not all. SQL Server now runs on Linux. All right, take a minute and look at all those hearts. As I'm sure you're aware, statistics show that most long-lasting, loving relationships and marriages, they start when you write two names with a heart in between. It could be on your notebook, your desk at school, carved into a tree trunk, or my personal favorite, carved into wet cement. So what does it mean, all those hearts? Well, when you write a heart with your sweetheart, it means that things are getting serious. So what are we left to take away from this image of so many hearts? Things at Microsoft, they're starting to get serious. All right, so what's all this about the .NET Renaissance? Earlier this summer, Ian Cooper at the NDC Oslo conference, he said, we are on the cusp of a .NET Renaissance. And the way that he framed it is, he looked at a lot of things that are happening in the community now. Specifically, he had all sorts of statistics about how we're losing jobs, C-sharp jobs are on the decline. And then he likened it to something that happened in the Java community six or seven years ago. And there was this time when in the Java world, the JVM was losing developers, and they were losing them to Ruby on Rails. The idea was that people were moving away from those really high-friction, heavy-duty app servers, Java EE app servers, and moving to this low-friction experience of building websites with Ruby. Well, what happened after that was, there was this renaissance of projects that came up, NETI, the Spring Framework, Netflix OSS, and suddenly they really reinvigorated and filled out this rich community. There was an explosion of projects around things like high resilience or high scalability, 12 factors, microservice application architectures. So where does that leave us with .NET? Well, if you look at the example of .NET, .NET just had its 15th birthday this year. Java is around 20 years old. So maybe timing-wise, we're about the right time for some kind of a cool thing to happen. We've got cross-platform.net core was released, Microsoft's pivot towards the open-source community and embracing that community instead of competing with it. But where we are is we're still missing some pieces, at least until recently, there hasn't been that rich community of tooling for resilient microservices. So that is where Steeltoe comes in, and that's what we're gonna talk about today. All right, what is Steeltoe? At this point, I'm gonna hand it over to Matt to talk us through what Steeltoe is. Cool. So Steeltoe is an open-source project, as Zach pointed out. It's sponsored by the company that we both work for, Pivotal. And it provides client libraries for Spring Cloud Netflix OSS, and in addition, some extra tooling to help it make it a little bit easier to use Cloud Foundry and Cloud Foundry services. So Zach had mentioned something about that. And so it's this open-source project that you kind of add to your project and your application can use all this code that's already existed from Netflix and from other open-source projects. And this is the Steeltoe logo here. It's actually an S, if you couldn't tell that. I did not design it. If I did design it, it would have looked something like this, which I did in the GIMP about 15 minutes ago. So I'm glad we had a designer do that professionally. But before we get into what makes up Steeltoe, let's talk about why we built it. So the first reason is to help you get your .NET applications cloud native. And so what do we mean there? Well, this 12-factor app concept, which came out around the time of Heroku and sort of this platform as a service movement, which was an effort to help you kind of decouple applications from keeping state on disk and relying on things like J-Session ID and Java to pin application instances for inbound requests because you didn't have a shared session store, maybe using a database instead of relying on disk persistence or hard coding database strings into your applications. All these things are anti-patterns in a 12-factor application. And so 12factor.NET, if you're not familiar, actually spells out these 12 factors that are important for applications that are targeting cloud native deployment. And Cloud Foundry being a cloud native deployment runtime and a platform as a service, that's where Steeltoe kind of glues everything together. And so Steeltoe helps you follow all these good practices for cloud native applications, not writing to the registry, getting rid of global application cache, all these anti-patterns when we want to move away from that server that Joe set up for you in the back room and you can only ever get that server running again when you call them because it's down. And then, of course, microservices. This wouldn't be a technology conference without talking about microservices. And so Steeltoe enables this building and deployment of resilient cloud native microservices. And what we mean here is enabling developers to take ownership of a small portion of an application and iterate on that, making it easy to run test suites and build components in isolation, give teams the empowerment to make their own decisions, and then come together and build that whole product. This increases developer velocity and decreases test cycle time. It also makes it possible to build bot applications. Say you had a giant application that required on the .NET desktop CLR, on a Windows server. But you want to enable moving away from Windows all these very tightly coupled Windows applications. So now we have the ability to run part of an application in a microservice on .NET Core on Linux and part of that application on the .NET desktop CLR on Windows. And so that's kind of this dream realized with microservices. And then you can always scale these components up individually. And so say you're expecting a lot of people to go to your home page and you want to have high throughput there. But maybe not everybody's going to turn into paying customers and go through your shopping cart. So you can kind of scale every component separately. And we'll actually show you that in the demo a little bit later. But microservices are hard. And this is a great tweet that kind of captures that. We replaced our monolith with microservices so that every outage can be more like a murder mystery. And that's true. Microservices are distributed systems. So you're taking this thing that was a monolith and that had its own problems that were hard to reason about and hard to work on that code base. And now you broke it down into these little kinds of reasons about hopefully a little bit harder, less hard to reason about on their own. What is going on here? And so how do you troubleshoot these microservices when they all come together? How do you set configuration across all those applications in a consistent manner? You mentioned with the 12 factor, you're not supposed to be variables into your code. So now how do you distribute those variables through it? How do you look up addresses as you consume? There are things like constant, there are service discovery mechanisms. But you're going to need a way to say you're running a music store, which is what we'll demo today. You've got a front end that's got to talk to a back end. How do you find those services? What do you do when one of those services goes down? So your back end inevitably is going to go down at some point and does your application going to throw a 500 error when that happens? You don't want that. So the good news is Netflix solved a lot of these problems for us already in the spring community, Java, with their Netflix access initiative. And so they worked on Eureka service discovery, the Histrix circuit breaker pattern, and released a lot of this as open source software. And Pivotal has been working on kind of continuing since Netflix has moved on to other fun and exciting new technologies. And we actually then were able to take some of that back to .NET. So that's why we built StillTill. To help you build cloud-active .NET applications and leverage spring cloud tooling, brilliant microservices, check out all the buzzwords you really want to use, StillTill. So Zach, tell us what's inside the box. Okay. So what's in StillTill? We heard about what StillTill is, we heard about why we built it. Let's take a look. So I think the libraries that make up StillTill roughly fall into two categories. The first are things that help support you do cloud-native .NET, especially run .NET applications on Cloud Foundry. And so the first in that group of things are connectors. So we have these built-in connectors that help you automatically wire up your connection to common backing data services. For example, MySQL, Postgres, Redis, RabbitMQ, and even OAuth. So the way that these work is on Cloud Foundry you deploy an application and you bind a backing service to it. So maybe it's a Redis database or a MySQL database. The credentials for that application, effectively the connection string, gets injected into the environment of the container where your application will run. So your application, all it needs to know is where to look for that information. So StillTill just wires all those up automatically. Next, StillTill provides some security providers. So there's an OAuth to SSO provider. There is a provider for JWT resource protection. So for example, if you want to use a JWT token in order to access a secured rest endpoint. And in addition to those two, StillTill also makes available an additional security provider, which allows you to easily use a Cloud Foundry-based Redis instance if you are leveraging the ASP.NET Core. There's a key ring store in ASP.NET Core security. There's data protection. It's called ASP.NET Core data protection. And the problem is the way that it's built by default, it writes your keys to disk, which is not a very cloud-friendly or cloud-native pattern. So what we've done is extend it so that all those keys are written to a Redis backing store. All right, and this is another really cool thing that's part of StillTill, and we'll demo it today. There are management endpoints. So it's fired by a spring project called Spring Boot Actuator. If anybody's a Java developer, you might have heard of it. There are these endpoints that end up decorating your application that can help you manage it. Maybe your application or your microservice is running in production, and you want to get some information from it to help troubleshoot some problem that you're having. But you're limited to what you can do in terms of how invasive you can be in your poking around. So what this library does is you bind to this library, and it automatically ornaments your application with these endpoints, and they are things like info. So this info endpoint, it returns application information which could include, say, the exact commit that the running application code corresponds to. So if you're an operator, you're trying to troubleshoot an application, knowing what the source code for that application looks like is very helpful. There's a health endpoint that returns some health information about your application. There's a trace endpoint that is a circular buffer of the last 100 HTTP requests and responses. So a very powerful, very useful tool right there. And then lastly, this is my favorite. Loggers allows you to dynamically configure, and this is on your running application, the logging level, all the way down to the class level. And you can do that on an application instance basis. So if your app is running at horizontal scale and you've got one instance that keeps crashing, you can drill into it and find out exactly why. All right, so those are the management endpoints. We've also got some configuration providers. There's a configuration API provided by .NET which enables you to pull values out of different sources and then access them from within your application in this form of a hierarchical configuration dictionary, if you will. And so each of these providers supports reading a set of key value pairs from different sources. So it might be from file sources like JSON files or XML files or it's Microsoft, so INI files. There are environment variables or command line arguments, but they also have a structure for creating custom config providers. So Steeltoe provides two custom configuration providers. The first one is called Cloud Foundry, and I talked about this environment variable that's a set of environment variables that are available inside of your application container. So this will read all of those into your configuration dictionary. And then the second one is Config Server. So has anyone here heard of Spring Cloud Config Server? Spring Cloud Config Server is an implementation of the shared configuration pattern. It pulls your configuration out of your application and then you can read it into your application across a bunch of different environments. You can have different config for different environments, et cetera. And it writes all of that data or stores it in a repo. It could be a Git repo, which gives you the advantage that you have full traceability to who made changes when. Or you can back it by vault if you want to store connection strings in there. And I think I've got a slide that shows roughly how it works. So somebody on the far left side there updates configuration in the repo. And these are like YAML files. They're like JSON files. And then your applications come online, app A, app B, app C. And they pull the config from the config server, which reaches out to that repo and pulls it in dynamically. So the cool part is there's an endpoint for each application that you can hit that will refresh that configuration while the application is running. You don't have to stop and restart it. You don't have to repush it or something like that. So it gives you the ability to dynamically refresh that configuration. It's also got the built-in ability to change that configuration in different environments and even override it as you move from, say, running on your local machine to running on Cloud Foundry or in the cloud. All right, resilient microservices. Matt, you want to talk us through the Eureka? Sure. Yeah. So one of those other components that came from the Netflix OSS community is Eureka. And so Eureka is service discovery, sort of like console, except instead of using DNS like console does, Eureka actually has its own internal mechanism for doing lookup. And so everyone who implements this Eureka pattern has to run the Eureka code. And there is actually a Eureka server that runs somewhere in the service registry. With Cloud Foundry, this can be provided to you via the Spring Cloud services. Or you can just run this server by itself. It's actually a Java application that just stands up. And so applications, when they come online, register themselves with the service registry. And then somebody who needs to consume something from the environment. Maybe you're talking about the music stores. So maybe there's a database that Frontend needs to reach out to. And it can look up the address of that database via the service registry. And so this server already exists. It's part of that open source Eureka community. And the Steeltoe library includes a client that allows you to both register producers, as they're called, and also register consumers that can look up those producers. And so this solves that, how do I find service A, service B, service C? And it doesn't require using DNS or anything like that. It just uses this Eureka client. And the great thing is it hooks right the standard .NET HTTP library. So there's nothing crazy you have to do here to integrate with Eureka. You just plug it in, and it works. We talked a little about circuit breaker pattern. So this implementation in Steeltoe comes from Netflix Histrix. And so the circuit breaker pattern, I'll talk about a bit on the next slide. But this allows you to bypass those failing services instead of blowing up the page with a 500 error and having a terrible experience. You can have this nice graceful degradation. You also get this rich metrics and monitoring experience. This Netflix already built this beautiful dashboard for looking at this information. The Steeltoe library implements the pattern and then streams back all those metrics to the Histrix dashboard. So the actual pattern looks a bit like this. When the circuit breaker is closed, all calls to an API just pass through. When they succeed, it resets a counter, an error counter. When it fails, it increments a count failure. And when a threshold is met, it trips the circuit breaker and no longer passes traffic to that broken API. So then you can put a nice error page in there or maybe fall over to a different API or give a different user experience while that backend service is recovering. When the circuit breaker is open, we'll be keeping track of that fail count and see if that fail count continues to go up. If it starts to succeed, we enter this half open state and begin doing a check to see if that service is actually alive. When we determine it is alive, we reset the circuit breaker and start this process over again. And so all this is provided in the Steeltoe library via a Histrix implementation. And it streams all that data back to the Histrix dashboard. So Steeltoe is open and flexible. It works with .NET Core and the .NET Framework. It works on Windows and Linux. And it works standalone and on Cloud Foundry. So I just wanted to follow that up by saying there's no other .NET library that I know that allows you to access the Eureka Service Discovery server from Netflix. There are other circuit breakers out there, but none of them have this rich Histrix dashboard and all the metrics that get emitted. So there's some really cool unique value here in Steeltoe. All right, well, you've heard us talk about Cloud Foundry a bunch of times, but in case you're not sure exactly what it is, then let me tell you a little bit about it. I have this great diagram here, which was very obviously created by somebody who works in marketing and not somebody who's on the architecture team. I heard a great quote at a conference earlier this year where somebody said, this diagram, what I recommend you do is print it out, and then you can use the back of that page to write your notes on. And so this might fall into that category. So Cloud Foundry is a PAS. It's a platform as a service that you can deploy applications to. And then as a developer, you have to worry very, very little about packaging that application up. Cloud Foundry is very flexible. It runs on a variety of different cloud infrastructures. You've got all the major public clouds. You can run it in your private data center on top of VMware or OpenStack. And it does that by virtue of an infrastructure, orchestration, and management layer called Bosch. It creates all the VMs. It creates all the networks and all the things in between. And then it's got health management to make sure that they stay alive. So then on top of that, it's got Cloud Foundry uses a build pack construct. If you're familiar with Heroku build packs, for example, they take a look at your application source code, determine what language it is, and then automatically assemble all of the things you need to run your application, your application runtime. If it's Java, you'll need a JVM and some sort of an application server, for example. And then all of the dependencies that your application has, it pulls it all together, bundles it up into a package, deploys it into a container, and then schedules that container somewhere running on a container host VM. And then your application is health managed. It's got integrated logging and all sorts of other cool stuff. So today in our demo, we will show you an application. It's made up of a bunch of microservices running on Cloud Foundry. It'll be running on PWS, Pivotal Web Services. So that's Pivotal's multi-tenant public instance of Cloud Foundry. It's actually 60 days free if you want to sign up. You can run applications there, try it out. And so with that, why don't we go ahead and dive into the demo? Cool. Live demos are always a little risky, but let's see how this goes. So over here, there is a slide that looks at your microservices architecture if you want to show it before or after. So here's a quick overview of what the actual architecture here is. The front end is music UI app. There's a back end store service, a back end shopping service, and a back end. Each of those services are independent. They all have their own backing store in MySQL. And the music UI also has a front end Redis store. And we use that for a session cache. So once you log into the site, it keeps you logged in. There's no instance pinning for any inbound connections. It's all just doing that transparently. And this is sort of a standard.net reference application that's out there, the music store. And what we've done is taken it, and we've just replaced some of the components with some of the patterns. So in between those different microservices calls, there are circuit breakers. Eureka is used to look up the location of those services. Configuration all comes from the Spring Cloud config server, et cetera. And so this front end app is just that music UI. I'm going to log in just for fun, maybe. And so here, this front end is just accessing that back end music store service. The front end is using the Eureka service discovery to go and find that service. The application code doesn't have hard-coded IP addresses for that service in it. It just has a reference in there. And then the Eureka service discovery agent has those services registered with it, and will return the IP address for those services that the front end can go and find it. When I go to add something to my cart, the front end actually reaches out to a second back end service, the order service, and or sorry, the shopping cart service, and adds the shopping cart. And so when I view my shopping cart, this actually reads from that second service. And then if I continue this process here, checkout, this is actually that third service, the checkout service. And if I were to fill this whole form out, this would submit all that back to this back end service, and I enter my promo code free, and it'll process this order for me. But the interesting thing to show you here is what's happening here on the front end versus those back end services. And so this is the Cloud Foundry application manager console here. You can see all the applications that are running here. I'll bump up the font size of it. We've got that front end music UI service, and the back end music store order processing and shopping cart services. And you see here, I actually have these two instances of the music store UI. And when I mentioned the bit about that session, when I reload this page, I don't want to be logged out. And so having that session store work is kind of what makes this whole page work. But the other thing that we mentioned was those Spring Cloud actuators. And so you'll notice a little difference here between this page and this page. Here it just says music UI, it's a regular app. Over here it shows the number of instances I have and some high level information about my application. But it's not super useful. Over here, when I click on the music store instance, I get this little icon up here which is actually for Spring applications. But what it means is we've actually implemented the actuators API. And so when I go to my instances over here, I can click this little arrow and get this additional detail about my application so I can see what disk space is available on there. And this doesn't just work on Cloud Foundry, this works theoretically anywhere. It only has this integration here. So this is a standard API for getting this information from your applications. It's just an API endpoint that returns a JSON string and then our UI designers made it pretty in this application screen. One of the other components of actuators is viewing the trace, right? So I can see everything that came in and out of those request headers here for my application. And so if I'm trying to debug some failure with my application, I can just go right here to the console and dig into that. Whenever somebody buys that one item, tries to check out with that, it's that minute work CD, I know it is. Then that's the thing that crashes it, right? So this is that circular buffer that I mentioned earlier in the trace endpoint. And if I was trying to debug something and I don't know what sort of code is pushed up to Cloud Foundry, this is that info endpoint that returns the Git SHA and where that code came from, right? And so you can see, oh, this came from my laptop. I pushed it up there last night. This is the SHA that I pushed and now that can help us debug what's running. And maybe I'm not getting enough verbosity or maybe I'm getting too much verbosity in my logs. And so this is what Zach had mentioned. You can actually, with the live instances, change the logging levels of this code that's running in production, right? And this actually sends a request back to my app, says you need to be doing a thing in a different way. It's actually all protected with O1, so this is just stuff. Not anyone can hit these endpoints and change my application, but it's tightly integrated with Cloud Foundry and Apps Manager, but it is a standard API. And you can do that across your whole application or you can do that on an individual instance of your application if it's running at horizontal scale. And one more thing we can do here, yes, ooh. I wanna stop this music store instance and see what happens. So my music UI instance is still running. And so if I reload this homepage, see, did it actually stop? It did actually stop. And so this homepage actually gracefully degraded and this is that hysterics pattern and that it's not returning a 500 here on the homepage. And now if I try to go around here, it's not gonna work very well, but it was able to catch some of these responses in that hysterics pattern, right? And so this is ultimately what you'd wanna do with your application when you're building with microservices to make sure that it gracefully degrades. All right, well, as we promised, I would like to talk to you a little bit about where we're going next with Steeltoe and I'd love to hear from you if there are suggestions for where we should go next. So the Spring Boot actuator project has a huge list of endpoints and there are quite a few out there, but there's a couple really valuable ones that we haven't built yet that we wanna get in there and they involve the ability to pull down a thread dump or a heap dump from your running application. So that's cool, that's something that's coming soon. Netflix Ribbon is probably the next Netflix project that we'll pull in. It provides you a client-side load balancer plug-in so that you can load balance from your calling application across all those, if you're using Eureka to reach out to provider microservices and you wanna consume them, you pull down a list and it might be a list of some number of dozen instances of that application running at scale. Well, how do you load balance in between them? So Ribbon provides a whole bunch of pluggable load balancing algorithms that you can use to bring your own, if you will. And then lastly, distributed tracing with Zipkin for NET. So you heard about the murder mystery that can be troubleshooting your microservices and production. So Zipkin helps you do distributed tracing so you can look at that call stack as it goes from microservice to microservice. Anything else that you're burning to see in here? Anyone, anyone? Prometheus Endpoints is a good idea. We haven't thought a whole lot about it, but it's definitely something that's possible. I know there's a lot of integration with Prometheus and Cloud Foundry. All right, so how do you get started? These slides are available on the website for the conference. You can pull them down, got links here to our website, GitHub repo, our NuGet feed, as well as we've got a Slack channel. It's public, you can register yourself and join and ask questions directly to the engineers that are building this stuff. And then lastly, other resources. I wanted to at least plug, we've got a two-day training class coming up for folks who are building .NET applications on Cloud Foundry. It's in San Francisco during the Spring One platform conference in early December. And there's, yeah, it'll be a great class. Please join. If you'd like to dig in a little bit on your own, here are a couple blog articles about some interesting things that people have done with Steeltoe. So with that, I think we're ready for questions. Any questions? All right, well in that case, thank you very much for coming to our talk.