I'm certainly not blaming you, Rob, and I fully understand the reasons why it happens this way. This wasn't meant in any way to accuse you of wrongdoing or even negligence, it's just a comment on the sad state of affairs.
I'm mostly complaining about the fact that DevOps was perhaps the worst idea we've had in systems since I came around in the early 90s, because it led directly to the "developer-ization" of Systems, which is horrible. I realize that the impetus was to get Systems Administration recognition for what it does, and hopefully to raise our profession's status to that of Development in the eyes of industry, but that was a predictable failure. Instead of more status, better pay, and more actual power, we've gotten the response of "Oh, you CODE too? Great - let me give you MORE work, and take away MORE power, but hey, we'll give you more responsibility!" And, of course, no more pay. DevOps people make the same as Systems Engineers, and less than equivalently-experienced. Which was the situation 10 years ago before DevOps came around. We lost the old position of Toolsmith, which at least used to be a real software developer that worked closely with Systems people and thus was fully aware of the requirements and limitations of systems/operational settings, and could code appropriately. Now, as "developer-Lite", we're expected to not only keep up with the fad-of-the-day in development land (and, thus, have to devote significant time and energy to actually having to learn to code in whatever is the "hot" thing right now), but the requirements of sys/ops are COMPLETELY glossed over. To quote a favorite movie line: Nice job breaking it, hero. NodeJS is a stellar example of this. Given the option, no sane systems person should ever allow something that incompletely developed/mature (and, I'm talking about the platform/language here, not specific apps) anywhere near critical infrastructure. App-land, maybe, but certainly not running systems services or doing stuff that has root-level privs. NodeJS is currently worse than Java 1.0 (i.e. 1.1.8) in terms of usability, reliability, and maturity for systems work. But, here we are, with all sort of systems tools written in half-baked platforms, in 19 different ways, none of which has any hope of being understood by the average systems person. Because they break ALL THE TIME, and no matter how good you are, I have yet to meet a systems person that can debug system-app-level problems efficiently in more than a couple of languages. For instance, a typical setup here at my place requires me to understand how to read stack traces of Ruby, Java core dump/stack traces, NodeJS errors, SQL dumps, Python errors, C/C++ core files, bash script errors, and that doesn't even include the Windows-specific stuff (PowerShell, .Net dumps, and VBScript crap). It's ridiculously impossible to be good at all that. Even sharing the workload across a team isn't practical, since you need at least 3 people to understand EACH setup well enough to get decent coverage. The numbers don't lie - you'd need a team of 6, presuming each person was good at 4 of the preceding. The environment has 3. So, when stuff breaks, the most we can do many times is take a brief look, look for stuff that sticks out like a sore thumb, and pray we didn't miss anything more. <sarcasm> Which does absolute *wonders* for stability and reliability. </sarcasm> And that's typical for most places. I can cope, because I've been doing this 20 years, and I've also got a lot more developer-style experience than typical for a systems person (I do release mgmt, also). But I weep for the new generation, because what happens is that they don't know what to learn that's useful, and the over-emphasis on the "Dev" in DevOps means that I see seriously deficient systems skills in the new generation, and a decided lack of emphasis on them learning those skills. This isn't the new gen's fault - they're being forced to learn the "tool of the week" and spent lots of time coding, when the reality is that systems are nowhere near transparent and automated enough to have us skimp on traditional systems-level knowledge, like performance (network and systems) analysis, understanding of hardware (i.e why is a Xeon X5500 different than a X5600), and the like. We've desperately needed reasonable, ENFORCEABLE standards for the profession for over two decades now, and we keep failing to understand that. At this point, the lack of a Professional Association (like the AMA or Bar Association, or heck, just the National Society of Professional Engineers) is really, really hurting the industry, and it's getting worse. Frankly, with all the technological advances we've made since 1990, we've taken several huge steps backward in professional standards, conduct, and developing the systems profession into something more than highly-skilled janitors. At least janitors have a union, and can reasonably get shit cleaned up. We can't. Sorry for the screed. I'll shut up now. -Erik On Sat, Sep 14, 2013 at 4:14 AM, Robert Fisher <[email protected]> wrote: > I largely agree with you Erik, but over the last few years, as admins > write more and more code, I have got used to the fact that baseline > standards for languages vary from site to site. . Back in the day we > *had* to use C, shell, and Perl, because there were no other options, > but now we've gone from famine to feast, and there's too much choice. > Whenever I'm asked to write code by any of my clients, I always ask > "what language do you want me to write it in?" The worst answer is: > "whatever you want". I much prefer to see a standard enforced, > whatever that standard might be. Otherwise, everyone does it in > "whatever they want", and no one understands anyone else's code. > r > At the site I'm on at the moment, Node,js is part of the standard > toolchain. We have lots of internal code written in it, so all the ops > team are comfortable using it. It's also used on our front-end, so we > can better understand what our developers are doing. My last job was > with a very big Chef house, so everything that was too much for a very > simple shell scripts was done in Ruby, because everyone already knew > it. > > These days, I can probably count on one hand the number of ops/admins > I know who are happy using C, and (decent) Perl knowledge is much > thinner on the ground than it was. I doubt I've done anything serious > in either of those for close on 15 years. I know critical pieces of > Solaris are written in Python these days, but IMO they shouldn't be, > and so far I've felt no pressing need to learn any more than the > rudiments that language. Obviously the shell wouldn't be an > appropriate language for handling HTTP requests, so I decided my best > options for SexyMF were Ruby or Node. (I'd never dream of writing > system software in Java, even if I understood the language well enough > to do so. > > I picked Node for two main reasons: first, I've been working > increasingly with SmartOS and Joyent products, and Node is most > definitely part of the toolchain there. Second, I wanted to know more > about the language, and there's nothing like doing a proper project to > get your head round something. > I didn't know that Node does run on SPARC until I was some way into > the project. If I'd realized sooner, I might have gone with Ruby. But, > it's been an enjoyable learning exercise, so no regrets. If you wish > to rewrite it in C, be my guest! :-) > > > Rob > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182180/21319143-b7837b05 > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
