Why Should You Build a Lab? - Series: Building an Infrastructure Lab, Part 1 (of many)

The importance of building a lab for doing testing is pretty obvious. Let's not pretend that this is a startling endorsement. For the majority of people out there who either do what we do or want to do what I'm talking about in this blog, they know it's something more than a good idea. In my opinion, it is the best thing you can do for your career.

It's pretty easy to tell the difference between someone who read about a concept to pass a test and someone who legitimately wanted to understand a concept so much that they figured it out on their own. Well, it's easy for someone in the latter category to spot the former, anyway.

Now, that probably sounds pretentious because it makes me sound like a know-it-all. The fact of the matter is that I'm far from it. One of the major reasons that I'm doing this blog is because I hope that by documenting my struggles and victories in my work and my own lab, I'll get better myself. Teaching others is another major reason, and teaching is one of the best ways to be a student.

But that brings me to the most important rule of all in the IT profession. Don't be afraid to be wrong! The second that you hold your tongue and don't let your curiosity get the best of you, you've lost out on an opportunity. You now know one less thing than you could have known and it's going to come back to bite you later. If you do this enough, the problem will become multiplicative and you'll find yourself in the worst position possible: having to unlearn something that was never right to begin with.

I've decided to kick off this series on building an infrastructure lab by listing reasons to do it in the first place. And, as I said, it's not because the people reading this are unaware of its value. It's because some of you need that extra kick in the butt to finally do it!

The rest of the series is going to be a lot more about planning, something that is often overlooked because people just want to wing it. But why would you want to forego something important like that?! When people "just wing it" in production, they get fired. Or well, you know, they get promoted. But let's not talk about Steve right now, that stupid jerk.*

*I made up Steve... but we all know a "Steve." 

So here are some other reasons for building a lab that you might not have thought of!

Exposure Beyond the Lesson Plan

I talked above about not being afraid to be wrong. But I'll also play the devil's advocate: there are times when you can't be wrong. As a consultant, I'm often in high-pressure situations with high-level company stakeholders. The only thing worse than saying "I don't know" is saying the wrong thing entirely.

By the way, your answer in this situation, when you're not 100% sure or maybe not even 10% sure, is that you are going to verify the answer first. Be honest. Tell them you don't want to say the wrong thing without all the facts. Sometimes you'll have someone that goes, "You have no idea, do you?" Of course you have some idea! You wouldn't be there if you didn't! But before I get sidetracked...

It is all those variables that come into play when you have to calculate the right answer. It's knowing their environment, which is the first and foremost reason why you might not know the answer. But beyond that, which takes you far beyond what any lesson plan can teach you, is how can the environment be set up? What's possible? What isn't possible? Those are two questions that, once answered, can answer virtually every other question.

There are the big picture elements that you learn from a book and other forms of instruction, but there are also the smaller pieces that you learn from doing. This is obviously a made up statistic, but I'd say about 90% of the learning comes outside of a lesson or a chapter. You need that 10%, and you need it first, but it's up to you to get past it.

Job Security

My client needed to know if changing the primary SMTP address in the manner that was described to them would interrupt mail flow to the original domain. I knew that it wouldn't, or at least I was almost sure. This came up during a meeting that I was attending. While they were talking about it, I remoted into my lab. I created a new accepted domain, configured the email address policy, and tested mail flow. Then, when the question came up again, I told them that it wouldn't be a problem. When they asked how I knew that, a little curious why I didn't say anything earlier in the meeting, I told them: I just tested it to make sure.

In their minds, this was a colossal change. It was the equivalent of building the pyramids. The reality is that it's not. Nothing is when you know how to do it. Testing that during the meeting was as easy as I described it above. But I couldn't have done it if I didn't invest time in building the lab beforehand.

A lot of companies don't have "test," "development," or "lab" environment. Keep in mind that those are three separate things... with even a fourth distinction possible for "pre-production" environments. While that's a horrible tenet to omit from standard business practices, it makes your own lab space that much more valuable.

