Our continued commitment to Steeltoe and the broader .NET community

[TimHess]

Quick History

Steeltoe was originally started by Pivotal 8+ years ago to cloud native and observability outcomes available in the Spring ecosystem to enterprise customers with .NET applications. The name SteelToe is a derivative of IronBoot, originating from the convention of using the “Iron” prefix for external offerings brought into the .NET ecosystem (i.e. IronRuby, IronPython, IronFoundry, etc…). The adoption of Steeltoe along with the availability of Windows server VMs on Pivotal Cloud Foundry (now named Tanzu Application Service) enabled the platform to provide a valuable and collaborative platform for both .NET and Spring applications. With the accelerated adoption shown in downloads of Steeltoe Nuget packages, we were excited to donate the project to the .NET foundation in 2017. Later, we built and donated the .NET version of OpenCensus, preceding the evolution into OpenTelemetry.

The Announcement of .NET Aspire

The launch of .NET Aspire, along with Microsoft.Extensions.ServiceDiscovery mark Microsoft’s genuine entry into the domain Steeltoe has occupied all this time. We are excited to contribute our own expertise to the Aspire project and continue moving towards even stronger and more approachable solutions to cloud native constructs in Microsoft namespaces. Steeltoe is not going away. We are going to rearrange where some of the functionality in Steeltoe resides (in collaboration with the Aspire project leaders) and continue to provide and innovate with Spring and Tanzu integration opportunities. The following section lays out our initial plan but we also need to hear from you! Please let us know your thoughts on the details of these projects and how you see them in relation to Aspire. Having more feedback from our Steeltoe community will help us ensure that the right options are chosen.

What is coming in Steeltoe 4.0

Our release plans for Steeltoe 4.0 and beyond have been available in our OSS repository for visibility and feedback. With the announcement of .NET Aspire and our conversations so far in collaboration with their project team, we will be continuing to deliver the following in Steeltoe 4.0:

• Public API Surface Area Review
• Enhanced compatibility with runtime configuration via IOptions usage
• .NET 8 support
• Configuration
  • [possibly research-only] Support for application configuration service on Tanzu
• Connectors
  • Support for the Kubernetes Service Binding Specification
  • Refactor to simpler implementation for easier maintenance
• Management
  • Actuators available on an alternate port
• Service Discovery
  • Align abstractions and core functionality with Aspire/Microsoft.Extensions.ServiceDiscovery
  • Blue/Green deployments through endpoints
    • Use endpoint to set registered instances to online/offline
• Refactoring, bugfixes and usability improvements across all components

In addition to the removal of Hystrix and the Credhub Client (prior to the announcement of .NET Aspire), we are planning to remove the following projects from Steeltoe 4.0 and future releases:

• Common.Expression
• Common.Hosting
• Common.Kubernetes
• Common.Net
• Common.RetryPolly
• Configuration.Kubernetes
• Discovery.Kubernetes
• Integration and related packages
• Management.Kubernetes
• Management.Tracing
• Management.Wavefront
• Messaging and related packages
• Stream and related packages

Please let us know your thoughts on these planned project removals from Steeltoe OSS. We are eager to hear from you on the matter and any other feedback you may have.

Conclusion

We are excited about the future of the Steeltoe project. We expect accelerated popularity within the .NET developer community as we align closer to .NET Aspire. The Steeltoe project remains with the .NET Foundation and will continue to provide value to our extended community.

[thompson-tomo]

I think it is a good move to align with Aspire and allow that to lead to a reduction in overlap between the 2 solutions and have them becoming complimentary.

One thing I think would be worthwhile is to move the service discovery to implement Microsoft.Extensions.ServiceDiscovery.Abstractions which also appears to be falling under the Aspire team. With this approach we could use eureka as a service provider for Aspire. This would be a similar approach as has been done for config. #1254