Where Does VCE Go From Here? and more...

Where Does VCE Go From Here?

DarkcloudAnd while we're at it, where does the whole category of converged and hyperconverged vendors go from here?

Right now, this is the #1 question I get from colleagues, IT pros and industry-watchers.

Make no mistake: I was a passionate advocate of VCE -- at the time.  Many of my colleagues have worked for VCE, or -- in some cases -- still work for VCE.  By the way, a big shout-out to my colleague Nina Hargus, just promoted from being VCE's CMO to EMC's.  

I tend to want to wish people the best, but unfortunately the future looks quite dark through my lens.

The products may not have yet changed, but the context certainly has.

The Big Idea

PartsVCE was born Nov 3 2009 (yes, six years ago) as a response to a problem we all saw in the industry -- customers were getting killed trying to self-assemble infrastructure.  To this day, many still are.

Folks would take storage from one vendor, compute from a second, fabric from a third and a hypervisor from a fourth-- and that's when the fun started.

Some assembly required.

Infrastructure projects became lengthy and complex, with uncertain schedules and outcomes. Worse, keeping everything patched, upgraded and operational was a huge drag on IT operations, not mention all sorts of support calls.

There had to be a better answer.

The idea was simple, yet radical at the time. Create a "virtual infrastructure product" (later dubbed converged infrastructure) that masked the end user from the inherent complexity of multi-vendor infrastructure. Effort spent on the plumbing could now be invested in other, more productive areas.  

BadreactoinIt might seem rather obvious now, but -- at the time -- it took some serious evangelizing.  However, to this day there are still many IT shops who haven't gotten the memo that build-it-yourself is often a poor way to do infrastructure.

Competitors reacted quickly but never really caught up in any meaningful way. And a host of startups tried to one-up the idea by eliminating the need for external storage, dubbed hyperconverged.

The good news?

Generally speaking, Vblocks delivered on expectations. Once IT teams realized they were making themselves miserable trying to be system integrators, their world became better.

But thee's always more to the story, right?

Structural Problems Underneath

StructuralThe goal of VCE was to hide complexity from IT users, but VCE had no shortage of structural complexity to deal with.

First, the VCE product itself is after-the-fact integrated using standalone technology designed and engineered independently by three entirely separate entities: VMware, EMC and Cisco.

Each company has its own technology agenda. Each company has its own customer agenda. Each company has its own sales agenda. Each company is trying to maximize their portion of the deal.

Trust me, it was an uphill battle at the time, and probably still is. Despite press releases to the opposite, there were never any group hugs, and we never sang Kumbaya together.

The expected divisive forces between the companies were held together largely through the efforts of John Chambers and Joe Tucci. John has since retired, and EMC is now being sold to Dell. Other than a shared desire to take care of existing customers, I don't see a lot of appetite to continue strategic investments in the original VCE construct.

CokeTo better serve its customers, VCE proliferated their portfolio like crazy. The singular notion of a Vblock has now morphed into a dizzying array of variations: Coke, Diet Coke, Coke Zero, Cherry Coke, Diet Cherry Coke, Diet Cherry Coke Zero and so on. What was once a simple discussion now had become complex once again.

The other structural problem I saw was the underlying business model: VCE is essentially an additional integration/sales/support function. Customers were paying for integration that arguably should have been there in the first place.  Also, that means almost no money for things like innovation, R&D, etc. -- most of that had to come from the parent companies.

What Happens Now

BiggerfishDell will eventually acquire EMC, and for all intents and purposes, VCE is now just another product group at EMC that gets to carry different business cards. While Cisco-based versions of their products will continue to exist for some time, that's not where the focus is going to be. Witness VxBlocks.

Using Dell technology will obviously be the new focus. Strategically speaking, there's little incentive for Dell/EMC to invest in Cisco integration, and vice-versa. And the two CEOs who made it all happen won't be involved going forward.

The other challenge will be to continue funding VCE's comparatively expensive business model. The elephant on the balance sheet is ~$50B in debt that has to be paid off sooner than later. If the folks at EMC and VCE aren't expecting a massive haircut, perhaps they should. VCE will be in a tough spot to keep up their high-touch model, invest in value-added differentiation, while they attempt to continue proliferating newer Dell-based models of Vblocks.

At some point, something will have to give, won't it?

Sorry, But There's More

SqueezedAll the horizontal infrastructure business models are getting compressed. It really doesn't matter whether we're talking about servers, storage, networks or hypervisors.

The twin culprits are commoditization and cloud. Margin compression means less money to spend on R&D, creating unique value-add, and delivering top-shelf customer experiences.

Integrating horizontal technologies into an appliance did create new value for a while, but now it looks like just another, bigger lump of commodity. It's like a movie sequel: we know what's going to happen.

Real and sustained differentiation takes money -- great gobs of it -- and that's not going to be part of the equation for the foreseeable future.

