0

Network Automation @Interop Vegas 2015

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.

Since the last Interop, my career has steered me towards a more direct approach to network automation, specifically through software development. So I’d like to spend some time providing an overview of my sessions at the upcoming Interop Vegas 2016, which are all inspired by the last year of my career.

Test-Driven Network Automation

The Network Revolution Is A Lie

http://info.interop.com/lasvegas/scheduler/session/the-network-revolution-is-a-lie

DevOps-Centric Networking at eBay

I am running the other two talks as an independent - just happy to participate

In case you are planning on attending Interop in Las Vegas this year, I’d like to let you know about my Continue reading

0

The Power of Test-Driven Network Automation

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. Linux networking has broken onto the scene in a big way. We’ve started using text formats like YAML and Jinja2 to template out network configurations to make more consistent network changes. We’ve started using tools like Ansible to drive those changes in a meaningful way to our network infrastructure. It’s clear that these ideas are useful, and are taking hold in a big way.

At this point, I’d like to ask you this question; with all of this tooling, which admittedly helps us achieve consistency of change, does it really ensure the success of a change? How do we even define success? At what point can we sit back and be able to truly say, “that change did not Continue reading

0

The Power of Test-Driven Network Automation

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. Linux networking has broken onto the scene in a big way. We’ve started using text formats like YAML and Jinja2 to template out network configurations to make more consistent network changes. We’ve started using tools like Ansible to drive those changes in a meaningful way to our network infrastructure. It’s clear that these ideas are useful, and are taking hold in a big way.

At this point, I’d like to ask you this question; with all of this tooling, which admittedly helps us achieve consistency of change, does it really ensure the success of a change? How do we even define success? At what point can we sit back and be able to truly say, “that change did not Continue reading

0

The Power of Test-Driven Network Automation

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.

0

The Unspoken Benefits of Open Networking

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.

I believe this sentiment is based on an incomplete understanding of all of the benefits of open networking. I’d like to bring up some additional points that aren’t being discussed as much as others, as it pertains to open network operating systems. I believe these additional benefits apply to a very large spectrum of organizations, not just the top 1% webscale companies.

This is not to say that closed-source operating systems do not have a place anymore, or that the current participants in the open networking ecosystem are perfect, or that we have anything but a long road ahead of us in this journey…my point in writing this post is simply to illuminate parts of the conversation that deserve more attention.

We discussed open operating systems in a recent video-enabled Continue reading

0

SDN and Network Automation: Splitting Hairs?

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).

0

The Unspoken Benefits of Open Networking

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.

0

SDN and Network Automation: Splitting Hairs?

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 am in full agreement that the term SDN, or “software-defined __ “ is at this point totally meaningless. It means so many things to so many different people, and predictably, this conversation ended with just as much confusion about SDN as when we started. So, to try to “define” SDN seems pointless, and smells of hair-splitting, but I do this for a very specific reason.

Splitting Hairs

To me, SDN and network automation are two totally different things, yet they almost always get lumped together in conversations. Normally I wouldn’t try to remedy this, but since one of these things is a practical thing to do for many organizations, I want to offer up a different way of thinking about this.

First off, you Continue reading

0

2015 Recap and 2016 Goals

Wow, it’s that time of year again! 2015 went by really quickly, and a lot has changed for me. It’s also worth mentioning that this is the first year-end recap to be published on my new github pages site!

If you haven’t seen this kind of thing before, 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.

2015 Goal Recap

First, let me recap some of the goals I set for myself at the beginning of the year, and see how well I did.

Public Presence (aka Community Contributions)

Last year I added this goal because I was doing a lot more than just blogging, and wanted to capture it all. This was a good move, since - as expected - I did quite a bit of community-oriented work, and a large portion of it didn’t take place on the blog. So, while I didn’t hit that (admittedly fairly arbitrary) 50 post number, I can say I truly feel good about what little writing I did manage to Continue reading

