Unit Testing Junos with JSNAPy
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.NASA Social OA-4 Tours and Launch
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.Intentional Infrastructure
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. One reason I joined Juniper is that much of what we offer is built on a highly programmable foundation. So you get the best of both worlds - high-level products to solve the hard problems, but you still have the ability to insert your own custom tooling at various points in the stack.
In the above video, I outlined a simple Github-available demo for applying policies to a vSRX based on the existing services running in Kubernetes, and then verifying those policies are actually working by again using Kubernetes to determine what applications should be available.
My demo is designed to be self-sufficient, meaning you should be able to follow the README and get a working demo. Feel free to watch the above video first for context, then Continue reading
Intentional Infrastructure
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. One reason I joined Juniper is that much of what we offer is built on a highly programmable foundation. So you get the best of both worlds - high-level products to solve the hard problems, but you still have the ability to insert your own custom tooling at various points in the stack.
In the above video, I outlined a simple Github-available demo for applying policies to a vSRX based on the existing services running in Kubernetes, and then verifying those policies are actually working by again using Kubernetes to determine what applications should be available.
My demo is designed to be self-sufficient, meaning you should be able to follow the README and get a working demo. Feel free to watch the above video first for context, then Continue reading
Intentional Infrastructure
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.New Role, Same Goal
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. There were a few reasons for moving on from the StackStorm team, some of which are personal and have nothing to do with either day job. Despite the move, all of these things are still true:
- StackStorm is and continues to be an awesome project. Regular updates are happening all the time, each full of tons of new features and fixes.
- The StackStorm team and Extreme Networks as a whole are some of my favorite people ever. I will never forget everything I learned from them, and will try my best to stay in contact with all of them.
- The concepts behind StackStorm, such as infrastructure-as-code, and autonomous response to events, are still top-of-mind for me. I still strongly believe that each of these concepts are Continue reading
New Role, Same Goal
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. There were a few reasons for moving on from the StackStorm team, some of which are personal and have nothing to do with either day job. Despite the move, all of these things are still true:
- StackStorm is and continues to be an awesome project. Regular updates are happening all the time, each full of tons of new features and fixes.
- The StackStorm team and Extreme Networks as a whole are some of my favorite people ever. I will never forget everything I learned from them, and will try my best to stay in contact with all of them.
- The concepts behind StackStorm, such as infrastructure-as-code, and autonomous response to events, are still top-of-mind for me. I still strongly believe that each of these concepts are Continue reading
New Role, Same Goal
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.A Guide to Open Source for IT Practitioners
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. I feel like going in with the right expectations can really help any efforts here go much more smoothly. So if you’re accustomed to getting most if not all of your technology stack from a vendor, and you’re wondering about the open source craze, and trying to make sense of it all, this is for you. My goal with this post is to empower you to start getting out there and exploring the various communities behind the projects you may already have your eyes on.
Open Source is “Free as in Puppy”
Before some practical tips, I want to spend some time on expectations. This is crucially important Continue reading
A Guide to Open Source for IT Practitioners
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. I feel like going in with the right expectations can really help any efforts here go much more smoothly. So if you’re accustomed to getting most if not all of your technology stack from a vendor, and you’re wondering about the open source craze, and trying to make sense of it all, this is for you. My goal with this post is to empower you to start getting out there and exploring the various communities behind the projects you may already have your eyes on.
Open Source is “Free as in Puppy”
Before some practical tips, I want to spend some time on expectations. This is crucially important Continue reading
A Guide to Open Source for IT Practitioners
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 Guide to Open Source for IT Practitioners
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.StackStorm Architecture Part I – StackStorm Core Services
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’ll be doing this in a series of posts, so we can explore a particular topic in detail without getting overwhelmed.
Also, it’s worth noting that this isn’t intended to be an exhaustive reference for StackStorm’s architecture. The best place for that is still the StackStorm documentation. My goal in this series is merely to give a little bit of additional insight into StackStorm’s inner workings, and hopefully get those curiosity juices flowing. There will be some code references, some systems-level insight, probably both.
Also note that this is a living document. This is an open source project under active development, and while I will try to keep specific Continue reading
StackStorm Architecture Part I – StackStorm Core Services
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’ll be doing this in a series of posts, so we can explore a particular topic in detail without getting overwhelmed.
Also, it’s worth noting that this isn’t intended to be an exhaustive reference for StackStorm’s architecture. The best place for that is still the StackStorm documentation. My goal in this series is merely to give a little bit of additional insight into StackStorm’s inner workings, and hopefully get those curiosity juices flowing. There will be some code references, some systems-level insight, probably both.
Also note that this is a living document. This is an open source project under active development, and while I will try to keep specific Continue reading
StackStorm Architecture Part I – StackStorm Core Services
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.StackStorm Architecture Part I – StackStorm Core Services
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.StackStorm Architecture Part I – StackStorm Core Services
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.Your Cheese Moved a Long Time Ago
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".
— StackStorm (@Stack_Storm) March 31, 2017
Great Auto-Remediation Meetup! pic.twitter.com/l76U1IydjB
One particular topic that came up was one I’ve struggled with for the past few years; What about Day 2 of network automation? So, we manage to write some Ansible playbooks to push configuration files to switches - what’s next? Often this question isn’t asked. I think the network automation conversation has progressed to the point where we should all start asking this question more often.
I believe that the network engineering discipline is at a crossroads, and the workforce as a whole needs to make some changes and decisions in order to stay relevant. Those changes are all based on the following premise:
The value of the network does not Continue reading
Your Cheese Moved a Long Time Ago
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".
— StackStorm (@Stack_Storm) March 31, 2017
Great Auto-Remediation Meetup! pic.twitter.com/l76U1IydjB
One particular topic that came up was one I’ve struggled with for the past few years; What about Day 2 of network automation? So, we manage to write some Ansible playbooks to push configuration files to switches - what’s next? Often this question isn’t asked. I think the network automation conversation has progressed to the point where we should all start asking this question more often.
I believe that the network engineering discipline is at a crossroads, and the workforce as a whole needs to make some changes and decisions in order to stay relevant. Those changes are all based on the following premise:
The value of the network does not Continue reading