Data Centers optimize

Why do products work (or not work) well with one another?

Scott Lowe discovers some secrets of product interoperability while attending the Storage Networking Industry Association meeting.

This week, I attended the Storage Networking Industry Association (SNIA) Storage Developers Conference (SDC) in Santa Clara, CA. In the interest of full disclosure, my attendance as a blogger at the conference was covered by SNIA. I attended the conference through Foskett Services, which coordinated the blogger portion of the conference with SNIA and, during the conference, the group did live daily sessions (as a part of Tech Field Day) in which we all discussed what we'd seen and heard that was of particular interest.

SMB3

Microsoft has spent a lot of time and effort on creating Server Message Block (SMB) 3, a massive update to older versions of SMB. SMB 3 is a serious enterprise-worthy storage protocol and a number of vendors-storage vendors, operating system vendors, test equipment and software vendors-want to ensure that their products can interoperate with SMB 3. Further, not all vendors will support every SMB 3 feature.

The goal for Microsoft is to make sure that their partners are supporting SMB 3 and, for those that are doing so, that their SMB 3 support works well and is a seamless experience for their customers. After all, Microsoft doesn't want a bunch of support calls because a vendor did a poor job writing code to support SMB 3.

Have you ever wondered how all of these vendors make sure that their products interoperate? Sure, not everything interoperates as much as we'd like sometimes, but it's often a pleasant surprise when two products from two different vendors connect together and work just like we expect.

Believe it or not, you often have deep vendor cooperation to thank for this fact.

The SNIA SDC Plugfest

At SDC, Microsoft sponsored an SMB 3 Plugfest. In a large ballroom at the conference hotel, vendors bring their gear to the room and run intensive interoperability tests and gather information about what needs to be fixed in order to provide the best possible support. What I loved about my tour through the Plugfest room was the openness of the attitudes in the room. In the photo below, you can see the list of vendors represented in the Plugfest.

Figure A

In public, many of these vendors are not known for their pleasant words toward one another but in private, their engineers work together to make sure that they're providing great support for SMB 3. Much of the work in the Plugfest room falls under NDAs and all of the engineers in the room are beholden to strict NDAs, which, in this case, is a good thing. With strict NDAs in place, engineers are free to discuss with one another what could be disastrous public relations issues. For example, what if it was discovered that Vendor A has a serious bug in their code that could result in data loss? That could be great fodder for a competitor, but in the spirit of the Plugfest, that information will never see the light of day, except between the vendors in question. This allows a great deal of honesty to be introduced into the discussion and for bugs to be identified, discussed and fixed with extremely talented engineers all talking the talk.

I was amazed at the sheer variety of equipment that I saw, including some of it labeled with Post It notes instructing anyone interested to simply connect to the equipment and play: "i.e. ‘Want to connect to me? Browse to \\10.1.1.1".

A feared (in a good way) partner

I was pleased to talk with a representative from a company called Codenomicon, which was present at the Plugfest. Codenomics runs a product through a series of rigorous tests and supports hundreds of communications protocols, making it a complete test environment. In fact, it's so complete that at least one major cellular vendor refuses to accept a new device from its partners unless that device has passed through Codenomics and the issues are resolved.

As I spoke with the company, I began to understand why their customers love to hate them. Codenomics is complete. It's able to find all kinds of issues that developers never dreamed of. In fact, I was regaled with a tale of an open source application, which, once it went through Codenomics had a major, major bug discovered that no one had noticed for more then ten years and this open source app is not one of the small guys.

I was also told that many engineers are proud to bring their products to Codenomics and expect to last at least 15 to 20 minutes before something egregious is discovered and that, five minutes later, many of these same folks are walking away dejected that they lasted only 1/3 the expected time.

Codenomics works its magic by working around the edges. Where the spec says "For XYZ feature to work, you need to send ‘abcd'", Codenomics instead sends ‘acbd' to see what happens. They operate using fuzziness to see just how far out of spec a product can be pushed before it fails. This kind of testing is critical for both security and interoperability.

Summary

All of this collaboration, even when supported by companies buying services from other vendors such as Codenomics, is really great to see in action. It shows that the SNIA mission for cooperation in the industry is both achievable and achieved. As consumers, we are all better off for it, too.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

2 comments
Deadly Ernest
Deadly Ernest

who are supposed to be the main industry leaders not only refusing to create their products in line with the established Industry Standards but also go about changing their own internal standards on a regular basis.

MyopicOne
MyopicOne

Remember the long distance carrier wars a couple of decades ago? I contracted at MCI, Sprint, and AT&T at different times, but they all had one thing in common. At the end of their switch routing tables, they'd route the call to another carrier. Why? Because it was more important that the call go through even if another company got paid for it. Same deal with this...