3 ms·
So, I am old enough that when I started my career I was just a "system administrator" who happened (rather luckily) to work primarily with BSD and Linux servers
by BirAdam 4y ago
So, I am old enough that when I started my career I was just a "system administrator" who happened (rather luckily) to work primarily with BSD and Linux servers. At that time, I was still learning a lot. I eventually learned enough and gained enough experience to become a "systems engineer" which meant that I could architect solutions for customers of my employer. I then became a senior systems engineer. Throughout this entire time things like Chef, Puppet, ansible, and Salt were not widely used even after they were created. Red Hat pushed ansible really really hard once it came out, and config management became a thing. The combination of config management systems with containers created two new roles: DevOps, SRE. Servers became VMs, which in turn became container platforms. Config managers took the place of version control and a bash script. CI/CD became weirder. In times past, you would have something like HAproxy on FreeBSD, which would then send traffic to Apache/Nginx servers, which in turn sent traffic to PHP servers, which called data from database servers and an NFS cluster. Now, behind the scenes, you may still have HAproxy or other load balancers, but those are combined with something similar to OpenStack with an underlying storage system like Ceph. All of that may get partnered with geo-aware DNS if you're really fancy. Systems engineers and admins are still managing that stuff behind the scenes at Azure, AWS, Google, RackSpace, Cloudflare, DigitalOcean, and other places (or at least I imagine so). There are also engineers who specialize in OpenStack. Most, however, have transitioned to the new roles of DevOps or SRE, because the need for highly skilled SEs and SAs has waned.
Essentially, these roles have narrowed the focus of system administrators and systems engineers. In one, you are concerned with CI/CD, and in the other you are making and maintaining cloudy solutions for people. This is yet another layer of abstraction for people, but it also means that most people do not know how to configure underlying software anymore. Because they lack knowledge of how to configure underlying software, they also require automation frameworks. They now do not know how to automate their workflows with Bash, Ruby, Python, or anything else. They need the cloud system to do it for them, which means that they get very vendor locked.
EDIT: the plus side of a new abstraction layer is cheaper tech departments at non-tech companies (fewer and cheaper personnel); which also means that pretty much everyone wants to be a software developer now, and very few people want to be SAs, SEs, DOEs, or SREs; you have to know everybit as much but you get paid much less.
All of this may bust. Increasingly, more and more people are becoming wary of monopolistic tech giants. The cost of their datacenters on the planet is increasingly rapidly. The governments of the world are growing wary of their increasing power. For businesses, complete reliance on a third party who has vastly more power isn't as palatable as it used to be. We may see a resurgence of smaller DCs and bare metal deployment, but any such change would only happen if another massive tech bust occurs. The reality that I see is that we may see both models live in tandem indefinitely, as there are differing use-cases that make either more suitable.