23 Things Only 90s Sysadmins will Remember

Sometimes it’s a beautiful combination of laugh-inducing and cringeworthy as we look back on the start of our careers in IT. University and College students starting this September will have grown up entirely post-Y2K. Having grown up in enterprise IT through the 90s, I bet that you can share these things that will make you smile a little.

Feel free to drop in comments with your own fun memories of technology in your career!

Token Ring

That’s right, folks. Ethernet wasn’t the first networking that was adopted in the enterprise. As a 90s administrator, you’ll remember the pre-switching days and the ever-enjoyable experience of chasing down beaconing devices on a network as the token made its way downstream. The physical click as a network card lit up the port on an MAU (or MSAU for the traditionalists of the Multi-Station Access Unit). Those nifty little tokens flew around the physical and virtual ring at 4 or 8 Mbps which felt like a jet car compared to the BNC serial networking before it. The late 90s brought switching and 16 Mbps with a protocol battleground laid out, to be won over by the Ethernet adoption at 10/100 Mbps and a much lower cost.

IBM PS/2

Enterprise computing needed enterprise computers. The price tag on an IBM PS/2 (aka Personal System 2) was steep, but the easy to replace parts and enterprise support agreements with many IBM-centric shops (aka Big Blue customers) were swimming in stacks of the IBM PS/2 systems. You also remember the Micro Channel architecture and that popping feeling as you pushed in the floppy drive ejector. Classic days!

Autoexec.bat and Config.sys files

Gamers will know this challenge especially well. Should we load into high memory? What drivers can I put before the OS and game? What can I strip out of the boot system to let things run faster? This was also the first appearance of MS-DOS getting a login screen as each nerdy sysadmin mastered the science of ASCII art to welcome their users to the freshly booted system.

Novell certifications were hugely valued

VMware wasn’t even on the radar (only to be launched in 1998), and Microsoft was still finding its feet in the certification space with NT4 only making a slow transition to Windows 2000. Novell dominated the file server and identify management (+1 for NDS, always) environment of many entrerprises. Even the small business servers were often running Novell NetWare and the badge of honour was the length of uptime you could have on a server. Administrators flocked to the CNA (Certified Novell Administrator) exam and then upped their game with the challenging and more rare CNE (Certified Network Engineer).

Brain dumps for certifications

Certifications were becoming a hot commodity, and so were brain dumps. These were online repositories of “hypothetical” questions (often word-for-word renditions) and multiple choice answers with the right one chosen for you. This led to the addition of some strongly-worded NDA statements as you sat for a technology certification, and also the familiar 8.5×11 whiteboard and box of kleenexes in every exam cubicle. Some say the kleenexes were for the tears of sysadmins who didn’t make the cut, rather than to wipe the dry-erase board.

“Paper” MCSEs

As Microsoft Certified Professionals poured out of certification centres at an incredible rate, we also saw a large number of tech pros leaning forward to the full MCSE (Microsoft Certified Systems Engineer). The issue among the tech community was that certification schools and boot camps were popping up like wildfire and producing dozens to hundreds of MCSE recipients in a matter of days using tools like brain dumps and teaching 100% towards test materials. This led to the industry (mostly old CNE techies) labeling these as “paper” MCSEs which meant they only got the cert but lacked any real experience.

Deploying Windows 95

There were actual videos featuring the cast of Friends at the launch of Windows 95. This also led to pain an suffering among the joy of successful deployments company wide for sysadmins everywhere. The standardization of the corporate desktop became a new possibility thanks to ADM files, imaging processes and more. This was the dawn of a GUI-driven enterprise with no turning back.

 

Ghost

This was actually an acronym as GHOST (General Hardware-Oriented Systems Transfer) which started as a PowerQuest tool, later bought by Norton, and eventually Symantec. Using a nifty tool to clone hard disks meant speeding the deployment of DOS systems and eventually Windows systems (thanks to the magic of SID regeneration in later versions). Sysadmins finally learned the value of automation and got away from the disk install or network installs of operation systems.

 

