Conferences and Meetups

My two favorite conferences to go to are the Carolina VMUG in Charlotte, NC every June and the Triangle InfoSeCon in Raleigh, NC every October.  Last week I went the Triangle InfoSeCon 2018 and as usual, it was awesome.

I used to go to a lot of local meetups about all kinds of topics but my available time outside of work keeps shrinking with a growing family.  So I try to go to fewer things but make them higher impact.  Also, I am far enough along in my career that I now can get something out of those conferences.  That’s why now I only go to big conferences.  I’d like to start going to some local meetups but with a more narrow focus.

I love going to conferences and meetups so I can meet new people and get new ideas.  At work we sometimes get into a rhythm of doing the same things over and over again.  Hearing how other people are solving the same problem is very cool.  It is ever better when I hear about problems that I’ve never heard of.  It would be nice if there’s a solution to it but I still want to hear about it.

At Tech conferences, almost all of the talks have the same format and they sound like there were written by the marketing department. Part 1 is how something is broken, Part 2 is how our product can fix it.  It makes it even worse since every company has the same handful of major problems so it gets really repetitive.  Most of the conferences are paid for by these vendors so I understand they want to at least break-even, maybe even make a few bucks but can they try and make it a little more interesting.  My favorite talks have funny and/or interesting stories with some product placement sprinkled in.

I know I shouldn’t complain so much because the vendors cover most of the costs.  But I don’t think anyone is going to buy your product if the presentation was so boring that they don’t know what the product does even if they were awake for it.

Most of the time I like a live demo and I don’t care if it goes perfectly.  I know how difficult it is to do a live demo and I really appreciate the effort.  I learn a ton about the product from the demo whether it is successful or not.  An unexpected error with live troubleshooting can turn into presentation gold if handled properly but it is at least entertaining either way if it goes really badly.

Overall I’m really glad that I get out of my shell and go these events.  Hope to see you soon IRL (In Real Life).

So Many Roles in IT

When I was growing up, I was fascinated by computers and technology.  Back then, I knew what programmers were and that was about it. At some point I learned about DBAs but I put that into the programmer bucket since I heard they wrote scripts to manage a database. I always knew about sales and at some point I found out about technology sales but just the thought of commission-only sales still gives me stomach pains.

My first real job out of college was at the Apple Retail Store.  I worked there for almost 4 years and slowly learned from my coworkers and customers about some of the many jobs and roles in IT.  At some point, that Apple Store closed for about two weeks for renovations. Near the end of the renovations, a guy came to work on the network rack.  I can only guess what he was there to do but it fascinated me.

With new technologies constantly being created, new roles are being created to manage those technologies.  Some of those technologies stay around for a while and others quickly disappear. The technologies that stay around for a while will eventually fade away but they never seem to fully go away.  Since they never seem to fade away, those roles never seem to fully go away.

An example is Cobolt.  It seems there will always be a need for Cobolt programmers even though it has been decades since anyone wrote new Cobolt code but someone has to maintain those ancient Cobolt applications.

Now when I think of the IT industry, it’s usually just IT infrastructure and even that is huge now.  Networking, servers, voice, virtualization, data center, security, storage and wireless now adds video, containers, SD-WAN, automation and the cloud.  Each one of those sections has numerous sub-sections and some roles combine multiple of those topics listed above.  We still haven’t even mentioned where everyone starts, the backbone of every IT organization, the helpdesk.  Finally there is the Network Architect that has to bring it all together.

The IT department provides more than just email.  Now it is expected to provide so many services and be available from anywhere on any device at any time.  It will take all these groups working together to make it happen. In order to do that we need to be more friendly to our fellow IT folks, building up walls around our territories is counter-productive (See the Datanauts podcast for more silo-busting).  Also, we need to be welcoming and help train others.  The machines are coming for your job but before that happens, there is a lot of work to do and we need all the help we can get.

Be Honest about your Network Resiliency

Everyone would love to have a network that is always up and available.  The problem is that few people want to design it and absolutely no one wants to pay for it.

There are many ways to make your Network more resilient.  Some are necessary for your organization, others would be nice to have and some are overkill.  A difficult part is to know which solution goes into which bucket (necessary, nice-to-have or overkill).  Then those pieces need to implemented, monitored and maintained.