0

2015 Recap and 2016 Goals

Wow, it’s that time of year again! 2015 went by really quickly, and a lot has changed for me. It’s also worth mentioning that this is the first year-end recap to be published on my new github pages site! If you haven’t seen this kind of thing before, 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.

0

Training the Next-Generation Network Engineer

The networking industry is at a crossroads. In the past few years, we’ve seen a flurry of activity in the world of software-defined networking (SDN), but this has mostly just resulted in a bunch of new products. I don’t feel that this has done nearly enough to improve network operations. In fact, this has in many ways resulted in more complexity.

What we desperately need more than shiny new products (hardware or software) is a better understanding of simple tools and open source software. We need to be willing to take more direct control over our infrastructure, instead of relying on a vendor and their support contracts to solve all our problems. While vendors should still serve a critical role in operating a network, I feel strongly that now more than ever, end-users have the power to really own their own management layer, and the roadmap for how their organizations offer network services to the teams that run (and in some cases develop) applications for the business.

To that end, I’ve been spending the past six months or so ramping up my own personal efforts at helping the network community as a whole to start this journey. These simple contributions Continue reading

0

Training the Next-Generation Network Engineer

The networking industry is at a crossroads. In the past few years, we’ve seen a flurry of activity in the world of software-defined networking (SDN), but this has mostly just resulted in a bunch of new products. I don’t feel that this has done nearly enough to improve network operations. In fact, this has in many ways resulted in more complexity. What we desperately need more than shiny new products (hardware or software) is a better understanding of simple tools and open source software.

0

Kubernetes: Basic Concepts

I have been diving into Kubernetes lately, for both personal and $dayjob reasons. With the combined effect of my attendance at a recent Kubernetes workshop by Kelsey Hightower (on his very last day at CoreOS no less!) and also having the amazing opportunity to attend the inaugural and sold-out Kubecon that starts today, I figured it’s high time I tackle a “basics of Kubernetes” post.

This blog post is meant to serve as a very high-level introduction to Kubernetes concepts and components. If you are looking to stand up your own cluster, I encourage you to read the exceptional Kubernetes documentation. No, really. They’re exceptionally good docs.

Scheduling 101

Within the context of computer operating systems, the “scheduler” is the component that manages the assignment of compute resources to running processes. Especially in the early days before parallel computing and multicore systems, it was crucial to very carefully manage how much CPU time was allowed for the various running processes, so that the user could have a seamless experience. Even today with multicore systems, this is important to ensure that each core is utilized as evenly as possible, or at least to meet certain SLA requirements.

With the Continue reading

0

Kubernetes: Basic Concepts

I have been diving into Kubernetes lately, for both personal and $dayjob reasons. With the combined effect of my attendance at a recent Kubernetes workshop by Kelsey Hightower (on his very last day at CoreOS no less!) and also having the amazing opportunity to attend the inaugural and sold-out Kubecon that starts today, I figured it’s high time I tackle a “basics of Kubernetes” post. This blog post is meant to serve as a very high-level introduction to Kubernetes concepts and components.

0

The Benefits of a Proper Development Environment

I’ve had a number of folks approach me about the topic of development environments, so I figured it was worth a blog post.

Maybe you’re curious what a development environment is, or perhaps you’re working through the challenge of developing code on one platform, and deploying on another. Maybe you already have a development environment - like a virtual machine - but you aren’t happy with your workflow, and feel it could use some upgrades.

If any of the above apply to you, this post should be useful to you.

A Continuous Integration Story

Imagine yourself as a member of a software development team. You’re all working on the MegaAwesome project, which aims to solve global warming, world hunger, and basically anything wrong on this earth. With such high aspirations, it is important to put a process in place that ensures maximum developer efficiency, while maintaining an uncompromisingly high level of quality.