EBCDIC

This is for the print shop admins who spent time in those Big Blue customers. You may have even administered a BARR print system at one time and learned of the oddities and challenges of converting print protocols. EBCDIC (Extended Binary Coded Decimal Interchange Code) was the peripheral code standard and eventually gave way to ASCII as distributed printing became cheaper and more popular. It also cut down on the number of print paper carts rolling through the offices all hours of a day and probably ended a few mail room jobs.

Replacing Coax with Cat5

BNC, yeah you know me! Coax and BNC was the early peer-to-peer networking wire of choice (or lack of choice) and was quickly giving way to the use of Cat5. We quickly bypassed Cat3 for the Cat5 UTP (Unshielded Twisted Pair). I bet you can still recite the wire colours and the order to create a crossover cable with your own punchdown kit.

 

Laplink Cables

Life comes at you fast in networking. At the same time, there was nothing more popular in the help desk and desktop support office as a lap link cable. For those who enjoyed the slow, reliable, parallel-to-parallel port goodness to transfer data between machines, Laplink software and associated crossover cables were your friend. By the 90s, these became rare, but I’m betting you held onto your cables a little longer than we all should have just because of nostalgia.

Lotus Notes and Novell GroupWise

Not only was I a Certified Lotus Notes Administrator, and Certified Lotus Notes Developer, but I was one of a handful of GroupWise-Certified Novell admins around town.

We were in the heart of a war over the de facto email standard, and productivity software was the new panacea. Lotus Notes possessed integrated email, directory services, Internet email, and applications (known as databases…much to the chagrin of legit DBAs). If it wasn’t for wide proliferation of HTML applications and rapidly adopted internet standards, you’d probably still be logging into a Lotus Notes client today.

Java takes over the development world

Write Once; Run Anywhere. That was the tagline and mantra of the Java developer. Write once; run slowly, and probably on the wrong version, anywhere, was the tagline and mantra of sysadmins. Java was fighting the Microsoft suites for dominance in the enterprise application market. Little did we know that the often despised (by sysadmins at least) language which was rapidly evolving, would continue it’s growth AND still leave a wide door open to .NET and the Microsoft tools.

READ WHY THEY DECIDED TO CALL IT JAVA HERE

Tower servers

The only pizza boxes in a 90s data centre were the empty ones left by sysadmins after an overnight upgrade of Windows NT or a Novell Server. While the Unix folks logged into their Sun Microsystems servers remotely, the rest of the Wintel kids were piling up server towers by the dozens along two-tiered shelves in every server room. Rack servers became more prolific in the later 90s, and we bid good riddance to the mini-towers of every shape and size.

Installing Windows 3.1 from multiple 3.5” diskettes

Many operating systems were so large that they spanned multiple diskettes.  Those pre-CD days were not fun.  I’m guessing that you’ve held onto a stack of 3.5″ diskettes, carefully sequenced for an installation.  This also led to the fun of having 40 of 41 diskettes and not being able to install.  Disk 31 was like the proverbial sock eaten by a clothes dryer for a sysadmin.

Zip drives

Hey, it was pretty cool to her able to cram 100 MB on a single piece of physical media. As you inserted the almost Nintendo cartridge shaped cassettes into the Zip drive and it clicked and whirred, you smiled your nerdiest smile knowing you could fit 70 floppy diskettes on a single Zip drive. You felt like a storage king…until the CD-R and CD-RW became easily affordable, and much faster…which didn’t take long.

PCMCIA cards

Laptop peripherals were as awful as you could imagine. Being expensive, difficult to carry, or just unavailable was the biggest challenge of the enterprise laptop user. How could you have a modem, an ethernet card, and a sound card in that Toshiba laptop?! Easy! Carry a stack of PCMCIA (or PC Cards) in your laptop bag to swap out as needed. Ahhh the smell of early standards.

The magical sound that indicated a 56k connection

