We would like to show you Azimuth, a new tool for exploring networks, built by interns at light speed. It’s like a command-line, except instead of the output being text, you get an interactive 3D graph.
How do you understand a network as it changes and grows by orders of magnitude?
Hand drawn maps don’t scale and machine drawn maps just show too much information. We took a stab at immersive 3D and VR, but found out that it didn’t really simplify anything because we were just pushing complexity into the z-axis.
After a lot of trial and error, we discovered that having a command-line tied directly into the running application, not only sped up development (which is where we got the idea), but also provided a powerful interface for users to dominate the complexity.
Instead of trying to simplify everything imaginable for users a priori, the key is to give tools that provide significant power coupled with immediate visual feedback (context), so users can do it themselves.
So, let’s check it out.
What can a command-line view of the network do?
Let’s say you just joined the team and need to update some backend “Starscream” servers. For starters, where are they even located and what do they depend on? Normally we’d have to read a bunch of code and hunt around to figure this out, but here we can just use a search command.
Now that we found the security groups for the Starscream servers, we can see how they are connected and get more details from the information cards in the panel on the right.
Next, we need to make a few changes to some web servers that host services over HTTPS, so we can again use the command-line to only show port 443 connections and focus on the task at hand.
Finally, since some of these services are load balanced, we can toggle into 3D mode and check it out.
Although most layout is done in 2D, the z-axis does come in handy. Here we can see the load balancers with all of their instances stacked on top of them.
Internally we’re starting to use the tool for keeping up with network changes, security checks and visually debugging connectivity issues. Next up, we’re planning to add cost tracking as well as usage and traffic information, plus a time machine so it’s possible to go back and watch changes to the network over time.
Metcalfe’s law is usually stated in terms of telecommunications networks, where the value of the network rises on the order of O(n²) as the number of connections between nodes increases. However, this also carries over to functional programming and system design.
By building around a set of functions that operate on a common data structure, every new function we include multiplicatively increases the value of the existing system, since each new feature can be used with all the existing ones.
For example, by adding a new
findByTraffic() function, we can use it with the existing functions to select all the links with port 443 traffic that are over one megabyte.
As a software engineer, it’s fun to have a quadratic O(n²) term actually working in our favor for once. But besides just using this to simplify internal designs, we’ve found that carrying this power onward to end users by exposing it through a command-line interface, combined with immediate visual feedback, is pretty compelling.
The importance of immediate feedback
Programming is a process of discovering exactly what we need to know in order to solve the challenges we face. Anything we can do to shorten this build, break, learn feedback loop, the faster we can converge on the understanding necessary to actually solve these challenges.
When we started the project, we didn’t know anything except that we wanted a system for mapping the network. Everything else we would have to figure out along the way. By building a system around quick iteration (to minimize the penalty of missteps), we can maximize learning and applying what we’ve learned, since we need to quickly discover what we don’t even know.
From the beginning, we built around the idea that we should be able to do an entire day’s work without restarting the server or ideally even refreshing the browser. When we save changes to our code, they should be immediately hot-swapped into the running application, so we can experiment and adapt as fast as possible.
It may seem eccentric, but this isn’t just about speeding up the workflow, this is about writing code that is easier to modify and change.
Towards better code
Good code is changeable because successful projects will always need to change. If code is so malleable that it can survive being altered while running, then it’s arguably pretty good stuff. Going further, we’ve seen that code written this way is also easier to refactor and update with new features.
“[Choice] is the only tool we have which allows us to go from who we are today to who we want to be tomorrow.” – Sheena Iyengar
Writing easily modifiable code is all about preserving choice, protecting the amount of options we have to incorporate what we learn tomorrow, into the code that we wrote today, and not getting trapped by the uninformed choices we made yesterday.
All in one wild internship
Hope this gives you a taste of what our interns built this summer and the underlying philosophy. Interns Stephen White, Sean Lee, and Robert Henning had a blast creating it.
We’ll be back with more details and code samples on how to build an immediate feedback system next time.
Also, if you’re looking for a radical internship and learning everything from 3D graphics, to functional programming, UX, networking and surfing (we’re near the beach) — all in one summer, give us a shout.