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 :

  • Application Virtualization (aka, “Write-Once Run Anywhere” –> Java VM’s)
    • + cross-platform development via Java/ JVM’s/ Web-App Containers (eg. Weblogic, Websphere, GlassFish)
  • Compute Virtualization – 
  • 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 –> VM explosion (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).

  • Network Virtualization (SW Defined Networking – SDN, SD-WAN,..)VMware’s NSX-T (Nicira acquisition), Velocloud | Citrix – SD-WAN, ..
  • Storage Virtualization (SW Defined Storage – SDS) – Converts & pools storage resources of direct attached server storage into loosely-coupled, shared block storage across nodes within the cluster.   eg. VMware’s vSAN, Dell-EMC’s PowerFlex (aka vxFlexOS formerly EMC/VCE ScaleIO acquisition)
  • The market rush to purchase low-cost commodity x86 HW (After the DOT.COM bubble burst and the 2001 Global Economic Recession).
  • 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 REST API’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  BYO (“build-your-own”) or BOB (“best of breed”) solutions was robust unified full-stack Lifecycle Management/ Orchestration of App SW, OS, System Provisioning, & Virtualization, NTM full-lifecycle management.. 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

While a little dated, the graph below clearly depicts the historic shift to fewer physical servers AND greater numbers of VM’s (Logical servers).

The irony is that what was initially viewed as a low-cost “panacea”.. (when dozens of ~FREE/FOSS KVM/Xen VM’s and x86/Linux systems need to be managed), quickly becomes a System/VM Management & Maintenance challenge as environments rapidly scale up & out, which adds more significant Linux-RHEL, & VMware/ESXi+ licensing costs (initially thought to be FREE & reduce cost).     

These hidden Support Costs for the Linux OS & VM licensing, coupled with the time & effort to maintain these growing islands of workloads running on several-fold 1-2 socket x86 Servers  (without SPOG & automation, can incur much more downtime to configure/patch 2x, 4x, 10x the number of systems and resulting VM’s), were 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 management/automation capabilities to fill the SPOG void that existed.   Today, the IaC (Infrastructure as Code, eg. Chef, Puppet, Ansible, Terraform) competition is squarely targeting this space, in addition to OEM frameworks/toolsets (eg. Dell OMEnt, Oracle OEM, etc).

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

For most Virtualized x86 (eg. KVM, VMware) deployments, over-provisioning is needed to accommodate for overhead (eg. each VM requires an independent full copy of the OS & CPU/Memory resources, +VM scheduling and layers of emulation/translation ..) inefficiencies (~12%+ per VM is not uncommon).    This is why modern Enterprise deployments of VMware need to utilize para-virtualized drivers to bypass as much overhead as possible, also one reason many are deploying/exploring Containers, which share only 1 copy of the underlying OS kernel and can run on BM without a Hypervisor layer.

Without Vertical Scalability (> 2 CPU’s) as a high-performance “tightly-coupled” & cost-effective option for larger workloads, an additional penalty for Horizontal Scalability GROWS with greater network latencies in larger “loosely-coupled” distributed environments, incurring 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 ?)
  • Performance / Latency   (Do your Service SLA/SLC’s require a very low end-user transaction response time in acceptable latency ?    This can dictate a higher cost dedicated Public cloud connection.   The same goes for Real Time expectations..)
  • 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.   Additionally, have you done a TCO study, including all tangible + non-tangible costs ? .. such as all SW / licensing, maintenance effort/time, Network ingress/egress costs, PaaS Services, etc).



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 :
  • VM migrations going over the network, need to be ENCRYPTED, and NOT able to be 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 & Disaster Recovery (durability/ Business Continuity) 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$

Combined –>   = Customer Business RISK, Overhead, Complexity, COST, & Control



A Bright Horizon for Cloud Adoption and Enablement has approached ..

Collectively, for all of the reasons above (Reduced Complexity, CAPEX reductions, reduction in facilities, staffing, etc), most organizations are today exploring the MANY private, public & even more prevalently, the Hybrid/ Multi- Cloud Deployment models & Service Offerings.    Public Cloud is still going to always be an option (AWS, Azure, Oracle OCI, Google, ..), however today the momentum is definitely targeting the rapidly growing On-Premises Private & Hybrid/Multi-Cloud space (~75% of deployments !), see below.

Additionally, Public Cloud providers are extending their deployment models on-premises with certain Hybrid-Cloud offerings (eg. AWS Outposts, Google GCP Anthos/ GKE, Azure Stack / ARC).    Also realize that most Hybrid/ Multi-Cloud solutions leverage Kubernetes (K8S).    Additionally, one of the most widely adopted solutions today for Private/ Hybrid/ Multi-Cloud is VMware’s vSphere v7 (now includes Containers/ Kubernetes) and VCF v4 (Vmware Cloud Foundation) solution offerings.

However, in the interim we should expect to see most Enterprise Mission Critical, Highly Secure, and/or Extremely High performance workloads (~70%-80+% reside On-Prem today) to either stay On-Premises, or potentially extend to Hybrid/ MC Deployment models (if able 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 from 2018 to 2020 :


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


*Continue the Conversation..

Let us know what you think.  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. 🙂

All content and comments made are that of TechThought.org, the author, and not of current nor past employers.

*Copyright© 2017-2020 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 *