Full Stack Engineers – Deep Like a Papercut?

The term “full stack engineer” has come up quite a bit lately on blogs and podcasts and the like and I figured I’d throw in my $0.02 on the matter. First though, I think it’s probably worth a super quick review of my “career path” (if you can call it that) since I think that probably has a lot to do with shaping my opinion on the term/idea (duh).

I started out in the Air Force and basically started doing network stuff right away. Strictly network stuff, there were server guys, and desktop guys, and long haul circuit guys, but I was just a network guy. My first real job after the Air Force I worked in healthcare for a large company that owns a whole slew of hospitals across the US. I was just a network guy again. I did like at least a million network refreshes on hospitals of 50 beds to 500 beds. Then I jumped over to a large VAR and for the most part was still just a network guy, but started to slowly touch more security (ASAs mostly) and wireless (5508s and the like).

So basically up till I jumped to the VAR I did nothing but route/switch network stuff. Like nothing at all, and I really liked that. I got to nerd out pretty hard and learn a whole bunch of crap that I don’t remember now about the OSPF database and spanning-tree and who the hell knows what else. That was a big point of pride of me being the “expert” (lol or whatever) on the network. Frankly at that time I scoffed at the idea of generalizing or getting wider w/out staying deep (beer was/is continuing to help me get wider regardless of my opinion on the matter). As I moved onto the VAR though and got into customer facing situations more so, or at least more often, than in the Air Force or at an Enterprise, and I got tasked with doing more things that were outside of my comfort zone I had to broaden out at least a little bit. That was good I think because I was still the “network guy,” but at least I could begin to have intelligent conversations about the firewall and how it should interact with the network.

As I moved into pre-sales and then into whatever the hell it is I am doing now I’ve gotten broader and broader, but have always been able to relate back to my core base in networking. I think my point I’m trying to get at is I don’t think its good advice (personal opinion here) to try to start wide and stay wide. I think you’ve got to be able to have an area of expertise that you can start from, and expand out from there — in my case nowadays that s learning more about virtualization, programming, and storage. These things touch all of the data center networking that I do most, and as I learn to converse about these other silos better I get better at my core strength because I’m able to bridge silos and help translate requirements and configurations between teams.

I have a love/hate with the idea of a “full stack engineer.” I think that you need to have a strong foundational knowledge in one or a few (but can’t get too wide IMO) areas, and then just start asking questions like crazy about the other things/silos that touch/interact with whatever your core area is. I think if you can do that and just never stop asking you will be setup for success in whatever you do.

APIs and the Network – Far Behind?

As I’ve been I guess “evolving” as a network engineer/packet pusher/router jockey/packet herder/ whatever you’d like I’ve been working more and more with APIs (in my case mostly ACI, but also a bit of vCenter, and other random bits). This has obviously been really cool, getting exposed to a new, arguably better, way to interact with devices. It has, however, opened up lots of new questions for me. These questions pretty much all revolve around APIs and standardization, and I think most poignantly around the question of: “is networking really that far behind everyone else?”

That last question is pretty near and dear to me as I’ve so far made my career out of just being that “network” guy. I certainly don’t want to feel like networking is the last kid on the block to get it together, but that is for sure the messaging that has been coming out of the Twitters and podcasts and the like.

I guess I should preface the rest of everything I’m going to write with this one tidbit: “I don’t know what I don’t know.” What I mean by that is that this post really is an open question because I only know what I’ve seen or been exposed to, and I’m genuinely interested and curious about this topic.

So my position (question?) on this is that it doesn’t seem, to me at least, that networking is really *that* far behind in terms of programmability or standardization. Now I guess I should clarify that position a bit because I do feel there are some relevant caveats to that statement…. Firstly, I completely agree with a lot of the rhetoric out there that networking hasn’t really changed in the last two decades. We still manage things box by box, we still have spanning-tree, we still have basic routing protocols, we still are doing all of the things that were invented when the Internet came to be (more or less).

That being said, I think there are some valid reasons why we do things the way we do them. The biggest point for networking not changing is that it (networking) is arguably the most critical component (from a technology perspective) of any organization. If the network is down people are not happy. No email, no VoIP, no applications, no eCommerce, no XYZ — without the network these things just don’t work. That is a serious burden to bear for the network. It makes changing things hard, because if you screw up…. it could be a bad day for you and your organization. This is definitely not intended to diminish the importance of other disciplines in the IT world — storage is super critical (perhaps the next most critical in my view), voice is super critical, security is super critical, but none of those pieces by themselves necessarily will cause a complete failure for an organization.

All in all I don’t see that there are standardized APIs across any hyper-visor or storage array or any other box in general, so I don’t understand why we should expect the network to have universally accepted standard APIs. Moreover I think that would even be a bad thing — think about SNMP! SNMP was supposed to be a standard universal way to query devices, and indeed everyone supports SNMP, but look what a shit show it is — do you really want that again!?

To put a bow on this I guess I’ll just lay out what I think about the current state of things. APIs are good — and networking folk should learn to love them. We’re getting there — Arista, Cisco, Big Switch, and tons of other vendors have heard loud and clear and are implementing them. I can tell you from my personal experience that working with the ACI API is smooth and awesome. We’ll get there in other networking domains (WAN/Campus/Security), but it will take time. Taking time is probably even a good thing as network folk like myself need to learn to get up to speed on all of this new fangled API stuff. So, in the meantime, learn some basics of how to interact with an API — I would strongly recommend checking out Google Postman and the collections runner — it’s a tool I use regularly and is a super simple way to get started. What are you waiting for?