Type to search

Conditions that led us to Cloud Computing : A Brief History & Key Considerations


Modified from an article originally published @Oracle.com on Monday, March 20, 2017 as :

By: Todd Jobson | Sr. Principal Enterprise Architect; MBA


WHAT “Conditions” led us to “Cloud Computing” ?

If you’re wondering WHAT “Conditions” led us to Cloud Computing ? .. this brief synopsis is targeted to bring you up to speed rapidly on the underlying themes and industry momentum (in a nutshell).

How did we get to where we are today ?

As you can see from the IDC report and chart below, the 2000’s paradigm shift was a rush to cut costs in a down global economy, where Capital IT Expenses (CAPEX) were the first to go.    Demand for expensive, high-performance HW (with 99.999% available RAS) became a luxury, and the new phrase “Good Enough” became the gauge that so many came to use (especially given that the majority of systems in place at the time where underutilized without virtualization, if not sitting idle as HA/Fail-over systems).

The Technology that fueled the fire that became today’s Foundation for Cloud Service and Deployment Models :

  • the rise of Virtualization technology in many areas :
  • + cross-platform development via Java/ JVM’s/ Web-App Containers (eg. Weblogic, Websphere, GlassFish)
  • OS Virtualization & Containers (Solaris Zones, BSD Jails, Docker, CoreOS rkt,.. ) leading the DevOps & MicroServices trends
  • Type 2 “Hosted” Hypervisors  (eg. VirtualBox.. for rapid agile Test/DevOps within a Host OS)
  • Type 1 “BareMetal” Hypervisors (eg. Xen, KVM, VMware Vsphere/ESXi, SPARC OVM, Hyper-V)
  • Consolidation of Workloads & Systems : together, Virtualization technology allowed companies the ability to effectively consolidate workloads (and Tenants) from many systems down to fewer (also increasing the utilization rates of those systems).
  • The market rush to purchase commodity x86 HW.
  • Mature “Clustered” App & DB SW (eg. RAC), enabling “Horizontal Scalability” without the necessity for HA Fail-Over products
  • Java cross-platform portability + SECURE Web Services adoption (and the wave of HTTP enabled protocols.. to today’s RESTapi’s/ JSON).
  • Adoption of FOSS “freeware” platforms such as LAMP : (Linux, Apache, MySQL, PHP, ..), Docker,
  • Repositories of SW, API’s, VM or Docker Images..[eg. bitnami, npm, Github, ..].​
  • +Competition, which is the BEST way to improve and advance an industry’s products, services, & pricing.

*For a more thorough examination of “enabling technology”, see my Cloud Architecture 101 article.

What Complexities & Challenges Arose ?


Unified SPOG – “Single Pane of Glass Management”

The missing piece within these “commodity”, (Custom-Integrated so called “best of breed” solutions) was robust unified full-stack Lifecycle Management/ Orchestration of App SW, OS, System Provisioning, & Virtualization, .. where VMware became the dominant player (at an ever growing, though initially hidden cost).

System Management EFFORT & COST Explosion : Complexity + VM Sprawl + MANY Vendors & Tools

The graph below clearly depicts the shift to fewer physical servers AND greater numbers of VM’s (Logical servers).

The irony is thatwhat was initially viewed as a low-cost “panacea”.. (when few VM’s and x86/Linux systems need to be managed),quickly becomes a System/VM Management & Maintenance challengethat added more significant Linux, & VMware licensing costs (initially thought to be FREE & reduce cost).     

These hidden Support Costs for theLinux OS & VM licensing, coupled with the time & effort to maintain these growing islands of workloads running on several-fold 1-2 socket x86 Servers  (incurring much more downtime to configure/patch 2x, 4x, 10x the number of systems and resulting VM’s), were together the catalysts that resulted in  the realities of the chart below.   The task became so great, that VMware’s dominance and traction grew even further, noting it’s advanced capabilities to fill the SPOG void that existed.

IDC’s Analysis of Worldwide Spending on Infrastructure vs Management/Admin Costs :

For most Virtualized x86 (eg. VMware) deployments, over-provisioning is needed to accommodate for overhead (VM scheduling, emulation/translation ..) & inefficiencies (~12%+ per VM is not uncommon).  

Without Vertical Scalability (> 2 CPU’s) as a cost-effective option for larger workloads, an additional penalty for Horizontal Scalability GROWS as greater network latencies in distributed system incur more network hops and inter-system traversing of TCP/IP stacks and protocol hand-shaking (several fold vs. all happening previously within a single system).   

For many of these reasons, Converged Infrastructure & Engineered Systems began to gain some traction to reduce these costs & complexities.

