I remember reading an article on one of the technology news sites back around 2012/2013 expounding upon the writer's view that the systems administrator role was DEAD.. that anybody in systems administration who cared about their livelihood should be looking for what's next, and soon.  I don't recall if the author provided any insight into their own profession, but I clearly recall that the article felt like it was preaching about a looming cataclysm for sysadmins, as though it would personally impact that person.

I also remember thinking that the author may not have quite the firm grasp of the situation that they thought they did.  Here we are 10 years later, and system administrators are just as necessary now as they were back then.  In many organizations, the role is pretty much EXACTLY what it was 10 years ago.  In others, it's changed a bit, but is still necessary.  So what was it that the author missed, or misunderstood a decade ago?

Actually, it's pretty simple.  Automation has come a long way, but we don't yet have systems building systems intelligently, from nothing.  Somebody still has to do the initial legwork to set up the templates or instances, and maintain those.  Somebody has to keep the lights on, perform troubleshooting, stand up new hardware, take down old hardware, and just generally do all of the design work for new projects.  Somebody also has to write and maintain all of the automation.  The hard reality, though, is that the need for keyboard jockeys and simple operators is dwindling.  Any job that requires pushing buttons or monitoring things, like backups, can be pretty nearly automated now.  Systems can be patched en-masse via automation now.  It's still good to have a trained administrator make the rounds after patching completes to make sure everything is still solid, but this is increasingly the job of the senior admin.

DevOps, microservices and container technology, when properly configured, are eliminating the need for downtime.  These are highly complex installations and require highly trained individuals to build and manage them.  Cloud environments, public and private, require skilled administrators to manage the moving parts on the backend.

The big difference between systems administration in 2012 and 2022?  Those individuals who just need a job, and are technologically inclined, but not passionate about what they do... end up moving on to other professions.  These people aren't staying current, they aren't learning the advanced technologies.  They ARE being automated out of jobs.  The jobs are still there, but the focus is increasingly on advanced skills in addition to solid sysadmin capabilities.  Everybody has to do more with less.

Systems Administration is as much of a mindset as it is a discipline.  It's more than managing systems.  I personally have always maintained that sysadmins are the glue that holds the enterprise together, because we HAVE to know how all of the pieces fit together.  We have to know the network configurations.  We have to know the system configurations.  We have to know which systems connect to which other systems, and how.  We need to know which databases are used for what, and what needs to access them.  We have to have a strong understanding of the security profile for the business,and how it applies to all of the above.  We basically have to clearly grasp the 'big picture' of the enterprise.

When I've gone into customers and found them spending large amounts of time putting out fires, it's often because that organization artificially encapsulates its sysadmins into tiny boxes, and ends up without anybody who really knows how it all fits together.

If you find yourself on the path to becoming a systems administrator, or are already one, but are concerned about the future of your position, the best advice I can give is this:  

  • Understand that properly built and managed systems manage themselves, so if you're constantly putting out fires, its likely you're missing the 'properly' part of that statement.
  • Take responsibility for your enterprise.  Own it.  The better you understand all of the moving parts, the better you'll be able to manage it.
  • Make the effort to learn the big picture.  Talk to the network team.  Talk to the DBAs.  Talk to the applications teams.  It doesn't matter if it isn't your responsibility today.  Think of it this way... if you're the expert on the enterprise, and you automate yourself out of a job, you'll still HAVE a job because you're invaluable to the company as the person who can keep the lights on.  Also, you'll be the best candidate to help design and implement NEW projects because you'll clearly understand how they should fit in.
  • Don't be satisfied with your current skill level or training level.  You may be awesome, but there's already new technology you're not aware of, and it could show up on your desk tomorrow.
  • always aim to be the best in the industry at your job.  It's a tough goal to hit, but it's worth the effort.
  • Mentor others - the best way to hone your understanding of anything, is to teach it.  You learn pretty quickly just how limited your knowledge was previously.
  • AND remember that you probably don't want to be a sysadmin forever... there are other, higher level positions that will interest you that are NOT management.  You may just need to move to another company to find them.  Some of those positions include:
    • Sales Engineer
    • Solutions Architect
    • Systems Engineer
    • DevOps Engineer
    • Systems Architect
    • Cloud Architect
    • Chief Engineer
    • Chief Architect
    • Technology Director
    • CTO

