Recognizing Disruption and the Death of the Storage Admin

Fun Fact, I wrote this in November of last year. Still holds up. Figured I publish it.


I’ve spent pretty much the last few years speaking to customers about the many disruptive forces that are invading the traditional Information Technology space. I normally start these talks off with the slide to the left. distruptionThat’s Steve Jobs holding the first iPhone in 2007 and the text to the left is the conversation between the two CEO’s of RIM the makers of the Blackberry smart phone.  “These guys are really good, this is different” – “It’s Ok, we’ll be fine” Fine you say? At the time RIM was the dominant smart phone platform along with Nokia, both companies were at the top of the smart phone game and had the dominantnotfine market shares. At one point RIM’s shares were trading at 135 dollars a share and their market cap was roughly 40B with Nokia sitting at 114B. Both companies would continue and accelerate in both market share and value, but only until a point. That point would come a short year later with the release of the iPhone 3G and with that, the app store ecosystem was starting to gain traction and how people used their phones started to change drastically.

Now, I was an avid Blackberry user from roughly 1999 (the 850) to 2011. I resisted the iPhone at first and only got one once I moved into a Sales Engineering role that required me to travel a bit more for work. One of the primary reasons I went to iPhone was the app ecosystem that had built up around it. For anyone that remembers the Blackberry app store, then you remember the abject failure that it was, how few appdevices actually existed for it, and how abysmal the experience was in trying to use it. So as much as I loved that physical keyboard, the user experience came to be so awful that I simply couldn’t stick with the platform. Seems like the market has spoken as well, since on September 28, 2016, Blackberry announced it will stop designing its own phones. Now was the Blackberry a bad phone? No, it was actually a really good phone and email device, but that was about it. The iPhone moved my phone from being something I simply communicated with, to something I utterly relied upon for my daily life. It became a computer in my hand, not a phone. That’s one thing RIM simply didn’t comprehend and failed to act upon, or at least, waited too long to address.

Ain’t Nobody Got Time For That

timeforthatNow this seems like a long pre-amble to a post about storage, but bear with me. The storage industry holds a lot of parallels to the story above. Storage used to be a complex beast that needed to be tamed by specialist, by SAN engineers, by graybeards (sorry @DeepStorageNet). It was practically a science in the data center requiring certifications, deep understanding of the physics behind spinning disks and the complexities of RAID layout, snapshot reserves, controller overhead and limits, drive types, etc. Fact is, you had to spend a lot of time to ohcomplexityprovision and design storage when it came to legacy storage platforms. Even many of the more modern systems that are deployed today, still require some heavy lifting on the design front. Sure it doesn’t take 158 actions to provision a volume the way it did in 2005, but the underlying challenges are still there, even for systems that market themselves as simple.  The simple fact remains, when we look at the advances in technology for the data center, Storage tends to be the one system that has failed to keep pace with innovation. It’s still fairly beholden to the standards of the head and sled design construct, it still doesn’t scale well, it still fails to deliver guaranteed performance even when using Flash SSD’s as the storage medium, and it still requires a specific skill set to leverage and provision properly.

RIP Storage Admin

deathThat brings me to the death of the storage admin and why recognizing disruption is hard. Storage admins in many respects are the AS400 operators of today. Sure they sill exist, sure they still perform operations, but honestly, most technologist in any given organization kind of look at them as relics. When all you really want is to answer 3 questions: How Big, How Fast, and Who Accesses, why should simplethat process be tasked to a “specialist”. Why isn’t it simply an API call that I pass, or an integration point with my hypervisor, or a near zero touch operation that is integrated into an orchestration workflow? Now the point isn’t to insult or be totally derisive to the storage teams within organizations. The reality for me at least, is that they tend to be entrenched in their lines of thinking, and part of that is also turf and job protection. I was the storage admin for a good portion of my career in IT, and I can totally see the other side of this argument. Yes I did all that heavy lifting and design work, and I took pride in it. It took a long time to build those skills, but at some point I realized that I had to move beyond that limited viewpoint, thus I got involved in virtualization, cloud, and other technologies pushing more for a full stack engineering skill-set.

joySo to tie all this rambling together into some coherent conclusion. Like we saw with the smart phone market, the move away from just providing phone and email to a device that allowed for a full computing experience was what killed RIM and Nokia. Their technology was sound and did what it was designed to do, but they as organizations failed to see the trends that were being adopted by the  customer ecosystem. The same is being seen in how storage is being adopted, deployed, and consumed in many organizations. Storage is becoming a service to be consumed and utilized, a platform that accelerates the deployment of applications, tools, and resources. As I’ve claimed many a time, there is no book called the “Joy of Menial Tasks”  At the end of the day, our customers (ie the people we provide resources for) are looking for the same simplicity that they get when they go to the Apple app store, download an app and start using it. We need to be able to deliver storage resources in the same fashion. Now obviously, I have my biases, but after nearly two years working at SolidFire, I still have not seen a solution that delivers the simplicity of design, operation, with the multiple disparate consumption models that SolidFire does.


Posted in Cloud Storage, Enterprise Tech, SolidFire, Storage, Uncategorized | 1 Comment

Podcast Idol Application

Dear readers (what few of you there may actually be after a one year blogging hiatus) Oh happy day is upon us, I have returned, just as the phoenix rises from the flames, I too have managed to do what comes naturally, that is, talking about myself.

In all actuality I have been hella busy. The last 4 months post NetApp acquisition has been a challenge to say the least. It’s also been a great learning opportunity and I plan to start chronicling a lot more of that process on these her pages for you dear reader (count your lucky stars)!

