I gave a presentation at the recent Network Field Day 17 (on my 3rd day working for Juniper). My main goal for this presentation was just to get people excited about building stuff. We tend to focus on vendor-provided solutions in this industry, and there’s a lot of good reasons for that, but it’s also good to stay sharp and be able to build your own solution to fill gaps where necessary.
I recently gave a presentation at Network Field Day 17 wherein I announced that not only was I about to give probably the most compressed talk of my life (time constraints are unforgiving) but that I also was now working for Juniper. Until today, this was pretty much the most explanation I had time to give: I decided to accept a position with Juniper over the 2017 holiday, and I started last week.
It’s easy to see that open source is changing the way people think about infrastructure. However, as the saying goes: “The future is here, it’s just not evenly distributed”. As is normal, there will always be pockets of IT where active involvement in open source will just take some more time. I’ve worked on open source for a few years now, and I have always wanted to publish a post that focuses on a few key ideas that I wish I could tell every new entrant into the world of open source.
A while ago, I wrote about basic concepts in StackStorm. Since then I’ve been knee-deep in the code, fixing bugs and creating new features, and I’ve learned a lot about how StackStorm is put together. In this series, I’d like to spend some time exploring the StackStorm architecture. What subcomponents make up StackStorm? How do they interact? How can we scale StackStorm? These are all questions that come up from time to time in the StackStorm community, and there are a lot of little details that I even forget from time-to-time.
I was recently on a panel at the Event-Driven Automation Meetup at LinkedIn in Sunnyvale, CA, and we all had a really good hour-long conversation about automation. What really made me happy was that nearly the entire conversation focused on bringing the same principles that companies like LinkedIn and Facebook use on their network to smaller organizations, making them practical for more widespread use. Nina Mushiana of @LinkedIn says "Anything that can be documented should be automated".
I was honored to return to Packet Pushers for a discussion on programming skillsets in the networking industry. I verbalized some thoughts there, but even 60 minutes isn’t enough for a conversation like this. To be clear, this post is written primarily to my followers in the networking industry, since that’s largely where this conversation is taking place. Scripting is NOT Programming I want to put something to rest right now, and that is the conflation of scripting and software development.
Yet another recap post to follow up on last year’s. 2015 was a big transition year for me, and last year I wanted to make sure I kept the momentum going. I make this post yearly to publicly track my own professional development goals. I find this helps me stay accountable to these goals, and it also allows others to give me a kick in the butt if I’m falling behind.
Earlier I wrote about some fundamental principles that I believe apply to any form of automation, whether it’s network automation, or even building a virtual factory. One of the most important concepts in mature automation is autonomy; that is, a system that is more or less self-sufficent. Instead of relying on human beings for input, always try to provide that input with yet another automated piece of the system. There are several benefits to this approach:
Two years ago, while I worked as a network engineer/consultant, I felt strongly that the industry was ripe for change. In February 2015 I jumped feet-first into the world of network automation by going back to my roots in software development, combining those skills with the lessons I learned from 3 years of network engineering. I’ve learned a ton in the last 2 years - not just at the day job but by actively participating in the automation and open source communities.
Automation is an increasingly interesting topic in pretty much every technology discipline these days. There’s lots of talk about tooling, practices, skill set evolution, and more - but little conversation about fundamentals. What little is published by those actually practicing automation, usually takes the form of source code or technical whitepapers. While these are obviously valuable, they don’t usually cover some of the fundamental basics that could prove useful to the reader who wishes to perform similar things in their own organization, but may have different technical requirements.
ToDD has been out in the wild for 6 months, and in that time I’ve been really pleased with it’s growth and adoption. Considering this was just a personal side-project, I’ve been blown away by what it’s doing for my own learning experiences as well as for the network automation pipelines of the various folks that pop onto the slack channel asking questions. For the last 6 months I’ve hosted ToDD on my personal Github profile.
At Networking Field Day 12, we heard from a number of vendors that offered solutions to some common enterprise network problems, from management, to security, and more. However, there were a few presentations that didn’t seem directly applicable to the canonical network admin’s day-to-day. This was made clear by some comments by delegates in the room, as well as others tweeting about the presentation. Accelerating the x86 Data Plane Intel, for instance, spent a significant amount of time discussing the Data Plane Development Kit (DPDK), which provides a different way of leveraging CPU resources for fast packet processing.
First in this series is the subject of Algorithms. This topic is very interesting to me because when I first strived to understand what exactly they were, I was expecting something a lot more complicated than what they turned out to be. I think, shamefully, that Hollywood may have had an influence on this, as the term “algorithm” is one of many terms abused by “cyber” movies and the like, portrayed to be some sort of ultimate cyber weapon in the war against Ellingson Mineral Company.
Historically, my background is far closer to the systems side of things, but as I’ve picked up software development experience over the past few years, I’ve come to appreciate the fundamentals of computer science that others in my shoes may not have been exposed to. That said, I have been working on a pseudo-formal blog series on computer science fundamentals. These fundamentals have a wide variety of applications. Those with more of an IT-focused background will learn that even if you don’t use graph theory, or optimize algorithms in your day job, many of these concepts are at the crux of many of the technologies that we use every day.
Now that ToDD has been in the public arena for two months, one of the things I’m happiest about is the fact that testing in ToDD is totally flexible. Thanks to the concept of testlets, ToDD doesn’t have an opinion on the specifics of your tests - all of that logic is contained within the testlet. I believe there’s real value in going further than simple “ping” tests when validating that your network is working as you expect.
I’m happy to be given the opportunity to speak once more at Interop Vegas in 2016. No workshop for me this year, but I will be putting on three individual talks, all focusing on topics that have been very near and dear to me over the past year. Last year I was very focused on putting the theory behind network automation into practical terms, and making it “real”. Over the past year I’ve seen rapid growth in adoption of these ideas, and I was happy to be just one very small part of helping to make that happen.
Late last year, I was pleased to be part of a special Tech Field Day event focused on network analytics. We had a day full of presentations from folks like Netflix, Google, and some goofball with a wrinkly jacket - all focused on what the next-generation networks will look like with respect to analytics. This was a while ago, but I’ve wanted to write about this ever since, and a recent conversation gave me the spark I needed.
Over the past few years, I’ve seen (and contributed to) a rise of real network engineers taking on the new and sometimes challenging world of network automation. Every time I check in on Jason Edelman’s Network Automation Slack channel, I’m very happy to see the sheer number of folks asking questions, trying to get the the concepts and tools of network automation working in their own environment. For many, this is all very new, and there’s a lot to soak up.
At the recent Network Field Day 11, there were several discussions at the Cisco offices after the Cisco folks left the room. One of these discussions, led by Terry Slattery, was centered around SDN, and I think it’s worth a listen/watch (only about 20 minutes): In this video, I made the argument that SDN should be limited to a very specific definition, which eliminates the management plane from the conversation entirely (around 5:40).
I have noticed a lot of very premature dismissal of a growing trend in the networking industry, which is the rise of open network operating systems. Nearly every post-announcement discussion that I hear among peers tends to sound something like this: I am not Facebook or Google. I don’t want to install third-party software on my switches, so this “open networking” movement is not relevant to me or my organization.