.Net 5 has finally reached the General Availability stage last week during the .Net Conf 2020. But is .Net 5 a good framework for DevOps?
Today I want to talk about it, but from a DevOps and CICD standpoint. Let me show you why I think .Net 5 is perfect for DevOps.
Intro
If you have been following the me he or on my YouTube Channel for a while, you've probably noticed that most of my examples and demos which require some code are done in .Net. In fact I've been a .Net developer for years and, although I'm proficient in other languages like Java, Ruby and Node.js, .Net is still my favorite language. However, I have to say that in the past .Net was not super DevOps-friendly, especially in its .Net Framework flavor.
But after using .Net five for a while, and following it GA release last week, Im now convinced that it is just perfect for DevOps and CICD scenarios.
Video
As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo, which to be fair is much more complete than this post.
(Link to the video: https://youtu.be/-2LcsiXLw88)
If you rather prefer reading, well... let's just continue :)
What is .Net 5?
Alright, lets jump into the topic. Let me start with a brief introduction of what .Net 5 is. If you already now this, feel free to jump to the next section.
So What is .Net 5?
It is a major release of .Net, with a broad set of new features and compelling improvements. It’s actually already in active use by teams at Microsoft and other companies, in production and for performance testing.
Most importantly, .NET 5.0 is the first release in the .NET unification journey. .NET 5.0 has been built to enable a much larger group of developers to migrate their .NET Framework code and apps to .NET 5.0. It also includes much of the early work in 5.0 so that Xamarin developers can use the unified .NET platform when .NET 6.0 will be released.
Speaking of which, there will be a major release every year, with .Net 6 coming in November 2021, and of course with minor releases if needed.
It is worth noting that .Net 5 doesn't replace the .Net Framework, and in fact .Net Framework 4.x is and will still be supported, and there are no plans to migrate WebForms, WCF and Workflow Foundation to .Net 5 or higher.
Also, .Net 5 doesn't replace .Net Standard, it will just not be necessary anymore because there won't be different APIs in different flavors of .Net. New application development can specify the net5.0 target framework moniker for all project types, including class libraries and so sharing code between .NET 5 workloads is simplified. And same would be true for .Net 6 and higher.
Alright, now that we have an overview about .Net 5, let see why I think it's perfect for DevOps and CICD.
1. .Net Momentum
First of all, .Net in general is one of the most used frameworks.
There are more than 2 million active .Net Core developers and more than 5 millions active .Net Developers, and those people would be able to switch to .Net 5 very easily.
Also, .Net Core, which .Net 5 is the evolution of, is the number 1 most loved framework accordingly to the StackOverflow framework for 2 years in a row.
Furthermore, C# (which is the main language used in both .Net Framework and .Net Core) is the 5th most used language on GitHub.
Lastly, Asp.net Core is the number 1 web application platform by performance in the upcoming TechEmpower Benchmarks
And this without mentioning the more than 40% of the developers new to .Net are students and that the whole .Net project not only is completely Open Source, but is also one of the projects with the highest velocity.
Put this all together, and you have something truly great for DevOps. Why? A performant framework which developers love and that is well known by the community. Your teams will be happy using it, and you'll be able to quickly find new developers should you need to expand your teams.
2. Performances
Speaking about performances, those have been really improved.
Not only .Net 5 is over 30% more performant on socket on Linux over .Net Core 3.1, which performances were already pretty good, but also the JSON serialization performance has been improved about 20%.
And for a modern application development, especially when talking about MicroServices, .Net 5 gRPC performance has been improved so much that now it exceeds the one of Go, C++ and Java.
While RPS (requests per seconds) are important, they are not everything. Most of the time in fact the performance of an application and ultimately the number of machine cores needed to run it depends on latency.
The team did an incredible job about it as well, and worked a ton on the Garbage collector of .Net 5, and now the latency is the lowest ever provided by any .Net Framework and .Net Core version.
Again, this is great for DevOps and especially for the Ops part: better performance + less latency means less computing power needed in production and hopefully less headaches.
3. Compilation Time
And talking about compute, there is also less compute needed for CI. The compiler in fact is now much more optimized, and offer great performances.
On the right side of the image here we have a small project, which targets .Net Core 3.1 and it is been built by the compiler that ships with the .Net Core SDK version 3.1.404
On the left side instead we have the exact same project, but I've retargeted it to .Net 5 and it's been built by the compiler that ships with the .Net 5 SDK version 5.0.100
As you can see, the difference is massive. The .Net Core 3.1 compiler takes more than 2 and a half second in average to build the solution, while the .Net 5 compiler consistently stay below 0.9 seconds.
And in bigger solutions this difference is even greater.
Not only it builds faster, but the resources consumed by the compiler in term of CPU and Ram are lower.
I think we can all agree that the team did a fantastic job here.
4. Container Images
Let's stay in the CICD territory, and let's talk about containers.
Containers are of course one of the most important cloud trends and the .Net team has been investing significantly in them. There are a number of improvements in the lower levels of .Net 5 that make it perfect to run in containers, but probably the most visible one is the optimization of the provided container images.
As part of .NET 5.0, the team has re-based the SDK image on top of the ASP.NET image instead of buildpack-deps to dramatically reduces the size of the aggregate images you pull in multi-stage build scenarios.
As you can see in the image, the SDK image size has been reduced somewhere between 30 and 65 Mb. But the biggest improvement is in the runtime image.
If you do this as a multi-stage build, your runtime images will be between 4 and 10kb! And this is possible because all the layers you need are already in the SDK image, so you have them already and therefore you just download and store the manifest.
With this change, the Asp.Net pull (for example), will be a no-op, because you will have pulled the Asp.Net layers via the initial sdk pull.
This will allow you to save up to 40% of the storage space for your images. You will see significant size wins for Alpine and Nano Server as well with 5.0, for multi-stage builds.
Smaller images means not only less storage needed, but also faster pull and therefore faster startup of your containerized image when pulling from scratch.
And if you need to run your containers on Windows, we now have Windows Server Core images, in addition to Nano Server.
5. Multiplatform
Which brings me to the next point. .Net Core was already multi platform, but .Net 5 is even more multiplatform... it has the widest OS support of any .Net version before.
In fact it runs on:
- Windows 7 SP1, 8.1 and 10, on both x86 and x64 architectures and for the first time ever on Arm64
- Windows Server and Windows Server Core 2012 R2 and higher, on both x86 and x64, and Nano Server 1809 and higher on x64
- Linux: all the major distributions including Alpine, CentOS, Debian, RedHat, Suse, Ubuntu and more, mostly on the x64 architecture but in some cases supporting also Arm32 and Arm64
- MacOS, from the version 10.13 onwards, on the x64 architecture
This translate to being able to build a .Net 5 application on virtually any CI agent, whether it is hosted or self-hosted, physical or virtual, Windows or Linux. And of course it also means that you'll be able to deploy your application to any of the abovementioned platforms, for a total flexibility.
From a DevOps standpoint it also means you can choose the platform you and your team are more familiar with, and that gives you more performances and reliability.
Also, .Net 5 is already available in both Azure Pipelines and GitHub Actions, so you can build it with no problems.
6. Single File Applications
Finally, and still talking about CICD, one of my favorite features: Single File Applications.
Single file applications are published and deployed as a single file. The app and sll its dependencies are all included within that file.
Even tho Single File Applications were already a think in .Net Core, their behavior is completely different. In .Net Core 3.1, in fact, it packages binaries into a single file for deployment and then unpacks those files to a temporary directory to load and execute them. With .Net 5 instead when the app is run t_he dependencies are loaded directly from that file into memory_ (with no performance penalty). A big improvement.
You can create a Single File Application using either the command line or tools like Visual Studio. You can also configure the single file publishing directly in the project file.
Remember that in .Net 5.0, single file apps can be either framework-dependent or self-contained. Framework-dependent single file apps can be very small, by relying on a globally-installed .NET runtime. Self-contained single-file apps are larger (due to carrying the runtime), but do not require installation of the .NET runtime as an installation pre-step and will just work as a result.
Why Single File Apps are great for DevOps? Well, your CD will thank you. Having to transfer and publish a single file is much faster and has much less latency than doing so with multiple files. And if you're thinking "I can do the same with a zip file", remember that in .Net 5 Single File applications don't have to be unzipped... so again, faster and more optimized.
Recap
So, to recap... Why is .Net 5 great for DevOps?
The momentum of the .Net frameworks and ecosystem is great, and the team worked a lot on performance improvement. .Net 5 is the most performant .Net ever.
It is also great for CICD, because of single file applications, smaller container images, and super fast build time.
Finally, it is truly multiplatform, being able to run on Windows, Linux and MacOS, on the x86, x64, Arm32 and Arm64 architectures.
Remember to watch the video for a full-length explanation.
Conclusion
Alright, that's it for today. Of Course .Net 5 has many other improvements and awesome features, but the ones we have seen today are for me the most important ones when it comes to DevOps and CICD.
What do you think? Let me know in the comment section below what your favorite features are, and if you agree with me in saying that .Net 5 is perfect for DevOps.
Like, share and follow me 🚀 for more content:
📽 YouTube
☕ Buy me a coffee
💖 Patreon
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
Top comments (3)
I am surprised to see no listing of Windows only features, if you look at the api, there are many features not supported on non Windows platform.
Unlike Java, .Net isn’t truly multi platform. If you drill down and try to use your existing projects on different platforms you end up with not supported exceptions.
IIRC there is very little that is Windows-only. .Net Core was much more Windows-oriented. The things that are Windows-only are like that because they are not available in other platforms, like for example WinForms or Windows APIs.
As I've mentioned, .Net 5 is the first release in the .Net Unification, with .Net 6 and Maui basically everything that is not OS specific (again, if your project uses OS APIs that is of course something that is limiting) will be multiplatform.
What makes it not truly multi-platform? I've been deploying projects to Linux + nginx for years. I've done extensive development on Mac. Zero issues.
If a legacy project was built for Windows, that is on that project, not the .NET ecosystem. Yes, .NET is in the middle of transitioning out of its Windows-only past, but new projects are plenty portable.