Looking forward to 2018Part 2: Hint, its not about infrastructure.

If you’re just catching up, this is a part of a multi-blog post epic saga (ha!) with some things that are on my mind as I reflect towards 2018.

I’d encourage you to read the first part here, which discussed the way I see the HCI market choosing between “build” and “buy” choices, and reflected on how this isn’t a new thing – it’s a debate that occurs at every part of the stack.

PART 2: Hint, it’s not about infrastructure.

Just like I’ve always believed that no human ever woke up and said “I need a storage array” or “I need a server”, or “I need vSphere”.   Likewise, no human ever woke up and said “I need CI/HCI”.

What do I mean?

There are people that THINK they need server/network/storage/virtualization/HCI – but they are delusional, or put more nicely, they lack the macro right perspective.   All infrastructure exists solely to support use cases, workloads, and ultimately applications and business processes.

Infrastructure is purely a means to an end, not an end to itself.

Yes, the infrastructure matters, most of all in it’s availability, but also its performance, it’s economic envelope (which is measured in bunch of different ways)

image

What’s actually underneath the black drop cloth is not the important thing.  The outcome is the important thing.

This is a point that I think often IT practitioners need to keep very “front and center” in their minds.    The tendency to focus on components rather than systems is the essence of the “build” to “buy” continuum I discussed in part 1 of this blog post series.

So then… What are the outcomes our customers are seeking?

The most requested on-premises workloads are NOT a specific workload per se – but a generalized platform.     This is a switch from years past, when we would spend oodles of time testing, validating, documenting and building lab queens for singular workloads.

The demand has shifted to generalized workload platforms – specifically Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Desktop-as-a-Service (DaaS) and now Container-as-a-Service (CaaS) platforms.

I’m going to be pretty binary in the next statement – the infrastructure underpinnings – the “what’s under the black drop-cloth” under these *aaS platforms are HCI – period.

If the x86 server + virtualized compute/SDS/SDN have become the “bricks”, HCI has become the “foundation”, and these IaaS/PaaS/DaaS/CaaS generalized platforms are the “house”.  Why?

  • You cannot build simplicity on top of complexity.   HCI and software defined approaches are simpler.   *aaS models demand simplicity – and have their own stacks with their own moving parts.  
  • You cannot automate on top of rigidity.   HCI and software defined approaches are more programmable and API driven – they expect more frequent updates and change.   Trust me, as the person where the “buck stops” for thousands of the largest CI stacks, I know what goes into a life-cycle update.   We do it better than anyone else with VxBlock, and it involves engineering and services perfection, careful planning and maintenance windows.   Conversely, we do remote lifecycle updates of VxRail all day long during business hours.  You simply cannot lifecycle a *aaS on an infrastructure stack that itself is hard to lifecycle.
  • You cannot make really good utility economic models on top of things that have massive “step functions” in their base cost of goods.   HCI and software-defined appraoches scale in a fundamentally different way – were “pay as you use” models have a strong benefit, as the infrastructure is supporting a platform where consumption is more difficult to predict.

It’s for those 3 reasons that when you are looking for an *aaS platform – odds are very, very good that the answer to “what is under the black drop cloth” is HCI.

SIDEBAR: Now, so people don’t get binary, let’s talk about where I see the answer under the black drop-cloth being CI, and not HCI.  

  • Most SAP HANA and SAP projects are a better fit on things like CI.
  • Most EPIC projects are a better fit on things like CI.
  • Most Oracle ERP projects are a better fit on things like CI.

These examples that tend to “CI” (and others like them) are due to several factors:

  1. Legacy data service requirements (some of these have very specific legacy remote replication behaviors)
  2. Long cycle time for application stack validation.   In several of the cases above – the validation process is very geared towards “legacy” stack design, and they are tried and true.
  3. Risk aversion (even if it’s not for real technical reasons).   In the list above – the infrastructure is a tiny, tiny fraction of the overall cost, and I find that customers (and the systems integrators/business consultants that invariably are attached to those projects) tend to “stick with what they know”.
  4. Unusual CPU/Memory vs. Persistence ratios.   While the old canard that “HCI doesn’t scale CPU/Memory independently” is no longer explicitly true (many HCI platforms have many node types, can add memory/storage to nodes independently, can mix clusters of different node types) – it’s still true that if you need a LOT of CPU/Memory and a LITTLE storage (or vice versa), the economics of traditional CI models win over HCI (even factoring in operational benefits). 
  5. Very “bound” multi-year scaling models.  In the examples above, in general there is an understanding of the economic model over a multi-year consumption basis – and in fact a large capital economic step-function is a benefit, not a negative.

Each of these factors have two important qualifiers: “most” and “for now”.   “Most” = there are some projects where either legacy data services are relaxed, or parts of the stack are validated (parts of EPIC are supported on HCI for example), the customers is less risk adverse etc.

But – for the world of IaaS, PaaS, CaaS, DaaS – those platforms are the “raison d’etre” of HCI.  

This is the basis of the “Hint: it’s not about infrastructure”.   The growth in HCI is a head-fake.   The real battleground is “can we make private, enterprise cloud work?”

In Q4 2017, we came to an observation that we HAVE to make our Hybrid Cloud offers that focus on outcomes versus foundational elements simpler, easier, and more aligned.

Going into 2018:

  • IaaS = I’m laser-focused on making our VMware Hybrid Cloud on VxRack SDDC simple to acquire, consume, lifecycle – a VMware Ready System, and our Dell Technologies aligned IaaS answer.   We will of course continue to support “build it yourself” IaaS stacks in a wide variety of choices (VxBlock, VxRack FLEX, VxRail – heck, piece parts), with services to put it together.   BUT - if you want “esay button IaaS” – this, along with it’s off-premises instantiation (VMware on AWS) is my focus – period.  
  • PaaS/CaaS = I’m laser-focused on making PCF 2.0 (including Pivotal Container Services) on VxRail simple to acquire, consume, lifecycle – a Pivotal Ready System, and our Dell Technologies aligned PaaS/CaaS answer.   We will of course continue to support “build it yourself” PaaS/CaaS stacks in a wide variety of choices (VxBlock, VxRack FLEX), with services to put it together.   BUT - if you want “esay button PaaS/CaaS” – this, along with it’s off-premises instantiation (PCF on AWS/Azure/GCP) is my focus – period.  

Sidebar: Attentive readers may wonder why we use VxRack SDDC for IaaS, but VxRail for PaaS/CaaS.   This is very intentional.   PaaS/CaaS use cases are linked to specific HA design at the PCF layer, as well as correlate nearly 100% with SDN network segmentation – in our case NSX-T.    Whereas IaaS use cases are well covered in VCF 2.3/VxRack today – the VCF/VxRack SDDC roadmap through 2018 will broaden to bring in the PaaS/CaaS use cases.   VxRail can cover these use cases today.    It also means that we MUST integrate VxRail and VxRack SDDC such that customers can start with VxRail and move non-disruptively to VxRack SDDC.  On it.

… This is interesting, because it’s a reflection of two things:

  • HCI isn’t about HCI.  HCI is about making private enterprise clouds really possible with sufficient simplicity to scale.   This is not new (we’ve been at this for years), but the learning has culminated in a realization of the need for maniacal focus.
  • It is a segue into tomorrow’s topic…

Next up tomorrow, a longer term (and perhaps the most controversial) post: Vertical “Stack Wars” are upon us.

Powered by WPeMatico


Christmas Directories - Enterprise Security Weekly #73

This week, Paul and John talk about Active Directory insecurity, how to solve problems with endpoint detection and response, and how to fix authentication issues! In the news, we have updates from Flexera, Amazon, ExtraHop, and more on this episode of Enterprise Security Weekly!

 

Full Show Notes: https://wiki.securityweekly.com/ES_Episode73

 

Visit https://www.securityweekly.com/esw for all the latest episodes!

Powered by WPeMatico


Looking forward to 2018Part 1: Buy to Buy and HCI (and more)

The ongoing evolution of HCI – 2017, 2018 and beyond – in three parts.

