With the release of Steeltoe 2.1, Pivotal continues to deliver useful tools to help developers build enterprise-quality, cloud-native .NET apps on Cloud Foundry.
Modernizing with a “lift-and-shift” approach? Or are you “re-engineering and rebuilding”? Either way, Steeltoe 2.1 offers several options to make your journey easier.
The new features in Steeltoe 2.1, all based on community feedback, largely fall into three major areas:
Let’s take a deeper look at each category.
Management & Monitoring (M&M’s)
Managing, monitoring, and diagnosing production issues with apps running on cloud platforms can be challenging. It becomes even harder when the apps in question are microservices, and when each microservice is built in different languages and frameworks (e.g., Java/Spring and .NET, just to name two.)
With Steeltoe 2.0, we added a subset of management endpoints that are compatible with Spring Boot Actuator endpoints, e.g., /info, /health, /trace, /thread, and /dump. These provide a consistent way to monitor and manage both Java and .NET apps. The endpoints integrate seamlessly with Pivotal Cloud Foundry’s Apps Manager, giving developers a consistent view of .NET and Spring apps running on the platform.
With v2.1 we’ve taken this consistency to another level. The team developed additional M&M tools and frameworks to increase observability of .NET applications. The cool thing about these tools? They are all open source, based on de facto industry standards. What’s more, they are compatible across several different languages and frameworks, including Java/Spring and .NET!
So what’s new in 2.1 M&M?
Additional Spring Boot-compatible Endpoints
We’ve added several new endpoints. Each one is available as additional REST endpoints you can expose in your applications:
-
/env – returns keys and values from the app configuration.
-
/mappings – returns ASP.NET routes and route templates exposed by the application.
-
/refresh – causes the app's configuration to be reloaded and returned.
-
/metrics – returns current metrics for the app (more on metrics below.)
And, like with previous endpoints, developers can view what’s returned by many of these with Apps Manager.
Out-of-the-box Health Contributors
One of the key Spring Boot-compatible M&M endpoints provided in 2.0 was ‘/health’. But in 2.0 we provided a limited set of out-of-the-box contributors to run health checks. While it was fairly easy to write your own, you still had to do the coding yourself.
Steeltoe 2.1 now includes several new contributors that you can easily reference in your .NET apps. The newly added ones are:
-
Redis
-
RabbitMQ
-
MySQL
-
Microsoft SQL Server
-
Postgres
Each of these new contributors have been added to the Steeltoe Connectors package. This allows developers to use a connector and easily get the corresponding health contributor. In fact, we automatically add the contributor to the service container. So when a developer exposes the health management endpoint (e.g., /health) in their app, the contributor is picked up automatically and used during health checking and reporting!
As you see below in the Apps Manager screenshot, MySQL, Disk Space, and custom contributors all add to your overall understanding of application health.
Application Metrics Collection – and a Nod to OpenCensus
As mentioned earlier, /metrics is one of the new Spring Boot-compatible endpoints added in this release. We’ve also implemented APIs from OpenCensus, a nifty project for metrics collection and distributed tracing started by Google. In particular, we include:
-
The OpenCensus Stats APIs for instrumentation. You can also use those APIs in your code to collect your own custom metrics.
-
The OpenCensus Tags APIs for tagging metrics and adding multi-dimensionality to the metrics collected.
We’re so excited about OpenCensus that we’ve embarked on the first port/implementation of OpenCensus for .NET. Steeltoe engineers have contributed work back to the community with the first PR to the “opencensus-csharp” community repo. The Microsoft App Insights team are very actively involved in OpenCensus for .NET the project as well!
Here’s a look at other highlights for app metric collection:
-
Collect .NET runtime metrics automatically, i.e., heap, thread, and GC usage. Stay tuned for more enhancements in this area, as we build upon the work Microsoft is doing in this area.
-
Automatically collect ASP.NET metrics, like request counts, response times, and others. There’s more to come here as well.
-
Automatically collect HttpClient metrics, i.e., request counts, response times, etc.
-
Expose metrics via the Spring Boot compatible REST endpoint ‘/metrics’ (mentioned earlier.)
-
For Cloud Foundry users, you can export collected metrics to the Loggregator Firehose using Metrics Forwarder. Just as with Java Spring apps, developers can send their .NET apps metrics to any one of several backend services for collection and reporting, e.g., PCF Metrics.
Want to learn more? Check out our M&M sample. It illustrates how to use Steeltoe to expose management endpoints and metrics in your applications.
Distributed Tracing
One of the most common FAQs from the community was, “When are you going to add Spring Cloud Sleuth, or Zipkin-like features to Steeltoe?” These capabilities dramatically simplify how you troubleshoot microservices. Why? In a previous post, we’ve said this about distributed tracing:
Today's architectures have exponentially more complexity. The question to answer isn't "what's wrong with my source code?" Instead, teams need to address a series of questions when issues arise:
Which component of the workload is having a problem?
How do we trace the relevant requests through the entire workload?
How do we find all diagnostic information from the components that processed that request?
And how do we do all of this as soon as possible?
The situation is compounded further when different teams own different pieces of the workload. Why? A select few have an end-to-end understanding of the entire workload.
But just as the industry has rallied around microservices, so too have we rallied to simplify the troubleshooting of these modern, distributed systems.
The answer: distributed tracing.
Devs want to instrument their apps in a way that would track a request as it travels through each of their microservices. That’s true whether those services were developed in .NET, Java, or some other language or framework.
We are happy to announce that we have added this capability in Steeltoe 2.1. By leveraging the trace functionality of the OpenCensus framework, we added the ability to track requests through your system. From there, you have the option to send the trace information back to a central Zipkin server for visualization.
Here’s what we’ve delivered on distributed tracing?
-
Implemented OpenCensus Trace APIs for instrumenting your code.
-
Instrumented ASP.NET Core so that spans are automatically started, stopped, or joined at common ingress and egress points.
-
Instrumented HttpClient such that traces and spans are joined with already existing spans.
-
Add trace and span IDs to the log messages produced by your app so you can use log correlation by trace ID when diagnosing problems.
-
Automatically propagate trace context (in Zipkin format) to downstream processes or microservices.
-
Provide a Zipkin exporter which you can optionally use to send your captured spans to a backend Zipkin server.
Below is a screenshot of a Zipkin server UI displaying a single trace captured from the .NET Fortune Teller sample contained in our repos. It shows how timing information is captured from both the Fortune Teller UI and from the backend Fortune Teller Service. Timing of both MVC actions and views are broken out as well as HttpClient requests made between the UI and the backend microservice.
If you’d like to see the code for the example above, have a look at the Fortune Teller application in our samples repo.
ASP.NET 4.x Support
When we started the Steeltoe project (over two years ago!) we decided to focus solely on supporting .NET Core and ASP.NET Core. We discovered pretty quickly that was not a great choice. Many organizations were simply trying to do a “lift-and-shift” of their ASP.NET 4.x apps to Cloud Foundry. What they really needed were tools to help make that easier.
So, in Steeltoe 2.0 we took first steps to add better 4.x support by enabling the Config Server, Eureka Server, and Connectors to be used with a 4.x application. In addition, if your app was using Autofac for dependency injection, we made it even easier to integrate those services by including extension methods to add those services to the container.
In Steeltoe 2.1, we tackled security and management.
With Steeltoe 2.1, you can easily drop the M&M endpoints in to a 4.x application. We have implemented the endpoints using both OWIN middleware, and by using an HttpModule. You can pick the method that works best for your app. Then you can configure or add each endpoint individually. Or you can add them all, if you’d like!
However, we also did not hold back on the endpoints we are supporting on 4.x. This is important because all of the endpoints that are supported on .NET Core have also been implemented on ASP.NET 4.x — including OpenCensus and metrics. In fact, the same exporter you use in .NET Core applications to export metrics to the Loggregator Firehose also works in your 4.x application. And, of course, this now all integrates with the Apps Manager on PCF.
The other significant 4.x enhancements in Steeltoe 2.1 focus on security. Since Steeltoe 1.0, we have offered two security providers for use in ASP.NET Core applications that integrate with Cloud Foundry security services (e.g. UAA and SSO tile).
With these two providers enabled, you are able to log in to your apps using OAuth 2.0 flows with credentials provided from Cloud Foundry. You’re also able to secure microservice endpoints using JWT tokens provided by Cloud Foundry.
With Steeltoe 2.1, we extended that same security functionality to 4.x applications. We support OWIN-based middleware for both MVC and WebAPI-based applications. We also added a Cloud Foundry ServiceAuthorizationManager, which can be used in WCF-based applications.
As with all other 2.1 enhancements, we made sample apps available illustrating how to use these new features in your apps. For the security enhancements checkout our 4.x security samples repo for details. Want examples on how to use the M&M endpoints in 4.x? We have several samples you can pick from, depending on your specific needs.
.NET Core & ASP.NET Core 2.1 Support
Finally, with this release, in addition to supporting .NET Core 2.0, ASP.NET Core 2.0, and .NET 4.6.1+, we are also adding support for .NET Core 2.1 and ASP.NET Core 2.1. We preserve compatibility with .NET Core/ASP.NET core 2.0. So, if you drop the Steeltoe 2.1 release into a .NET/ASP.NET Core 2.0 app, you should see only a few “Microsoft.Extensions” packages (e.g., Logging, Options, Configuration) that will update to 2.1. Your ASP.NET Core dependencies should not be impacted.
One additional new feature that we added in Steeltoe 2.1, which is dependent on Core 2.1, is support for the new HttpClientFactory. We have added a new DelegatingHandler that will carry out service discovery lookups and random load balancing when used with an HttpClient. This functionality is similar to what we already offered in 2.0, but is now also available when using the HttpClientFactory.
For an example, on how to use the new DelegatingHandler take a look at the Fortune Teller app in our samples repo.
Check it Out!
As you can see, there are many new and exciting features in Steeltoe 2.1. We hope you are able to build some killer apps with it. Let us know what you’re up to, either via Slack or you can tweet us at @SteeltoeOSS. We welcome your pull requests, GitHub issues, and general comments.
Want to learn more? Visit Steeltoe.io and check out the docs. Of course, you can always review the code in our source repos on Github. You can also attend the SpringOne Platform 2018 Steeltoe session or Steeltoe pre-conference training!
