Sun Microsystems’ famous quote “The network is the
computer” served for more than one decade as an inspiration how
to design distributed (“Hyperscale”) web applications.
At rtbrick we have always asked ourselves why Hyperscale
design principles have never been applied to the domain of
networking equipment. We believe by adhering to those principles
one can build better switches and routers.
- Small is beautiful. Build small components,
rather than large monolithic systems which are hard to extend
and maintain over time. Avoid a big “blast radius” of failing
components by keeping things small.
- Clear separation between I/O, compute and
storage. By keeping the three major functional units separate,
one can independently engineer software which greatly simplifies
the lifecycle of your networking software.
- Use a common API - Expose all your data to the
outside world using a JSON based API such that your software may
interact with an unbounded number of external programs, thereby
repeating the success of the UNIX operating systems.
- No locality assumptions - It should not matter
where an individual component of software is located. For
example: an IS-IS Routing protocol instance may run on a
bare-metal switch and the corresponding Border Gateway Protocol
instance may run out of a data-center, yet the router is viewed
as one coherent system. Where things are getting deployed is
entirely a network operator choice.
- Rapid Prototyping - Rather than waiting up
until hardware packet forwarding is available, prototype new
functionality using software based forwarding and model based
networking. What matters if how fast new functionality gets into
your integration and acceptance test labs.
- Test driven development. One of the guiding
principles of the DevOps movement is that the people who develop
the network, also have to operate the network. Therefore its
paramount prior to any roll-out to run unit- , integration- and
acceptance- tests. Hence we share our test frame work for
speeding up network delivery time.