Forget the pain of not having Google Fibre. How about crossing your fingers that you get the full rocket-like speed of 56k versus 33.6 which was triggered by that telltale sound in the midst of a modem handshake. The next generation of Internet users will only know the pain of 3G versus LTE and believe that Edge is abysmal (which is nearly 4 times the bandwidth of a 56k connection).

T1 lines

High speed networks in the data center began with T1, Fractional T1, and if we were lucky, upgraded to a T3. With a T1 being around 1500$ per month, it’s hard to imagine that a 1.544 Mbps line can even compare against today’s 49.99$ per month for 5 Mbps residential internet connections.

3270/5250 emulators

The mainframe is the heart of most of our financial, insurance, and retail businesses. As we moved to the next generation of distributed computing and Windows desktop operating systems, we needed to install emulators for the clunky (yet strangely reliable) 3270 and 5250 terminals. Long live the green screen!

The Internet was new

Compuserve and AOL were the leaders in delivering this magical new thing called the Internet. Curating your experience and filling your mail with physical CDs to win over as many clients in the pay-per-hour fight for subscriber dominance. Ironically, by the end of the 90s, AOL would buy Compuserve and most of us were far beyond the initial stages of Internet access. Google would launch in 1998 and change things greatly.

 

 

 

All Software being named 2000

We knew that the decade was closing out. It also caused a sudden and unnecessary urge for software makers to appear leading edge by naming everything 2000. Windows 2000 is probably the most memorable of these. As we look back on products that released late or didn’t last beyond that landmark year, the idea of attaching a release year to the product name is definitely a fairly bad idea. Somehow Microsoft is one of the only ones who holds onto this nomenclature to this day.

Celebrating NYE 12/31/1999 in a data center

Nobody had any idea how the landmark New Year’s Eve would be spent a decade earlier. Little did we know that the lustre and shine of a career in IT would also mean toasting your fellow sysadmin with a bottle of Baby Duck in plastic cups at the office during a short 15 minute break watching the countdown to midnight. This led to worldwide checks of patches and fixes which were the result of a decade of work after someone, somewhere doing what we all do in IT…going to production without gathering requirements first. Besides, who would have thought we would need more than two digit years, right?!




All about:virtualization

Thanks to the great community that has been build around virtualization, cloud, and everything that I’ve been writing about for many years, I have been given some great opportunities to create content to share in those communities.

In my role as Technology Evangelist for Turbonomic, I get to contribute to a very cool community blog which is called about:virtualization that features content related to virtualization, cloud, development, networking, and much more.

Just in case you didn’t already find that content, here is the link to be able to read articles there including some from me, and many other great content contributors from the industry.

about-virt

http://discopos.se/about-virt

Want to contribute to about:virtualization?

We are always looking for community content that can be hosted at the about:virtualization blog.  If you are interested in creating content and being able to get your voice out to the community, please email me to eric.wright {at} vmturbo.com with your contact information and I’ll get you on the road to being a published blogger!

 




DiscoPosse Review: The Phoenix Project

phoenixbookThis book is indescribably awesome. That could be the review itself, but I want to dive into how I discovered this book and what makes it such an amazing read.

At the most recent Toronto VMUG full-day event we were lucky enough to have Nick Weaver as our keynote speaker with a great presentation titled Automation Generation. For those who aren’t already following Nick’s work at http://www.nickapedia.com you should know that he is one of the driving forces towards automation, orchestration and the adoption of DevOps methodologies.

DevOps Revolution!

The DevOps methods are quickly gaining adoption, and with good reason. While it may seem like an unreachable goal to many IT Operations teams, the truth of the matter is that just like running a marathon it all starts with just one step.

Understanding where you can make gains from automation, and process improvement with Agile methodologies is the real first step. The challenge that most teams face is in getting the analysis underway to realize just how easily, and efficiently you can apply these new processes and methods to your current team.

The Phoenix Project

Written by Gene Kim (@RealGeneKim on Twitter) Kevin Behr (@kevinbehr on Twitter) and George Spafford (@gspaff on Twitter), The Phoenix Project presents a fictional story of Parts Unlimited, a company which is on the verge of an IT breakdown. Under the gun to produce Project Phoenix, a massive system which is overdue, over budget and tearing the IT organization and business departments apart.

