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.
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.
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.
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.
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.
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.
Infrastructure doesn’t matter. That’s what we keep hearing, right? The ongoing effort to commoditize infrastructure has generated a lot of buzzwords and clickbait taglines, and this is one of the biggest. IT infrastructure has had a long history of hero culture, and it’s easy to make the assumption - given how low many of these technologies sit in the stack - that we are the important snowflakes and that we run the whole show.
I have been spending this week in Silicon Valley at Network Field Day 10. One of the announcements struck a chord with me, as this year has marked some significant career changes for me: specifically an uptake in involvement with containers and software development. My good friend Brent Salisbury once wrote about the idea of using Golang for Network Operations tooling. While I’ve continued (and will continue) to build my Python skillset, I’ve also been getting more and more experience with Golang and with some of the great software projects created by it, such as Docker, and Kubernetes.
Cumulus recently announced their CumulusVX platform, which is a virtualized instance of their operating system typically found on network switches. They’ve provided a few options to run this, and in this blog post, I’ll be exploring the use of Vagrant to set up a topology with Cumulus virtual devices. Brief Review of Vagrant In software development, there is a very crucial need to consistently and repeatably set up development and test environments.
This is a rant. It borrows emotional (and some verbal) inspiration from Lewis Black’s “Big F**king Thing” bit. However, in order to keep things light and professional, I will be using the term “flower” in lieu of the four-letter word that I am using in my head. It’s not unreasonable that ongoing operations for existing applications, and as a result, remaining profitable, have been and always will be the priority.
There has been a plethora of docker-related info on the internet this week, thanks in no small part to DockerCon, and I was motivated to finish this blog post about container networking. In short, it seems like most if not all container networking projects are going out of their way to give devs the feeling of a “flat” network. My question is - who cares? Seems to me that "cloud-native" applications should be okay if two of the cattle are not on the same broadcast domain.
I’ve been playing around with various message queue implementations for a few projects, and wanted to write a quick post on some basics. Message Queues Before we get into the detail of RabbitMQ, it’s worth briefly defining exactly what a message queue is, of which RabbitMQ is just one implementation. You may have heard message queues described as a “Publish/Subscribe” system, or “Pub/Sub” for short. This is a style of communication between software elements, where some components publish messages onto a queue, and others subscribe to that queue and listen for messages published on to it.
Earlier, I wrote about some interesting open source routing software that I’ve been exploring lately. In this post, I’ll provide you with some tools to get this lab running on your lab, using Vagrant and Ansible. In this post, I’ll be using VirtualBox, and also Ansible and Vagrant. For this purpose, I’m assuming you’re at least somewhat familiar with these tools. Please checkout my GitHub repository for access to the latest versions of all of the files we’ll discuss below - and an easy way to spin all of this up yourself.
Python is one of the easiest programming languages to learn, because of it’s inherent flexibility. (This can be a good thing as well as a bad thing.) One example of Python’s flexibility is the double parentheses. Take the following snippet for example: print(funcwrapper(3)(2)) Even an inexperienced programmer should be able to make sense of most of this. Reading from left to right, it looks like we want to print the output of a function, and we’re passing an integer - 3 - to that function.
I have been getting more interested in open-source networking software, and I figured it was time to write a post comparing some of the more popular open source projects in this space. Not only do we have several options (which hasn’t always been the case) for running routing protocols in FOSS, but we also have a variety of use cases that are increasing in popularity (using BGP for SDN-type purposes, not just to do internet peering).
I have moved to a new blogging platform! The timing was interesting, since the wordpress installation on which Keeping It Classless has operated for so long is about 5 years old (I operated on an older domain before Keeping It Classless was born). WOW. Five years is a long time in blog years. I could not have possibly predicted back then what this blog would do for me. In going over these old posts, I saw a very interesting progression of my own skillsets and mentality, and I figured I’d share.
I would like to take the opportunity to let you all know that Keeping It Classless will be moving to a different blogging platform in the near future. For the vast majority of you, this will not be a problem. My intent is to keep as much as possible consistent between moves. However, some of you subscribe to my blog using some WordPress-specific features such as email subscription, as well as following me through the WordPress service itself.
I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.
You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case. Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept - because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline.
From time to time, I’m asked by new or potential technical bloggers for advice on how to get into writing, or how to overcome some kind of mental reservation that he/she may have. It’s actually somewhat ironic - I still suffer from many of the same issues that I suffered from back before Keeping It Classless existed. I have been having some serious "Newbie Blogger" issues last few weeks. Ironically, I feel compelled to write about them.