However, granted that most of these commodity Converged x86/Linux/Virtualized IaaS/SDN deployments have continued to grow.. and grow, the cycle continues .. further fueling a justification to explore alternatives to On-Premise Infrastructure.. aka Hybrid or Public Cloud deployments & services.


Key Considerations when developing your Roadmap to Cloud Enablement

This section is an excerpt from the article :  Cloud Architecture 101: The Road to Cloud Services (IaaS/PaaS/SaaS) & Deployment Models (Private, Hybrid, Public)

Before your organization boils the ocean and does detailed Discovery & Requirements Analysis, the 4 Key areas in the chart below highlight the Key Questions that you need to first explore more thoroughly in order to determine cloud “viability”, let alone select the appropriate Cloud Service (IaaS, PaaS, SaaS) & Deployment Models (Private, Hybrid, Public) :


  • Security   (Are there significant business or industry regulatory/compliance restrictions that dictate where your data can reside, or specific security needs/ controls that you must incorporate ? .. such as physically Isolated, single-tenant services, or On-Premise only requirements for Production or DR data copies ?)
  • Control    (Does your business require strict control over underlying physical Network/ Firewall, Storage and/or other infrastructure configuration details that you might not otherwise be able to manage with a Public Cloud deployment model ?)
  • Latency   (Do your Service SLA/SLC’s require a very low end-user transaction response time in acceptible latency ?    This can dictate a higher cost dedicated Public cloud connection.)
  • Cost     (Would your business benefit from having rapid capacity elasticity for peak periods that you wouldn’t have to pay for other times of the year ?    Is CAPEX – up-front Capital Expenditures buying the systems  or OPEX accounting more appropriate, where Operating Expenses are spread across monthly payments where you don’t “own” the Equipment).



Business Impacts & Considerations :

On top of the items noted above, having a greater density of an organization’s SW running on less reliable (lower RAS/ less redundant) HW, lends itself to other significant business issues (having all your eggs in fewer baskets) :

  • Security :
  • VMware VM migrations NOT encrypted.. going over the network, easily snooped.
  • NO Silicon Secured Memory, exposing systems to Heartbleed / Venum type vulnerabilities.
  • The risk of running unvetted FOSS stacks & container images (little visibility of what the level of exposure is to use public Open Source SW stacks/images)
  • Patch management requirements for 100’s or 1000’s of smaller x86 systems (each with dozens of VM’s and/or Containers), ALL of which need to be patched !?
  • Availability Concerns = > RISK & Exposure
    • due to Greater Consolidation (higher densities of Virtualized Mission Critical Workloads running in fewer multi-tenant “shared” systems, w less redundant HW).
  • Multi-Vendor Support :   Time to Identify Root causes with MANY disparate utilities & several support #’s & Organizations = Greater DOWNTIME
  • System ManagementConfiguring, Integrating,Managing 1000’s of VM’s across 100’s of small x86 servers = TIME & ! = Costs$
  • Performance & Scalability :  Linux / x86 / VMware are not Linearly Scalable = inefficiency = Costs$

TOGETHER = Customer / Business RISK, Overhead, Complexity, and COST



A Bright Horizon for Cloud Adoption is approaching ..

Collectively, for all of the reasons above (+ CAPEX reductions to reduce facilities, cut staffing, etc), most organizations are today exploring the MANY private, plublic & Hybrid Cloud Deployment & Service Offerings (AWS, Azure, Oracle OCI, Google, ..).

The future will most-likely end up primarily utilizing Public Cloud deployment models (as the capabilities begin to match what is available On-Premises).

However, in the interim we should expect to see many Mission Critical, Highly Secure, or Extremely High performance workloads to either stay On-Premises, or more-than-likely extend to Hybrid Deployment models (driven by the ability to meet compliance/regulatory/SLA/SLC requirements), as the current trends depict.


Cloud Architecture is ushering in a series of Paradigm Shifts and Emerging Technology that today’s organizations need to come up to speed and embrace asap !

A sampling of these trends are reflected in the charts below :





** See my other blogs for a more thorough examination of Cloud Architecture and Solution Offerings **.


Continue the Conversation..

Let us know what you think and please Comment and/or Retweet Below with any Q’s, thoughts, or requests for future content.

Visit our Contact page for further ways to reach out..  or participate by becoming a contributor 🙂

To contact the author directly :

All content and comments made are that of Todd A. Jobson, Sr., TechThought.org,  and not of current nor past employers.

Copyright© 2017-2019 Todd A. Jobson & TechThought.org ; All Rights Reserved *


You Might also Like

Leave a Comment

Your email address will not be published. Required fields are marked *