The book takes you through the transition of a Bill, the new VP of IT Operations being thrust into the fire pit and how through the almost Zen-like guidance of Erik, a prospective board member, he leads the IT organization and the business leaders into a new way of delivering IT services and fully integrate the business process into the end products.

Who should read this book?

Everyone. Literally, everyone who is in an IT organization, or who is in business today should read this. The story, and the concepts presented in it will inevitably map against your current organization in one way or another.

While you may not be positioned to lead the organization into change like our character Bill, you can be a proponent for change in your own portion of the business and even in your home life.

This book delivers realistic concepts without droning through IT delivery methods like many books have been known to do. What makes it extra fun to read, and more applicable, is that the story is using real examples of the application of DevOps methods and where the challenges come along the way.

Three simple words: Read This Book!

Available through Amazon by clicking the image below:

 




What Jaws taught me about Information Technology

Sometimes the greatest life lessons can be inspired by other events. Perhaps a movie, song or something that inspires you to think differently about something that you do in life and at work. What I’ve learned, and want to share with you today, is that a lot of great strategies and lessons in IT and Systems Architecture can use the move Jaws as a parable.

Note: This is pretty much all inside humour for folks who’ve seen Jaws way too many times like myself 🙂

City Hands: Theory versus Implementation

When Quint first meets Hooper he comments that he has “city hands”. This is what we see in the industry sometimes when those of us who’ve been in the trenches first encounter the new staffer who has gathered most of their experience from theory, reading and limited lab time.

QUINT: Porkers! Talkin’ about porkers! Mr. Hooper. Just tie me a sheep shank.
HOOPER: I haven’t had to pass basic seamanship in a long time. You didn’t say how short you wanted it. How’s that?!
QUINT: Give me your hands. Dogfish? When you got a 5000 dollars net, you got 2000 dollars worth of fisherman. And along comes Mr. Whitey, by the time he’s finished with that net, it looks like a kiddy’s scissor class has cut it up for a paper doll! You got city hands, Mr. Hooper. You’ve been counting money all your life.

The lesson that comes from this is that, as we know, implementation will often differ from the plan or the theory due to unforeseen circumstances and limitations that couldn’t have been, or just weren’t accounted for in the early design. Implementation needs to be done from a solid design with the understanding that when the rubber hits the road that we may have to work a little to get things to follow the desired path.

It’s not that the theoretical knowledge isn’t valuable, but we need to temper our design theory with some real world implementation or even extensive lab deployment can help to strengthen the overall understanding of how systems really act when we need to bring them up in a real environment. The manuals only get you so far.

The Cage: Requirements Gathering

QUINT: Whatta ya got here? Portable shark cage, or monkey cage?
HOOPER: Anti-shark cage
QUINT: Anti-shark cage? You go inside the cage? Cage goes in the water? You go in the water? Shark’s in the water…our shark….Farewell and adieu to you fair Spanish ladies…

As the role of the seasoned IT guy, Quint has a little chuckle over Hooper’s plan to use a cage to get up close and personal with the Shark. If you’ve had the pleasure of being in a requirements gathering session, you have bumped into this before. You are often presented with what seem like entirely impossible or at the very least implausible requirements for a new system or process.

We’re Going to Need a Bigger Boat: Capacity Planning

This is probably one of the most famous lines from the movie, and ironically it was ad-libbed by Roy Scheider who plays the role of Chief Brody. Much like the Chief Brody figured out when he first saw the shark for himself, we are faced with this realization in our IT world quite often.

jaws_biggerboat

My old rule of thumb for capacity planning is take the original plan for growth, and multiply by 2.5 to get a longer term plan. With the cost of disk and memory dropping in recent years, this is an easier sell. Remember of course, that CPU sizing doesn’t follow that rule. In general we have to take heed with adding multiple CPUs because there are many more factors when adding CPU versus adding memory. This is a careful balance that your lab time will help you with.