SIT-logoObviously, that time is not now. For those of you who listen to Speaking In Tech podcast, you will notice that Sara Vela has decided to leave the show to pursue a career in opera, or street singing, or something of that nature (Keep Austin Weird). Alas, this leaves an opening in the shows cast for a new member to join and opine weekly on all the tech things. Thus, I figured why not put my application into a blog post and force myself to actually sit down and write something.

Being an illeists (look it up) here is my submission for Podcast Idol.bobdole

You know the Gabriel, he’s actually been on Speaking In Tech before, occasionally he shows up on his own group Podcast called In Tech We Trust (always be plugging). The Gabriel would make an excellent co-host and or host, sidekick, man servant, lackey, digital butler, minion and or cabana boy for the Speaking In Tech podcast. Having achieved the status of “employable” in the technology field for the last 20 years, Gabriel has managed to amass a stunning array of unimpressive knowledge for which he is in no way qualified to deliver his opinion on. This would include some of or all of or possibly even none of the following:

  • boxes that you plug wires into
  • wires you plug into boxes
  • information we used to store in books
  • books we now store on disks
  • disks we now store inside of boxes that you plug wires into
  • hyphenated words of varying length
  • tubes that carry the information we used to store in books but also store on disks inside of boxes with blinking lights
  • consumption of meat and meat like products

oldpeoplevsnewpeopleAs you can see, these are top of mind subjects that any podcast listener would find to be utterly fascinating, and of course would hold their interest for the duration of at at least 60 seconds or the amount of time it takes to swipe left or right on tindr (whichever is shorter).  This is obviously the most important skill required for Speaking In Tech, because lets face it, informed commentary on technical matters boils down to rolling bones in a pan and deciphering their meanings and then making a proclamation of fact.

All of that said, please simply provide Gabriel with the proper credentials and the an invite to the Speaking In Tech slack channel and lets get this show started.

Oh and as for that other show I’m on, who said you can’t do two podcasts as poorly as one?

Posted in Enterprise Tech, Facepalm, Podcasts, Tech Marketing | Leave a comment

Musings on the last year, successful exits, and the future in general

Let me preface this one with there has been a lot of stuff locked away in my noggin that I’ve simply not taken the time to sit down and spit out.

Fun fact, I’ve been busy.

Since joining SolidFire in April, my day job has taken up a fairly significant amount of my time, not to shark-cartoon-112mention, I’ve done a good amount of writing for SolidFire which has not all found its way over here, just in case you are curious, take a look. At SolidFire My goal has to been to make as much of a personal contribution to the success of the organization as possible. Initially my role was to take over the responsibilities of the Agile Infrastructure deliverable collateral as part of SolidFire’s Tech Solutions team. I’m personally indebted to Jeremiah Dooley for setting the bar high enough that I felt compelled to meet it (tall order indeed). The result of this effort was primarily to craft a mixed workload Reference Architecture design around Dell Compute/Networking, VMware Virtualization and SolidFire storage. You would be amazed how much effort goes into a Reference Architecture design, but as challenging as it was, I learned a lot about myself and abilities in during the process. 

A Promotion

US_Army_Enlisted_PromotionWith the Agile Infrastructure  solutions work taking a lesser priority within the organization and some of the personnel changes that altered the team’s structure, I found more time being focused on customer outreach and engagement to work on assisting the West team as needed in the role of the Principal Field Architect (yay a promotion). It was refreshing to get back into the field and in front of customers working on a daily basis to move deals across the finish line. Part of me missed the day to day trench warfare, but in this role there is a larger emphasis on being an overlay to a larger territory and team, as I’m fond of saying “being a Prime Mover”.

Enter Netapp

Now the time finds me on the cusp of a new change with the impending acquisition by Netapp. Obviously, for anyone who has listened to me on the In Tech We Trust Podcast, I’ve not been a major Trikot_NetApp_2011fan (that’s putting it lightly). My common thought has been that Netapp is the Blackberry of the storage world. Failing to keep abreast of changes in the space, rigid in its thinking, inflexible, full of hubris, all the things that leave an organization ripe to be surpassed and eclipsed by the very startup companies I’ve come to enjoy working for. I would forever hate myself if all of the sudden I put on the Homer Trousers and suddenly was pushing the OnTap message, in fact I’m half tempted to make a T-Shirt that says the only thing I serve OnTap is beer (as a certain CEO once told me “You are a walking HR Violation). Obviously, I probably won’t do that, and just in case Mr. Kurian reads this, I promise to only wear that shirt at home. But to a larger point, I feel its important to stick to ones principles and not fully sell out, and frankly in my opinion the reason Mr. Kurian took a strong interest in SolidFire was exactly because we were not OnTap and traditional Netapp in our way of thinking, design, implementation, marketing, sales, and corporate esprit de corps. In that respect, I do feel compelled to move forward if an offer is made to retain my services. There is something about being able to challenge the status quo from within the belly of the beast that has always appealed to me.

Big Names Open Big Doors

name-dropPrior to leaving Cisco, I managed to have a 30 minute 1X1 with Chuck Robbins. I got to sit in his office and chat about anything that came to mind. It was actually a great experience to sit down and trade stories of how we both entered the industry, and what drives us. Of the several things that stood out from that meeting, the one that stuck most was something Chuck said: ” In the last week I’ve met with both Hillary Clinton and Bill Clinton, the Prime Minister of South Korea, and several major business leaders, and the reason they meet with me isn’t because of who I am, it’s because of the logo on this card”. There is a lot of truth in that. When you are 55 people at a startup with a killer idea, amazing technology, and a product that solves many problems, opening the door to a major companies bathroom is tough, let alone getting a meeting with anyone who can actually make a decision. Having the heft of a major corporation behind you does indeed get you more at-bats (that challenge in and of itself is another thing I love about startup land), thus it may seem like the cards are always stacked against you, but they’re not, it just takes persistence. All this said, I see a very bright future for the SolidFire team within Netapp primarily because outside of my snarky viewpoint, the company has built an astonishing channel organization and customer base over the last few decades, and frankly deserve respect for that. It’s very easy to get caught up in the mortal combat of the us vs them world of technology sales, but remember, at any time you can end up working for one of your biggest competitors. Hubris goes both ways.

