101 Comments

Summary:

I was recently meeting with a Web 2.0 company discussing their network infrastructure plans. As I started asking questions about their racks of servers, their storage area network (SAN), their plans for routing, load-balancing and network security, the CTO of the company stopped me and made […]

I was recently meeting with a Web 2.0 company discussing their network infrastructure plans. As I started asking questions about their racks of servers, their storage area network (SAN), their plans for routing, load-balancing and network security, the CTO of the company stopped me and made a bold statement.

He said, “The Internet is like electricity. We plug into it and all of the things that you mention are already there for us. We don’t spend any time at all on network or server infrastructure plans.”

To this CTO, knowing the details of his network and server infrastructure was like knowing the details of the local utility electricity grid – not required. Is this a bad thing, or proof that networking technologies have succeeded?

I guess I am old school, but I recall in the not-so-distant past that every startup needed a plan for their network and server infrastructure and even knew the details of their service providers network – are they using OSPF and BGP? What is the latency across the local peering point? Who are their upstream network peers? How are their firewalls and load-balancers configured? What blocks of IP addresses have I been assigned and how are they routed?

Some companies, like InterNAP and Level 3, have businesses that emphasize their network optimization and network architectures. I don’t know of any electricity optimization companies and I don’t have any idea of the architectures they have built.

My roots are in network engineering and I have spent a good part of my career building network devices and global IP-based networks and services. I’ve spent years studying routing protocols, quality of service algorithms, security mechanisms to prevent DDoS attacks and have every field of the IPv4 packet header memorized.

When the CTO of a Web 2.0 company does not know how a router or switch works (or even what layer of the OSI model they even operate on), I tend to cringe a bit.

I guess I’m reluctant to admit that my technical depth in networking has been abstracted to not being relevant in the Web 2.0 world of social networking, mash-ups, RSS and AJAX. I know that a well-architected network can have a dramatic affect on application performance – but maybe on today’s high-speed Internet it does not matter. It might be that network engineers are not relevant for today’s Internet in the same way that software optimization engineers are seemingly not relevant for Microsoft applications.

On the other hand, I see the current state of the Internet as the ultimate success of these networking technologies. You can deploy a wildly successful Web 2.0 application that serves millions of users and never know how a router, switch or load-balancer works. Even network security and firewalls that were making headline news not more than a few years ago are considered perfunctory. The success of these networking devices and technologies has enabled them to become part of the technology landscape that exists for all to use as they see fit, similar to the microprocessor or electricity.

In your opinion, has the Internet reached a level of abstraction similar to electricity? Do you use the infrastructure that is given to you by your local Internet service provider or a specialized hosting facility like Amazon without questioning how it is architected and designed?

In my role as a venture capitalist, the answers to these questions will help me determine if startups that are building optimized networking devices, improving network security, virtualizing storage, and so forth are required in today’s market.

