Questioning HP ConvergedSystems and their Intended Purposes

convergedsystem

I recently had the opportunity to sit in on a call announcing a new product offering from HP ConvergedSystems.  The call left me with many more questions.  The new ConvergedSystem offering is built for Microsoft Analytics software and is highly tailored to doing big data analysis.

As a systems administrator, many times it is up to my group to implement and integrate our storage, networking and servers to provide infrastructure for our systems analysts to deploy their software solutions.  This strategy normally works well and we use the same infrastructure for a wide range of solutions.  We also reuse components several times during their life cycle.  So, this is the point that I don’t fully understand HP’s strategy with the ConvergedSystems.

From what I do understand, ConvergedSystems are prepackaged solutions to help customers speed up procurement, implementation and support of a solution by bringing the customer a known configuration of storage, network, compute and software.  The sales pitch is simplified management and deployment of the software solution.  And on the back-end, it is intended to have better support because all the components are known and tested together and the support team is versed in all the components to support it as a single solution.

At a high level, this certainly makes sense.  It’s a logical approach.

Where I have questions is the fact that it seems that most of the ConvergedSystem solutions are major infrastructure investments based around a particular software solution or use case.  So, what happens in an environment if the software solution launches and then flops?  Are they easily repurposed or are they so tailored to a particular solution that it’s a lost investment?

What happens with the hardware hits the end of its useful life for running Exchange?  Or Microsoft SQL?  Or another software package?  With our existing BladeSystem and storage, we simply order refreshed hardware – something more powerful with increased RAM and CPU specs – transition the running software to the new hardware and then pass down the previous generation to be re-purposed into a new use.  During the life of a blade server or a rack-mount server, it may run 5 or 6 different solutions.  I don’t know if the same can be done with ConvergedSystems.

That also brings into question upgrades of the package solution – how do those work?  If its third-party software, does HP deliver a streamlined upgrade that’s been tested with the hardware and management?  What if it requires more CPU or RAM – can those components be easily traded or upgraded moving forward?  Since the ConvergedSystems are so new, I’m not sure that they’ve been through refresh cycles yet to know.

I am obviously still learning, but I’ve spent a good bit of time around the HP portfolio – the AppSystems, VirtualSystems and CloudSystems – and I am still unclear where these fit in businesses.  And given the exposure I’ve had through blogger briefings, I’m sure I’m not along with my questions. I’ll be attending HP Discover next month and this is one of the topics that I hope to get some clarification on from the HP folks.

Tags: , , , ,

 

About the Post

2 Responses to “Questioning HP ConvergedSystems and their Intended Purposes”

  1. Hector A. Arevalo #

    Hello Philip, Nice blog, with really interesting questions. Although you’ve probably gotten answers for them during HP Discover. Here’s another piece that may clarify these questions for your readers. http://owl.li/yldH6

    Regards.

    Hector.

    June 23, 2014 at 10:06 am Reply
  2. Ken #

    I had the same question about hardware upgrades within a converged infrastructure stack.

    Ideally, you don’t want to ask the vendor for, say, a certain number of cores, but the ability to run a certain workload at a certain price/performance point. I wouldn’t roll the CI into production until I validated in a lab somewhere that the CI stack does what it says it does.

    If we allow HP to slip into the datacenter and swap out a component, we don’t know what the overall performance impact is without re-validating. We only know that the original CI SKU meets our requirements. If we don’t allow them to upgrade in place, then we have to buy a whole other CI stack with a different SKU to take advantage of the faster components.

    June 24, 2014 at 3:17 pm Reply

Leave a Reply

%d bloggers like this: