Contents |
Summary
At scale, CIO's will find that it's between 8-23% more expensive to place infrastructure function into application stacks than it is to manage storage function at the array level. This is not to say it doesn't make sense to pursue an application stack approach - but practioners should do so with an understanding of the costs and business value such a strategy will deliver.
This was a major finding discussed at the March 23rd Wikibon Peer Incite Research Meeting. Based on in-depth research with more than 20 practitioners and extensive financial modeling the Wikibon community debated the merits of a shared hardware-oriented infrastructure versus placing function in application stacks. Notably, small and mid-sized customers that don’t want to deal with complex infrastructure will often find it more effiecient and less expensive to place function into application stacks; underscoring yet another ‘it depends’ dynamic in IT.
What is Meant by Application Function?
The Peer Incite discussion evolved around the topic of infrastructure and specifically, should infrastructure function reside in application stacks or hardware. Function was defined as a functional capability that supports a business application. An example is recovery. The example given was should recovery capabilities be designed into, for example, Oracle 11g or Exchange 2010 or does it make more sense to place that function in, for example a storage array.
Research Background
Wikibon interviewed more than 20 practitioners in support of this research. Participants included CIOs, application heads, infrastructure professionals and technical experts. The following excepts summarize the statements made by some of the participants:
CIOs
“Infrastructure is evil. It needs to be simpler.”
“I am the CIO, I am not in the hardware or software business I am in the business to deliver business value (grow revenue, reduce cost). Speeds and feeds are nice but what does it do for my business?”
“We used to have one of everything where businesses made decisions independently-- but that didn’t work. Users want dialtone and to provide that we have to unify our business model on a standard set of IT services.”
“If a vendor can really save me money I’ll listen. But I need to understand how I get from where I am today (point A) to where I’m going tomorrow (point B) without jeopardizing the business.”
Application Heads
“What matters most to me? #1 Availability; #2 Availability; #3 Performance; #4User experience. Cost? Sure; cost is important too.”
Infrastructure Heads
“A well-defined services model cuts costs and improves services to the business. It also shuts vendors up– they can’t disagree with it, they can only comply (if they want to sell to me).”
“We have very informal chargebacks and the businesses pretty much do what they want. Of course we end up paying for it.”
Top Five Findings
At the Peer Incite we discussed the major findings of the research, specifically:
- There was a clear desire from executives to simplify infrastructure. Practitioners are pursuing two broad strategies: 1) Build infrastructure services into software stacks (e.g. Microsoft or Oracle); 2) Standardize with a common reusable set of services.
- Oracle, from a business resilience standpoint has a more credible approach but Microsoft is a force within the application development community, especially in mid-to-smaller businesses.
- Organizations that use chargebacks are much more receptive to an infrastructure services approach.
- CIO’s care about risk and business value; Application heads are focused on the end user experience, speed to deployment, business flexibility and business value received; Infrastructure heads care about service levels and cost.
- Cloud adoption is limited to virtualization. CIO’s are very cautious about bringing legacy apps into the cloud. But business lines are all moving to the cloud and the trend toward outsourcing to the cloud has been accelerated by 12-18 month due to the economic downturn.
Key Data Findings
We presented and discussed the following key graphics:
Application- vs. Array-centric Strategies
Figure one depicts the choices organizations are considering broadly.
- Organizations are either placing function in application stacks or standardizing on a shared services model
- Organizations with chargebacks tend to favor the latter approach
- Application heads have greater influence and decision-making authority in organizations pursuing an application stack approach.
- Both approaches are viable however at scale, application-centric strategies tend to be more expensive.
A Model for Infrastructure Services
Figure 2 presents a model of infrastructure services developed by John Blackman and presented to Wikibon when he was an architect at Wells Fargo. A similar model has also been deployed in his current environment at a large grocer. The cube presents a three dimensional model of 1) Infrastructure components; 2) Availability levels and 3) Performance Groups. The intersection of the three dimensions is a service that is priced and delivered to the business.
- The approach has the benefit of simplifying infrastructure decisions
- Not all applications can be serviced from the cube (but 80% probably is a reasonable estimate)
- Such an approach can save more then 20% at scale relative to an application-centric, bespoke approach
- Often such a model will create tensions within application groups and business lines.
- Notably, this model will not satisfy 100% of applications in the portfolio-- 80% is a good target for practitioners.
Comparing the Cost of DAS v SAN
Figure 3 shows the cost per TB per month of three scenarios: 1) An Oracle 11g workload running DAS; 2) A mixed SAN workload and 3) A Microsoft Exchange 2010 environment. The figure shows cost on the vertical axis and scale on the horizontal plane. The model shows that in small environments (e.g. less than 750 seats), DAS is cheaper than SAN for Microsoft Exchange 2010 but above 1000 seats, SAN is less expensive. Oracle, due to exceedingly high license and maintenance costs was not found to be lower in terms of TCO.
- Data accounts for capex as costs depreciated over a 48-month period or lease costs.
- In no instance is Oracle DAS less expensive than SAN due to Oracle’s license fees at $20K - $30K per server.
- SANs of 20TB and under assume iSCSI SAN.
- Larger SANs use EMC CX (100/200 TB) and V-Max (500/1200 TB).
- Includes incremental server and software license costs to accommodate increased compute requirements.
- SAN is a fungible asset that can be shared across the application portfolio and is less expensive at scale.
Figure 4 shows the drilldown of Figure 3 in a 200TB example. The model developed uses a return on asset methodology to capture metrics for installed assets as well as new gear.
- At 200TBs, a One-off model is 15% more expensive than a storage services approach
- The efficiency improvements from a storage services model at 20TB and up range from 8-23% relative to a One-off approach
- The ability to share resources across the application portfolio is the key enabler.
Advice to Practitioners
The Wikibon community agreed that pursuing initiatives that simplify infrastructure was commonsense business, however not having a simplification strategy (either application- or infrastructure-centric) was imprudent. Generally, at scale an application-centric approach will be more expensive than a shared services (e.g. SAN) model. However an application-centric approach can often deliver outstanding business value, especially in the area of database recovery. Pracitioners are advised to ensure adequate business value when pursuing application-centric approaches and justify the added expenditure.
In addition, in smaller shops, the application-centric approach is sensible as it removes the complexities associated with shared infrastructure such as SAN. Further, organizations interested in pursuing a shared infrastrucutre approach at scale should obtain a clear roadmap from their vendors as to how existing infrastructure will be migrated and how organizational risks will be mitigated. As well, users should push vendors to provide reference architecutures and proven solutions to further limit risk and speed deployment.
Action Item: Organizations must actively initiate simplification strategies as one-off/bespoke infrastructure approaches will increase costs and deliver hard-to-measure business value. Application-centric approaches should be pursued with a clear understanding of ROI and business value while infrastructure-centric strategies should be designed to facilitate technology migration. By accommodating these simple parameters, organizations will limit complexity, improve service levels and limit lock-in.
Footnotes: Related Research
- Why Microsoft's Head is up its DAS
- Infrastructure Wars
- How Google Apps Threatens Microsoft
- Should Exchange 2010 use DAS or SAN
- Should Storage Services Reside in Arrays or Application Stacks
- A Storage Services Approach will Streamline Infrastructure Delivery
- Comparing Return on Assets (ROA) to Return on Investment (ROI)