simon_bisson
Contributor

Steeltoe: Simplify building .NET cloud microservices

analysis
Dec 01, 20206 mins
Cloud ComputingMicrosoft .NETSoftware Development

Open source .NET tools help build and deploy distributed applications to Spring Cloud and Kubernetes.

miniature figurines on a circuit board amid binary code / hardware / development / microservices
Credit: Alfexe / Toni Vaver / Getty Images

The .NET Foundation is the home for more than .NET. It’s the open source hub for languages and frameworks to help you build on top of the various .NET runtimes and compilers, with contributions from companies and individuals around the world.

One of the more popular tools came out of Pivotal (now part of VMware again). Intended to help developers build better .NET microservices, Steeltoe serves as a bridge between .NET and Pivotal’s Spring Cloud and Cloud Foundry platforms, as well as to Kubernetes and other containers, with a set of libraries that speed up application development. Now that it’s open, it’s receiving code contributions from across the .NET community, including teams at Microsoft, and building on work done in Netflix’s open-source libraries. You can find its repository on GitHub.

Microservices with Steeltoe

By building on familiar ways of working, Steeltoe can also be used as a springboard into .NET development from Java and other enterprise languages. You can take work you’ve done in Java on Spring Cloud and port it to .NET, or use Steeltoe connectors to mix different technologies so existing applications can be enhanced with .NET microservices. Project managers will find this approach helpful, as they can mix and match available resources as necessary without having to worry about compatibility issues.

Steeltoe can create a cloud microservice using its initialization tool, adding providers for different cloud services and automatically configuring code for deployment. Configuration can be easily stored outside your code, so you can keep tokens and other important authentication details in secure services such as Hashicorp’s Vault without exposing them in code repositories.

Its biggest advantages are its libraries, which prepackage useful cloud design patterns ready for use in your code. These include support for service discovery, with Eureka and Consul clients, along with distributed tracing to help debug code. Other key elements support messaging by working with network file shares and provide connectors to the cloud services you’re going to use. Cloud-native microservices need to be stateless, easy to compose, and well-defined, and Steeltoe’s libraries help build code that supports cloud-native design patterns without changing how you write your .NET Core applications.

The latest release is Steeltoe 3.0. This moves support away from the .NET Framework to .NET Core, ready for .NET 5 and future .NET Core-based releases. It’s added support for other distributed application platforms, such as Kubernetes, and for messaging-based architectures. That has meant changes in package naming, so code will need some refactoring when you upgrade to the new releases.

Using circuit breaker patterns

One useful Steeltoe feature is support for Circuit Breaker patterns using tools based on Netflix’s Hystrix. The original Hystrix is in maintenance mode, but the model it uses is still useful for making microservices fault tolerant, adding resilience to applications by providing a way to quickly lock down failures and prevent cascades.

Circuit breakers are an important tool in distributed architectures where you have limited observability into remote or third-party services. That makes them useful where services are built and managed by different devops teams, and where you may be consuming a service that becomes unreliable when too many applications use it. A circuit breaker monitors all calls to a service from your code. If too many calls fail, it falls back to alternatives and raises an alert. This can trigger a restart or simply wait until the remote service is available again.

Steeltoe makes it easy to add a circuit breaker wrapper around any service call. This runs in its own thread pool to help manage load on the target service. If a thread isn’t available because there are too many calls from your code or the circuit breaker is waiting while the remote service isn’t responding, the circuit breaker can call its fallback. Similarly calls can have a timeout, with all actions logged and displayed in their own dashboard so you can see how services are operating. These logs are a useful diagnostic, and you can use tools like the ELK stack or Azure’s Monitor to make them part of your devops processes.

Deploying to Kubernetes with Project Tye

If you want to make .NET part of a wider cloud-native environment, Steeltoe works well with Microsoft’s Project Tye, bringing .NET microservices to Kubernetes (in particular Azure Kubernetes Service). Here you build services using Steeltoe libraries before adding them to containers using Project Tye. This automates the process of creating .NET containers and Kubernetes manifests, as well as finding other services and handling container dependencies. It’s a useful tool, installed using the .NET command line tools. Once installed it’s easy to go from app scaffolding to running code, with a dashboard to monitor running services and view logs. Multiple services can be added to a single .NET solution, which can then be run using a single tye call.

More complex configurations are managed using Project Tye’s own YAML manifests, with application and per-service configurations. The tye.yaml file will help manage dependencies, working with Docker files and container registries to pull in services and deploy them as necessary. Some cases require preconfiguring and deploying external services, for example databases or caches.

Building services with Steeltoe and bundling with Project Tye is a quick way to get started with cloud-native .NET development. Although Project Tye remains an experiment, it will be interesting to see if Microsoft continues working on it now that .NET 5 has shipped, as its planned integration with tools like Dapr would make it a useful set of extensions to any .NET development environment. From my point of view, integrating it into the .NET command line environment would make a lot of sense, doing for .NET much of what tools like Draft do for the wider Kubernetes ecosystem.

A cloud-agnostic approach to distributed applications in .NET

Building and running distributed applications shouldn’t be hard; they’re key to working in and across multiple clouds. By supporting Spring Cloud and Kubernetes, Steeltoe offers an agnostic approach to multicloud development. You can build .NET code using familiar tools and techniques with the Steeltoe libraries, before using its configuration tools to support delivering your code to your target platform.

The result is code that can be quickly switched from one cloud to another, and from your data center to a managed platform. Modern .NET Core-based code is designed for microservices, and Steeltoe helps provide many of the features you’d otherwise need to write yourself. It’s well worth exploring the various projects hosted by the .NET Foundation; you’re likely to find something that helps you write better code more quickly.

simon_bisson
Contributor

Author of InfoWorld's Enterprise Microsoft blog, Simon BIsson prefers to think of "career" as a verb rather than a noun, having worked in academic and telecoms research, as well as having been the CTO of a startup, running the technical side of UK Online (the first national ISP with content as well as connections), before moving into consultancy and technology strategy. He’s built plenty of large-scale web applications, designed architectures for multi-terabyte online image stores, implemented B2B information hubs, and come up with next generation mobile network architectures and knowledge management solutions. In between doing all that, he’s been a freelance journalist since the early days of the web and writes about everything from enterprise architecture down to gadgets.

More from this author