Successful Exits Are Tough

Not one to make major predictions with each passing year, I do believe that the infrastructure vendors imagesare in for some challenging times ahead, especially a number of the private storage players. Tegile, Tintri, Kaminario all face uphill struggles as that space collapses. The Dell/EMC situation confuses things and creates opportunities, but is there enough time and runway for those other players to garner enough sales to make successful exists themselves? Frankly I don’t see IPO as a route to exit for very many organizations.  The public players Nimble, Violin, and Pure all face challenges themselves and their reflective stock prices foretell a bleak future in many respects unless they adapt their product lines since single product platforms with limited true disruptive power are not long for this world, at least that’s how I see it. Adapt quickly to the new model which tends to be software oriented in nature (alas thats a subject for another blog post altogether) or starve. Not to say all software options are going to hit it big. There are large number of software storage plays out there today who have hitched themselves to current trends (aka hyper converged) but will not generate enough momentum to break out and will fail completely or get picked up for pennies on the dollar for their IP. The VC pools are tightening in light of recent events, even relatively powerful entrants like Nutanix face significant challenges as their burn rates, and sales expenditures outpace their ability to generate revenue. At some point you are not a viable concern, too expensive to acquire, too sales poor to IPO, that down round is the kiss of an impending death.

What The Future Holds

thefutureRamble much? Yeah, I guess I had a lot sitting in the noggin indeed. As for the future, at this moment, It’s hard to tell. There are many unanswered questions in front of me. For all intents and purposes, nothing has actually changed at all (not till the inks dry), so for me its business as usual. I’m still visiting customers, I’ve got travel booked for corporate events, I’ll be in Berlin for Cisco Live Europe. I have obligations that I feel I need to meet, and frankly, I think there are various upside options that I’ve not fully taken into consideration when it comes to a future with Netapp. I wouldn’t consider it fully prudent to simply move on without hearing them out, and there are some great people there I’d like to chat with about longer term strategic goals.

Still, if I’m 100% honest with myself there is something that really draws me to startup culture, especially the early days in that Pre-A round/A-Round time frame where the beta customers are being engaged, the story is being baked and formulated, the go to market message is being crafted, tested, rehearsed and finalized. Its that period where a handful of individuals can make an amazing impact on the future direction of a product and company. Not to say those things can’t be accomplished within a larger organization, its just the impact isn’t quite the same, and there is also a safety net that in my view may not properly motivate the individual. Still there are some major shifts afoot that I’m interested in being part of, so I’m open to discussion.

Posted in Cloud Storage, Sales Engineering, SolidFire, Startups | Leave a comment

Too Much Information Running Through My Brain

AKA: A long rambling post of disparate ideas that are loosely coupled together but really kind of maybe not so much.

The Police were one of the very first bands I fell in love with. If I go back to 3rd/4th grade, where I maxresdefaultstarted to get into music, I had 3 cassette tapes that factored heavily into my personal rotation: Blondie: Parallel Lines, The Police: Ghosts in the Machine, and The Cars self titled album. All 3 of those albums hold up pretty damn well in my opinion, but the Police have always been my first real musical crush, and Ghosts in the Machine is probably my favorite album still to this day. One track that always sticks out to me is Too Much Information

Over my dead body
Over me
Over you
Over everybody

Too much information running through my brain
Too much information driving me insane

toomuchThis is pretty much how I feel some days when I look at the current state of data center computing and the future of what we used to call “computing” is becoming. My day job brings me into contact with a fairly interesting customer space, and its well and beyond where I initially got my start in technology, ie the Windows 3.X era.

Today, what most of us consider the “Enterprise” is facing a weird form of technological mid-life crisis when it comes to the “How” of the data center, as well as the direction in which to take their development , delivery, and daily work flows.  The “Great Migration” off of ITIL to DevOps has begun, but as with all migrations, the pace is slow, and the mass extinction event has yet to happen. That event is coming, and I when I look at the legacy Enterprise focused vendors aka the “Dinosaurs”, I’m not sure if they have the ability to evolve fast enough to the evolutionary pace in which we are facing today. You get the feeling that many decision makers in the Enterprise space desire a move toward service based IT delivery, but they have had it fail to work because of a plethora of roadblocks they have faced. The technology wasn’t there, the team wasn’t capable of delivering, the organization as a whole couldn’t adjust to the rapidity of change. It could be all or none of those things. The one thing that does ring true though is that there is a need to move and do something, what that is, I think is still being realized.

Those in the traditional hardware space are going to be hit the hardest as these changes start to build ChildPleaseand move from the Web Giants, Service Providers, and Content Delivery companies down into the Global/Fortune 2000 Enterprise space, and eventually further. For the sake of argument as well, lets put Public Cloud out of the picture for this discussion,  that in and of itself could take up a few dozen pages of speculation and its not where I want to spend my time today.

There was a truly awesome article in The New Stack that was kind of the genesis of today’s ramblings:  How the Enterprise Adopts the New Stack, or “I said no dammit”  (stop now, and read the entire thing)  The timeline in the chart below is in my view fairly accurate for many Enterprise customers.

  1. Year 1: The way we do things is great; all that crap that startups are doing is basically just the same as what we do, but obviously we’re better.
  2. Year 2: That stuff that startups are doing works for them, but it wouldn’t work for us because we have different requirements.
  3. Year 3: If we were starting from scratch, we’d do it the way the startups do, but we aren’t, and we have different requirements.
  4. Year 4: Yeah, OK, we should probably do a pilot project to see if we can do that new thing that the startups are doing.
  5. Year 5: Ok, yeah, actually, it is pretty good. We’re going to do it everywhere and be awesome again. We are embarking on a two-year plan to apply that startup stuff everywhere. It will be expensive, but it’s the right thing, and then we’ll really be set.
  6. Year 8: OK, so it took us three and a half years instead of two, but we’re finally done!
  7. Go to step one.