Some of those other roles require additional skills, and often there's a progression.  Keep learning, try to climb out of the cave and interact with real people every so often, and slowly develop some diplomacy.  A trained, quality sysadmin is a huge asset when they move into the higher roles, because you have a MUCH better handle on the big picture, which lends itself VERY well into Engineer and Architect roles.

For over seventeen years of my professional career, I was a systems administrator at one level or another.  I've managed just about every version of UNIX that's ever been, and been a core team member for two related Desktop Linux distributions.  Much of my career was spent managing Red Hat Linux.  I was just like every other sysadmin out there - I was the master of my domain, and knew more than any VAR resource that might show up at our doorstep.  I certainly never needed any help, and I know that's the way many other sysadmins feel.  You can't admit any weakness!

The thing about that mindset, though, is that no matter how smart you are; no matter how much reading you do in your spare time; no matter how fancy your sandbox at home; you simply can't keep up with the pace of change on your own.  I exist on the VAR side of IT now, and I see what's coming down the pike.  The future of IT is only getting more complex.  It's necessarily crossing team boundaries.  It's creating chaos and disruption in IT shops that are insisting on sticking to the traditional lines of battle.

Ten years ago, things were somewhat complex in that we had to understand the way our expensive apps were constructed, which systems have to be built how, which ones need to talk to which other ones, what version of application server is required, etc.  But by today's standards, that was elementary by degrees.  At least then we had a document that called out how it should all be built.  Today we have TRULY complex systems, where there are no fewer than ten completely different products within a function swim lane which could theoretically do the job, but no clear indicator as to which ones will interoperate properly. 

Trying to go DIY on something like a Kubernetes deployment, while earning you Kudos up front for being able to make it work, may indicate your chops as a sysadmin, but in the long term, this a very clear instance of where you should engage the help of your favorite VAR.  Where it's new and interesting (and built atop a plate glass floor that happens to double as the lid for a huge pit of alligators), there are way more moving parts here than you realize. 

Taking on this type of challenge is exactly akin to building your own Linux distribution in order to avoid paying somebody like Red Hat for subscriptions.  Is it doable in the short term?  Absolutely.  Is there a reason why companies like Red Hat employ thousands of engineers to manage their Linux product?  Absolutely.

When you read the blogs talking about Kubernetes and its shortcomings, understand that unless they say otherwise, they refer to the community version that you can download from Google.  To be very clear, that version of Kubernetes is NOT intended for use in production environments.  It is not hardened.  It is not secured.  It does not have any of the controls that an enterprise class customer typically requires to be there, like Role Based Access Controls.  If you want to play with the latest version in a sandbox, it's fine for that.  You need to understand all of that before you install it, then go on your blog and talk about what a piece of junk it is.  Very few things in life play out well when you try to use them in situations for which they were not intended.

If your favorite VAR has no idea how to help you on your DevOps journey,  talk to your Connection Enterprise, or Connection BSG rep and tell them you saw my post. (http://www.moredirect.com)  You owe it to your longevity in your career to start leveraging your partner resources.  I guarantee to you that there's a lot out there you've never seen or heard about, but they have.  They are presales resources, so it won't cost you anything.. and if they indicate that it will... again, contact Connection and I can tell you that it won't there.

In years past, demonstrating your sysadmin chops was a way of creating job security.  These days it's all about demonstrating how you can do more with less.  If you don't change with the times, your position will, and you'll be wondering why it's so hard to stick with one company.  Leverage your resources.  You'll look smarter for it.