Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time.
I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to the resume.
The industry at large asks most developers to stay up-to-date, so it starts looking suspicious when a company doesn't stay up-to-date too. For C# in particular, companies who have only recently migrated to .NET 5+ are now a red flag to me considering how long .NET Core has been out.
I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations.
In the latter case I would consider it a red flag if some long-deprecated tool turned up in the tech stack of a company, but there might be perfectly good reasons to stick to the former, a bunch of VMs, instead of operating a Kubernetes cluster.
I ran a small Kubernetes cluster once and it turned out to be the wrong decision _at that time_. I think I would be delighted to see a job ad from a company that mentioned both (common hypervisors/VMs, containers/Kubernetes) in their tech stack. Without more information I would think that company took their time to evaluate their needs irrespective of current tech trends.
I'm hiring for a company that is building a tech stack of VM's. My username at mastodon or twitter has the details, and it's about working with https://github.com/purpleidea/mgmt/
Comments
I think there is even a widening talent gap where you can't get people excited about doing something that maybe should have been done years ago (assuming VM -> containers makes sense for a thing). The salary needs to go higher for things that are less beneficial to the resume.
The industry at large asks most developers to stay up-to-date, so it starts looking suspicious when a company doesn't stay up-to-date too. For C# in particular, companies who have only recently migrated to .NET 5+ are now a red flag to me considering how long .NET Core has been out.
I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations.
In the latter case I would consider it a red flag if some long-deprecated tool turned up in the tech stack of a company, but there might be perfectly good reasons to stick to the former, a bunch of VMs, instead of operating a Kubernetes cluster.
I ran a small Kubernetes cluster once and it turned out to be the wrong decision _at that time_. I think I would be delighted to see a job ad from a company that mentioned both (common hypervisors/VMs, containers/Kubernetes) in their tech stack. Without more information I would think that company took their time to evaluate their needs irrespective of current tech trends.
I'm hiring for a company that is building a tech stack of VM's. My username at mastodon or twitter has the details, and it's about working with https://github.com/purpleidea/mgmt/
Even Microsoft themselves have a bunch of products that still require .NET Framework.
SharePoint CSM, Dynamics, SQL Server CLR, Visual Studio extensions, Office AddIns.