Any mature software development team will leverage version control like Git to ensure changes to the codebase are properly tracked and managed. They will also likely leverage some kind of continuous integration, or build server like Jenkins to run automated static code analysis (i.e. PEP8) or unit Continue reading

0

The Benefits of a Proper Development Environment

I’ve had a number of folks approach me about the topic of development environments, so I figured it was worth a blog post. Maybe you’re curious what a development environment is, or perhaps you’re working through the challenge of developing code on one platform, and deploying on another. Maybe you already have a development environment - like a virtual machine - but you aren’t happy with your workflow, and feel it could use some upgrades.

0

Network Namespaces: The New Access Layer

When considering containers and how they connect to the physical network, it may be easy to assume that this paradigm is identical to the connectivity model of virtual machines. However, the advent of container technology has really started to popularize some concepts and new terminology that you may not be familiar with, especially if you’re new to the way linux handles network resources.

What is a Namespace?

It’s important to understand this concept, because containers are NOT simply “miniature virtual machines”, and understanding namespaces is very important to conceptualizing the way a host will allocate various system resources for container workloads.

Generally, namespaces are a mechanism by which a Linux system can isolate and provide abstractions for system resources. These could be filesystem, process, or network resources, just to name a few.

The man page on linux namespaces goes into quite a bit of detail on the various types of namespaces. For instance, mount namespaces provide a mechanism to isolate the view that different processes have of the filesystem hierarchy. Process namespaces allow for process-level isolation, meaning that two processes in separate process namespaces can have the same PID. Network namespaces - the focus of this particular post - allow Continue reading

0

Network Namespaces: The New Access Layer

When considering containers and how they connect to the physical network, it may be easy to assume that this paradigm is identical to the connectivity model of virtual machines. However, the advent of container technology has really started to popularize some concepts and new terminology that you may not be familiar with, especially if you’re new to the way linux handles network resources.

What is a Namespace?

It’s important to understand this concept, because containers are NOT simply “miniature virtual machines”, and understanding namespaces is very important to conceptualizing the way a host will allocate various system resources for container workloads.

Generally, namespaces are a mechanism by which a Linux system can isolate and provide abstractions for system resources. These could be filesystem, process, or network resources, just to name a few.

The man page on linux namespaces goes into quite a bit of detail on the various types of namespaces. For instance, mount namespaces provide a mechanism to isolate the view that different processes have of the filesystem hierarchy. Process namespaces allow for process-level isolation, meaning that two processes in separate process namespaces can have the same PID. Network namespaces - the focus of this particular post - allow Continue reading

0

Network Namespaces: The New Access Layer

When considering containers and how they connect to the physical network, it may be easy to assume that this paradigm is identical to the connectivity model of virtual machines. However, the advent of container technology has really started to popularize some concepts and new terminology that you may not be familiar with, especially if you’re new to the way linux handles network resources. What is a Namespace? It’s important to understand this concept, because containers are NOT simply “miniature virtual machines”, and understanding namespaces is very important to conceptualizing the way a host will allocate various system resources for container workloads.

0

Network Automation: Be Bold!

I’ve had something on my mind concerning network automation, and I think it’s worth mentioning it here.

There’s been a lot of talk - including plenty from myself - about using tools like Ansible for creating network configuration files; that is, text files that contain configurations for network devices, usually a list of CLI commands. And this is a great first step, certainly if you’re new to network automation.

It’s really not that hard to generate configurations. You can do it in about five lines of Python, or you can stick with that Excel spreadsheet powered by macros (you know who you are). I challenge anyone to tell me that Ansible is better at generating config templates than Excel. The reality is that it’s not - and it’s hardly attempting to be.

So, for the sake of making a point, let’s say the generation mechanism doesn’t matter. Let’s concede that this is the wrong optimization to be making. The question becomes - what is the right optimization?

I think the bigger problem to address is that of treating our networks like fragile snowflakes. I can’t tell you how many times I’ve logged into a device, and felt like I was Continue reading