4 ways we are dogfooding our product at Sproute

Posted by Sproute Networks on May 10, 2019 · 5 mins read

Thus, I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. .. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important.
    —Donald E. Knuth, “The errors of TeX”

Dogfooding has been a common practice in software development. Without getting into the surge of controversies and debates about dogfooding vs. user research, we can at least assert that we have been actively using our product and it has had a positive impact on the product. Besides, which business doesn’t have a requirement to run a sound network?

SPAN using SPAN: backend operation


We use our product to operate the very backend that serves all our customers. SPAN service is hosted on AWS across multiple VPCs. Like any modern multi-tiered backend with micro-services, all of the individual service instances except for the web frontend have private addressing. Using SSH jump hosts across all of these services for deployment as well as regular maintenance just doesn’t cut it.

Here is how we have used SPAN for the purpose.


Backend operation
Backend operation


We have instantiated a SPAN virtual appliance on our AWS VPCs using CloudFormation templates. From an office Sproute device, we have connected to those SPAN instances in an SD-WAN overlay. This allows seamless access to individual servers for any operation.

We have been using it for a few years now for production upgrades, maintenance, essentially all backend operations. Here is a view of the loss on the overlay to an AWS VPC as reported from our dogfood backend:


Backend operation
Loss report to AWS VPC - April 2020


Office Internet gateway


The base infrastructure at our office in the bay area consists of two Sproute devices in PAIR mode. This allows us to survive both network and device failures. We have two Internet connections (they both happen to be AT&T at the moment which is another story) and traffic is load-balanced across the two in the PAIR setup. We haven’t yet set up any specific SaaS traffic steering, but that may change in the future - our regular application usage has been for G-suite and Slack.


Internet gateway
Internet access with PAIR


Connect our offices (& homes) together


Since the time we opened an office in India, connecting them together to have one unified network was an important goal. And then there are those of us who love to work from home. Though remote access (see below) was always an option, replacing the router at home with a Sproute device keeps things simpler and more powerful (e.g. no need for a remote access client, better QoS, visibility, and so on). The result was a fully-fledged SD-WAN overlay across our offices and (some) homes, as follows.


SDWAN Overlay
Overlay connectivity


The primary applications and resources we use the overlay network for are, in no particular order:

  • Gitlab. We use gitlab for all our development projects, issue tracking, and wiki
  • Jenkins for the entire CI/CD pipeline
  • VNC to different build servers
  • Testbed access for running various tests

Remote access


We have always had a few great engineering and business consultants. And employees who love to work from a coffee shop :smile:! For them, a secure and seamless remote access to work comes quite handy.

Remote access
Remote access