Buzzwords, technology, terminology, and the interconnection of modern networking
I'm way overdue for a soapbox session -- I found this one in my drafts and thought it was something I needed to put out there. It's already dated in terminology but that actually helps make the point - it's hard to keep up.
Lets throw this out there: social media can be exhausting. Do not misunderstand me, it’s a great tool for communication, obtaining and disseminating information as well as standard goofing around. It’s also a serious business for a huge amount of companies. I use it extensively myself and I’ll assume there is a pretty good chance you followed a tweet or other social media link to get here. However, for a green network engineer looking for a path forward it can be a bit daunting. Those my age never had the social media aspect to deal with when we were learning, we may have had IRC or other haphazard back channels to bounce ideas and questions, but for the most part, the resources were far more limited than they are today. In actuality, I believe that this was a bit of an advantage that we had over today: we were often forced to bulldoze through problems, making mistakes that taught us deep understandings of the inner working of that given technology. It also sucked a lot more [time].
Am I right? Maybe. Maybe not. Who is to say? These days I take full advantage of the wealth of information that is the internet for both personal and professional tasks, I would be a tad crazy not to. It's why I write the tech stuff I write.
With all of that, though, comes so many buzzwords and so much hype that it is very easy for an aspiring network engineer (or any professional IT hopeful, student or casual techie) to become completely overwhelmed by simply looking at twitter and following a handful of key players. I’ve been doing what I do with networks since the 1990s and even I have been feeling a little overwhelmed by the sheer number of “Network Engineer Killer” or “Must know” technologies being thrown around in the last few years. It's both exciting, encouraging and at the same time enough to make even the most grizzly engineer feel snowed under.
Wait for it……Cloud. No wait, DevOps. Containers! NO! NO! SDN! They're all cool and they're all important. They are also a lot to take in.
I have been thinking a great deal about DevOps and SDN lately. Being a really, really bad developer, DevOps is a tad uncomfortable for me. It is an obviously useful skill set: Understanding code and automation. It’s powerful and will make your professional life easier. Do you need to obsess over it? Probably not (do you need to obsess over any of it?!?). Remember that internet thing that I mentioned before? Yeah, there are a lot of resources there. Search engines are your friend.
Will you need to know the concepts? For sure. Guess what, though? There are a ton of resources for that too.
As I was brainstorming this, I mind-mapped some of the things that jumped into my brain [mindnode pro is a fantastic app for this, I highly recommend it]. Things that get a lot of attention and maybe deserve a cursory glance. Lets break them down in a simple-ish and concise-ish manner and understand that by the time of this writing I’m positive it will be outdated and there will be some new whiz-bang thing that the marketing machine will be saying is the “something-killer".
Here are the high level things I see thrown around a lot. For what it’s worth, OpenDayLight has a page with some definitions that is pretty good, too.
This is absolutely not all-encompassing and is likely missing major things, however, the point is really not to be accurate as much as it is to demonstrate that there is a monumental amount of scope that is in some ways interconnected and in other ways completely autonomous. It is also pretty clear that due to the nature of what “DevOps” is, it has ties into many other things.
The biggest take-away is that the communication paths need to be there - Better communication between these specializations makes for better, more secure, more usable tools.
It is how the DevOps is done, not what it is doing.
What I am really getting at here is that there is no need to get overwhelmed. You don’t need to know all of this stuff. If you know a little about most of it and a lot about one or two topics, then in my opinion you are doing really, really well.
My best advice to any new IT person is not to know everything but to know where to find it - and then share what you learned.