Cloud is not just someone else's Computer
Cloud is not the trope you think it is
It is often said, in a derisory fashion, that Cloud is "just someone else's Computer" - which sounds almost lofty and philosophical enough to be true; but it usually isn't, if Cloud is executed correctly. Sure, we could just consume Cloud in the form of Infrastructure as a Service (IaaS) - a smattering of Virtual Machines (VMs) here, a fluttering of Load Balancers here, and maybe add in some Autoscaling Groups to right-size that fleet - but that's not where the true power of Cloud lies. Doing this is the Cloudy equivalent of buying a Ferrari and "kicking the tyres" by taking it for a run to the corner shop for milk; sure, it'll definitely get you there and back, but it's not really the intended usage model.
Really, in referring to Cloud as "someone else's Computer" you've already boxed your thinking into the lowest-common-denominator that any Cloud Services Provider (CSP) has to meet, and are at the left-hand-side of the "x as a Service" paradigm that the elasticity and agility of Cloud provides, a spectrum of:
Sure, used in the same fashion as current state of art in On Premises Information Technology (IT) - where the smallest abstraction is typically the VM (at least in the Enterprise world, Containers such as Docker are slowly getting traction, but not yet "de jure") - then yes, Cloud could notionally be considered to be a world-scale Computer that "someone else" runs, and the benefits might not be so clear. However, sticking on this lowest hanging fruit of the IaaS world, let's dig down into that a little more.
So you think you're better than Amazon/Microsoft/Google
While we're focussing on the easily-comparable IaaS (it's just the same as my on-prem VMware ESXi, right?), let's delve into what a typical CSP's IaaS VM offering gives you today, and compare side-by-side with your on-prem Environment, to make it a fair fight (you're going to win here, it's "just a Computer", you've got this in the bag):
| IaaS Cloud | On-Premises Virtualisation | |
|---|---|---|
| Lifecycle | Built-in UI/API/SDK | Built-in UI/API/Custom Scripts |
| Backup | Built-in UI/API/SDK | External Product |
| Networking | Built-in UI/API/SDK | External Product(s)/Skillset (CCNP) |
| Storage | Built-in UI/API/SDK | External Product(s)/Skillset (SAN) |
| Scaling | Built-in UI/API/SDK | Buy another box/Internal Design+Provision Process |
| Monitoring | Built-in UI/API/SDK | External Product/Mostly works(ish) |
| Alerting | Built-in UI/API/SDK | Not yet setup (too hard) |
Need I go on, you see my point here; even just focussing on the most-simple of Cloud Services (IaaS), and a few operational lifecycle facets, the distinction - more than at "just" the Compute layer - becomes a bit clearer. By far the main advantage (even at low-level IaaS) within Cloud is around the elephant in the room that facetious statements such as "just someone else's Computer" completely miss; Day 2 Operations.
Day 2 Operations - A day in the life
Sticking with IaaS, and back to our "same as what we do today, what's the big deal" angle - it should be fairly obvious from the above, and if you've ever worked in Enterprise IT, that heterogeneous vendors don't typically:
- Work well together
- Cost small amounts of money
- Implement themselves
- Become operable in small timescales
Yes, you can definitely spin up a VM on-prem in the same amount of time as Cloud IaaS; and maybe arguably you can even do it cheaper, or in a Capital Expenditure (CapEx)-friendly manner - rather than the Operational Expenditure (OpEx)-focussed Cloud world - but I guarantee you, after this Day 1, you won't be able to beat the ease of use and speed of Day 2 Operations in the Cloud. While I'm clicking a button (or better yet, have written an Azure Function to invoke an Azure VM Backup for me on a schedule), you'll be sat somewhere in a corner crying, trying to get the Storage Array LUN setup and wrangling with the Backup Automation Software that promises it was just a "one click install". That's Monday, and you've not even thought about how it's going to scale-out if you need to do this all over again for a second or third VM - or how you're going to setup the Monitoring System to look at... Oh man, it's already dinner time!
IT Systems aren't your main competence
Let's step back a bit, why is all this relatively simple IaaS stuff so difficult on-prem? Why are you even trying to do it, after all, you're an Enterprise Company doing <whatever you do to make money/serve the greater Public Good> - which likely isn't running IT or Compute - so why are you wasting your IT Department's time trying to bodge all these disparate components together, to get it to half run? We've not even gone up the stack to PaaS or SaaS offerings yet, and you're already setting your hair on fire with Day 2 Operations pain - when all you wanted to do was get <Application X> up and running, so you could get onto your next To Do List Ticket or Item.
This is the real differentiator of Cloud - and by extension "x as a Service" offerings - tightly-integrated, lifecycle-wide, ever-self-improving, unified-orchestrated Day 2 Operations that are available for (literal) pennies per hour, per instance. No on-premises Software Defined Data Centre (SDDC) is ever going to be able to come close to this - and even if it somehow does, where's your inflection point where running all the "meta" instances (Orchestration VMs, Provisioning VMs, Monitoring VMs, Management VMs, Storage VMs...) outweighs the handful of Application VMs you wanted to run?
Speaking of "run", you've obviously got specialists in each of these areas (and maybe more), and cash to pay for them, right:
- Network Engineers/Architects/Designers
- Storage Engineers/Architects/Designers
- Hypervisor Engineers/Architects/Designers
- BSS/NMS/OSS Engineers/Architects/Designers
- Backup Engineers/Architects/Designers
- SRE Engineers/Architects
- <Various ITIL Roles>
- ...
Ah, you can't get them for pennies an hour; and often they don't speak well to each other, or maybe even have competence in the shiny new Backup/Network/Storage/Management Software you just went through a six month RFP procurement cycle to evaluate and obtain...
That's just the bottom of the stack
All we've really spoken about so far is the easiest part of the overall stack - the bottom layers of the OSI Model or "xaaS Model" - we've not even gone into how complex it might be to do all of that, and then also create your own in-house Database as a Service (DBaaS)-style in-house SQL Cluster and then use all of that house of cards to do the Applicationy thing you actually wanted to do. So yes, at a Day 1 usage perspective - or the bottom of the stack - you are indeed correct with statements like:
- Cloud is just someone else's Computer
- Serverless still needs Servers
...but you're also focussing at completely the wrong element of "The Stack" - you're in the forest, surrounded by trees on fire, and trying to put out one fire on one little branch by spitting on it. You're not appreciating the wider Value Chain, or where you are in it. You're not appreciating anything that happens when you try and extract value out of all this Compute gear you've cobbled together; you've completely forgotten about your poor Network/Storage/Application Engineer, running around with her hair on fire.
You've somewhat missed the entire point and paradigm-shift that Cloud has brought to the entire IT discipline:
Cloud isn't just someone else's computer; it's someone who knows how to use and operate it much better than you do