When I got started in networking, my education (like so many network engineers) was all about Cisco. All my networking courses in college, as well as my early networking jobs all used Cisco curricula and equipment, and valued Cisco certifications like the CCNA/CCNP/CCIE above all.
It wasn’t until I had already been in the industry for about three years or so before I even got my hands on a Juniper device, and by that time, my IOS habits had taken root in my muscles, which made the new set/delete style of Junos configurations even more strange.
I’ve been passionate about the idea of proactively testing network infrastructure for some time. I revived and added to these ideas in my last post. In that post’s video, I lay out three types of network testing in my presentation:
Config-Centric - Verify my network is configured correctly State-Centric - Verify the network has the operational state I expect Application-Centric - Verify my applications can use the network in the way I expect In the same way a software developer might write tests in Python or Go that describe and effect desired behavior, the network engineer now has a growing set of tools they can use to make assertions about what “should be” and constantly be made aware of deviations.
In December 2015 I had the distinct honor to be selected to attend a NASA Social event that coincided with the OA-4 launch, an ISS resupply mission. NASA runs these events occasionally to give the world some insight into what goes on at various locations pertaining to the space industry. There’s a lot of really cool work going on, and I’m happy to finally have a chance to publish my experience on this amazing trip.
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.
Matt Oswalt