For 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
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 
specific 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.
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.
While 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.
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.
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.
Back 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:
Programmatic
Repeatable
Automated
Policy-driven
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.
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 
comes 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 
that 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 Netwo
rking. 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.
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.
I have always been fascinated by strong historical characters, esp
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.
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.
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:
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.
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:
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.
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.
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:
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.
Which 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)
I can see why the financial analysts would say that a Cisco/Nutanix pairing would be smart. Personally I think it 
would 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.
Nutanix delivery vehicle is a standard 2U 4 Node solution, in my view this makes up the bulk of their 
sales. 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.
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.
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)
Today 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.
T
hings are heating up something fierce in the Container space as of late. This edition will focus a bit around the big announcements of the last week. Microsoft and VMware both are starting to invest heavily in container and microservices offerings that will lure the cloud savvy customer base into their folds. VMware has pulled out all the stops when it comes to their full fledged entry into the Container world with the launch of Open Source projects or “Cloud Native Apps”: Photon, Lattice, and Lightwave. Make sure to read the Platform article as its probably the best at laying out what VMware is looking to do. Look for the throngs of VMware fanboys to push heavily into what should be a fairly new space for many of them.
I for one will be very curious to read into the positioning of these technologies, and the benefit afforded by leveraging a hypervisor in a world where bare metal is the dominate delivery vehicle (at least based on the customers I’ve been working with). More thoughts to follow.
This weeks Ed
ition brings tries to grab a swath of “Vote for Me” links into one area. It’s amazing how many sessions are being submitted by the various vendors, and I think it lends credence to their push to engage at a full partnership level with the OpenStack community. It also means that with so many vendors pushing for sessions, that the voices of the common man may be diluted. At this stage, OSS is starting to take on the feel of earlier VMworld conferences, say circa 2009/2010. And with that comes the maturation into a vendor driven conference, that is still very much driven by the developer community at large. This is bound to happen as the platform matures, and as businesses start to adopt it whole sale. As I wrote the other day, the Developers have won, and as such their voices will carry more weight, and the growth of OSS is one more inflection point that backs this.
Because I have nothing better to do on a Saturday night I thought I’d jot down a few random thoughts that have been floating around in my head. So this post may be a bit disjointed or rambling in nature, forgive me. If you would have told me 5 years ago that the Developer team within the company I worked for would be driving the technological direction of IT within the organization, I would have laughed at you. Harken back to 2009, and what you would have seen in many organizations was a centrally planned IT, lead primarily from the infrastructure, administration, and operations teams. Developers, well they were not calling the shots, they were in many instances beholden to a rigid ideology that came from those central planners.
Today, the developers have won control, and I don’t see that changing anytime soon. Furthermore the approaches to infrastructure are becoming more developer focused. The programability around all things “software defined” is dominating the focus of IT needs, and in turn we have entered the age of app-centric infrastructure. Todays new application approach is a scalable, agile, self healing, resilient, automated, distributed system, focused on programability (buzzword overload). The apps are driving the business, and defining the infrastructure. The apps are created by the developer teams, and the operational efficiencies being achieved with this new focus are allowing businesses to achieve unheard of agility and ability to respond to the economic realities that a globally connected society demands.The goal is real time decision making, and the means to get to that point requires an infrastructure and development platform that can respond in real time as well.
If we look at the rapid rise of OpenStack, Chef/Puppet, the hyper-growth of Docker and containerization, as well as the far too many to name startups that are focused on the concepts around DevOps space, we see that there is a fundamental shift in how applications are being created, managed, and deployed. The “Cloud” was the enabler for this new normal mindset, and now there is a shift to bring the elastic nature that cloud presents inside the business and gain full control. These systems are taking greater advantage of the 
advancements made in the infrastructure space. The “new normal” is to craft apps that understand these changes and can adapt as quickly as the changes take place. In this landscape commodity hardware will dominate, and custom built hardware based solutions will be shunned. At true Web Scale, platforms like what is being done with the Open Compute project will be the infrastructure of choice, where down the food chain, Rack Scale, and Hyper Convergence will provide the basic building blocks for IT.
To close out, it’s a great time to be working in this space. Nearly every customer I speak with today is working to implement this new operational model, and it’s great to see all of the new companies that are popping up to meet the new challenges that this space presents. The biggest challenge I see right now, is keeping up with it all.
Mark Twain’s “The Adventures of Tom Sawer” was a book I read when I was in Elementary School and tells the story about Tom Sawyer, and Huckleberry Finn growing up along the Mississippi river and some of the adventures the two boys get into. One of the classic passages in the book is how as punishment for getting his clothes dirty, Tom is made to Whitewash his Aunts fence, a chore that would take considerable time, and effort yet yield him no personal reward. Utilizing his clever wit, and intellectual prowess, Tom convinces the boys of the neighborhood to trade him their small personal treasures for the “privilege” of doing the work for him. By the end of the day, there are 3 coats of whitewash on the fence, and Tom has a horde of treasures from the towns boys. Tom muses that “all it takes to make someone want something is to make that thing hard to get.”
If we look at 
the EVO:Rail platform, at its core, its a simple hardware effort that any OEM/ODM could create and deliver to their customers, yet on its own, without the VMware Software integration it has almost zero value. Up until the Hype Converged market was created, there is very little demand for a 2U 4Node server with internal storage in the general IT world, at least there wasn’t until Nutanix came to market with their initial design. And while that platform today takes several different shapes and sizes, the base unit that is sold is the 2U 4Node configuration.
So today what do we have, HP, Dell, Super Micro, Hitachi, EMC, and a host of other box pushers rushing out the door with their own Hyper Converged EVO:Rail systems, none of them so far setting the world on fire, none of them so far, actually providing any value above and beyond the base template that EVO:Rail provides. Yet only one of those players is adopting the Tom Sawyer strategy, and that would be EMC.
In concept, EMC isn’t actually building their VSPEX:Blue system in the same manner as they would a VNX, it’s a template/reference architecture for Hyper Converged and as such they actually don’t craft and ship you a box themselves. The systems are actually sold and driven through their large partner organization, who places the order and then receives the units from manufacturing (Foxconn/Intel). This is different than their bread and butter storage business.
In this respect, EMC doesn’t have to carry the inventory, the insurance of goods, the risk associated with building too many or too few units, the shipping or crafting of the final product, etc. The turn around time on these systems is short enough that they may not even have to pre-seed a warehouse with first sale units if they don’t have to. Yet in turn, they capture a huge margin on the sale of each unit by selling the software package that goes along with each one, as well as follow on business if customers decide to expand the licensing that comes with each system (15 units of recover point is just a taste).
VMware gets their cut for the base EVO:Rail licensing, and EMC gets their cut for the value add portion that is afforded with each unit. In that respect, much like Tom Sawyer convinced the boys in the neighborhood to white wash the fence in exchange for their personal treasures, EMC is convincing their partner ecosystem to do go forth and sell their Hyper Converged system while reaping the lions share of the treasure, and VMware is doing the same when it comes to EVO:Rail because in reality the platform is a simple vehicle to sell advanced VMware licenses. This strategy removes much of the risk in taking on a new market space, yet provides the lions share of the reward by packaging and selling existing software products as part of the solution.
All this plays out in opposition to the other Hyper Converged vendors who still have to carry the bulk of the risk laid out above, as well as pay a sales force to push it, In turn, the Tom Sawyer approach will yield much higher returns on investment and allows EMC to focus nearly 100% on the much higher margin Rack Scale converged offerings that VCE is providing. Bottom line, they can tackle the Hyper Converged market without doing much work, and still make higher profit margins doing so compared to their competitors.
Fun Fact: the impetus for this post came from a dream I had that woke me up at 4:30AM today where Joe Tucci came to a house party. I don’t know why that triggered the above thoughts, or why I’m dreaming about Joe Tucci, but hey it prompted a flood of thought that I had to push out of my brain. So if you find yourself waking up from strange dreams and compelled to write about them, go for it.
And now for your listening pleasure:
