DISCLAIMER: the companies named in this blogpost

• COHODATA: sponsor of Storage Field Day 4, where I was an attendee and my T&E was covered by the collectiveness of all sponsors.
• DIABLO TECHNOLOGIES: a very recent out-of-stealth technology with whom I have no affiliation (yet?)
• SCALECOMPUTING: I am currently working on a marketing project to help ScaleComputing with brand awareness. If you want to read this post as sponsored by them I will allow you to 🙂

Today I got inspired by J.Metz’s article The Napkin Dialogues: “Open”-ing up to SDN where he admits being caught in speed by new technologies. Sometimes you need to go back to the napkin design to get a grip on it. These are the things I have tried to make my speciality; diving in a technology, simplifying it for any type of audience. If you are a seasoned technologist and used to do this type of writing, you could pull that off easily by sticking somewhere halfway between the knowledge of a newbie audience (as I probably won’t have to explain to experienced architects).

I try to dig deeper, trying to understand the technology at heart so I can both serve my customer (the vendor) better by taking all details into account and to serve the audience better by not settling for mediocre. Mostly it goes beyond the scope of the task but it keeps me safe from just reiterating the vendors’ voice. If you have that urge to understand technology at heart you sometimes get challenged by the lack of basic knowledge. So this article is my confession to startups that have challenged my basic knowledge in the last year. I’ll pick 3 in a different category. 

COHODATA – storage IP stack

First time I meet COHODATA is at Storage Field Day 4 in San Jose. Just a few weeks/months before the event they came out of stealth and I purposely had not investigated their technology before because I like to be surprised by vendors presenting us what they are so proud of. And boy did they surprise us. I even had issues following what was happening as it appeared I lacked some basic knowledge.

It appeared to me that although I tend to be a good storage technologist, I don’t truly have a grasp on the ins and outs of storage protocols and more specifically NFS. I am not talking about client and server targets or how to implement this according to proven practises because that’s (for me) the easy part of what we need in our daily jobs. But to truly understand why this new technology is cool you need to dig in the IP-headers, the protocol versions, what the limitations of that protocol in it’s implementation are. If someone would have asked me how to fake a parallel NFS system for the (old-school) client of VMware I would have had no answer.

DIABLO TECHNOLOGIES – CPU & IO architecture

Lately there are a lot of storage startups that want to challenge the smallest latency possible. All of them pointing at each other that they are the closest to the CPU which is logically the most obvious way of decreasing application latency. If we could run applications in CPU only we would. There are a lot of ways to run applications in RAM but all of them have some challenges of their own: the data in RAM is not persistent and not replicated for failure protection. 

Diablo Technologies announced their new distributed & persistent RAM technology. Now it’s not really RAM but they emulate flash as RAM on the RAM bus. One of the things they want to challenge for example is the bandwidth limitations of the PCIe IO bus. While trying to understand what this truly means I stumbled on my lack of knowledge in CPU architecture. What is the speed of the memory and PCIe bus? What is the bandwidth and how does this add up when counting it in parallel? It takes a back to basics in CPU architecture to truly understand what the status quo is that Diablo is challenging. Before you jump to the conclusion that this is the best solution we should go for I have to mention that you simply can’t really implement this on the current x86 motherboards. The only platform I know today of that could use this is the brand new IBM X-series.

SCALECOMPUTING – virtualization basics

Before 2006 I was just another Windows guy like most of you. And I have never been a linux lover, like most of you. But I did jump on the VMware wagon as of ESX2.5 & 3. Mostly because I could run more Windows machines in one single hardware server. Although the VMkernel is not a Linux kernel they are still quite similar in the syntax approach so that would have easily scared me from touching it if it wasn’t for VMware to make the use of it digestible through a GUI.

When I first heard of ScaleComputing I knew they were running on the Linux KVM hypervisor. At first I dismissed this solution just for the fact that I have an averse for CLI-based management like most Linux solutions. And then I remember that I did not have those issues when i started with VMware now more than 8 years ago. So if all this is also UI-based I should be ok with it. So I started my research in KVM technology.

A hypervisor in its true basics is not really more than a task scheduler for CPU and memory to run VMs as a single application/user domain. A differentiator when you look at all hypervisors is definitely driver management and on top of that you’ll need to understand how cluster services work (HA, DRS, vMotion, … ). I know one or two things about how VMware does this but not enough in depth to truly understand the differences from a Hyper-V, KVM or XEN for that matter. So this is a back-to-basics in virtualization for me.

My $0.02

Every time you get in touch with new technology or if someone explains it, ask yourself if you truly understand what has been said. Sometimes it’s just too obvious to rely on your latest knowledge of what you have been working on in the last 2/3 years as this mostly does serve your day to day activities. I probably ‘work’ (being active with technology) more than the average people in IT. I listen to a dozen podcasts per week, read a few dozen blogposts a day and talk a lot to people that are smarter than me in their area of specialisation. But if I can’t keep up either I am not doing a good job at it or this must be something a lot of you out there are feeling.

If you don’t truly understand what has been explained I have two very simple solutions:

• Do your research!
• Ask a specialist. You’ll be surprised how eager they will be to help you understand it.