In 2016, EMC (and then Dell EMC) and VMware started with several goals – one of which was to become #1 in the HCI market by the end of 2017. That mission was accomplished mid-year 2017, so check.

That said, as the calendar comes to a close, and I reflect a bit on the HCI market – I know we’re just getting started.

I also know that people will try to make this black and white. I’ve noticed that if I write a post on a topic, people sometimes assume it’s the only side of the story, or an official position.   It’s a weird accidental byproduct of Virtual Geek being a personal blog (off domain, I pay for it myself, and I compose during strange hours). Virtual Geek, remains my own labor of love - but naturally biased by what I do at work.

I’ve also found people want to be binary, to polarize every topic. People will read into this post series that it’s about CI **OR** HCI. Hint: it’s not – the Converged Infrastructure market will be the same size as the HCI market through 2020. Others will read into part 3 of the post that I’m saying that the “vertical stack wars” era means that there isn’t a need in the market for horizontal, open ecosystem CI/HCI stacks. Nope. Those are both are going a step too far in my humble opinion.

IT Industry transitions simultaneously are fast (grow rates shift seismically, and new ideas take hold quickly) but also take a long time (big long tails and complex systems with material and real inertia).

Back to the “where do I see HCI going next?”

There are two distinct HCI mega-trends that we are simultaneously leading (the largest player in the HCI ecosystem and are part of (in the broader ecosystem).

Here’s I’m not talking about the shift TO HCI from traditional 3-tier IT stacks of server/network/storage. That is a transition is in flight (again, CI will be as big as HCI until a crossover I believe will be in 2020).

The drivers for HCI are basic, simple and clear:

  • A fundamental IT need for simplification/automation through software (much lower costs to operate, and much better ratios of people/time : value)
  • The ongoing shift of value to software + industry standard hardware (faster tech adoption curve + scaling model)
  • The increasing recognition that infrastructure is something to be consumed, not constructed – and that shift keeps moving “northward” in stack (never ending commoditization at the bottom layers, and shift up the value stack).

What AM I talking about?

There are 3 essential strategic observations about the market from where I sit – and I’m reflecting on as we enter 2018:

  1. There are two HCI “ways forward” that are emerging. These two that fall into the natural “build” to “buy” continuum.  Here, it’s about two ways that customers consume HCI: Software led + open ecosystem hardware (“Build”) and Integrated Systems (“Buy”).
  2. It’s NOT about HCI – it’s about cloud.   The HCI value proposition is evolving northwards into turnkey cloud stacks (IaaS, PaaS, CaaS, DaaS), and increasingly I’m finding (and everyone is finding!) that you need the simplification of HCI as the “base strata” of a sustainable cloud stack.
  3. That we are in the first pitches of the first inning of an era of “vertical stack wars”.   This isn’t just about us – there are many examples across the industry.

I think that these will be “challenging ideas” as they butt heads with things people have been doing for eons. I think that it means we’re also entering an era where ecosystems that have been around for decades will be challenged.

Personally, I’m determined to tackle these with the same ferocity and willingness to self-disrupt that has been necessary in tackling the first chapters of the HCI industry transition.

I’m convinced that these 3 simple observations will be taking a lot of my own cycles, and I suspect the cycles for many as we all participate in the next orbit around the earth, and I’m noodling furiously on it.

Read on for more!

PART 1: Two ways the market is choosing to move forward with HCI…

One of my favorite people to follow in the twittersphere is @kelseyhightower.  Kelsey is a Staff Developer Advocate at Google, and one of the people in the Kubernetes community with a “large impact radius”.   Check out his github repo here: https://github.com/kelseyhightower

Where am I going with this?  Consider these three posts:

image

imageimage

These three tweets are fascinating for me – because they make it clear: the “‘build’ to ‘buy’ continuum” is a generalizable idea, perhaps a reflection of human nature and personal perspectives.  None of these tweets are about the infrastructure domain, but the layers above – and the sentiment/learning is completely applicable there, but also above, and below.   These tweets represents the “buy” and “build” choice.

  • The first is a link to a github repo to help people learn Kubernetes from the ground up – no scripts.  For someone who wants to learn, and to have ultimate flexibility and control, a great way to start.   This is was a super-popular tweet, and a great resource.   To me – this highlights the great burning desire for people to learn, to play.  “Builders” are everywhere (I’m one myself).
  • The second started a huge dialog/flamewar – read the tweet stream.   This is fascinating because I think Kelsey is reflecting something I see.   The reaction highlights that often people underestimate the power of the platform layer “above” them.   You can imagine that people who LOVE playing at the container orchestration layer found this tweet to be “blasphemous”.  It’s also interesting because it highlights that when you challenge the value or even point out the trade-offs of building to a “builder”, the arguments about lock-in, closedness come fast, and they come furiously.
  • The third is particularly fascinating to me, and not only because Kelsey said it so succinctly, and so much better than I do :-)   He so accurately captures the trade-off.   He captures that often people have to have the experience of building (to learn, including learning how hard it really is to maintain and sustain).