Allan Leinwand is a venture partner with Panorama Capital and founder of Vyatta. He was also the CTO of Digital Island.

  1. Internet business is highly layered today. And Web 2.0 is qualified to be an application layer and really don’t need to worry more about the infrastructure. They can start from commodity hosting plan as “electricity”. However, if they dig into depth with growing number of users and joint social connections between those users, they have to pay more attention on the peak of networking. Like the problem with Friendster two years ago.

    Share
  2. Interesting post. I tend to agree with the CTO … if they’re plugging into something like Amazon’s server services.

    If not, however, they better know something about the mechanics of how their solution will be delivered. Even a trucking company cares about the road conditions, which routes are faster, and so on.

    Share
  3. If the company is at the stage of concept building, the CTO may more focus on the application technology like J2EE or PHP or Rails. Until they want they have beta users and really concern about operation, then networks knowledge is must.

    Share
  4. The internet is like electricity – you need to understand it well once your needs scale. The same is true for heating, hardware failure rates and disk throughput. Most companies will never get to the critical mass where these are even an issue (it’s amazing what you can do with even just one server these days). However, from my experience once you do you find good network engineers hard to find.

    Share
  5. I tend to agree with you about what lies outside the rack being largely irrelevant to most upstart web application/service providers, but I wouldn’t go so far as to throw load balancers, switches, and other technologies clearly within the control of the company into that mix.

    Do I care about the internals of how my co-lo communicates with the outside world? Probably not. But do I care how my Netscaler distributes traffic between all of my own servers? Hell yes. Some people may do without a traditional load balancer in favor of robin-robin DNS (WordPress.com and Bloglines do this) but even in that case, you need to know what it does and how it works.

    The other option, of course, is running everything on one machine, which a low-volume company can get away with, but you almost don’t even need a CTO for that sort of company. Or you can use managed hosting, which is extremely expensive.

    I guess my point is, I would separate pools of knowledge into “outside the rack” and “inside the rack”. Does outside the rack knowledge matter a lot less now? Sure. Inside the rack? Probably not.

    Share
  6. Jesse Kopelman Tuesday, April 10, 2007

    The problem with electricity is that maybe we take it a little too much for granted. Lack of choice, ever increasing costs, rolling blackouts anyone? Is this really what we want in terms of Internet?

    Share
  7. Has the internet reached a level of abstraction comparable to plugging into an electrical socket?

    If one where a “CTO”, I would hope the answer is no. A CTO really should be aware of not only the application his/her company is providing but the pipes that connect that application to the outside world. Does this mean knowledge of things down at the packet level? No. But, if something goes wrong I would hope that the CTO has the knowledge on where to start troubleshooting. This includes attacks (security), performance (servers/bandwidth), and overall availability (all of the above).

    Title are thrown around a little too easily in this day and age. However, for large scale deployments, knowing what is going on from application down to IP packets is critical to making sure one’s application is on a stable infrastructure.

    Share
  8. It all depends on what scale they’re operating at. I had a small Web 2.0 startup that was acquired by a much larger company. When we were operating with ~1M pageviews of basic web stuff, it was all a service.

    Now that I’m working on services that are constantly pumping out many Gb/s of data, it’s entirely different. I still mostly deal with the software architecture, but I certainly do talk to our ops folks on a regular basis. I make sure I know what’s up with everything from our various POPs and fiber to Netscalers and Netapps.

    Beyond a few special deals we have, do I care about routing tables and the like? Not really, our providers handle most of that. It’s still useful to know so we can make back-of-the-envelope guesses when designing new services.

    Is this CTO implicitly saying he doesn’t think he’ll get significant usage?

    Share
  9. These days you can add month’s use of a dedicated server for the cost of an hour worth of labor. Focus on what differentiates your product. In some business that’s the network infrastructure. But most startups are not in that business these days. That doesn’t mean you should ignore the design of your network, and not have a plan to scale. But doing so at the expense of developing your core product is premature optimization. Make it work first, have a plan to scale, and focus on that plan when the time comes, not before. There’s a tipping point when it’s smart to optimize your application instead of doubling the number of servers needed to run it. Both extreme denial of the need to understand network optimization and extreme focus on network optimization are silly moves.

    Share
  10. For a brand-new startup that doesn’t know if it has a hit or a dud on its hands, they can certainly find out first and worry about scaling later.

    But ask any so-called Web 2.0 company with scale, and they’ll tell you figuring out the server- and network-level scaling is both vital and difficult. Leaving it to someone else who doesn’t intimately know the details of your app is very risky and error-prone.

    I’d say that a scenario like you described sounds like nirvana. I’d love to be there. But currently, it’s just a dream.

    Oh, and you’ll also find that “electricity” is no longer a faceless utility but a very real problem for a popular web app. Power and heat densities (which is really another way of saying power and power :) are something we spend a lot of time thinking and dealing with.

    Share

Comments have been disabled for this post