I am going to do something annoying: I am going to classify computer networks into three broad types and discuss the differences. You may rest easy however, knowing I will not take the cliche next step of creating a social hierarchy based on this analysis. I’m sure there are other ways to slice ‘n’ dice types of networks and plenty of sub-types, but in my career these distinctions have really stood out as relevant to a network engineer’s career path. I have no experience in university networks, so I’m pretending they don’t exist.
Corporate
The corporate network is the most ubiquitous. This network is characterized by several features:
- User interaction. Here is where you are going to interface directly with your customers (aka users). They will lean over the cube wall if their web sites load slowly, their phone doesn’t work, or any number of things that may or may not be in your playpen.
- Chaos. There is a great chance you will have a group of switching closets all connected back to a small data center (DC). The key to appreciating this data center is realizing that unlike many environments in other types of networks, in this DC every rack is different. While this can happen elsewhere, it is all but guaranteed in the corporate network world. You will probably also have to deal with fairly lax physical access controls to the DC, leading to what any self-respecting, OCD neteng would label an unholy mess.
- User-facing technology. Here is where you deal with VOIP, 802.1x, wireless, and other technology that affects users directly.
Content
Content networks are about pushing gigabits, pure and simple. Any Content Distribution Network (CDN) will be here, and to a large degree the massive sites like Facebook (and my alma mater Myspace in its heyday) fit here too. While the business model is more complicated than “me deliver bits, ugh,” the network is set up do that above all else. This type of network has a good future with the current cloud craze. Here’s what you will see in a content network:
- Fat pipes. While content networks vary in size, you can expect to see multiple 10Gb interfaces per site, with annoyed foot-tapping from geeks and management alike while you wait for 100Gb cards to filter out into the world.
- Scalability issues. As implied by the last point, many if not most of the problems you will be solving in a content network will surround scaling the network as fast and sanely as possible.
- Simplicity…of sorts. Because of the scaling problems and relative abstraction from end users, you can expect to roll out 10 or more racks of identical hardware at once.
- Multiple providers and peers. Since your primary task is to shoot bits across the globe, you will find yourself peering with as many companies as possible with little concern for business goals or strategy. Officially, this is called an “open” peering policy; essentially, it means you say “yes” to anyone and solicit everyone you can without being rude or annoying. You will also be one of those complicated BGP use cases you probably read about as a CCNA/P trainee, splitting outbound traffic between various providers based on latency, cost, politics, and other factors. (As a corollary to this point, expect to spend a lot of time troubleshooting the internet and shifting traffic around.)
Provider
I deliberately avoided the term “ISP,” because nowadays your ISP also provides more than the “I.” It provides whatever it thinks it can make a profit on. These are your telcos (telephone companies) like AT&T, cable TV/internet players like Cox Cable, regional carriers like PCCW, and little guys with plenty of big-ish players like Hurricane Electric in there. Provider networks entail:
- Process and procedure. The larger the provider, the longer it takes to get anything done. This is not necessarily a slight; if you add the wrong static route, you can down 10 neighborhoods or worse. That procedure is there for a reason, even if it does not always work. Either way, if you hate that sort of thing, working at any large provider will frustrate you.
- Transit traffic. In a corporate environment the end user is in your network. In a content network, the content is in your network. In a provider network, typically neither is. This has interesting security implications (maybe I’ll dedicate a post to those). This does not apply to full hosting providers (where you have root on the customers’ servers), or in some cases to the business units that provide hosting inside a traditional ISP.
- Legacy stuff. Providers tend to move slower than…well, anyone outside the DMV, really. You are bound to come across things you read about but did not expect to see in production, like RIP, Frame Relay, or a router the vendor stopped supporting 3 years ago.
- Silos. Chances are you will not know the people fielding support calls for work you do, or if you field support calls, you will not know the people responsible for the design work. Everyone is abstracted.
- Lifers. For some reason, mid-to-large providers have a relatively massive number of people who have worked there for 10+ years, something fairly unheard of for us Gen-X geeks. There are political and technical repercussions here, but tact and self-preservation demand I leave them to your imagination.
Career Implications
If you are starting out in the networking field, it helps to know where you want to go. Corporate environments are great for job security. They are everywhere, so it is pretty easy to land a new job fast. If you want to move into management, this is a great place to work because you can move from working on a 500 user network to managing a 100 user network and you will have a “been there, done that” aura. The down side is non-tech companies treat IT as a bill, similar to electricity. You will have a variety of technologies to work with, but the budgets will not have much fun money.
With content and provider networks, you move up the totem pole. In a content network, the network is critical to the business goals; a single minute of downtime is very quantifiable in damages, so you can expect more wiggle room in the budget for security and redundancy. On the other hand, you spend a great deal of time on logistics, like counting free ports and ensuring the next wave of circuit upgrades have optics.
In a provider network, the network *is* the product, so your team is the top of the heap in many ways. Instead of being the enabler for delivery of applications or content, applications exist to enable you. Budgets grow to include things like *GASP!* labs. The tradeoff for this maniacal power is stress. As you get closer to the center of attention, the stomach aches and restless nights climb along with the accolades and budgets.
I highly recommend any network engineer work in all three arenas if at all possible. The technology focus is different in each one (with leakage obviously) – VoIP vs load balancers vs MPLS, for example. But the soft skills are what distinguishes the architect. Working in operations in each environment forces you to learn what providers exist where (and which to avoid…), peering exchanges and their ettiquite, how to work within companies with vastly different models, and just boatloads of other things that make you more knowledgeable and hence valuable. You also start building your professional network, and within a few years you have ex-coworkers strewn about the landscape, awaiting your awesome prowess with the giddyness of a child on Christmas eve.
About Keith Tokash
