The (much appreciated) twitter and website attention that we’ve received over the last few days has led to a few good jokes around the office. It has also made us reflect on the differences that we’re seeing in our business today versus this time last year when we saw a similar spike in traffic, and a handful of reasons for why the market today is in such a different place.
The team on our side would be very curious to hear your reactions to this, and stories are always appreciated. You can comment here, or reach us at info (at) or @bigswitch.

Reason 1: Users are starting to vote with their dollars We recently announced that we’ve booked over $1 million in orders related to our Big Cloud Fabric product before ending our beta period and are shipping to first customers (last week). Rod Hall noted that we just raised our revenue forecast with our board by 50% due to a mix of Big Tap and Big Cloud Fabric acceleration. Contrast this to two years ago when new SDN product announcements generated a stream of write-ups, a handful of lab trials, but relatively few actual purchases. Back then, *nobody* wanted to make a major commitment before seeing what the incumbents had to offer. The market has changed. Thanks to products released this year, we are in the first quarter when folks from companies like Cisco, VMware and Big Switch can follow up a PowerPoint promise with production-ready products. The cards are on the table! Reason 2: The underlying problems are getting worse Hyperscale operators who have embraced SDN are sitting on a different cost trajectory and a very different operational/agility norm than the rest of the industry. If provisioning new enterprise grade applications in a “normal” data center required zero calendar days and zero network engineer hours, there would be little need for SDN. Today, enterprise-class security, reliability and visibility over the long term takes agonizing amounts of network design and analysis for each new application. Either design shortcuts are taken (we call these “mosh pit” style data-center designs) or calendar time is taken (we see apps that take 10-12 weeks to roll out). IaaS-style build-outs, devops-style operations, and a hyperscale-design philosophy are growing, and neither the design shortcuts nor the calendar time is acceptable in these environments. I went back through my calendar and was counting customer meetings that were focused on “trying to pilot an IaaS cloud” rather than on “growing a successful IaaS cloud.” Comparing September 2012 to September 2014, the number “growing a successful IaaS cloud” tripled. Traditional box-by-box networking has no good answer to this, thus SDN. Reason 3: It is getting easier to get bare metal switching hardware that works with SDN software Two and a half years ago, I remember sending members of my team out to a warehouse in Fremont, CA to get four bare metal switches to loan to a financial services customer so they could get their Big Tap PoC going on schedule. We now order bare metal switch hardware almost every week, and the awkward friction around commercial terms, warranties, and support responsibility has slowly given way to practical methods that the software and hardware vendors in the bare metal switching supply chain work together to make sure that solutions work for customers. Reason 4: It is getting easier to get SDN software that works with bare metal switching hardware We like to talk about the 2010 “erector set” days of SDN when the mental model was to have a control application sold by one vendor, a controller platform sold by a second vendor, and a dataplane (i..e., switch hardware/software) sold by a third vendor. Today, the model is more like the Android phone. There is a hardware ecosystem and a software ecosystem, but in the end a user expects a fit-for-purpose product and one throat to choke. Controllers like the Big Tap controller or Big Cloud Fabric controller come not only with the platform and app software thoroughly tested together, but the software images themselves embed the requisite Switch OS and act like a PXE server for switch software. Installs and upgrades where our SE team assists have gone from weeks to just hours, yet the REST APIs that give our end users the ability to tweak these things to their hearts’ content remain intact. With a $99k (list) “hardware/software/support” starter kit launching shortly for Big Cloud Fabric, the contrast from the old days to today is stark. Reason 5: Users like it better I am going to quote an email from a consulting engineer taking our product for a test drive: “Recently I've been doing some contract work for an MSP, and in the last couple of weeks I've seen this sort of stuff: Frame Relay, RIP, NAS ports connected at 100Mb, 7206s with uptimes of 5+ years (and obviously running ancient code…) and Arguments about how Telnet + TFTP is still perfectly acceptable … and then I get a chance to play with something like Big Cloud Fabric. So far ahead of traditional networks, and it just makes me despair at some of the old stuff I still come across.” ’nough said. Conclusion / Next Steps If you like the idea of cutting through the noise and going straight to a hands-on session, let me invite you to the beta of our online, hands-on labs at If you like the idea of seeing a few demos, check out our pages under the “SDN Products” menu above, or the whitepapers under the “Use Cases” menu. If you want to speak to us directly, feel free to reach out at info (at) or @bigswitch. Thanks.