DevOps Consulting and AWS: Saving money end-to-end

Until just recently, attempting to clearly establish the total cost of any enterprise systems development usually involved wading through a number of discrete cost centers ranging from infrastructure, ops, development, quality assurance, support and administrative loads, to costs associated with various third-party activities. However, with the emergence of demand-driven, public-cloud systems like AWS; supported by new management methodologies such as DevOps, the total cost furball has been largely unraveled, if not eliminated entirely.

Part of this value assertion can be easily defined at an infrastructure level when reviewing AWS´ original design goals, as professed by Global Knowledge´s Rich Morrow;

High availability

| 01

Via geographical fault tolerance, redundancy, and horizontal linear scale – Upside: reduced universal support costs.

Auto-scaling

| 02

The ability to dynamically respond to spikes in demand and increase or decrease capacity – Upside: reduced systems admin costs.

Integrated backup and disaster recovery

| 03

Operations like recurring database backups and snapshot restores become as simple as checkboxes and buttons on web forms – Upside: reduced systems administration, and active/passive support costs.

"Infinite" scale

| 04

Users should not have to consider ever outgrowing a service – Upside: reduced universal opportunity costs.

Simple Storage Service (S3)

| 05

Allows users to store an unlimited number of objects and Elastic Cloud Compute (EC2) lets users spin up thousands of virtual servers – Upside: reduced static data archiving, reduced administration, and active active/passive support costs.

Ease of use

| 06

Modular, API-driven services that can be used either independently or with one another – Upside: reduced systems integration costs, reduced universal implementation costs.

And on the DevOps consulting side, as asserted by our own Jason Goldberg, with Stackoverdrive:

Opportunity cost reduction

| 01

The DevOps/AWS matrix encourages enterprise development cadres to intrinsically employ a constant improvement model – Upside: reduced opportunity costs derived by eliminating administrative, infrastructure loads; allows dev, ops, QA/Test cadres to focus on the rapid deployment of systems that work right the first time.

General Development cost reduction

| 02

The utilization of the DevOps doctrine calls for the elimination of management logjams between Dev, Ops and QA. – Upside: reduces time/motion end-to-end, allows for quicker practical response; creates more efficient products, faster.

Specific DevTest cost reduction

| 03

Given the global transparency afforded by the AWS infrastructure, in parallel with DevOps rapid process discipline, enterprise-scale systems development can be created and validated much quicker than ever before – Upside: reduced universal administrative, coding, and test costs.

Universal support reductions

| 04

A DevOps/AWS matrix largely eliminates, or automates, many traditional support cost components. Upside: reduces time/motion costs when effecting necessary remedial changes/updates, allows an ability to identify fix and alter processes on the fly, and establishes an ability to execute universal responses on-demand.

Altogether these cost mitigating elements, in addition to numerous other cost-saving impacts of the DevOps/AWS paring creates a reduced enterprise liabilities floor, thereby allowing a company´s development cadre to behave smoothly and nimbly, when faced with nearly any negative market pressure, or in the event that a spontaneous opportunity appears.

However, while pure cost concepts are just fine as a matter of form, a practical understanding of how various cost elements stack up is even more useful. Consequently, we´ve researched a clutch of average numbers based on legacy infrastructure and development costs, versus how the dual DevOps/AWS value might resolve.

Based on TCO totals provided by Gartner Research, and also by applying the Amazon Web Services calculator a general cost acknowledgement can be defined while utilizing a baseline company model valued at $50 million:

Global network infrastructure ownership (Legacy)

| 01

In this case, TCO is generally represented by a 2:1 ratio, or $2 spent in ownership, versus each $1 originally spent. In gross terms then this means that if an enterprise spends an average of $25 million on its original IT infrastructure, it will cost $50 million or more in affiliated monies throughout its lifetime.

Global network infrastructure ownership (AWS)

| 02

TCO here is generally represented by a 1.3:1 ratio, or $1.30 spent in ownership, versus each $1 originally spent. In gross terms then, this means that if an enterprise spends an average of $25 million on AWS infrastructure provisioning, it will cost $32.5 million in affiliated monies throughout its lifetime.

In the aggregate then – $50 million versus $32.5 million devolves to a $17.5 enterprise cash windfall.

Enterprise systems development ownership (Legacy)

| 01

TCO on the development side is a bit more complex given the number of moving parts and people involved. For example, a typical enterprise development involves a large mix of different platforms, operating within and across a hopefully cohesive network infrastructure. This means that each area of focus requires a different group of human resources. Consequently to simplify we´ll use 5 groups as a baseline including admin, dev, ops, QA/Test and support; costing $500 thousand, per quarter, or an annual TCO of $2 million.

Enterprise systems development ownership (DevOps)

| 02

On the other hand DevOps co-mingles three of the five, i.e. dev, ops, QA/Test and streamlines all three focus groups. On top of this upside these team members serve dual-purposes and therefore can be expected to produce a highly-conservative cost reduction on the order of 20% annually. So, in this model the TCO for this group annually is be $1.6 million.

And in the aggregate here – $2 million versus $1.6 million devolves to a $400,000 enterprise cash windfall.

As a result, using these very general assumptions, one can gain a fairly clear sense of just how the DevOps/AWS paring can create end-to-end value from a change from legacy to next-gen systems and precepts.