[nycbug-talk] Hypothetical: the end of the sysadmin/systems engineer/DBA?
swygue at gmail.com
Tue Mar 30 09:49:59 EDT 2010
On Sat, Mar 27, 2010 at 11:01 PM, Marc Spitzer <mspitzer at gmail.com> wrote:
> Solve hard business oriented problems and you will make money. None
> of the things you listed is particularly hard or particularly
> business oriented. What you want to be is the guy that people come to
> that can say "ok I will figure it out" and they go away happy because
> you will and they will pay you money to do so.
> Tech is tools, mechanics need to know their tools and know how to use
> their tools. But if all you know is tools how do you fix cars? And
> you are in the business of fixing cars not knowing tools. Figure out
> what *your* cars are and how to fix and improve them, this will help
> you select the tools you need to do the job. Two I would recommend,
> and am working on my self, are project management and writing. Others
> your mileage may vary.
> On Sat, Mar 27, 2010 at 2:56 PM, Matt Juszczak <matt at atopia.net> wrote:
>> I'm still a little confused by all these replies. So all in all, what skills would be best to focus on over the next few years? I do agree that hardware specific skills will fade unless you're really advanced.
>> But what about systems engineer type skills? What if you're good at things like nagios, puppet, ldap, apache, mysql, postfix, etc etc. Will that matter?
>> Will it come down to just two types of people: developers, and implementation experts?
>> -----Original Message-----
>> From: George Rosamond <george at ceetonetechnology.com>
>> Date: Sat, 27 Mar 2010 14:47:09
>> To: Marc Spitzer<mspitzer at gmail.com>
>> Cc: Matt Juszczak<matt at atopia.net>; NYCBUG List<talk at lists.nycbug.org>; John Villa<john.joe.villa at gmail.com>
>> Subject: Re: [nycbug-talk] Hypothetical: the end of the sysadmin/systems engineer/DBA?
>> On Sat, Mar 27, 2010 at 12:11:16PM -0400, Marc Spitzer wrote:
>>> On Sat, Mar 27, 2010 at 10:57 AM, Matt Juszczak <matt at atopia.net> wrote:
>>> >> build process and you fix the build process. ?Now doing this right is
>>> >> a high skill task, trouble shooting a box has become a low skill task
>>> >> and the middle get squeezed a bit smaller.
>>> > So where are the lines drawn? ?If someone who has experience only in the
>>> > things you specify, like running fdisk, debugging broken servers, basic
>>> > installs, etc., then I agree that type of skillset is going to be less and
>>> > less in demand. ?But what about people with more knowledge? ?Knowledge in
>>> > LDAP, CF Engine, Puppet, Apache - those sorts of tools, and even more
>>> > important, standardizing servers (central authentication, central
>>> > authorization, sudo in ldap, etc.). ?Are these going to be automated as
>>> > well?
>>> Personally I think you want to keep an eye on the system side and not
>>> so much on the server side. I expect that other then fans servers
>>> will have no moving parts fairly soon, 5 years or 10 at the out side,
>>> as plater drives get replaced by SSD drives, there goes a lot of work.
>>> Also properly designed servers, for example HP's, are very fast to
>>> work on, again there goes some work. So you will have less to do and
>>> what you have to do will take less time, any manager will tell you
>>> that means reduce head count.
>>> > Think about this: will there be a time when competitors no longer compete,
>>> > because major providers will automate the instance creation of environments
>>> > (for instance, Amazon may choose to make a one-click environment that uses
>>> > puppet for configuration, openldap for authorization/authentication, postfix
>>> > for email, and a few other tools for things like monitoring). ?Would
>>> > competiting tools (like exim, for instance) be run out of demand as more and
>>> > more people go to these "one click" approaches and choose not to replace
>>> > them?
>>> Well for postfix, at the time it was written sendmail was the MTA on
>>> the internet, no not so much. Good ideas do tent to survive and
>>> prosper. But the need to be much better to be worth the pain of
>>> switching. Postfix is as long as you can live with a mail switch as
>>> sendmail is a mail router, switch == internet only and router ==
>>> internet to other network(ex. decnet).
>>> Also traditional sysadmin skills include areas like security, security
>>> is a growth industry. Disaster recovery, capacity planning, building
>>> cloud physical plant for people who want the cloud but need to keep
>>> data private and a bunch of other skills. And to reply to the exim
>>> bit, what is stopping exim people from taking the dam thing and
>>> replacing postfix with exim and uploading it for people to use?
>>> I think the SA world is going to split along the lines of people who
>>> build integrated circuits, people who build things with integrated
>>> circuits and people who put IC's in sockets, Figure out where you
>>> want to be and get there. Two of the three will pay well.
>> I think the problem with approaching this question is everyone gets very linear in their estimations.
>> The waves and troughs vary in depth and breadth.
>> What would your guest-imates be if the internet (really) "Balkanized"?
>> What if technology goes into something of a stagnation or a decline? Certainly whole periods of history are full of such happenings.
>> Even look at the shallow yet explosive technology boom of the late 90's. From new web browser releases, IDS systems, etc., every six months. .. to a certain amount of stagnation for a few years post-2000.
>> Assuming there continues to be forward-moving trends, though, I'd agree with Marc about the "less moving parts" idea. . . that is already in flux, and it's hard to believe on desktops/laptops/stand-alone servers/devices that this trend won't continue. Oh, right, it's kind of like old-school terminals in the terminal-mainframe model.
>> More generally, what about the cloud?
>> Well, if someone figures out how it's dramatically different from clustering, network-wide file storage, etc., then it would be worth approaching as a distinctive trend.
>> However, lots of development in security devices and apps, management tools, control panels,
>> etc., will certainly go hand-and-hand with the (possible) cloud growth.
>> The 1990's explosion of colocation centers, company and carrier-neutral, certainly opened some deskilling among a layer of staff at those places, and also opened up "differently skilled" technical people into the world of higher uptimes and networks. This is also the case with various hosting packages, available all over.
>> That was a more significant trend, IMHO, then the (in the) cloud talk.
> Freedom is nothing but a chance to be better.
> --Albert Camus
> The problem with socialism is that eventually you run out
> of other people's money.
> --Margaret Thatcher
> talk mailing list
> talk at lists.nycbug.org
Your are on point, your reference to the tripwire yellow book is
exactly how things are done at my place of employment. One of my
primary roles is to migrate our tomcat application from Windows to
Linux, I'm in between development and the application support teams.
One day, after spending another week troubleshooting an issue that
turned out to be a application configuration problem again. I turned
to my manager and told him we need to adopt a policy of rebuilding
systems rather than troubleshooting. I suggested this because I
realize that its difficult to troubleshoot something you don't have
control over, when you have another team that insist the issue is on
your end and you have to prove them wrong before they take a closer
look at their configs.
You also mentioned project management and writing, you are absolutely
right about that as well. One thing I've realized since working as a
sysadmin is, you don't come across developers or support personnel who
understands infrastructure or understands something simple as how the
OS you are running boots. My writing skills sucks, and my project
management is improving. The little I know of both has helped me deal
with these two groups of people which lead to us "Solving hard
business oriented problems". I've also noticed some people in IT just
stopped learning, and sadly some of these people are now managers, so
knowing how to articulate something in writing can take you a long
If you understand the business you will make sysadmin decisions that
improve business, and every company values that.
- Rodrique Heron
swygue neron --->>
More information about the talk