I have been speaking regularly on .NET Core for quite a while at this point. It is the way of the future with 100% proof, as we learned earlier this week. Overall this is a great thing for technology as a whole. .NET Core is faster, lighter weight, and allows development across a much larger set of technology. However, there is a slightly hidden "feature" that will impact many organizations that isn't highlighted with the same fanfare in the public announcements; the update & support strategy. .NET Core handles this in a manner that is a major departure from the current trend in technology.
Update & Support Strategy with .NET Framework
Lets first look at the update & support strategy with the .NET Framework. The support lifecycle for .NET Framework has actually shifted in recent years and isn't necessarily something that people have paid a lot of attention to. Per the Microsoft guidance the most recent stance is:
Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed.
They continue with a special note regarding .NET 3.5 SP1
.NET Framework 3.5 SP1, beginning with Windows 10 version 1809 and Windows Server 2019, is a standalone product and receives 5 years of mainstream support followed by 5 years of extended support. For operating systems released prior to Windows 10 version 1809 and Windows Server 2019, .NET 3.5 SP1 remains a component of the Windows version on which it is installed.
Overall this is a bit cryptic and requires you to go digging for detail on what the actual support term ends up being. Trimming this down to the most basic understanding, we can generalize that there are at least 10 years of support remaining for .NET Framework 4.7.2, and maybe slightly less than that for .NET 3.5. Loosely generalized this means that something developed with .NET 2.0, back in 2005 will still have support from Microsoft in 2029, a 24-year lifespan.
.NET Core's Lifecycle
Transitioning to .NET Core the support for .NET Core paints an entirely different picture. There are two models of support for .NET Core; Current and Long-Term Support (LTS). For the sake of this discussion, I will focus on the LTS policy only. This policy is defined as:
LTS releases are supported for the following timeframe, whichever is longer: Three years after initial release or One year after a subsequent LTS release.
Looking at the current releases of .NET Core, 2.1 is the LTS version with the last LTS release being completed on August 21, 2018. This translates to end of support for .NET Core 2.1 being August 20, 2021. This can change, if Microsoft creates another Patch release, but cannot be counted on.
Once outside of the support period you no longer have support from Microsoft for Technical assistance or security fixes....not a good thing. No, your application will not blow up on that date, or just suddenly stop working but you will be flying solo.
Modern Day Complaceny
If you look at solutions in the .NET world today, many organizations have adopted a complacent attitude towards the management of their solution. I see it every day working with new clients or providing guidance to individuals.
- Production solutions still using .NET 2.0, when migration to .NET 4.7 would take less than a few hours
- Production installations of DNN Platform using a version that is 7-8 years old
- Projects initiated with no confirmed budget for future maintenance
There are countless other examples, heck, there are still endless items in production using Classic ASP. This mindset has been embraced for years, and the support policies granting such long windows of support provided no incentive to move forward. If the solution was working, why improve.
This Must Change
With a three-year support window, this mentality cannot continue. The days of building something and setting it to run in the closet for 10 years is no more. Running applications on a software platform that isn't supported is a risky endeavor, and all organizations should take this seriously. As IT Professionals implementing solutions, it is our job to educate the organizations on the risk, as some may not know.
But It Isn't Doom & Gloom
It is true that a huge shift is being made to the life expectancy of a delivered solution, however, this isn't necessarily a catastrophe. There are some mitigating factors and side-benefits associated with this shift.
Upgrades Are Well Documented
I'm not going to say that upgrading from .NET Core 1.1 -> 2.0 -> 2.1 -> 2.2 was 100% easy, However, I will say that by following the excellent documentation the cost to upgrade has not been too horrible. The documentation that is published provides grave detail, including line-by-line examples of the code they need to change.
The only real hassle with upgrades are if a feature is utilized that no longer has a future, or has a drastic change. The number of thse items seem to be dropping as the .NET Core product matures. It is still a risk, however not a huge risk in my opinion.
Regular Upgrades Result in Better User Experience
We live in a technology world that is ever changing. Our internet connectivity is getting faster, our devices are becoming more powerful, more of our life is connected to technology. With the world around us changing so quickly, being forced to keep our technology current affords the benefit of taking advantage of these new features earlier. The more modern features employed, the better and more consistent the user experience will be.
Less Likely to Need a Greenfield Reimplementation
Stale projects, that don't see regular maintenance can often get to a point where the upgradeability is limited or the technical knowledge to perform the upgrade has moved on. By keeping a product constantly updated, there is less risk of information loss, or a big jump in functionality causing major breaks in available features.
Summary
.NET Core is the future, and the future is bright. However, there are considerations that must be understood. Corporations might need to review their budget allocations. Implementation groups need to continue to educate their development teams on the latest and greatest. Developers can no longer get 10 years of experience doing the same 1 year of work, continuing education will become crucial. Not necessarily collegiate education, but self-study, conference attendance, etc. to stay current with the changes.
Organizations will need to adjust budgets, and expectations, with regards to how they manage their software projects. It will become important to establish regular maintenance for all applications. Which is not a bad thing at all.