While we can’t always deploy with a large system out of the gate, you should at least have a plan to be able to augment your system once it is live. Knowing whether you will hit limitations with growth is as important as having lots of space to begin with.

Those Beaches Will Be Open!: Fighting Deadlines

jaws_badpress

MARTIN: Larry, Larry, if we make an effort today, we might be able to save August.
MAYOR VAUGHN: August? Heh, for Christ’s sake tomorrow is the fourth of July! And we will be open for business. It’s gonna be one of the best summer we ever had! Now if you fellas are concerned about the beaches, you do whatever you have to , to make them safe. But those beaches will be open for this weekend!

Sound familiar? The business has set a launch date before the start of the project. It seems entirely reasonable, until scope creep and project delays push out the time-lines until they all start getting dangerously close to the launch date. Unfortunately with the traditional waterfall project methodology, we sometimes have trouble backing away from features and enhancements which impact the deliver-ability of the project..

Agile project methodology and Agile development can alleviate this a little better with shorter sprints and features being managed and dropped as needed as each sprint arrives. The end result of any project is that you may be faced with 23 hour days to hit the launch target if it is set in stone.

The moral of this story is to track your implementation and stay aggressive on limiting scope creep. Deadlines based on dates and not features can be the bane of any IT staffer’s existence and certainly makes our jobs more difficult.

You Knew All Those Things! *slap*: Disclosure

MRS. KINTNER: I just found out, that the girl got killed here last week, and you knew it! You knew there was a shark out there! You knew it was dangerous! But you let people go swimming anyway?!You knew all those things!

jaws_slap

When we have an awareness of potential danger or design flaws in a technology project, we have a responsibility to notify the business sponsor and our own management of those issues. This isn’t just so that we can have that “I told you so” moment if issues arise, but a safeguard for the project to highlight potential problems. While we all know that our warnings often slip through the cracks and may not get the attention we hope they would, it is still an absolute necessity to voice valid concerns as early as possible, and to the right audience.

Hopefully, if we do encounter that moment when a system fails despite our warnings to the business owner, that their reaction is a little less painful that what Mrs. Kintner doles out to Chief Brody.

He Can’t Stay Down With Three Barrels: Performance Testing

jaws_threebarrels

QUINT: He can’t stay down with three barrels on him, not with three barrels he can’t.
CHIEF BRODY: What about us?
QUINT: Hooper, get the pump outta the locker in front of you, will you?
CHIEF BRODY: We’re gonna sink aren’t we?

Performance testing is not just something we do for fun. It is designed to give predictive results for the launch and design of any system. We often forego testing in a project due to the time constraints and lack of understanding of the performance requirements of the new system.

Experience tells us what we should expect, but the only way to provide comfort to our business sponsor and to our IT management teams is to gather real results before we put our system into production. Nobody wants to be at a launch party to then watch everyone’s phones and pagers light up that the system just ground to a halt because of load.

An often misunderstood area of IT, I highly recommend that you invest time in learning about I/O performance, bottleneck identification and testing tools for web and client/server systems. There are some great free tools out there, and that knowledge can change your status from scapegoat to hero if we do our part to design for high volume scenarios at the onset.

The U.S.S. Indianapolis scene: How IT Community Helps You Learn

Sometimes the greatest experience comes from sharing war stories with others in your industry. Comparing scars and horror stories of how implementations went completely sideways, passing along tips learned in the hard way. You can get great value by participating in IT communities like the VMware User Group (VMUG) and other IT community groups.

It can be a great learning experience just to be involved in discussions about how real product and infrastructure deployments have gone. It can give you an insight into the pitfalls and good methods to do many things. You can learn significant amounts about technology just by being in the right crowd. Don’t be afraid to ask questions and be a good listener. One day you will have your very own U.S.S. Indianapolis version of an IT story to share with a new sysadmin.

And we close with that. I hope that you enjoyed it.

“Farewell and adieu, to you fair Spanish ladies…”