The Cirrascale Blog/ Scaling the Cloud One Blog Post at a Time

The Cirrascale FOREST Container

My last blog post was very non-technical, and despite all the positive feedback I received, I was committed to writing something more technical this time.  Believe me, I wanted to write something data driven this time around, but found myself having to deal with the same issue over and over these past few weeks: Core Competency. When I use the term “Core Competency”, I mean being really, really good at something, and centering your efforts around things that take advantage of that goodness.  Although Cirrascale is a relatively small company, we make some very big products.  This means constantly having to deal with make-versus-buy decisions, wisely choosing our solution partners, and reigning in eager sales folks who want to give the customer anything they ask for.

One example of what I’ve been preoccupied with these past few weeks comes in the form of a make-versus-buy problem in developing some new functionality for the power subsystem of our Modular Blade Chassis (which we call the “MBC”, since it’s far less of a mouthful).  One of the ways to create the functionality would be to make it in-house, incorporating the feature into our existing components by adding a microcontroller, transceivers to implement a CAN bus, power relays, a few ancillary parts, and some firmware to make it all work together.  The cost breakdown ends up being something like:

An alternative way to achieve the same functionality is to buy an off-the-shelf part, and integrate it into our existing product.  For low quantities, this results in costs that look like:

On paper (or more likely photons), the “Make” solution seems very attractive.  Not only do we save $430 on our 25 unit build, but we end up with some additional intellectual property to boot!  Let’s talk about that $430 first.  The numbers above are for an initial implementation, a first release, a version 1.0.  Assuming we get the hardware right the first time (which honestly, we usually do), our history has shown that we usually need to make some bug fixes or tweaks to the firmware after release. $430 doesn’t go very far toward firmware and test engineer time spent on bug fixes, so that cost differential is likely to evaporate on the first bug that needs to get fixed.  “But what about all that valuable IP you’d have?” I hear you say.  That’s an excellent point.  At companies of all sizes, intellectual property is an important asset, but is firmware for a power subsystem in our low-end chassis really something valuable to Cirrascale?  Is that what we “do”?  Is that something likely to increase our value or differentiate us from everyone else?  Probably not. ¹

Another area these past few weeks that I repeatedly had to deal with was solution partners wanting to check all the boxes for a customer.  Generally, Cirrascale sells solutions, not just point products.  To enable this, we partner with like-minded companies, and together have something compelling to offer customers.  Take enterprise storage as an example.  We have a handful of different partners, and depending on the needs of a customer, usually select one of them to go offer as a solution along side our hardware.  But what happens when a customer has two different needs?  Say they need a NAS for one department, but on hearing more about the solution mention that they could also use Object Storage for another department?  What happens more often than I’d like is that the storage partner who does NAS chimes in “Oh, we have a plug-in that does Object Storage too!”.  Or conversely, our partner with kick-butt Object Storage who is in the account will pipe up with “This extra piece of software/hardware/magic will turn our Object Store into a NAS for you!”  The reason why is obvious: “the” storage partner wants to get the deal, and believes they need to make it clear to the customer that they can do everything the customer needs.  What really happens is that as everyone starts digging into the capabilities of the secondary feature (e.g., the Object Storage plug-in from the NAS guys, or the NAS gateway for the Object Storage product) limitations start to become apparent, and it becomes clear that the solution is no longer best-of-breed for all the needs.  Now we’re left with a solution that started off as “This is the best datacenter-widget you could ask for” and ended up with “This is a kludgy solution to your problems”.  The desire to check all the boxes results in an outcome where there is doubt about some features of the solution, rather than the customer knowing that they are getting the very best feature set and implementation available.  I for one would much rather hear somebody say (for example) “We are the best at enterprise NAS.  None better. If you want something other than a NAS, we can easily coexist with other vendors products, but we don’t want to dilute our product functionality.”  As a partner, I know I would much rather think that resources are getting invested in making the primary product more robust than having those resources spent adding functionality that is never going to compete with folks who do that as their primary function.  Be the best at what you do, and don’t squander resources just so you’re able to check boxes when a customer asks questions.²

Engineers and solution partners aren’t the only places where diverging from what you do best occurred lately.  We have really good, smart sales people here at Cirrascale.  The caliber of customers that they get us involved with continually astounds me, and equally impressively they actually find customers that buy products.  Sometimes, however, there’s a bit of over-eagerness to say “yes” when a customer asks for something.  For new products, we’ve implemented as part of our Product Development Life Cycle a mechanism that requires the requester (who is usually somebody in Sales) to define how the new product aligns with our corporate goals and strategy.  While we still get flippant answers to that question like “The customer has money”, for the most part this has allowed us to weed out diversions from what we’re actually good at.  Of course, that hasn’t completely solved the problem.  As I mentioned earlier, we make big products. We’re very good at building dense systems that can be deployed cost effectively at massive scales.  Recently we engaged with a potential new customer who wanted a solution that would start relatively small (a few hundred terabytes…very much on the small side for Cirrascale storage solutions), but would let them grow to a few petabytes quickly (a few petabytes is still rather small scale, but at least it fills the better part of half a rack).  After spending some time working up a solution based on the initial requirements, we started our iterative design process with the customer.  It turns out that they were a little optimistic when we first met, and now they want to start at a couple hundred terabytes, and grow to a few hundred ultimately. Bad news for Cirrascale, since when a solution ends at a few hundred terabytes of storage, not only does the overhead of the infrastructure investment get larger as a percentage of the total cost, but the ability to have control over the failure modes diminishes; it’s really hard to spread disk arrays out to tolerate the failure of a Storage Blade when you only have 2 Storage Blades in total!  Further discussions resulted in more refinement of the customer needs, and we ultimately ended up with a solution that starts in the tens of terabytes, and can grow to a hundred or two over time.  Rather than continue to propose a system which had removed the cost and density advantages of Cirrascale products, the better choice is to work with the customer to find a more appropriate form-factor for their storage needs.  There are other vendors which make really good small-scale storage solutions, and informing a customer of that not only builds our credibility in their eyes, but lets Cirrascale stay focused on what we’re good at.³

I realize the scenarios I described above sound like tales of woe, but fear not dear reader, they all have happy endings.  Perhaps because we’re an engineering driven company, Cirrascale usually makes good, logical decisions, our solution partners know when to bow out of a deal, and our sales team understands our capabilities.  Then again, as a Systems guy at heart with a widely varied educational and professional history, I’m probably the last person anyone should listen to when talking about doing only one thing well.

<sup>1. Obviously, the real situation is far more involved than what I described, with lots of other intangibles like opportunity cost and schedule considerations.↩
2. Since Cirrascale hardware can support Partner #1 NAS software, Partner #2 SAN software, and Partner #3 Object Store software in the same rack, usually on identical hardware configurations, of course that would be my ideal answer!↩
3. Don’t get me wrong, I also like having money to keep the lights on and the doors unlocked! Sometimes you gotta do what you gotta do.↩</sup>

Share this Post: