Summary

The overall aim of this dotnet open source Framework is to:

• Standardise practices around code/logging/implementation when writing Cloud based, containerised microservice applications
• Speed up development time by providing tools
• Easily achieve Containerisation (using docker in templates provided)
• Decoupling of code and lessen the use of Cloud specific implementation code (Cloud agnosticism)
• Improve testability by using abstractions
• Split and remove dependency trees - no one package does all
• Deployment flexibility - use in various hosting environments, such as Webjobs or Containers deployed as pods in AKS
• Reduce cost/dev time by creating robust applications quickly and reliably
• Give more insights into application startup and shutdown
• Follow a high testing standard - test first and automation

Overview

The Cloud.Core Framework is a suite of open source packages help build native or containerised Cloud applications, using the .dotnet SDK, in a standard way. The applications can be run on Windows or Linux targets easily. Packages are built using the .net Standard specification and applications utilising the Framework will typically be built using the .net Core 3.1 (at present).
Migration to .net5 coming soon.

An aim of the Cloud.Core Framework is Cloud agnosticism, achieved by loose coupling of Cloud specific dependencies. Other than the Startup.cs (presuming you are using the Cloud.Core Framework's AppHost or building an ASP.net Core Web Application), which is your project dependency root, you should not see references to any Microsoft Azure (or Goolge/Aws) specific packages throughout the application code. If you do, it should raise an eyebrow that something's gone wrong 😃

You can find all the code from the project here: github

By taking this approach it means if the need ever arises to use a different cloud provider, it should only be a matter of modifying the Startup.cs to use the Cloud specific implementation of which ever interfaces was needed (see Cloud.Core for more information on supported interfaces). The modification could either by a fork of your application, hard coded changes of the implementations, multiple startup classes with different wiring or using build parameters to choose which interface instance to create.

Further Reading

If you want to learn more, the following useful articles can help: