zlacker

I would be hesitant to claim "the world is moving to" anything, really. 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.

And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On the other hand there are systems that are not designed to run in a container and there is frankly no need to, because not everything needs to scale up and down or be available 100% of the time at all costs.

I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.

>>karmar+(OP)
Not disagreeing with you there; technology lingers for many years. But in terms of market share and mind share, configuration management has shrank in dominance and I suspect it will continue to do so.

>>karmar+(OP)
>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.

>>hnthro+Uo
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.

>>karmar+(OP)
> I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.

I think so too, however "mgmt config" builds a lot of radical new primitives that Ansible and Puppet don't have. It's been negative for my "PR" to classify it as "config management" because people assume I'm building a "Puppet clone", but I really see it as that space, it's just that those legacy tools never delivered on the idea that I thought they should have correctly.

>>karmar+sD
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/

>>hnthro+Uo
Even Microsoft themselves have a bunch of products that still require .NET Framework.

SharePoint CSM, Dynamics, SQL Server CLR, Visual Studio extensions, Office AddIns.