One example that I have seen at dozens of companies is about the uninterruptible power supply (UPS).  A UPS has a battery that is supposed to “kick in” when the normal power source goes out, kind of like a fancy generator.  The goal is for the critical equipment to stay alive and the non-critical to power-down gracefully.  Most companies have a UPS at their sites but they are not ready for two main reasons, the battery is dead and/or it isn’t cabled properly.  Just like any other battery, over time it won’t hold as much of a charge so the battery needs to be replaced.

Another example is if a branch office invests in two ISPs for redundant internet, make sure everyone knows exactly how redundant it is.  If both ISPs use the same physical path to the branch office, they aren’t as redundant because the same backhoe will still take them both out.  Or if the network isn’t setup for proper failover and failback, then it isn’t as redundant as we thought.

A competent network designer should be able to tell with a high degree of certainty just how resilient the network is and in which ways.  Probably the toughest part is to explain to upper management the pros and cons of the new proposal and get their buy-in.  Management needs to listen and understand what all the scenarios are and their impact so everyone will be informed and aware of the possible situations.  Those meetings are time consuming and can be very boring but they are necessary.  The other option is for the engineer to write all this up and email it out but we all know that no one reads anymore.

Responsible Code

At an increasing rate, software now controls our lives.  A few examples are credit scores, loans, stock trading, releasing people from jail, new job screenings, getting into college and just about everything else.  Those decisions have major impacts on our lives.  Since they have such a huge impact on our lives, they need to be done properly.

An example of hugely important and impactful software is self-driving cars.  People’s lives directly depend on it, therefore it must be properly and correctly.  This is not like building a database, people’s lives are at risk. Lots of lives are at risk.  This is not something where someone should just fail-fast and then fix it.  But mistakes in production should not be acceptable.  Mistakes will happen, that is inevitable but it needs to fail gracefully.

No one enjoys unit testing but it is necessary for quality software.  There are so many different driving scenarios that they all can’t be accounted for and coded in.  Data needs to gathered from a wide variety of sources (such as still images, videos, radar, lidar), then it needs to be put together and analyzed.

In addition, no one enjoys government regulations but when it comes to self-driving cars, those regulations need to be followed.  All regulations need to be followed, I’m sure that some of them are ridiculous but please don’t skip them.  If they are ridiculous, object to them but still follow them while the laws are on the books.

I’m not saying this is easy.  This is a very hard problem that requires a lot of smart people working really hard.  I just want the people involved in this and other software projects to remember that this isn’t just an academic thought problem but people’s lives depend on this software.

I also think that technology can solve so many of the worlds problems.  I am optimistic,  not pessimistic, about the future of technology.  I do not want us to stop innovating.  We cannot stand still, we should always be moving forward but we need to proceed with caution.  The new and innovative technologies of today will become the foundation of tomorrow.  I want to make sure we have a solid foundation for everyone in the future.

This post was inspired by The Tesla Show Podcast, episode 85 about Comma.ai, “the Android of self-driving car companies” Link

 

Why Network Engineers Should Learn Programming

A typical network engineer starts off in a NOC and does break / fix work and that doesn’t require them to know how to write code.  But it would be great if they did AND it would help them advance.

Most other IT infrastructure engineers need to know either how to write basic scripts or at least edit or debug other’s scripts. Networking Engineering folks should learn about coding to expand their tool set and to better understand their Software Engineering brethren.  Even better to work better with the programmers that we are supporting.

An example is Powershell.

Powershell is a necessary skill for folks who work on servers, Exchange, Active Directory and Office 365. Lots of networking folks who want to dabble in other disciplines will  need to know Powershell and basic coding to keep up.  Here is a link to Greg Farro from the PacketPushers.net talking more about this very scenario.

Here are a few examples off the top of my head that other IT infrastructure engineers routinely perform.

Server / Storage Admins
•Automated backups
•Datacenter failover script
•Automatically setup new VMs and resources
•Linux Linux Linux

Security Admins
•Writing Firewall rules

Voice Admins
•Phone tree scripting

Architects
•Switch failover rules
•Pings sweeps
•SDN
•Device auto-discovery script

The IT world is becoming more and more automated.  That automation is done by scripting and coding. The networking world is far behind storage and servers in terms of automation.  Better for you to automate your own job away before someone else does… and it will happen eventually.  We’ll be examining automation in the IT world in general more in another post.