Converged Infrastructures – Trying to Cure the Symptoms not the Disease

Converged Infrastructures (CIs) and Reference Architectures like vBlock from VCE, VSPEX from EMC and FlexPod from NetApp have seen a lot of growth in the last few years. The growth did not come as a surprise to anyone given the perception around CIs solving some of the big IT pain points around Sizing, Architecting, Standardizing and Faster time to market.

The big benefit that Vendors promised with CIs was that it would reduce time required for making infrastructure ready to provide service by reducing or eliminating the time needed in various phases like Architect & Size, Detail Design, Deployment and Test.


But what was the real need for CIs and reference architectures?

  • Growing focus of Organizations on managing applications and not the infrastructure.
    • With the shrinking IT team, Organizations wanted to reduce the time IT spent on architecting and design, deployment and testing of hardware
    • IT team looked at Vendors to solve the ever growing complexity of different layers in a Virtualized environment
    • The need for predictable performance
  • Faster time to Market
    • One of the key need was that businesses wanted to reduce the time to market and IT wanted to become an enabler, not a roadblock to the business

The Challenge

Reference architectures and CIs are a great asset but the challenge is that they are based on assumptions. Unfortunately, they help only to an extent.

In reality, every Organization has a unique requirement and one type of Converged Infrastructure or Reference Architecture can’t address the unique requirements that different Organizations have. The result is that the IT team still spends a considerable amount of time in the various phases they thought they could eliminate.


Traditional Infrastructure: Advanced Functionality = Lot of knobs = Lot of Best Practices = Need for Reference Architectures

Traditional Infrastructure: Advanced Functionality = Lot of knobs = Lot of Best Practices = Need for Reference Architectures

Reference architectures were needed because Traditional IT infrastructures have always been complex. In fact the more functionalities the infrastructure had, the more complex it was. IT Infrastructure providers never focused on maintaining simplicity with added functionality instead they kept adding these functionalities with a ton of knobs around them. These knobs had best practices around various applications and therefore the need for Reference Architectures.

Reference Architectures are not be-all and end-all for IT. Let’s assume for a moment that a configuration can be pre-designed for an Organization and shipped to them. But once it is shipped and deployed, it has to start running certain VMs and applications. Because the applications vary a lot, organizations still have to follow different best practices in terms of layout etc. getting into ongoing provisioning, tuning and management.

You may ask, how about Automation software? Automation can help with some of the provisioning and management tasks but it doesn’t help with ongoing Tuning and Reshuffling of resources, as that would need built-in analytics and deep understanding of infrastructure before someone tried to Automate. Automation has its place but it is like a Band-Aid on the complexity and multiple management interfaces that traditional IT infrastructures bring in.

The Ideal Solution

Smart Infrastructure: Self Learning = No Knobs = Negligible Best Practices = No Need for Reference Architectures

Smart Infrastructure: Self Learning = No Knobs = Negligible Best Practices = No Need for Reference Architectures

Solving the above problems needed attacking the problem at the root, starting from the grounds-up, changing how the infrastructure itself behaved. Instead of having infrastructure that became complex as more functionality was added and had no idea of what is happening outside its boundaries, this required Smart Infrastructure that learnt about workloads, tuned itself based on that, had insight across various components and brought in continuous guidance. Thus eliminating the need for best practices/reference architectures and making IT more predictable.

Ideal State with Smart Infrastructures

What would a Smart Infrastructure like that bring to the table?

  • A Smart Infrastructure that was similar to a plug-n-play appliance, would reduce the time to deploy the infrastructure
  • It would bring in predictability and continuous guidance resulting in eliminating the time IT team spends in Architect & Size, Detailed Design and Test phases.
  • Since it would learn and adapt, it would also eliminate the need for tuning and continuous reshuffling of workloads, which none of the CIs or Reference Architectures can achieve.
  • As it would not require any Best Practices to be followed and knobs to be turned, it would reduce the amount of Automation to be done.

Does something like that exist? If you have read my previous posts (here and here), you can understand my reference here 🙂

Edit: As a follow up to this blog post I’ll discuss more about what is it that you should look at in a Storage Platform beyond the Reference Architecture? What are the key things that you should pay attention to when selecting a Converged Infrastructure, that will help not only in the initial deployment but also with ongoing operations.



1 thought on “Converged Infrastructures – Trying to Cure the Symptoms not the Disease

  1. Pingback: Converged Infrastructures – Curing the Symptoms Follow Up | livinginclouds

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s