I’m fairly certain that that there are a lot of people who see whats coming out of start-up land and the first reaction is “I Said No Dammit”, honestly I’ve been there so I understand where they are coming from and it takes a significant amount of exposure to the startup space to get into that new line of thinking. I visited an ex co-worker this week whose company is going through a massive consolidation effort. Roughly 12 formerly independently run organizations are having their IT departments collapsed into a single entity (something that should have happened a decade ago). Its an opportunity like that one that opens the door to do a lot of pretty significant adjustments and changes for the better, but after chatting with my friend, I got the feeling that based on a lot of the options that they have available today that would greatly benefit the organization as a whole will be seeing Ignore, Ignore, No, No and I said No Dammit, with that last part being elongated from a year to maybe three.

But why is this? Why is there such push back on the new things? I used to think it was simply risk aversion, and “we’ve always done it that way” thinking, and both of those hold true for many organizations that can seem to move at a glacial pace when it comes to innovation and adoption of new technologies, but I do think there is another factor, by damn if there is just too much shit out there to take in and absorb in a rational manner.

Lets just take one of todays hype cycle darlings, Containers and OpenStack. Now, I’ve probably seen two dozen articles in the last week that mention Docker, CoreOs, Kubernettes, and Mesos. The last 24 months have seen a massive push into the Container space, with barrels of ink spilled on how they are the death of VMware and will change how virtualization in the data center is approached etc. Then of course there is OpenStack and its adoption curve and the growth of the private cloud ecosystem. Follow this with the rapid assimilation of most of the managed OpenStack players by major companies like Cisco, HP, IBM. All of this activity points to a “sea change” in data center virtualization and workload delivery. The push towards the amazonification of the private cloud for the Enterprise customer. But how much of this is rooted in reality? How many Enterprise customers are actually leveraging Containers as the key foundation for their production environments, how many have their mission critical functions utilizing this technology? If I had to hazard a guess that number sits at less than 100 when we look at Global 2000. Of course, a lot of this brings to the forefront the death of Pets vs Cattle as a concept, but honestly, that time is a long ways away.

Two great data points to point too: BT complaining about the lack of maturity of OpenStack and its support for NFV (honestly a poor nitpick) couched against Bank of America and their challenges around having to craft proprietary systems to bring OpenStack to maturity for use in production in their environment. Both pieces have some very good points to make and bolster the case that OpenStack is still a maturing technology that requires heavy lifting to implement to its full potential. The same can be said for the promise of container technologies. Steep learning curves, significant complexity, and a lack of a strong talent pool are roadblocks to adoption in the Enterprise space. All of this said, the space is maturing and it will be interesting to watch it continue to do so.

lreqopgunucyyn7tljhqAs you can tell, there is simply too much going on in my brain and this was a very ppor attempt to dump some if out. Honestly, this is what happens when you keep waking up at 2:47 AM all week and are running on 3-5 hours a sleep a night. Fun facts, I’ll be at Dell World next week spittin hot solidfire knowledge. Following week finds me in the land of Robots, Tokyo Japan for OpenStack Summit. Impending American Godzilla photo album to be posted afterwards. If you are attending either of these events and feel froggy, jump over to see me.

Posted in Cloudy, DevOps, Enterprise Tech, OpenStack | Leave a comment

In Tech We Trust – Live from VMworld 2015

2015-09-17_7-02-28For those of you who missed it live (which is probably everyone) here is the live broadcast from VMworld 2015 with the wonderful panel I managed to pull together by dragging people out of the blogger lounge in the hang space. Some good banter and insights from the collective team.

Make sure to follow the panel on twitter: @VMcutlip @malhoit @vSential @timantz and me @Bacon_Is_King

Posted in Enterprise Tech, InTechWeTrust, Podcasts, Tech Marketing, VMWare, VMworld | Leave a comment

2005 Called, They Want Their Storage Issues Back


Bear with me folks, as this is going to be a two-parter, and yes I ramble when I write, which is also how I speak.

Like many people who work in the technology field, I’m a bit of a pack rat when it comes to old hardware and tech manuals. Rooting around the garage the other day, I came across a pile of Storage magazines from the mid to late 2000s.

In one of the lead stories, “How to provision the right way,” one thing stands out immediately: many of the discussion points and trends from a decade ago are still just as relevant today.

We still struggle to provision and allocate storage
We still employ tricks to address performance We still have yet to tame storage growth. When one looks at the numerous storage products that exist in the market today, some are affected with all of those challenges, some can help alleviate a few, and very few have been able to address all of them.

Let’s tackle these issues one by one.


Storage administrators have historically had a difficult decision tree when it comes to the provisioning and storage allocation process.

As frustrating as it may seem, there are still solutions today that require the administrator to determine a vnxspecific RAID level at the LUN level, or performing LUN masking, striping, and concatenation of RAID groups or disk pools. There can be manual path selection concerns for most dual controller storage solutions that don’t have a proprietary pathing software component. Adding additional complexity, some solutions still have disparate disks types deployed for which complex design scenarios are required for provisioning.

While becoming less prevalent, some solutions leverage LUN mirroring for data protection. This requires that the administrator allocate additional storage for data protection or purchase twice the storage capacity actually required (try explaining that one to your CFO). Then, of course, there are reserves and set-asides for replication events, snapshot reserves, and the like.