With a year under our belt, I can say with confidence that this choice is playing out clearly in the HCI market via the two ways people like their HCI:

  1. Software-led + open hardware ecosystem (“build”)
  2. Integrated Systems (“buy”)

Its funny to see this not just through the lens of “gut” or “opinion” – but black and white data.  

I see all the data on the breakdown of customers that take vSphere + vSAN and pick the open ecosystem of servers that are part of the vSAN ReadyNodes HCL program. Ditto with VMware Cloud Foundation on same said open ecosystem of vSAN ReadyNodes.

Whether they are doing it consciously or not – these customers are examples of the Software-led “build” approach to HCI stacks.

Conversely, I see the data representing the customers that pick integrated systems – the corresponding stacks to the above manifesting as VxRail and VxRack SDDC.

Integrated systems are not simply bundling or factory load of the software-led + open hardware ecosystem – it’s a whole set of IP (intellectual property), software tools, engineering and support mechanics that mean that there is not a “software/hardware” distinction.   

It’s critical to grasp that core distinction: “build” choices represent improvements over what you do today – and you retain the responsibility of how it works; “buy” choices represent a transfer of that responsibility to someone else.

What does the data show?

The data shows that the “build” marketplace relative to the “buy marketplace” is somewhere between 50% of the revenue total and 60% of the revenue total. This has held up to be remarkably consistent all year long.  

Between the consistency (and here we’re talking about many, many thousands of customers) over time – and the fact that it’s not just us, this suggests this is something fundamental.

Who else is doing this? Nutanix is an example - see their position on trying to transition to being a software company, and changes in how they compensate their field only on software – encouraging their customers to pick their hardware in an open ecosystem (BTW - this is all public info in their earnings calls).    We have some interesting thoughts on this as you can imagine – and it likely isn’t what you think (but that’s for another blog post).

Microsoft is an example where their position on Azure Stack is the other way – only being offered in Integrated System form… but where they charge for their software being consumed on said integrated systems.  

Net: I think the HCI market having these two variations: 1) software-led, open hardware ecosystem (“build”); 2) Integrated Systems (“buy”) is a fundamental reality of the HCI market.

Now, which one of these is “right” or “better”?

That’s not the right lens. They are different – and it’s important to be thoughtful (and honest) in which is right for you – consider Kelsey Hightower’s quote:  "Build vs Buy.   The challenge is understand what you can build, and maintain, may not be better than what you can buy or adopt.  Sometimes you have to build it before making that decision."

Now – what happens over time?   I don’t know.   I suspect that over the long arc of history, there a couple things that play out:

  • A trend towards “buy” for things that are common.   This takes time for any set of technologies to sink into the zeitgeist.    This is offset by a constant trend of new “build” layers appearing on top of the commoditized layer.
  • Ongoing commoditization and automation in the “build” domain. 

That said, while features/functions vary over time (and there’s a never-ending treadmill of commoditization of the bottom part of integrated systems value and life-cycle automation, with net new value and innovations constantly being added in)… there are certain intrinsic pros/cons, or said otherwise value/trade-offs in these two approaches.

Consider these trade-offs and apply them not only to what I do at Dell EMC, but as a more generalized observation about the HCI market (and frankly “build” and “buy” choices more generally) as a whole.

Software-Led (“Build”) Integrated System (“Buy”)
Intrinsic values Flexible, HW choice, control over specific software features System-level value, single accountable party, unique software functionality, redirect resources to focus on other activities
Intrinsic trade-offs Operational expense of system/stack-level integration, lifecycle management, multiple supporting vendors Price premium over the “sum of the parts” associated with the embedded integrated engineering / integration / support of the system/stack, specific set of choices

Now, I have a strong personal opinion as you can imagine. 

  1. If we ever stop offering these two choices, customers will be pissed – they like choice.
  2. At the same time, I think customers need to question long and hard the value they get out of building things themselves, and I would encourage you dear reader to look into your heart.

This is a “challenger” dialog to be sure.

I’ve been an Exchange admin in my career. I’ve been an engineer at a startup helping build a product. I have built many a vSphere/vSAN cluster in my days, and I LOVE it. I like to build, I like to play. The intrinsic values of flexibility, broad ecosystem of hardware to choose and control over specific features is a strong siren call.

That said – I rarely think practically about how much time/effort I spend in that zone.

Likewise, in many cases, I’ve found that customers have a hard time putting a number on “operational expense of system-level integration”, and struggle when they measure it against the very clear “price premium” of integrated systems.

BTW – I’ve found that the price premium of integrated systems (as someone running very large business that does this) has an upper-end maximum.

Go above this, and it becomes too much for the market to bear.

Below that – it’s a function of just how good the integrated systems experience is – ergo, how much do you REALLY offload from the customer, and how good are you at explaining that value to the market at large, and to a customer specifically.

It’s important to understand that you can end up at the same place technology stack-wise using a “build” or a “buy” approach.   It’s also important for each and every customer to think through what’s right for them.

I talked about this idea here – but my own thinking was not complete, and I don’t think it was adequate.  I had just left a customer meeting where we didn’t explain the difference well enough, or the customer didn’t agree with our explanation – and I think I let my frustration show. There are very legitimate reasons people go one way or the other.

Let’s look at ONE example in more depth.

In particular, consider the process of doing a lifecycle update of an HCI stack through the “builder” lens and the “buyer” lens.

When a customer takes a Software-led (“Build”) approach – they place a lot of value on the fact that they can tap into a broad ecosystem, leverage the hardware vendor they have/like. They are perfectly find in carrying the integration workload. VMware will keep making this easier for them (this is the constant over time commoditization of the “base”).

  • First – they acquire the software first – and then pick hardware by evaluating against their criteria. In the case of vSphere/vSAN, the customers picks vSAN ReadyNodes from the support matrix – which is simple and visible here.
  • When they do an update, VUM with vSAN 6.6.1 will HBA firmware issues (an example of the ongoing simplification/automation in the open ecosystem)
  • They can use VMware’s vSAN Configuration Assist tool to catch and remediate HBA firmware gaps relative to the vSAN ReadyNode HCL.
  • If they are using Dell EMC PowerEdge, they are perfectly happy to use iDRAC and scripting to do other firmware updates (bios/NICs, SSDs, etc). People that love this get into bar fights over iDRAC vs. ILO.   If you’re one of these people – you’re likely a “builder” :-)   These people accept/recognize (even if they aren’t conscious of it) that they own doing this right.
  • They like using the server vendor tools (again, if they are using Dell EMC PowerEdge in this case it would be OpenManage Essentials vCenter plugin in) to manage their hardware separately.
  • They may pick a higher-level orchestration/automation engine to coordinate these tasks
  • They completely understand, and in fact WANT their support from VMware to be from VMware, and their support from the hardware vendor from the hardware vendor.

This reflects the intrinsic benefits of the “build it” approach to HCI (tons of flexibility, tons of control) – but the customer accepts (consciously or not) the trade-off of owning the integration and support model. There is someone at the customer who accepts, embraces (relishes?) the process of integration testing/validation, automation, etc. In fact, often those people don’t even acknowledge, and sometimes dismiss the trade-off that they are intrinsically accepting.

Conversely – all those exact same steps are in essence embedded in the integrated system model – someone else does it so you don’t have to.

  • The integrated system vendor owns the hardware selection. In the case of VxRail and Dell EMC’s vSAN ReadyNodes – we work to make these match as closely as we can. There’s a whole whack load of testing and integration. We push as much as we can into the vSAN testing cycle and are working to make them as coincident as possible. But, there’s also testing into other parts of the embedded stack (like VxManager that does some stack-level management, integrated fault management and alerting systems, and integration with RecoverPoint, Cloud Array, Data Protection)
  • When you do an update of an Integrated System, all the hardware/software elements are integrated not only in testing, but also in the update process. The steps noted above are integrated into the offer, and the update in the software. There is a internal REST API call to “update system” – which then goes about all the steps. This can be batched and automated easily, because all the steps are already automated. Unlike in the “build” case where the customer is integrating the stack, in the “buy” case it is already integrated. That means, by definition a trade-off in the loss of open ecosystem choice.
  • The Integrated System customer does NOT want as much choice. They don’t view that as a trade-off, they view it as a benefit. They want to get out of the business of putting the stack together and maintaining it. That customer accepts that it’s going to come at a premium to the “sum of the parts”, because there is more than the “sum of the parts” (the “sum of the parts” in this case vSphere/vSAN and a Dell PowerEdge server + additional software and data protection). The incremental ingredient is the embedded integrated engineering / integration / support – and the software that pulls it together.

To be very clear, any example where someone claims that a “bundle” is the same as an integrated system I would humbly suggest doesn’t understand the delta.   The easy test is to ask questions which poke at the “transfer of responsibility” that is fundamentally the delta of “build” and “buy”.

I’ve seen this error get made – sometimes by customers, sometimes by SOME people at a customer (usually a single customer has “builder” advocates and “buyer” advocates). I see this error get made by our own teams that specialize in one part of the stack or another.

Integrated Systems are a non-trivial lift.  Above and beyond all the great humans we have building software at VMware and software + hardware at Dell EMC are the ingredients that go into Integrated Systems, we literally have hundreds of people working on making sure that VxRail and VxRack SDDC are the best Integrated System manifestations for our VMware-vertically aligned stack. Uniquely – we have both offers from one place for a common stack. While there is a broad ecosystem for vSAN, for VMware Cloud Foundation (representing “software-led build”) - VxRail and VxRack SDDC are the Integrated System manifestations.    The same is true further up the stack into IaaS/PaaS/CaaS domains – but more on this in the next post.

By the same token – anyone who suggests that the only way for customers is the integrated system approach doesn’t appreciate how much of the market actively wants and chooses the software-led “build” approach for its intrinsic benefits and trade-offs.   I have people on my own team that can get too passionate on this topic.   I have an opinion – but my opinion also recognizes the reality I see in the marketplace.

Also note that in the example above you get to a very similar place (how the stack gets life-cycled), but in a totally different way, and with two totally different operational models.

I’ve found more often than not – customers have a very clear preference one way or another.

I’ve also found that as you work with the IT administrators, they tend to like the “build” approach, and as you work with the IT senior leadership – they tend to like the “buy” approach.

I think this is a dialog that needs to happen in every IT shop, and they need to come to their own conclusions.

My 2 cents? I think we’re on the steps of an inevitable journey where infrastructure is consumed, not constructed – whether it’s private or public, whether it’s on-premises or off-premises.

The next 2 posts will reflect on two linked observations – the move up the value stack from HCI today to full IaaS, PaaS, CaaS stacks, and also the emerging era of vertical “stack wars”.

What do YOU think?   What are your experiences – positive, negative – with regard to the “build” to “buy” continuum?

Powered by WPeMatico


Hack Naked News #154 - December 19, 2017

Michael reports on a suspected North Korea Ransomware attack, Kaspersky federal software ban, compelled passwords, and 1 in 3 IT professionals looking for new jobs! Jason Wood of Paladin Security joins us for the expert commentary on Bitcoin, and more on this episode of Hack Naked News!

 

Full Show Notes: https://wiki.securityweekly.com/HNNEpisode154

 

Visit https://www.securityweekly.com/psw for all the latest episodes!

Powered by WPeMatico