Happy New Year!

It has been another very exciting year for cloud infrastructure, and in particular for virtualized networking.  This year we saw the launch of several products, services, and open source projects, including, OpenStack Quantum, vCider, and Embrane, not to mention several interesting products from networking hardware vendors.  We also saw the establishment of the Open Networking Foundation, whose role is to develop and standardize protocols such as OpenFlow and the future OFConfig.  We at Midokura are excited to be a part of this exciting period in the IT industry and the transition to cloud based infrastructure.

 

In 2011 the virtual networking solutions have still been in the exploratory phase.  In 2012 the focus will be sharpened as these systems are deployed in production and new challenges arise.

 

Thus far most, though not all, of the activity around virtualized networking, and its close cousin Software Defined Networking, have been focused on the first order problems of scalable, fault tolerant, multi path, and multi-tenant isolated L2 connectivity.  As these systems are deployed in production scenarios, new challenges will arise with respect to integrating virtualized environments with L3 networks, in particular the Internet.  For example, Virtual Routing and Forwarding has been used in conjunction with L2 isolation to create multi-tenant networks, but has proven to be unscalable, and also rather expensive.  Using SDN it can be done better.  Providing higher layer services traditionally performed by middle boxes, such as load balancing, and IDS/IPS, Intrusion Detection and Protection Systems is another key area.  We are also likely to see the emergence of multi-site solutions, including disaster recovery, global IP mobility, global load balancing.  Integrating all these is likely to benefit from the cross-layer visibility made possible by SDN based components.

 

We’re all looking forward to exciting new developments in 2012, the Year of the Dragon!

 

Happy Virtual New Year!

Unit tests are not enough

In one of our datastructures, there’s an entry for a 64-bit unique resource identifier.  This turned out to be a little too vague a description:  Is it an 8-byte array, a 64-bit wide integer, or an instance of a 64-bit UUID class?  One of our developers though one thing, and another thought another.  No problem, right?  The first compile by the one who chose wrong will show the type error.  Except we’re using Python, so no type checking until the code runs.  Still no problem, because our devs wrote unit tests, so the type error will show up on their first run, right?

Unfortunately, unit tests help not an iota in situations like this.  The developer expecting UUID objects writes unit tests which consume UUID objects, and the dev expecting byte arrays writes unit tests which produce byte arrays.

So, integration tests, then?  It turns out our devs did these too, verifying that their code integrated with the fancy datastructure class, but this still didn’t catch the mismatch!  This is because the datastructure class doesn’t actually do anything with the resource identifier that would trigger a type check:  it just accepts it as an entry in a slot when an item is inserted, and gives it out as one of the slot entries when items are looked up, and Python is happy to let an instance of any type pass through unchecked.

It’s only when we plug everything together that this trivial type mismatch shows up.  So the moral:  Make end-to-end tests early.  You need them to turn up even problems as basic as this, and the earlier you find problems, the better.

Welcome to our Midokura Blog

Welcome to the Midokura company blog.  Here you will find company updates, technical posts, ramblings, and rants from members of the Midokura team.

Please feel free to leave feedback on future posts by commenting, we are looking forward to hearing from you!