Given the strong move of many organizations today toward a more automated and simplified management scheme for all aspects of the data center, the above issues pose a barrier to rapid provisioning and allocation of storage for the next generation data center.

Storage Performance Shenanigans

Let’s face it, storage performance has always been a challenge, especially with primarily disk-based solutions. Vendors have done everything from short stroking hard drives, to loading in expensive cache memory/cache cards, and in some instances throwing a few solid-state drives into the mix to address the shortcomings of the underlying architecture.

giphyWhile most solutions today have moved away from leveraging those tricks, data tiering/disk tiering tends to still be utilized to address performance shortcomings.

On its face, a tiering solution seems smart. Let’s use HDDs for what they do best (capacity, sequential I/O), and let’s use faster disk, flash, or cache tiers for what they are best used for (high speed random I/O), and maybe even let’s throw in the “cloud” as a long-term archival solution, because it’s “cheap.”

But (and there’s always a but) the devil tends to be in the details with these types of solutions.


Most specifically, the ability to predict when data will be “hot” can be a challenge in and of itself, and the backend manageability of those “hot blocks” can result in resource contention in the classic robbing Peter to pay Paul sense. CPU cycles and overhead dedicated to the movement of granular data chunks (ranging in size from 32k to 1MB) can result in a reduction in performance, and in some instances, by the time the data has sufficiently been moved into the performance tier from the capacity tiers, the event that triggered the move may be over.
So now we get to start all over again moving data up and down the tiers, incurring wasted CPU cycles, impacting wear cycles on flash media, and impacting the longevity of spinning media. The hidden impact of data movement inside the array, and sometimes off of it, must be taken into account when looking at solutions that use on-array tiering and data movement.

Death, Taxes, and Growing Storage Demands


Indeed, as the old adage goes, there is nothing certain in life but death and taxes.

Let’s add storage growth to that as well. I think for most of us who started out as “storage admins,” the ability to predict storage growth within the organization has always been an exercise in futility. Sure, we poll the organization or business units that need storage solutions. We work with teams to “predict” some specific allocation needs for a project, which by and large always seem to actually be 3x what was asked for.

Bottom line, things change rapidly and that sweet box of storage we bought last year can be outgrown by a phone call from a business unit, a new customer being on boarded, or a merger/acquisition that was unforeseen. While some storage growth is indeed predictable in smaller environments, as the organization scales, its needs scale.

Many storage solutions today are perfectly capable of adding additional shelves of capacity, but it’s when that capacity outgrows the controllers behind it that we have a problem, and that’s when the dreaded “forklift upgrade” or expansion starts to rear its ugly head. Scaling of storage capacity in conjunction with the ability to scale the needs of driving that capacity (compute capability) tend to be elusive to many of the current crops of storage arrays on the market today due to their inability to scale out in a sufficient manner that addresses both capacity and compute capability in parallel.

The result tends to be organizations that end up with a more siloed storage approach as they outgrow the capacity and performance of the solutions that initially may have met their needs, but which they have outgrown.

What to do?

Sometimes an organization will face one of these challenges, or sometimes even all three. When looking to the future and attempting to address provisioning, performance, and capacity all at the same time, it’s important to take into consideration that no one size fits all and that there are indeed tradeoffs that can be made. The goal, of course, is to limit the impact of those trade-offs while minimizing risk and reducing costs.

I have a bit of a bias when it comes to how to address these issues, so in the next part of this post I’ll tackle each one head on. Stay tuned.

Posted in SolidFire, Storage, Storage & Virtualization, Tech Marketing | Leave a comment

The PRAP approach to the automated data center

newnormalBack during my time as Joe Virtualization and storage administrator, many of the daily tasks I performed were done by hand. Storage LUNs were created in an ad hoc fashion, virtual machines were built from scratch or deployed from simple base templates, the processes were tracked via paper forms, or email requests. The entire operation was inefficient, time consuming, and required far more complexity than it should have.

Furthermore, as my environment grew from a few host systems to dozens, and from a handful of virtual machines to hundreds, I quickly realized that doing things by hand was not going to cut it.

It has been several years since I had to deal with day-to-day IT operations, but I still speak to and visit numerous customers across many business spectrums who had or still have the same challenges I did. They are hampered by time consuming process that lends itself to human error, a lack of agility, requirements for custom ad hoc changes, and great difficulty in dealing with the sprawling nature of their environments.

All of this is one of the reasons I’ve been fairly fascinated with the rise of DevOps over the course of the last few years, as well as the strong push toward automation in nearly all aspects of the data center. As such, I’ve come up with an acronym that can help lay out some of the basic concepts I believe can help IT organizations of all size as they transition away from many of the challenges of the past.

I call it the PRAP approach for automated management.

PRAP stands for:

I use this to help outline the means of achieving greater efficiencies for IT operations. One of the benefits being that this approach can span the main pillars of IT systems from storage, to virtual machine management and creation, to network provisioning.

Let’s lay out the four concepts in a little more depth.

Programmatic: Today’s API ecosystem is rich and diverse. It requires the ability for IT operations to leverage multiple tools in order to achieve positive outcomes. It’s simply not enough to offer a CLI for a customer to leverage; there needs to be a concentrated effort on the part of the vendor to illustrate the benefit and value of code as a tool for everyday operations.

Going a step further, exposing APIs may not be enough for some organizations with the need to integrate into a bigger tool bag that can offer well documented SDKs, support for multiple language tools such as Python/Java, and task automation tools like PowerShell.

Repeatable: The ability to repeat a process or proof point within IT operations is paramount to moving forward with an automated management approach in the data center. While speed and agility are outcomes we wish to achieve, they require reliable and repeatable methods that validate that the job(s) are accomplished correctly. Without consistent and repeatable outcomes, we lose our ability to provide an auditable record of activity.

