Keeping NATS Connections DRY in Go

In the previous posts, I covered the basics of connecting to NATS in Go and the different ways subscribers can request information is sent to them. In this post, I’d like to build on those concepts by exploring how to structure your NATS-powered Go code so that things are clean and DRY. I’ll also show that trying to make things too DRY can be problematic; as with everything, moderation is a good idea.

Matt Oswalt – Portfolio

Short Bio Matt Oswalt hails from Portland, OR, and focuses on the intersection of network infrastructure, automation, systems, and software engineering. He’s passionate about enabling engineers to evolve their careers to the next level, and sharing the bright spots that exist within the technology industry with the masses. You can often find him speaking at conferences or meetups about these topics, as well as writing about them on his blog (https://keepingitclassless.

The Bookshelf

I am a big fan of Audible for books. Every once in a while I have time and patience to read a physical book, but often times I find myself needing to do things like washing dishes, going on a long walk or drive, and Audible has made it so much easier for me to get back into “reading”. Since I started doing this, I’d like to share the books that I’ve been able to get through this way.

Controlling Information Flow: NATS Subjects and Queues

Publish/subscribe messaging platforms like NATS allow us to build highly event-driven software systems, where we can build software to constantly listen for relevant messages and take action accordingly. This is what makes EDI projects like StackStorm (a project I’ve worked on and written about before) - and others like it- so powerful. Another advantage of pub/sub systems is that publishers don’t have to know or care if anyone is listening.

Kicking the Tires With the NATS Go Client

I am doing some prototyping for a project and part of this includes becoming more familiar with the NATS project, including its Go client (since all of the components in my project that will be talking to NATS are written in Go). In short, I have a bunch of little services that need to talk to each other, and a message broker like NATS fits the bill. One thing that drew me to NATS specifically is that it is unapologetically - nay, proudly - simple.

Matt Oswalt – Speaker Bio

Photo Short Bio Matt Oswalt hails from Portland, OR, and focuses on the intersection of network infrastructure, automation, systems, and software engineering. He’s passionate about enabling engineers to evolve their careers to the next level, and sharing the bright spots that exist within the technology industry with the masses. You can often find him speaking at conferences or meetups about these topics, as well as writing about them on his blog (https://keepingitclassless.

Keeping It Classless 1970-01-01 00:00:00

One thing that’s always bugged me about the whole “You’ll be out of a job in 5,10,15 years if you don’t learn programming” is this. Who cares when you’ll be OUT OF A JOB? It’s like we’re driving a car in dense fog, trying to figure out when to perfectly apply the brakes so that we don’t go over a cliff that’s SOMEWHERE in the distance. Like - the fact that we’re even having this debate is a horrible waste of time in my opinion.

Don’t Throw the Multicloud Out with the Bathwater

https://twitter.com/CTOAdvisor/status/1103034794781429761 https://www.youtube.com/watch?v=wNOA-sPqf80& https://twitter.com/randybias/status/1103713819195408384 https://twitter.com/C_Z_Raisch/status/1103723011037900800 Keith was totally right to push back on the idea that multicloud was about cost optimization. Not only is this a fantasy, it’s also off-brand for most enterprises. In my experience, the enterprise is totally fine paying a premium on what they consider best of breed technology solutions. to me, multicloud isn’t about trying to boil the ocean and build some master plan for world dominance that includes dynamic blah blah blah.

December 4 – NRE Labs Outage Post-Mortem

I awoke yesterday to a very crisp Tuesday morning in Portland, Oregon. I had just poured myself a nice glass of Stumptown Nitro cold brew coffee, and wandered upstairs to my office for an 8AM conference call. I joined the meeting, and started going through my usual routine - part of which includes looking at the day’s NRE Labs stats. Here’s what I saw: Well, that kind of sucks.

December 4 – NRE Labs Outage Post-Mortem

Troubleshooting NGINX Ingress Rewrites in Kubernetes

When deploying an application to Kubernetes, you almost certainly will want to create a Service to represent that application. Rather than relying on direct connectivity to Pods, which may be ephemeral, Services by contrast are long-living resources that sit on top of one or more Pods. They are also the bare minimum for allowing those pods to communicate outside the cluster. While Services are a nice abstraction so we don’t have to worry about individual Pods, they are also fairly dumb.

What is Network Observability?

If you have ambitions to improve reliability through experimention you MUST have observability. You cannot know if you’re getting better without thi. https://twitter.com/tammybutow/status/1067135822204329984 If you don’t set the SLOs for your network, someone else will, and you probably won’t like it. Basically, if we don’t go up the stack and quantify success using application-specific metrics, someone else will do it for us, and we’ll be left out of the loop.

About Matt

My name is Matt Oswalt, and I have a fairly eclectic background. When I was 14, I created my first program - an alien shooter on my TI-82 calculator. Since then, I’ve enjoyed building new things and showing them to anyone who will listen. This passion continues to this day, as you’ll find with projects like ToDD and NRE Labs, I just really enjoy building cool stuff. You can explore these and all my other open source projects on my GitHub profile.

Up and Running with Kubernetes and Tungsten Fabric

I have a predominantly technical background. You can show me all the slide decks you want but until I can get my hands on it, it’s not real to me. This has greatly influenced what I’m focusing on now that I’m doing more than just technical work - how to reduce the barrier to entry for people to become acquainted with a project or product.

As a result, I’ve been getting more involved with Tungsten Fabric (formerly OpenContrail). Tungsten is an open source Software-Defined Networking platform, and is a healthy candidate for building some tutorials. In addition, I’m new to the project in general - so, even if only for my own benefit, a blog post summarizing a quick and hopefully easy way to get up and running with it seems quite appropos.

Introduction to the Lab Environment

We’re going to spin up a 3-node cluster in AWS EC2 running Kubernetes, and using Tungsten Fabric for the networking. Why AWS instead of something like Vagrant? Simply put, a lot of advanced networking software require a lot of system resources - more than most laptops are able to provide. In this case, a total of four virtual machines (three-node cluster plus Continue reading

Up and Running with Kubernetes and Tungsten Fabric

Get Started with Junos Quickly (and free!)

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. While my Junos experience never came close to exceeding my IOS/NXOS experience, I grew to appreciate some of the subtle advantages that Juniper bakes into its software. However, getting this experience meant I had to work that much harder to get my hands on lab gear to make it more a part of my day-to-day experience.

These days, it’s way easier to get started with Junos. You don’t have to wait for someone to get you some lab gear - you can set up a virtual lab right on your laptop. While there are a few places you can do this, one of the Continue reading

Get Started with Junos Quickly (and free!)

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.

Unit Testing Junos with JSNAPy

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. One of those tools popped up on my radar this week - jsnapy.

JSNAPy

JSNAPy describes itself as the python version of the Junos snapshot administrator. While this isn’t untrue, I think it’s a huge undersell. In my view, the assertions you can make on the data retrieved via these snapshots is where JSNAPy really shines. So in order to conceptually understand JSNAPy, I’d recommend you think of it as as a generic assertion engine for Junos, and the snapshots Continue reading

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.

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

1 2 3 … 21 Next »