The best answer to escaping the infrastructure commoditization trap is to move up the stack: applications and databases. People spend real money on that stuff :) But there's almost none of that in the combined Dell/EMC portfolio.

The best answer to escaping the cloud trap is to have one, obviously. Dell/EMC certainly has sincere plans, but it's going to take a while, not to mention great gobs of, errr, money.

And unless that future cloud has very rich PaaS and SaaS capabilities that enterprise customers want to use, any future IaaS cloud will tend to be commoditized as well -- thanks to Amazon, Google and Azure.

Strategically, VCE is stuck in a nasty vise.  And there's no way out that I can see.

Playing The Game

HandofcardsAs any card player knows, the value of the cards in your hand depends greatly on what game is being played. If the game changes quickly, what once looked like a winning hand can end up being a struggle. That's how I would describe what's happening here.

So what should VCE customers expect?

To be clear, nothing is going away anytime soon. The VCE construct will certainly continue to exist in some form or other to take care of existing customers, provide upgrades to existing products, etc. Neither Dell nor EMC nore Cisco will ever want to walk away from enterprise customers.

But I think that the days of VCE as a growth story are over. When a part of the business stops growing, investments are capped, and it's turned into a cash cow on the consultant's chart.

That's how the game is played.

By The Way

I think Oracle has figured out a strategically brilliant way to escape the twin traps of commoditization and cloud.

LarryLet's not forget, Oracle has a compelling array of applications and database technology to integrate with infrastructure IP it designs and builds itself. If an IT shop is heavily invested in the Oracle Database and the applications that run on top of it, it's not even a fair comparison. That's what you can do when you own the whole stack: infrastructure, database, middleware and applications.

And have great gobs of money.

Oracle has escaped the cloud trap by actually having one: the Oracle Cloud -- a comprehensive array of IaaS, PaaS and SaaS services clearly targeted at enterprise IT that can be consumed either on-premises or via Oracle's Cloud -- or any combination.

If the game has changed, Oracle is holding some extraordinary cards, and certainly knows how to play them.


Like this post?  Why not subscribe via email?



When Cloud Grew Up

Coming off of Oracle Open World, the message was clear: cloud, cloud and more cloud.

Larry Ellison called it the biggest industry transition since the desktop PC. In my words: cloud in all its sundry forms fundamentally re-invents how IT services are produced and consumed.

BlueprintIt's the new design pattern for enterprise IT architectures.

Turmoil and controversy abound as a result. On the vendor side, not all of the current industry players will cross the chasm. Many have tried, and are flailing. On the enterprise IT side, hard choices and big bets need to be made, and soon.

I've seen some of the industry press express skepticism around Oracle's cloud ambitions. While we're all entitled to our opinions, not all of us have the same insight into what really seems to be happening.

I've looked at cloud from my previous employers: EMC and VMware. I've worked with service providers on architectures and business models. And I've spent way too much time in the bowels of enterprise IT. I, too, am entitled to my opinions.

Here I present my personal, biased case for Oracle's cloud strategy in all its forms -- evaluated as a mature paradigm through the lens of enterprise IT. As always, none of this has been reviewed or approved by my employer, and I of course will take personal responsibility for any factual errors herein.

My History With Cloud

I was an early devotee of the Clouderati.

CloudeyeFor example, early on I interviewed Nicholas Carr (author of The Big Switch and Does IT Matter?) just to get some initial perspective on what was starting to happen.

In 2008 and 2009 I blogged endlessly about public, private and hybrid clouds, and how they would fundamentally restructure how we thought about enterprise IT.

Starry-eyed stuff, as I go back and read it. At least I wasn't the only one!

It wasn't long, though, before I parted ways with the starry-eyed crowd. Reality struck. Most enterprise IT organizations weren't going to embrace external cloud services -- or the cloud operational model for in-house IT -- any time soon. And they had very good reasons.

As I remind people, enterprise IT is different.

Pick your favorite industry analyst, and ask them to segment how much IT is consumed on-premises vs. via an external cloud provider. The conclusion is simple: the vast majority of IT spend still remains in the data center -- although there is every sign that is beginning to change.

Aol-netscape-logosHere's the point: with regards to enterprise IT adoption, it's still early days in a very big game.

Remember when Netscape was supposed to rule the browser, and AOL the internet? I've learned not to declare early winners, especially when most of the market spend has yet to materialize.

Within enterprise IT, what's going to be first to go to the cloud?

Stuff that doesn't affect the core of the business: checklist SaaS applications, desktop productivity, test and development, long-term archiving and the like.

What's going to be the last to go to cloud?

Stuff that affects the core of the business: critical applications, sensitive data and the like.

This observation isn't rocket science, it's just human nature.

Put differently, the industry prize that's still in play is the bulk of enterprise IT spend around the stuff that matters. And the cloud provider that secures that franchise gets first crack at everything else.

My New Understanding Of Cloud

The original public cloud message went straight to the wallet: save money on capex and opex. Cloud operators had scale and automation that (theoretically) could save money over using in-house IT resources. Before long, the reality emerged: it all depends.

EvolutionThe public cloud message then evolved to being about infrastructure agility: public cloud services can react faster to changes in demand vs. stuff you do yourself. Spin-up, spin-down, anywhere.

That benefit has turned out to be largely true, simply because most cloud operators have greater scale, more data centers, preprovisioned services ready to go, etc. than in-house IT.

Now, the public cloud message is all about application agility: delivering new applications faster than before with modern development environments and tools. Not absolutely true: a well-designed in-house application factory can frequently offer many of the same benefits.

All of this has brought about an evolution in how I think about cloud these days. It is not a separate thing, it is best thought of as an end-to-end design pattern that changes the way we envision our next generation enterprise IT architectures.

Cloud demonstrates how IT services should be presented, how applications are to be developed, how operations are to be managed, and how infrastructure should be consumed. Taken this way, cloud does not insist that only public clouds must be used, but only presents them as yet another consumption option.

Cloud is an architecture. Cloud has grown up.

When my kids were younger, I measured them one way. Now that they are young adults, I measure them quite differently. If cloud has grown up, how should we measure it?

Criteria #1: Comprehensiveness

OC_slide_1It's been true in on-premises enterprise IT for quite some time; having fewer comprehensive suppliers is strongly preferable to many niche suppliers. Better integration, less hassle, volume pricing -- all of that.

One would presume that this preference will apply to enterprise cloud as well.

Let's look at this through our enterprise IT eyes -- what's the preferred cloud stack, and -- more importantly how does it all work together as a whole vs. sum-of-pieces?

At the top, our ideal enterprise cloud supplier should have a broad library of SaaS industry applications; either used as-is, or as building blocks for newer applications that span categories. These should be able to be deployed on any mix of on-premises or external resources as needs and desires dictate.

OC_slide_2Here, Oracle brings serious game. I won't go through the entire catalog, but let's just say there's quite a successful application portfolio to consider, and it continues to evolve at a frenetic pace.

Taking the paradigm further, Oracle has started offering Data-as-a-Service (DaaS), offering top-quality external data sets to enrich many of these SaaS applications.

By comparison, both AWS and Azure don't have much to say in the enterprise application category, which I would argue puts them at a strategic disadvantage.

However, SaaS without PaaS isn't all that appealing. You want to be able to extend and integrate application building blocks, and create entirely new applications. PaaS without SaaS is also unappealing; it would be great to start with proven application components, and extend from there.

OC_cloud_slide_5Again, here Oracle brings huge game around the Java platform, in addition to supporting all sorts of other popular frameworks and tools.

Next up is IaaS, of course. In an ideal world, SaaS+PaaS would be able to interact directly with optimized infrastructure, whether in the cloud, in the data center, or both.

In addition to IaaS interacting closely with SaaS and PaaS, you'd also like to expose attractive infrastructure services (compute, storage, data protection, archiving, etc.) for other parts of the landscape.

Here, once again Oracle brings game. Not only generic Intel/Linux white-box compute, but differentiated SPARC/Solaris if you're looking for something, errr, more specialized. The lowest cost per terabyte of any storage archive in the market. The ability to precisely control service levels (performance, availability, recoverability, etc.) in a way that the other guys can't.

Basically, all the infrastructure stuff you'd want for your enterprise cloud.  

Because enterprise IT is different.

Criteria #2 -- Compatibility

I've said it before, and I'll say it again: the ability for enterprise IT shops to choose between 100% compatible consumption options is *huge*. Here's why: the next enterprise IT architecture isn't all about the data center, or all about the cloud -- it's about *both* working closely together.

Cloud_choicesIT has long been working to standardize technology and operational models within the data center, and for good operational reasons: less effort, less complexity.

Add cloud to the equation, and we're just drawing a bigger perimeter around where we'd like to have standard capabilities and operations.

True, Microsoft has footprint in the enterprise, and they're clearly working towards harmonizing Azure and their datacenter offerings -- all smart moves. By comparison, AWS is nowhere to be seen in this all-important on-premises operational compatibility discussion.

Now, let's look at it a different way. Imagine it's a few years from now, and let's say you've got your critical applications spread between on-premises and a healthy helping of public cloud resources. Suppose there's a problem involving the two, and you're not quite sure where to start.

How important does it become to work with a vendor that's responsible for *both* sides of the wire?

As I keep reminding the armchair cloud pundits: enterprise IT is different.

Criteria #3 -- Cloud-Native For The Enterprise

NativeCloud-native applications are a real thing, even for enterprise IT. They're built differently, and they're operated differently than traditional enterprise applications.

That's what modern PaaS is all about.

But in an enterprise world, cloud-native apps don't live in a vacuum: they often source data from existing databases, and use those same databases to capture system-of-record transactions.

Rarely does someone get to start fresh with a blank sheet of paper.

Given this context, there's a lot to like here in the Oracle portfolio -- a richly mature cloud-native enterprise PaaS that's been proven to deliver the goods. Better yet, Oracle PaaS knows about infrastructure and how to work with it.

This is where I part company with PaaS vendors promoting the fantasy of being "cloud-agnostic": sooner or later, every serious application has to interact with hardware. Details matter in the real world.

OC_slide_4The latest cool, shiny thing in Oracle's strategy is the interestingly named Oracle Private Cloud Machine for PaaS and IaaS. Yes, that is the real name.

Here's the hugely attractive idea: Oracle developed a cloud-native PaaS+IaaS engine for the Oracle Cloud. This new product is the *exact* same technology now packaged for data center use.

It's not an exaggeration to call it "cloud in a box", because that's precisely what it is: platform, tools, operational model, everything. And, of course, it seamlessly interoperates with equivalent resources in the Oracle Cloud using a single management tool for both.

It'll be interesting to see whether the other big cloud players can do something similar.

Criteria #4 -- Choice

ChoicesNo surprise: not everyone wants to use Oracle software technology exclusively.

As you dig through both the on-premises and cloud options, there's significant and meaningful choice: different databases, different operating systems, containers, OpenStack, different framework and tooling choices, etc. etc.  

All your favorite names.

Yes, Oracle has plenty of licensed offerings in the stack, but if prefer mashing together different open source technologies -- have at it.

Even a choice of CPU architecture. How many cloud stacks offer that? :)

Criteria #5 -- Consistency

GardenIt takes a while to appreciate this, but as you invest the time to go through Oracle's sprawling cloud portfolio, there emerges a sense of design with purpose.

Each product stands on its own merits (or not), but -- taken together -- they are clearly designed and engineered to work together. Having worked with, err, other sprawling portfolios, that's not always the case.

There is a clear yet pragmatic vision of future enterprise IT in evidence. It spans from mobile applications to CPU architecture, integrating datacenter and cloud into a seamless whole. There is no shortage of in-house technology and resources to pull it off.  It is both breathtaking and exhausting in scope and comprehensiveness.

It presents as a complete and consistent response to the next generation of enterprise IT architectures.  Today, I would argue there is no equivalent offering.


Choices2If you agree with me on a few basic premises, e.g (1) cloud is a design pattern for next generation IT architectures, (2) cloud architecture is independent of consumption model, (3) a full and integrated stack is preferred, (4) enterprise IT requirements are different -- well, how do the other guys stack up?

AWS, despite what they'd like you to think, isn't all that attractive for the core of enterprise IT. There are no enterprise applications, and there is no technical and operational compatibility with what's happening in the data center. The fundamental message seems to be "life can be great, just start over with our stuff".

Certainly not an option for 99.99% of enterprise IT shops I've met.

I do expect them to grow and continue to be a powerful force in the cloud business; but not entirely successful in the enterprise -- the chasm is just too big to cross.

Salesforce is certainly a force to be reckoned with, but through my lens, they have rather singular focus on sales and marketing. While important, an enterprise runs on much more than that. They don't own any significant IP other than their application, preventing them from being a full-stack cloud player. The same generally holds true for Workday.  And neither appear to be strong at deploying in the data center.

LoseMicrosoft's Azure is more interesting to me. They're well along the path of cloudifying their core enterprise desktop franchise, they can do PaaS, but currently come up short on both deploying infrastructure on-premises as well as credibility with larger-scale enterprise applications.

Going to the next tier down, IBM strikes me as "dark matter". I'm pretty sure it's out there, I'm just looking for hard evidence to prove it has any mass. Besides, everyone is wondering which piece of its business IBM will shed next. SAP is a powerhouse in enterprise applications, but "cloud" for them largely means a SaaS consumption model. They don't do infrastructure, weak on PaaS, etc.

Dell, EMC, VMware, HP, Cisco, et. al. -- not really able to play this grown up cloud game as defined above. Not that they're not great companies, they're just lacking big, critical components in the full-stack world.

The Bottom Line

ChasmFor me cloud has obviously grown up, and become the design pattern for next generation enterprise IT architectures. It fundamentally changes the way IT services are produced and consumed.

Some IT groups will move quickly, most will move at a more measured pace. Some IT vendors will cross the chasm, others won't.

Final thought: I'm usually not a big fan of keynotes and demos, but this one was amazing:  Thomas Kurian ("Oracle Software Innovations" on this page) walking through how the Oracle Cloud can change the way enterprise IT is done. 

It changed the way I think about cloud, and maybe it'll do the same for you as well.


Like this post?  Why not subscribe via email?








The Amazing Oracle M7

Slide3There was a time decades ago when I was intensely interested in CPU technology. RISC, CISC, all that.

Endless debates about which one was "better", which one was going to win in the long term, etc.

Well, we know how the story ended up for most of the datacenter market: it’s mostly an Intel world. Like most people, I thought "well, that's that": most everything was going to run on x86 unless there was a good reason not to.

Sort of like regular-grade unleaded gas, or basic cable TV.

Fast forward a bunch of years, and I land at Oracle. I find that the Sun-derived technologies are alive and well, and carving out a fascinating market segment where everyday x86 doesn't do so well: demanding workloads where using a fewer number of smarter processors can do more work than a boatload of familiar x86.

As part of this week's Oracle Open World and the launch of the new M7 processor, I enjoyed getting my CPU geek back on, and found a lot to really like.

I think you will too.

Generic Vs. Co-Engineered

LoafIn my opinion, the familiar x86 has become generic -- the basic architecture is expected to support a vast universe of workloads and use cases.

It doesn't have to be exceptionally good at any particular use case, just decent at all of them.

Oracle created the M7 as an optimized engine for enterprise software: Oracle's and others. How many CPUs have been designed by enterprise software companies? Not many, I'd argue.

Indeed, the theme for the M7 is "software in silicon", and it’s an apt description.

You'll see clear evidence of this extensive co-engineering as we dig through the highlights.

But, make no mistake, the M7 is awfully interesting -- even without the presence of Oracle software.

Basic Speeds And Feeds

Slide4At first glance, it's pretty clear the M7 is nothing like a familiar x86 processor.

32 cores, check. 4.13 GHz clock speed, check. Outrageous memory and IO bandwidth, check. Huge chip cache, check. 8-way SMP using glueless logic, 16-way using switch ASICs, yup.

OK, it looks pretty freakin’ fast – but you'd expect that from a brand-new CPU.

So, what else is there?

Security In Silicon

Slide7Upping the security game is on everyone's mind these days. It's war out there, and advanced weaponry is very much in demand.

The first major new feature here is silicon secured memory.

It's dubbed as the first-ever hardware-based memory protection for applications -- dramatically improving both security and reliability.

Here's the problem: malicious (or buggy) code can access and/or overwrite memory. The infamous Heartbleed attack was a buffer over-read attack; Venom was an over-write attack.

Silicon secured memory can help prevent both.

How it works is pretty slick: hidden "color" bits are added to memory pointers (the key), and in-memory content (the lock). If there's not a match, the access is aborted, and can be trapped for further processing.

And because it's based in hardware, it can run all the time with almost no performance impact.

Slide9The second, perhaps even more useful feature, is newer dedicated crypto engines.

32 of them per processor, to be exact, supporting the broadest range of ciphers in the industry.

This design enables strong encryption to be used universally, with almost no degradation in performance.

That’s important, because up to now there was a difficult choice to be made – do you want performance, or encryption? Extreme performance with full encryption changes that equation.

SQL In Silicon

Slide18Databases are not only getting bigger, they're moving into memory quickly -- the need for speed never ends, does it?

The M7 once again has two very cool (and completely unique) capabilities implemented as a co-processor, known as the DAX - data analytics accelerator.

The first feature leverages the ability of Oracle 12c database to support dual formats in memory: rows for transactions, columns for analytics. Each DAX engine is able to load multiple columnar values from main memory into special registers, and scan them completely independently of the core processor.

The result is nothing short of amazing: the ability to scan *tens of billions* of values per second, per processor. Nothing else even comes close.  Small data sets, not a dramatic improvement.  Big data sets, enormous improvements.

Slide19The second feature in the DAX is a set of special memory decompression engines that can unpack in-memory database values at full memory speed, greater than 120 GB/sec.

This means larger databases can fit in smaller memory spaces, in addition to improving read speeds from main memory to CPU.

One test showed 6x compression of a 1 TB Oracle database being shrunk to 160 GB. Six times larger databases, or only use one-sixth the memory -- you get the idea.

Again, impressive.

So, What Can All This Superfast Stuff Really Do?

Slide10Let's start with the 32 crypto engines on the M7.

An M7 has a completely unfair advantage over both Intel and IBM Power series. Results will vary by cipher used, but as you can see here, a range of 4x-35x faster can be reasonably expected.

If you're moving to a world where strong encryption is used by default, that's a huge advantage.

Here's another way to look at it.

Slide11Consider a single M7 CPU in the new Oracle T7-1 server.

Imagine you're ingesting 8 GB/sec of AES-128-CBC encrypted data, which needs to be processed, and ultimately sent to disk.

One test showed that only 19% of CPU resources were consumed by crypto, leaving 81% to do useful application work.

Not enough for you?

Oracle builds some pretty big systems.

The largest M7-16 (sixteen M7 CPUs) can theoretically encrypt/decrypt at an amazing 1.3 terabytes per second. Good news, smaller sizes are available.

Slide20What about query performance?

Flash storage – in any form -- can't even begin to compete with the combination of CPU and memory technology used here.

One early beta customer found an astounding 83x performance bump on a routine query vs a flash array. As always, your mileage may vary.

Indeed, the levels of performance are so astounding that it's perfectly reasonable to assume a single system can do both OLTP and heavy analytics, with ample performance to spare.

How about big data performance?

Slide25So glad you asked.

Here's the result of another test running Hadoop-based Terasort against a 10TB datastore.

Just to make things more unfair, the M7 was set to do full AES-256-GCM crypto, the x86 and the Power processors weren't.

A four-way T7-4 was 3.8x faster than an eight-way Power cluster, and 3.5x faster than x86, -- while running fully secured.

What about cloud apps?

Slide26More good news.

A single T7-4 (small, four-way system, 128 cores) was put up against an impressive 12 Cisco C240 M3 configuration. The test was using the Yahoo Cloud Serving Benchmark against the Oracle NoSQL Cloud Database.

Not even close.

The vastly smaller (and cheaper) T7-4 delivered almost twice the performance as the larger, more expensive Cisco configuration.

What Does All This Mean?

Not everybody needs always-on encryption at memory speeds. And not everyone needs screaming performance from in-memory databases, or silicon secured memory, or smaller systems that do the work of much larger ones, or any of the other amazing capabilities of the M7 as compared to alternatives.

Slide29But some people do. And you know who you are.

That being said, everybody is looking for ways to reduce costs, and there's an interesting proposition here.

Let's assume for the moment that the M7 delivers a substantial improvement to do much more work per core, and more work per socket.   That impacts IT costs in two substantial ways: obviously less hardware, and also fewer licenses for compute-licensed software.  I'd encourage people to do their own math.

Congratulations to John Fowler and the Oracle engineering team for delivering such an amazing piece of silicon.

Your fan club should grow considerably as a result :)


Like this post?  Why not subscribe via email?


A Balanced Perspective On The Dreaded Lock-In

No_lock_inOne of the red-meat topics in IT guaranteed to spark a debate is the topic of "lock in", e.g. the difficulty in moving away from a given technology should the desire present itself.

Lock-in is frequently presented as an evil thing, to be avoided at all costs.

The reality is a bit more nuanced: if you're working in enterprise IT, some degree of lock-in is inevitable -- there will always be switching costs involved. For experienced practitioners, it's just one more aspect of a complex equation to be managed and optimized.

Like most aspects of enterprise IT, I've given the topic considerable thought, as I'm sure others have done.

When I was at EMC, lock-in was a huge customer concern. At VMware, paradoxically it didn't come up all that much. And now that I'm in Oracle, I'm back in the middle of lock-in debates.

So lets' get started, shall we?

My Theory Of Enterprise IT

Blackbox3DAt a high level, enterprise IT groups exist to deliver information services to the businesses that need them.

To the people who pay the bills, enterprise IT is essentially a black box: money goes in, services come out. Success can be measured by reducing the money that goes in, improving the quality of services produced, or a combination of both.

Alternatively: IT is more about the "I", and less about the "T".

To deliver these services, enterprise IT groups build and operate one or more 'architectures' (combinations of technology and process) that support the applications that deliver the services. To build an architecture, you make very complex and nuanced decisions about what you select.

SwitchOne consideration among many is switching costs -- which might be important if your choices don't work out down the road.

This is where the notion of reducing lock-in comes into play; the idea that certain technologies have reduced switching costs, making them inherently more attractive as architectural choices.

An example of a technology with low switching costs might be Linux -- there are multiple distros from multiple providers with a great degree of compatibility. An example of a technology with much higher switching costs might be an enterprise network, even though they are built from ostensibly industry standards.

Pay Now, Or Pay Later?

PlanBAn over-emphasis on reducing *potential* switching costs down the road can get in the way of the immediate mission at hand: quality services at attractive costs. Put differently, if a given technology is better/faster/cheaper/more secure than other alternatives, but it also entails the potential of somewhat higher switching costs in several years, what to do?

Since you're basically hedging against a potential risk in the future, most reasonable folks would make sure they have an idea of what a Plan B would entail, and go with option with the more immediate payoff.

Operational Switching Costs

Many people tend to focus on the technology switching costs, and perhaps don't fully appreciate the true nature of operational switching costs.

Complicated-machineryLet's say you bring some technology in. You train your people. You migrate to the new thing. You integrate it with everything else it needs to talk to. You set up a cadence with the vendor: procurement, support, upgrades, etc. You go through inevitable growing pains. 

It's a lot, isn't it?  And all of this has very little to do with the specific technology being discussed, does it?

Add it all up, and operational switching costs can easily outweigh any technology concerns.

An all-too-frequent story: you meet certain enterprises that have invested in automating the heck out of their infrastructure operations. Good for them. But to do so, they had to write to vendor-specific APIs to get what they needed. Ruh-roh.

As a result, they now realize they're locked in from choosing alternative infrastructure components as the effort associated with re-establishing the automation environment is so daunting that they end up buying more of what they have, even though they realize there are better alternatives out there.

Well, it sounded like a good idea at the time :)

Perceptions Don't Always Align With Reality

Perception_vaseMy previous employer, VMware, is an interesting study on how perceptions don't always align with reality.

It's not uncommon to meet enterprise shops who are "all in" on vSphere and associated components. From an outsiders' perspective, you see the potential for extremely high switching costs should an alternative be required, but -- for some reason -- this doesn't seem to be a concern for most.

Maybe they feel there's safety in numbers? I really can't explain it. The same is largely true for x86 architectures now that AMD is no longer a viable alternative for many.

It also can go the other way.

Now that I'm at Oracle working on infrastructure, I hear the "lock in" thing all the time. The reality is that Oracle software runs on just about anything and everything. Switching costs are comparatively low -- it's relatively easy to move an Oracle database from place A to place B should the need present itself.

Granted, that Oracle database runs better/faster/cheaper/more securely on Oracle infrastructure, but I would describe that as optimization. More bang for your infrastructure buck isn't lock-in, folks.

The Evolved Perspective

GameoflifeI do admit I get a bit annoyed when someone throws out the simplistic red-meat argument that "lock-in is evil". In reality, it's just a fact of life that has to be managed.

I buy a car, or a house, or get married, or have kids, change jobs, etc. -- I'm essentially locked in for a while.   Switching costs can be high indeed.

Life would be worse if I avoided those commitments.

Lock-in (or perceptions thereof!) isn't inherently good or bad; it's just another factor in the Big Enterprise IT Equation. At a high level, it's three factors: switching costs in their entirety, combined with the likelihood you'll need to switch, amortized over the time horizon of your decision.

Every moderately-sophisticated enterprise IT environment has lock-in everywhere: it's the natural result of people making pragmatic decisions around architecture and operations.

All things being equal, should lock-in be minimized? Perhaps.

But don't forget you're part of the black box of enterprise IT, and results matter to the folks paying for it.


Like this post?  Why not subscribe via email?






Dell and EMC -- The Aftermath

When_Worlds_Collide_Book_CoverSo much has been written about the tech industry's largest buyout -- a mind-numbing $67 billion.

It's been exactly one week since the announcement -- just enough time for me to get my thoughts in order. 19 years at EMC, two years at VMware -- yes, I'm entitled to an opinion or two.

As you might expect with a transaction of this magnitude and complexity, it's going to take some time. I figure 9-12 months to close, another 6-9 months of getting organized, so we'll be well into 2017 before we all know how it ends up. That's two years from now -- assuming that there aren't any significant legal challenges.

Here's the problem: a lot can happen in two years. Not good to be sitting on the sidelines, waiting for future clarity.

As with everyone who's been involved with EMC, VMware and all the other players, there are mixed emotions all around. Some of the articles got a few key points right, a few I thought were way off base.

And there was a whole lot of echo chamber.

Bottom line: although I wish all my ex-colleagues well, this event does not bode well for those employed by horizontal technology vendors.

Not them, not their customers and not their partners.

You Can't Fight Industry Physics

Obey_physics_its_the_law_tshirtIf you're in the hardware business, you know the drill. Every new product is bigger, faster and better than the one it replaces. You can't easily raise prices, so you end up delivering much more bang for the same buck, year after year.

Except there's a problem. Technology demand isn't keeping ahead of industry supply.

Every year we vendors get faster components, we learn how to assemble and deliver them more efficiently, etc. or our competitors will each our lunch. But not everyone needs hundreds of cores, terabytes of RAM and petabytes of capacity.

Speaking from my storage perspective, a decent entry-level array today does what a high-end array did just a handful of years ago, and for a fraction of the cost.  Ditto with servers, etc.

If your requirements aren't expanding, you can keep your kit around for a very long time. Three years used to be the norm, now it's more like five and sometimes seven. Very much unlike smartphones in that regard.

FeaturesWe IT vendors continue to pile ever-more features onto existing products; hoping to differentiate ourselves and claim a meager premium. But how many people are actually going to need (or use?) all those features?

Not enough.

So we see ASPs (average selling prices) inevitably drift downward over time.

Dell has built their business largely on the back of PCs and servers. EMC, storage arrays of all types. Neither can fight this form of gravity for long. As a result, both have invested in promising expansion businesses --- but it's nowhere near enough to offset the magnitude of the fundamentals at play here. With the exception of VMware, none have really turned into barn-burners.

And even VMware is not immune to these forces. After all, how many new CPU sockets need to be virtualized once you've virtualized almost all of them? The sockets themselves get bigger and faster every year. Not a pretty long-term picture if you're in the hardware business: physical or virtual.

On an optimistic note: Dell has figured out to move a lot of aggressively-priced tin. Not clear if they're actually making money at it, but they know the drill. The race to the bottom has been accelerated.

Yes, There Are Synergies On Paper

On_saleDell wants to do better in the enterprise. I can vouch for the fact that EMC does enterprise quite well. EMC never really cracked the code on how to go downmarket; Dell certainly has. So, just looking at market coverage, there's a potential win here.

But it's not going to overcome gravity.

EMC could never really get close to a server vendor; preferring to be agnostic. Indeed, rampant server / OS / hypervisor diversity makes the EMC independent storage proposition all the more attractive. EMC did make a valiant try to get close to Cisco with servers (witness VCE), I believe the Dell tie-up will allow tighter integration between server and storage; especially important as hyperconverged solutions become more popular.

However, there's a downside: name a server/storage vendor that's successful outside their own base. Time's up: there aren't any. HP, IBM, Dell, Fujitsu, the old Sun, Dell ... they all sell servers and storage together.  Maybe this is good for NetApp and Hitachi and the rest of them? Apply traditional TAM (target available market) sizing, and a big piece of EMC's storage business goes away.

Coordinated M&A is another potential; both companies have demonstrated a flair for good acquisitions. And there are other synergies out there as well -- that is, before we get to "cost efficiencies", e.g. laying off scads of people.

Yes, It's About Cloud -- But Not Like You Think

So many industry writers pointed to Amazon's (and Microsoft's and Google's) success in the cloud as being the driving force behind this transaction. Not exactly so, in my book.

There-is-no-cloud-sticker-shopI'll give partial credit for Big Cloud aggravating the industry supply side of the equation. Lots of IT infrastructure now available as-a-service. But there's another side to this.

If any of these pundits were to spend time actually talking to enterprise IT folks, they'd realize that -- yes -- cloud matters, but not like they think.

No surprise, enterprise IT groups tend to focus on critical workloads. These important workloads aren't going to a commodity cloud anytime soon, and for good reasons. Instead, enterprise IT buyers want a convenient consumption option that's compatible with what they have on the floor: same tech, same operations, same data protection, same security, etc.

CompatNeither Dell nor EMC really had this important strategic capability prior to the acquisition. I can only guess this will be a priority going forward, but it's going to take a lot of capital in addition to the $67 billion that's already spoken for.

Hard for me to see how this is going to get done in the next two years, given everything else that's going on.

Obligatory Oracle plug: one of the many things that attracted me to Oracle is that they already have a successful enterprise cloud portfolio aimed at this exact use case. It doesn't get the same headlines as the biggies, but it certainly is a force to be reckoned with in the enterprise IT world.

And The End Of The Federation

FederationYou've got to give Joe Tucci and the EMC leadership team their due in trying to make an avant-garde business model successful. In places, it was the right combination -- just not in enough places. On paper, it looked like it might have worked in time.

The reality is that it was *really* hard to get any meaningful coordination going across the different sub-companies. Each was focused on their own proprietary mission, first and foremost -- just as designed.

In my mind, you can't have it both ways. You either impose strong leadership focused on a singular mission (as Oracle has done), or you leave various business units to largely go their own way, as EMC has done.

In some ways, the market has spoken.

The Aftermath

Fasten_Seat_Belt_Safety_Sign_SC1083-baMy acquaintances at EMC and VMware realize they're in for a bumpy ride going forward, and more than a few are evaluating their options. Just as you'd expect. Unfortunately, EMC and VCE punishes people for working for them in the form of a very draconian non-compete.

What are these people supposed to do, sell real estate?

Many resellers and value-added partners have built their businesses on the EMC and its federation. They, too, are probably evaluating their options as we speak. From a customer point of view, I'm sure there's a bit of extra hesitation when making that next big purchase. I know I'd be hesitant as well.

One thing everyone craves is a degree of certainty about the future. Thankfully, I now work for a company that can offer that.

In related news: tech IPOs for on-premises equipment seem to have lost their lustre. Pure Storage didn't set the world on fire, and there's maybe a half-dozen similar small companies thinking about their future.

Over-supply hurts everyone: both established players and newer entrants.

The Oracle Perspective

It's pretty simple, really.

Box7Applications and databases are the most critical part of the enterprise IT landscape. More often than not, they run on Oracle software. Oracle has created both a focused infrastructure portfolio as well as a compatible cloud consumption offer behind this unfairly strategic part of the IT landscape.

While it's true that Oracle software runs on almost anything, it's also true that it runs better, faster, cheaper and more securely on Oracle infrastructure solutions: be they on-premises, in the Oracle cloud, or both.

Good luck to both Dell and EMC.


Like this post?  Why not subscribe via email?



Email subscriptions powered by FeedBlitz, LLC, 365 Boston Post Rd, Suite 123, Sudbury, MA 01776, USA.