Automated: My IT organization would have benefited greatly from the move toward automation sooner rather than later, and yes, we did move toward automating of many of the pain points I outlined above. More than just a means to make things easier, automation frees up considerable time and removes many of the roadblocks to an automated management approach to IT operations.

An entire business ecosystem has appeared in the last few years that address automation: Chef, Puppet, Ansible, and Salt, just to name a few, are all part of a growing and diverse approach to automating as many processes and actions as possible for various IT teams.

Policy-driven: The final concept may seem difficult to fully implement, but is potentially the most rewarding. The ability to drive IT operations via a flexible policy-driven approach will allow for speed and agility to be fully realized. By allowing IT operations and administration personnel the ability to manage the full spectrum of their IT solutions via policies that govern behavior, we pull all the hard work we have done above into a cohesive and concise means of achieving positive outcomes that enable truly automated management in the data center.

Watch my recent whiteboard video on automated management and PRAP, or read more of our blog posts on the Next Generation Data Center.

Posted in Cloudy, DevOps, OpenStack, SolidFire | Leave a comment

Great Feats of Deployment: OpenStack in 90 Minutes

A few weeks back I had the pleasure to attend Cisco Live in San Diego, this came right on the heels of the OpenStack Summit in Vancouver.  Both events were great opportunities for the team at SolidFire to interact with customers and partners, many of whom are investigating solutions built around OpenStack. For me, the one thing that linked the two events was the release of the Agile Infrastructure (AI) solution based on Cisco UCS, RedHat Openstack, and SolidFire storage.

At its core, a SolidFire AI is a series of Reference Architecture documents that provide a blueprint for our customers and ecosystem partners to rapidly deploy scaleable infrastructure solutions. Their genesis AIRackcomes from the daily work of our Technical Solutions team, who spend the majority of their time designing for the various infrastructure and application challenges that our customers face on a daily basis. As was the the case for what we released at Cisco Live, we replicated a solution for a workload environment where several disparate technologies would need to leverage high performance, scaleable storage along with the ability to provision several distinct workloads and have them run concurrently without performance degradation. To make it even more fun, we gave ourselves a time limit of 90 minutes to deploy, provision, and spin up the entire environment. I know, sounds easy as pie. 🙂

In this instance we decided to implement the following solutions working in conjunction to simulate a business AIWorkloads2that had the need to utilize a high transactional web presence with read and write heavy MongoDB instances working in parallel. Second, dozens of 3-Tier LAMP stack distributed web application workloads were provisioned with a goal of doubling these instances quickly to rapidly scale to meet the demands of a highly transnational web based business. To inject even more disparity into the mix a series of MySQL instances were also created to stage a production database into a test/dev environment. The goal in having all 3 of these unique solutions running in concurrence was to bear out the primary benefit of the SolidFire All Flash Storage platform, Quality of Service (QoS). It’s through QoS that SolidFire storage is able to segment the performance of multiple workloads and ensure that storage performance requirements are met and that strict enforcement of storage based SLA’s are achieved.

At the Infrastructure level, RedHat OpenStack was chosen along with Cisco UCS for compute and NetwoCR1rking. Both solutions are leaders in their respective space and have strong, dedicated teams who are contributing heavily to the OpenStack foundation. Within SolidFire, we have spent significant time and effort to ensure that our Scale-out, All Flash storage platform is turn-key ready for customers looking to build OpenStack based clouds. Having been a major contributor to the Cinder project going back to the Folsom release, SolidFire has worked hard to position itself as the defacto standard for Flash based block storage in the OpenStack ecosystem. Working alongside our partners at RedHat and Cisco, we were able to craft this specific Agile Infrastructure solution based on the workloads detailed above and have the entire platform operational in 90 minutes. I know that may sound like pure marketecture, but at SolidFire we like to provide proof points for our claims.

While this post originally appeared on the SolidFire page to work in tandem with a public facing webinar that we did, you can see the output of this particular solution in this short video.


Posted in Agile Infrastructure, DevOps, OpenStack, SolidFire, Storage | Leave a comment

Storage industry: Stop that, start this – A history


Shameless Plug Disclaimer:  This is a cross-post from one I wrote for the Corporate blog at SolidFire, and is one in a series that will be written around the legacy storage concepts and how their application today may not be keeping up with your needs tomorrow. I’ve changed the title, but the content is the same.

Today is the Tomorrow you Worried about Yesterday

I have always been fascinated by strong historical characters, espRemember, today is the tomorrow you worried about yesterday. - Dale Carnegie ecially authors who spent the time and effort to craft a message and put pen to paper to expose it. For those not familiar with Dale Carnegie, I suggest a quick glance at his Wikipedia entry. Odds are you have been exposed to several of his writings in the course of your life and may not have known it. How to Stop Worrying and Start Living is one that has fascinated me, especially as it applies to the IT world.

As someone who spent 15 years on the end user side of IT, I spent a lot of time worrying about the various technologies I was enacting, how they would hold up to the challenges that seemed to pop up out of the blue. With this said, we’re starting a new series here on the blog, the goal of which is to expand upon some storage concepts that can allow you, the customer, to worry less and focus more on the future without having to fret about the past.

Throughout the series, we’ll cover things you should stop doing in storage. I’ll discuss a few of them broadly in this, Part I.

Long, long ago, in 1987 …

In 1987, researchers at Berkeley California (Patterson, Gibson, and Katz) released a paper titled A Case for Redundant Arrays of Inexpensive Disks (RAID), collectively known within the storage industry as “the Berkeley RAID paper.” Contained within, the researchers noted that a redundant array of inexpensive disks were preferable to a single large expensive array not only in terms of cost, but as well as providing superior data protection and performance. Taking this theory and putting it into practice, the modern storage industry was born and has relied upon RAID ever since.

In 1987, researchers at Berkeley California (Patterson, Gibson, and Katz) released a paper titled A Case for Redundant Arrays of Inexpensive Disks (RAID), collectively known within the storage industry as "the Berkeley RAID paper."

RAID’s wide-scale adoption can be said to be responsible for most of the storage array platforms that exist today. And while you probably are not reading this blog post to get a history lesson on the fundamental concepts that birthed an industry, there is one item from the paper I’d like to dig deeper on:

Increasing performance of CPUs and memories will be squandered if not matched by a similar performance increase in I/O.

That’s the first line of the abstract from the Berkeley RAID paper, and in my view, this holds just as true today as it did back then. The ever-increasing performance gains for which Moore’s Law provides will continue to outpace the ability of storage platforms to service the I/O requirements they can sustain.

Out of the three pillars of the data center (compute, network, and storage), the storage side of things has always seemed to lag in terms of performance. As such, it becomes a limiting factor in many data centers. At SolidFire we have worked from the beginning phases of our design process to address this mismatch of resource allocation, or to at least bring it closer together and meet the challenges laid out by our storage predecessors.


Yep, that’s your father’s Oldsmobile

This IS your father's Oldsmobile

When we look at the storage industry in its current state, we see a large number of designs that continue to leverage concepts created decades ago to address the storage challenges of those times. Don’t get me wrong; that these designs are still being utilized for newly created storage platforms are a testament to their validity. That said, those designs will not hold up next to the solutions crafted from day one to tackle the mismatch in resource utilization and the design flexibility the modern data center requires.

Outside of simply faster and larger disks, array design has leveraged a “scale up” approach that has required storage administrators and organizations to plan in terms of capacity and performance for what was available from the component level during the period the storage platform was designed and delivered. Those systems will always be behind the market when it comes to having the most recent compute and memory resources at their disposal.

Commonly, these systems use a dual controller configured in various ways as active/passive or active/active in order to reduce a single point of failure for the array itself. The challenge here tends to be that storage administrators have to plan their environments and connectivity around these limits. Upgrades are complex and often require a “forklift” approach, and in some instances swing gear (a loaner unit) is brought in to serve as the middleman for temporary use while an upgrade is performed.

As design in the data center itself moves to a distributed model, the ability to pair appropriate resources for all three pillars needs to be taken into account. Scaling compute, network, and storage resources in tandem, or as needed without impacting existing workloads, should be a mandatory design consideration.

To illustrate the point further, “scale up” design (shown compared to “scale out”) is where a head unit (controller) sits as the gatekeeper for storage resources:

Scale-out vs. scale-up storage infrastructures

Storage administrators can only scale capacity in this design. The downside here is that it becomes more likely that the existing processing and network connectivity of the controller will be overwhelmed as the array is drawn upon to serve more and more resources to more and more end points.

In order to address increasing performance concerns, controller-based designs tend to use various workarounds: Cache (memory) has been added to accelerate the rate in which data is fetched and provided to an external workload. Many vendors leverage tiers of disk (either in faster spinning media, or solid state drives) to serve as staging areas for hot data to reside.

Others will attempt to guess what data is going to be hot, and will pin it into these cache/higher speed disk areas to meet storage demands and attempt to defeat the inability of the limited resources afforded in the controller unit to move the needed data at the needed rate.

Scale-out storage architecture

These additional tiers of storage can address some performance requirements, but often end up not being able to keep up with the dynamic demands that disparate workloads place upon the storage system. At some point cache is overrun and defeated, the hot tier cannot predict data movement fast enough, or simply the resources that are finite in the common dual controller design cannot keep up with the performance demands of today’s workloads.

To further complicate matters, storage administrators have to spend a significant amount of time and energy fine-tuning the arrays themselves and micro-managing RAID groups, lun placement, and path policies.

There has to be a better way.

Scale-out storage benefits

In a scale-out environment, capacity, compute, and network connectivity scale equally, so performance will remain linear as more units are added. Unlike the scale-up model, the ability to fine-tune and utilize resources is not impeded by the limitations of the controllers that were purchased with the storage system.

Of course, not all scale-out solutions are built the same. In the case of the SolidFire platform, the ability to mix and match different system models (mixed node clusters) is present, offering a far greater level of flexibility and agility. Downtime or disruptive data migration events are eradicated since upgrades to compute, memory, and connectivity are simply absorbed into the original system and become part of the greater pool of resources available.

To put it into simple list form, at SolidFire we have looked to design a storage platform that reduces the complexities of the past, and focuses on the workloads of the future through the following concepts:

  • Simplify capacity planning with a building-block approach
  • Eliminate forklift upgrades and controller limitations
  • Defer capital expenditures with incremental expansion
  • Eradicate the need for point solutions
  • Mitigate against painful migration events

Mixed-node clusters in storage infrastructure

Back to the thrust of this discussion: storage capacity and planning tends to be one of the more difficult challenges IT faces, primarily because of its unpredictable nature. A scale-out approach can help alleviate many of the challenges that other storage platforms are incapable of addressing without significant complexity. Storage should be able to keep up with the gains of the compute and network pillars in the data center.

I hope the above content is helpful. As always, the goal in writing these posts is to provide my take on a topic. If you have any comments or questions, feel free to hit me up online: @Bacon_Is_King.

Posted in Enterprise Tech, SolidFire, Storage | Leave a comment

Cisco To Buy Nutanix?

This is about as likely to happen as me becoming a vegetarian.

