Do-it-yourself always entails a few risks, no?
More and more enterprise IT groups are becoming disenchanted with “traditional do-it-yourself” infrastructure assembly.
Selecting individual components. Evaluating beyond the data sheet. Testing both standalone and combined. Self-integrating and self-supporting the entire end-to-end result.
This hasn't been lost on IT vendors.
There’s now a burgeoning category "integrated" solutions intended to lessen that burden and produce more predictable results with less effort -- reference architectures, converged systems, hyperconverged systems and similar.
Each of these are attempting to tackle the same ugly reality: do-it-yourself IT infrastructure is losing its appeal. The projects take too long, they cost too much, they sap precious IT resources, they require unique skills and they often produce unpredictable or substandard results.
Somewhat uniquely, Oracle has invested heavily in what it calls “engineered systems”. I’ve come to appreciate it’s a completely different take on the broader infrastructure solutions category.
If you’re running critical applications — especially those built on Oracle’s database — Oracle's engineered systems deserve your consideration.
That being said, I also realize that most IT pros might not be familiar with what an engineered system really is, and how it is fundamentally different than apparently similar offerings.
So I thought I’d help out :)
The Lay Of The Land
Any time I meet with IT leadership, it’s generally the same picture: they’re slammed having to do more with less. That was true decades ago, and it’s still true today.
The only thing that seems to vary is how much pain and where it’s coming from.
While most IT leaders do a good job with most challenges, there’s a particularly hard one to overcome, e.g. “that’s the way we’ve always done it”.
When it comes to IT infrastructure, there’s a strong preference for do-it-yourself: pick a server vendor, pick an operating system, pick a hypervisor, pick a storage array, pick a network interconnect, management software, data protection, etc. etc.
I've met more than a few people who thoroughly enjoy the the whole integration thing. Like kids in a candy shop, they love endlessly researching everything, bringing their choices into the lab, evaluating, integrating -- and trying to make it all work together. For them, it's big fun.
Few that I’ve met are really good at that particular skill, though.
Unfortunately, when IT integration guy is done, there's a hand-off to another team who has the unenviable task of keeping the assembled contraption running: support, patches, updates, troubleshooting, migration, etc.
The people who built the environment are off doing other things ...
Obviously, not an ideal situation — at least from a business perspective. Way too much time required, compromised functionality, unpredictable results, and a huge OPEX wake in the aftermath.
Expensive and risky.
The people who like to do this kind of design and integration work have their reasons: it’s all about best-of-breed, we’re getting the best price, we’re not locked in, we can tailor to our requirements, we can differentiate from our competitors.
I’ve heard it all, many times.
Rarely do any of these arguments stand up to close scrutiny. My personal belief is that certain people really enjoy building stuff, and if they can get paid for it — great! That might work for them as individuals, but it’s certainly not working out so well for the folks paying the bills.
Progressive Industry Responses
One successful response to the obvious disadvantages of do-it-yourself infrastructure has been reference architectures. Pick a use case (e.g. Exchange), follow this recipe and here are the results you should get.
I think of these as kit cars.
Appealing to the hobbyist, but still lots of work required before, during and after the integration exercise.
And as no vendor has a complete self-sourced solution, you’re inevitably working across multiple vendors and multiple support relationships.
I spent a lot of time working with reference architectures. They’re certainly better than a random pile of parts, but still plenty of room for improvement.
Several years ago, VCE came up with the idea of a VBLOCK. I know, I was closely involved at the time.
The idea was simple: take technology from EMC, Cisco and VMware and turn it into what appears to be an integrated “product” — one pre-sales motion, one support experience, etc. At the time, it was a controversial proposition that has since become more mainstream.
That being said, there were challenges.
For example, VCE didn’t actually own (or engineer) the components — different teams at EMC, VMware and Cisco did that. And a VBLOCK has almost zero native application awareness.
A few years later, Nutanix, SimpliVity and VMware started talking about “hyperconverged”. I was close to this one as well :)
The idea was simple: by running the storage stack on the same server hardware used for compute, you could potentially eliminate the cost and complexity of an external storage array — all things being equal. Nice -- if it can do the job, that is.
However, external storage arrays exist for good reasons. And no hyperconverged vendor would confidently claim they’re ready to take on the big, critical applications at the center of most modern enterprises.
Enter the notion of engineered systems.
What Makes An Engineered System “Engineered”?
Like many of you, I have grown a distaste for made-up marketing words. If a term doesn't have a reasonably precise description, don't bother. Fortunately, there is a very prescriptive set of attributes for an "engineered system" -- at least, when the term is used by Oracle.
#1 — Optimized for Critical Applications
The first thing to understand about engineered systems is that they are specifically designed and optimized for critical applications — the ones that really matter in the enterprise IT landscape.
To be fair, plenty of enterprise IT applications are less-than-critical, and there’s plenty of market space for reference architectures / converged / hyperconverged solutions to address them. While engineered systems could certainly be used for those situations, that’s not the envisioned target — it’s design for those applications and databases that are highly critical and visible to the entire business.
And, more often than not, those run on Oracle software.
Performance optimized, support optimized, protection optimized, operations optimized, cost optimized -- all around the design point of critical applications.
#2 — A Product, Not An Assembly Project
Like other forms of pre-integrated infrastructure, an engineered system is a defined product: defined capabilities, defined cost, defined results.
You’re paying for a very specific outcome — just like buying a car.
It contrasts with do-it-yourself integration which often has uncertain timelines, undefined costs and undefined results.
Unlike other product-like infrastructure solutions, Oracle owns and engineers all the core technology bits: storage, server, operating system, hypervisor, database, management, security, etc. all under one roof.
None of the converged or hyperconverged players can make this claim — which is highly relevant if we’re talking engineered systems that are intended to support critical applications.
#3 — Architected From App To Storage By A Single Engineering Team
Every other integrated infrastructure solution vendor faces a fundamental challenge: they don’t engineer all the ingredients. If Nutanix doesn’t like what VMware is doing, tough luck. If Cisco or VMware or an EMC storage group doesn’t play nice with VCE, a similar situation. If VMware doesn’t like what the storage vendors are doing, too bad.
And *none* of these folks have database and applications in house to co-engineer with.
The seams are obvious. I think we’ve simply gotten used to the gaps. But they don’t need to exist.
With Oracle’s definition of engineered systems, not only does Oracle engineer all the important pieces, but they all report to the same person: Larry Ellison — Chairman and CTO. And I can personally vouch based on my time here at Oracle that he plays a very active role.
Dig under the covers of any Oracle engineered system, and you’ll find co-engineered “handshakes” architected consistently up and down the stack. They’re not negotiated, they’re engineered.
That’s impossible for almost anyone else to do.
#4 — Application-Aware, Complete and Secure
Time for some secret sauce.
Oracle engineered systems know about Oracle databases, and Oracle databases know about Oracle engineered systems.
Examples: there’s no need for a storage admin to explicitly express what the storage should do: that’s engineered in. There’s no need to go multiple places for a database-centric or application-centric view of the infrastructure — that is engineered in. The security model can start with locking down critical data and work outwards. And many more examples.
I have been struck by just how complete an engineered system can be.
A single management console that integrates application, database and infrastructure views. Synchronized and automated patching of all components from app to firmware. Data protection that’s database-aware. Performance tools that can span the entire stack.
This isn't a science project, it's grown-up IT for grown-up applications.
#5 — Enterprise Cloud Designed In
Here’s a killer value proposition: for many of the engineered systems Oracle offers a precisely compatible Oracle Cloud equivalent: same technology, same capabilities, same operational model, same enterprise experience.
The only difference is your choice of consumption model, period.
None of the other infrastructure vendors -- nor public cloud vendors -- can make this rather important claim.
And, for any enterprise IT team who’s gone looking for compatible “cloud” solutions to complement their critical applications, this is a very big statement indeed.
Think about doing serious development and testing on an external services that's 100% compatible with your internal systems. Or swing capacity. Or remote recovery. Or any of the dozens of things you could use it for.
Maybe you’re not interested today in 100% compatible enterprise cloud consumption options, but things have a way of changing. I think it’s an incredibly useful option to have that entails almost no risk and almost no adoption curve.
#6 — Compelling Capabilities Unique To Oracle
One of the benefits of engineering all the layers of the stack together is that the resulting solution can do some pretty amazing things that just can’t be done by combining separate independent technology stacks from different vendors.
I’ve assembled a partial list, but the fun part is that it keeps growing as I dig deeper and deeper into the maturity of engineered systems.
One of my favorites is HCC — hybrid columnar compression. Database and storage work together to dramatically compress databases (10x-50x) as well as provide a significant performance boost on database scans.
Forget ordinary storage dedupe folks, this can only be done when the database and storage subsystem work together.
Being a storage guy, the proprietary Infiniband protocols direct from database to storage look pretty darn sexy. Not to mention ExaData’s SmartScan pushing SQL query fragments directly to the storage cells. Database snaps that are impossible to do any other way.
The more I dig, the more I find. Not only that, all of these features translate into direct economic impact for the enterprise IT shops that have adopted them.
In some sense, these customers now have an unfair advantage.
#7 — One Integrated Experience — One Vendor
It’s really more than just “one throat to choke” — it’s having a single vendor responsible for your entire experience: presales, installation, production, support, maintenance, contracts, etc. From app to storage to cloud. That’s a dramatic simplification over any other infrastructure experience for your critical apps. Not even the best outsourcers or system integrators can match that.
The inevitable push-back is, of course, lock-in. Enterprise IT folks might say “we already spend a lot with Oracle, why would we spend even more and reduce our options?”
The obvious reality is that Oracle software runs on just about anything, unlike dedicated database appliances such as Teradata and Netezza. It just runs faster/better/cheaper on Oracle Engineered Systems.
If you find you don’t like the Oracle engineered systems experience, you’re free to kick it to the curb in just the same way you’d do with any other infrastructure solution that didn’t work out for you. There is nothing different about an engineered system in that regard.
But — based on all the great customer experiences I’ve seen to date — that’s very unlikely to happen.
-----------------
Like this post? Why not subscribe via email?
Ah, I see you have run into Mike Workman-speak: Application Aware. I was at Pillar when I had an email banter about this term. I brought up the term Application Adaptive, then. This is the twenty-First Century, and I feel Application Aware is meaningless and very less bold than being adaptive. With the right Software the 'S' in SDx should equip any Enterprise to DIY. Scott McNealy called it the Big Freaking Switch in 2002. Now we call it hyperconverged. We add two prefixes to verge -- big deal. If we are going to mix latin and greek prefixes lets think in terms of Hypertransverge. Hypertransverge does more than push verges together. It goes across those verges with interdisciplinary awareness. Now add 'hyper' to it, Greek for above. Let's now look above interdisciplinary awareness, what do we see? -- Well, think like a supreme being. When writing your SDx put some DNA in it!! Not just the code for growth and differentiation but the code to adapt over and over again generation after generation. -- If Oracle is writing that code I'll pay the HUGE license fees for it -- so I can DIY. :-)
Posted by: Al Bledsoe | September 10, 2015 at 02:17 PM