
Author Archives: Russ
Author Archives: Russ
Project AI+Compassion just interviewed Heidi Roizen about compassion in IT; it’s worth listening to. From the show notes—
Language is deeply contextual—one of my favorite sayings from the theological world is if you take the text out of its context, you are just left with the con. What does context have to do with development and operations, though? Can there be low and high context situations in the daily life of building and running systems? Thomas Limoncelli joins Tom Ammon and Russ White to discuss the idea of low context devops, and the larger issue of context in managing projects and teams, on this episode of the Hedge.
Everyone is aware that it always takes longer to find a problem in a network than it should. Moving through the troubleshooting process often feels like swimming in molasses—you’re pulling hard, and progress is being made, but never fast enough or far enough to get the application back up and running before that crucial deadline. The “swimming in molasses effect” doesn’t end when the problem is found out, either—repairing the problem requires juggling a thousand variables, most of which are unknown, combined with the wit and sagacity of a soothsayer to work with vendors, code releases, and unintended consequences.
It’s enough to make a network engineer want to find a mountain top and assume an all-knowing pose—even if they don’t know anything at all.
The problem of taking longer, though, applies in every area of computer networking. It takes too long for the packet to get there, it takes to long for the routing protocol to converge, it takes too long to support a new application or server. It takes so long to create and validate a network design change that the hardware, software and processes created are obsolete before they are used.
Why does it always take too long? Continue reading
It often seems like the IETF is losing steam—building standards, particularly as large cloud-scale companies a reducing their participation in standards bodies and deploying whatever works for them. Given these changes, what is the future of standards bodies like the IETF? Mark Nottingham joins Tom Ammon and Russ White in a broad-ranging discussion around this topic.
My article on Internet centralization just published over at The Public Discourse—
We’ve all been told agile is better … but as anyone who’s listened here long enough knows, if you haven’t found the tradeoffs, you haven’t looked hard enough. What is agile better for? Are there time when agile is better, and times when more traditional project management processes are better? Mike Bushong joins Tom Ammon, Eyvonne Sharp, and Russ White on this, the 95th episode of the Hedge, to discuss his experience with implementing agile, where it works, and where it doesn’t.
This last week I was talking to someone at a small startup that intends to eliminate all the complex routing from campus networks. In the past, when reading blog posts about Kubernetes, I’ve read about how it was designed to eliminate routing protocols because “routing protocols are so complex.”
Color me skeptical.
There are two reasons for complexity in a design. The first is you’re solving a hard problem. The second is you’ve made bad design choices in the past, and you’re pasting complexity on top to solve some perceived problem (whether perceived or real).
The problem with all this talk about building something that’s “less complex” is people tend to see complexity of the first kind and think, “we can get rid of that complexity if we start over.” Failing to understand the past before building the future is a recipe for repeated failures of the same kind. Building a network without a distributed routing protocol hasn’t been tried before either, right? Well, yes, it has … We either forget how it turned out, or we say “well, that’s not the same thing I’m talking about here” (just like “real socialism hasn’t ever been tried”).
Even worse, Continue reading
If you’re like me, you’ve heard a lot of hype about quantum—but you’ve never really been able to understand what quantum networking might be useful for. On this episode of the Hedge, Josh Slater, who works in the field of quantum networking, Ethan Banks, and Russ White discuss the current state of quantum networking and potential use cases for the technology. Things are farther along than you might think.
It always takes longer to find a problem than it should. Moving through the troubleshooting process often feels like swimming in molasses—it’s never fast enough or far enough to get the application back up and running before that crucial deadline. The “swimming in molasses effect” doesn’t end when the problem is found out, either—repairing the problem requires juggling a thousand variables, most of which are unknown, combined with the wit and sagacity of a soothsayer to work with vendors, code releases, and unintended consequences.
It’s enough to make a network engineer want to find a mountain top and assume an all-knowing pose—even if they don’t know anything at all.
The problem of taking longer, though, applies in every area of computer networking. It takes too long for the packet to get there, it takes to long for the routing protocol to converge, it takes too long to support a new application or server. It takes so long to create and validate a network design change that the hardware, software and processes created are obsolete before they are used.
Why does it always take too long? A short story often told to me by my Grandfather—a farmer—might help.
One morning a Continue reading
We talk a lot of about telemetry in the networking world, but generally as a set of disconnected things we measure, rather than as an entire system. We also tend to think about what we can measure, rather than what is useful to measure. Dinesh Dutt argues we should be thinking about observability, and how to see the network as a system. Listen in as Dinesh, Tom, And Russ talk about observability, telemetry, and Dinesh’s open source network observability project.
The Hedge is over 90 episodes now … I’m a little biased, but I believe we’re building the best content in network engineering—a good blend of soft skills, Internet policy, research, open source projects, and relevant technical content. You can always follow the Hedge here on Rule 11, of course, but it’s also available on a number of services, including—
I think it’s also available on Amazon Music, but I don’t subscribe to that service so I can’t see it. You can check the Podcast Directory for other services, as well. If you enjoy the Hedge, please post a positive rating so others can find it more easily.
I’ll be teaching a three-hour live webinar on data center fabrics on the 20th of August—
Data centers are the foundation of the cloud, whether private, public, on the edge, or in the center of the network. This training will focus on topologies and control planes, including scale, performance, and centralization. This training is important for network designers and operators who want to understand the elements of data center design that apply across all hardware and software types.
We tend to think every technology and every product is roughly unique—so we tend to stay up late at night looking at packet captures and learning how to configure each product individually, and chasing new ones as if they are the brightest new idea (or, in marketing terms, the best thing since sliced bread). Reality check: they aren’t. This applies across life, of course, but especially to technology. From a recent article—
RFC1925 rule 11 states—
Rule 11 isn’t just a funny saying—rule 11 is your friend. If want to learn new things quickly, learn rule 11 first. A basic understanding of the theory of networking will carry across all products, all Continue reading
On the 28th—in two days—I’m doing a master class over at Juniper on DC fabric disaggregation. I’ll spend some time defining the concept (there are two different ideas we use the word disaggregation to describe), and then consider some of the positive and negative aspects of disaggregation. This is a one hour session, and it’s free. Register here.