nobody-likes-vegetarians11Which is not to say that it’s not an outright impossibility, but the probability is very very low. Like many people, I’ve heard the rumors of Cisco looking to buy their way into the Hyper Converged Infrastructure marketplace. It certainly makes sense for Cisco to make a play in this space as today they have no real competitive product of their own. Yes they certainly have a large number of product offerings with partners that would allow them to stay in the discussion, (VSAN Ready, Maxta, SimpliVity are all partnerships) but nothing that lets them capture the entire revenue stream (SW and HW)

Financially It Makes Sense

I can see why the financial analysts would say that a Cisco/Nutanix pairing would be smart. Personally I think it nutanixnodewould be smart. It would give Cisco a dominate position in the HCI space, allow them to expand their reach into the SMB/SME space where they struggle at times when it comes to compute offerings. It would put them in a place of market leadership as well, and when viewed through the singular prism of a financial viewpoint its easy to see why the bean counter analysts would see this as a great pairing. But, and there’s always a but, the technology doesn’t fit.

A move to Cisco would require a ground up design effort

Nutanix delivery vehicle is a standard 2U 4 Node solution, in my view this makes up the bulk of their UCS-Scalablesales. Yes they have other offerings that are 2Node and Single Node based, but the vast majority of their sales come from the basic Nutanix block. Their partnership with Dell (which I’ve heard is working well) was a validation effort, not necessarily a pure engineering one. Dell had a delivery vehicle that fit the Nutanix standard, and at that point it’s a qualification effort around drivers, firmware, etc.

Today, Cisco does not have a 2U 4Node solution, at least not one that I have ever seen in the flesh. I’ve not even heard of a “rumor” of a solution like this. Today the primary Cisco compute deliver vehicles are Rack and Blade systems. Alternately, the M-Series modular solutions are seeing traction in the Service Provider, Web Host customer base, but that solution would require some significant engineering on the part of Nutanix engineering to fit into that deconstructed server model.

Cisco would need to design and build a 2U 4Node solution from the ground up, which is no small task, and more than likely at a minimum a 1 year effort if not 2. On top of that, there are all the integration points with the current Cisco model of management with UCS Manager and UCS Director. Director is not as heavy a lift as UCS Manager. The Nutanix method of management from their Prism portal would need to be integrated into UCSM/UCSD at some point. It doesn’t have to happen on day one, but in my view that would be the direction that Cisco would want to take it.

What about Stateless Computing?

That is the message that Cisco has presented with their UCS platform, and it’s why Hyper Converged has been a difficult sell for the rank and file Cisco sales teams and Cisco partners. The move has always been to remove the intelligence, and storage from the compute solutions and move it into the Fabric Interconnects, this poses a problem for the go to market model that Hyper Converged presents which brings everything back into the host node. It will be interesting to see how any HCI solution gets integrated into the Cisco compute mantra. It also presents another problem for Nutanix (or Maxta, SimpliVity) who would want to be part of the Cisco UCS story.

From a networking side of things, VIC integration would be a bit of a challenge as well. Support for Single/Dual wire management to the FI’s is not a trivial matter. I believe the initial SimpliVity/Cisco based solution was 2Wire to start and moved to 1Wire over time. It’s simply another item to take a look at in terms of integration headaches.

Stealth Edit: OMG $$$$$

One item that in my rush to publish I forgot to mention is buying Nutanix is expensive. We are not talking a quick purchase here, we are talking 3B+ in order for this to work. Obviously, with 50+Billion sitting over-seas Cisco could easily pull the trigger on a purchase of this magnitude, but the more likely situation exists where a debt offering is made to cover the cost. Repatriating 3B in cash at 35% US tax rate is far more expensive than a debt issuance at 3%.Other potential fits will come in as expensive (some more than others) but not Nutanix-Expensive. There has to be a return on investment, and at current state, the HCI market is still not quite a 1B annual run rate business (not to say that can’t change, but that’s a different blog post all together)

There are better fits out there

SimpliVity_Cisco_square_webpageToday Cisco has a rather convoluted approach to the HCI space. They have loose partnerships with a number of 3rd party vendors and look to leverage those as needed based on the use case. Gridstore, StorMagic, SimpliVity, Maxta, VSAN Ready, and others all fall into the bucket of HCI/SDS offerings that Cisco can go to market with. None of those solutions allow Cisco to capture the full revenue stream of a HCI offering though, and at that, they simply allow them to be part of the conversation with customers, but frankly, doesn’t get them many wins.

It would be far smarter for Cisco to purchase one of the existing HCI partnership solutions that are already qualified on their UCS platform. SimpliVity and Maxta would make the most sense, with SimpliVity being the more mature of the solutions available. Either of those would allow Cisco to go to market on day one of acquisition without an significant engineering effort. The ramp would be for the sales/marketing teams. There would be no messy technology port (which is what they would have to do with Nutanix). And both of those solutions appear in my view to be viable enough for Cisco to be highly relevant in the HCI customer discussion and capture a large portion of HCI business.


The tech industry is full of rumors, we hear them all the time in discussion with customers, partners, and each other. At the end of the day most of them are unfounded, and tech journalists do the industry a dis-service by publishing rumor and speculation as fact/near-fact. I myself have no specific knowledge of any impending purchase, and like others I can speculate and offer my opinions based on what I think would be a good fit vs not-good. My past experience with both Cisco and SimpliVity affords me a bit more tribal knowledge, and I’m not approaching this from a pure financial point of view, but more from a technical one.

That said, I have no inside information, or knowledge about any impending purchases. My personal opinion is that Cisco will act at some point in the near future to make an acquisition either in the Storage or Hyper Converged space, and with Cisco Live just around the corner would be a good time to make an announcement.

Posted in Cisco, HyperConvergence, Nutanix, SimpliVity, Tech Marketing | 9 Comments