Figure Out Your Career Path

When I first started out as a Systems Engineer, I had preconceived notions about a number of technologies. I would think, "I don't get much use out of this program, so why would I enjoy setting it up for other people?"

The perfect example is Lync. I thought it was just some boring instant messenger that companies went with because they were sold on a feature list or its integration potential with Exchange. As I got a little deeper into Exchange, I started to see mentions of what could be possible by adding other parts of the Microsoft infrastructure lineup. It's no surprise that a lot of them mentioned Lync. I didn't know that it was also a complete VoIP platform, extensive to the point of being its own PBX, capable of hosting meetings for literally the entire internet, and its implementation was designed so simply that you can view the entire environment from one UI component.

Now, my studies focus almost entirely on Unified Communications. If I hadn't gone over that first hurdle, setting up Lync in my lab, there would be an entire world closed off to me for the rest of my career.

Create Good Habits

If everything is working, you aren't learning. Be happy when something breaks in your lab. That means you'll know how to fix it when you have your company's employees counting on you.

But you won't know how to fix issues at first. You won't know about the tools that are available to you until you discover them, and that's not going to happen by accident. Even if you set up everything correctly and then run those tools, you aren't getting much information. All you're getting is a confirmation that you followed the instructions.

Put simply: if you Google 10 different problems and 8 of the answers you find tell you to look in the Event Viewer, you're hopefully going to learn that you need to start there. An embarrassing number of IT professionals don't gather all the information before asking the question.

It Teaches Organizational Skills

This is something I plan to talk quite a bit about during this series. Planning out a lab is the first and most important aspect of building the environment.

I just talked about making mistakes and learning from them. However, failure to properly execute a plan that you created in your head a month or two ago isn't the kind of mistake that you should be making. Spend extra time to see what resources you have available, how you can use those as efficiently as possible, how each service is going to communicate with one another, etc. This is going to come in the form of spreadsheets and diagrams. This is going to be boring to some people, but it's also a really valuable skill to have down the road.

Another side-note: make your network as complex as you can handle and then keep making it more complex. Don't just throw everything in one subnet and point each machine at your modem as a default gateway. You probably already know how to do that, so what's the point?

Break Out of the Mold

Working for a Microsoft subsidiary, the IT world can seem pretty small sometimes. I can go months without hearing about Nagios or Citrix or Oracle or even things like VMware or Linux in general. Then, when they do come up, I can be completely caught off-guard.

Being well-rounded is often frowned upon in this profession. People love to use the demonstrative "jack of all trades" when referring to someone who's not bad at much. However, think about that one guy or girl you know who's just awesome with computers. Chances are they're pretty dang good at one or two things, but also above average with the others.

Also, it's just plain fun. I loved seeing how Cisco put together their UC kit compared to Microsoft. They're so different because they were designed with two entirely different environments in mind. They're both quite amazing and could each be the best choice for two separate companies.

Extras

This article is about the non-obvious reasons for building a lab, so I thought I'd throw in a few short reasons:

• Great time killer: I often remote into my lab from my phone when I'm stuck somewhere like the DMV or during Thanksgiving dinner. Okay, not the last one, but Microsoft's RDP app is actually pretty great for being on a 4-inch screen. It takes about 5 minutes to get used to maneuvering around with the cursor.
• Game servers: Host your own game server and throw down the ban hammer on hackers yourself.
• Grant access to friends: Create accounts for your friends who work in IT. If you're worried about them breaking something, segment it off so they'll only break something you don't care about. Or take a lot of snapshots and backups... but you should be doing that anyway.
• Segment your personal life from work: If you can remote into your lab from work, surf the web from the lab and only use your work computer for work. This isn't so you can fool your security team and get past filters because they aren't that dumb. But it's nice to be able to have the same browser open with a different set of bookmarks and history.