From what I understand you need both a large or complex computational load and a lot of traffic before clouds should become the weapon of choice.
But Im not entirely sure.
You don’t need to physically rack servers, lots of systems integration vendors and remote hands will gladly put servers together for you. Most colos will gladly help you figure out connectivity. And there are lots of vendors, like Cisco, who will deliver a rack to your datacenter with virtualization software installed and everything, plug and play..
My point is there isn’t an either/or choice of using the cloud or building the universe from scratch, there are so many available options in-between. And while those options aren’t available conveniently behind an API and might require a few old school phone calls, you can save millions of dollars, get access to better performing hardware, have better control over data sovereignty, and 90%less lock-in if you choose to go down that road. It’s not for everyone but a /lot/ of workloads that people are running in the cloud can be done better elsewhere.
We are a company with 4 IT employees including myself, and two of us alone (both full-time programmers) handled our hybrid cloud migration. We rented a rack in a colocation facility. I learned how to design racks in a couple days and did the rack design myself. We found an inexpensive contractor who racked and stacked everything to my design, and remote hands does any ongoing hardware maintenance. The other guy had an old, outdated CCNA and he designed the network. We got a fiber connection to AWS up and running for a hybrid cloud approach. All of this was very doable for a part-time two-man team with other job responsibilities and we're saving a ton of money for database and workstation hosting--big, expensive, totally static workloads. Perfect for on-prem.
It was clear from the outset that we could accomplish this. I wouldn't have signed us up for a boondoggle. Certainly, there are more demanding configurations where the complexity would be too high, but people act like on-prem is literally impossible without a team of dedicated staff in every case. It's not.
On-prem is like that. Yes, you have all the skills to originally stand it up. But you don’t know what you don’t know, and you make a bunch of resource trade-offs, usually by not implementing stuff that you’ll never need (until you do).
That was the point I was trying to make.
As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.
As other a have pointed out, other benefits are scale-on-demand, pay only for what you use, and agility - if you have a great idea you don’t have to do a PO and wait months for a server.
AWS vs. on-prem is always a tradeoff. You have to look at the costs and benefits for your particular situation to decide which is best. We decided to go with both, because AWS has benefits for our dynamic workloads and on-prem has savings for our static workloads.
But what you described sounds like a packaging / software distribution issue.
Like, someone writes a one off Python script or program to do a thing and a year later it doesn't work because the host machine is using a newer version of Python and the dependencies need to be reinstalled to the new site-packages and they didn't document if they used the package manager or a virtualenv and a pip requirements file or setup.py or whatever.
The "it works on my machine" thing isn't really a "cloud" thing? It doesn't really solve the issue of having a weird bespoke service that nobody understands. Even if it's so abstracted from a normal computer that it has some esoteric requirement like an OCI image to run software, if the Dockerfile/Containerfile or whatever that generates the image doesn't exist/work/make sense then you have the same problem.
> As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.
Reinventing the wheel like with docker ansible terraform kubernetes nomad aws?
Recently I was asked to help a company receive out of office replies to their web service that sent mail from Amazon SES. The client was sending mail from app.foo.org (with MX SPF for amazon) and wanted to receive them to foo.org (MX and SPF for outlook). Setting Reply-To or some other headers to foo.org worked in testing but not in practice. I maneuvered the amazon product menagerie and set up SES to get notifications on out of office replies and that also worked in testing but not in fact. Even then it would not store a list or provide details in the dashboard about replies without further using lambda or SQS or something. Every deficiency in an amazon product is "solved" by another amazon product. You're swallowing a horse to swallow a fly. In the end I just added AWS to the foo.org SPF records along with outlook's and set the From header accordingly; way simpler, didn't need to any more AWS products, and knowledge of DNS is more portable than knowledge of AWS. AWS is in the business of inventing wheels and trying to get you stay in their wheel ecosystem.
Not to contradict everything you're saying like you're wrong or something. I wonder what the circus is like for those of you who run it. Everything you say reads like high-level manager/sales engineer marketing talk from someone who spends all day in meetings. Not to say I'm an authority and that your voice is illegitimate; I'm just a resentful out of touch NEET waiting for the world to change to the point that I have nothing left to offer it.
> And do it again in a different place for geographic redundancy.
With all due respect this is a trivial and misleading point of view.
Most people who do cloud don't need or employ redundancy across machines; much less so in different regions. But they do have devops teams or programmers who are required to learn bespoke cloud dashboards and AWS products. Even though most of the time they could just ssh into a box and run nodejs in screen and be 99% of the way there. Cloud providers convinced everyone that it's really hard to run a computer program. And companies set money on fire because spending signals growth, especially to investors.
Literally everything you said is the opposite of how I've seen people use "cloud" in the real world. I don't know what universe you're living in where things are as wonderful as you proclaim but I wish I was in it because mine is a nightmare.
I’ve been working in SaaS since 2008 and in cloud providers since 2012. And the use case I see over and over is people who don’t think they need or want geographical redundancy, until they do, and then they want it yesterday. Typically they are running fine for months or years and then there is an outage - maybe an AZ or a network partition - and then all of a sudden they’re scrambling for failover. Cloud often (usually?) has higher availability than the infra they migrated off of, and they grow addicted to it while not wanting to pay the dev cost for true high availability.
I've seen more region wide outages than just an AZ e.g. where AWS us-west-2 goes out and so it doesn't make a difference.
> and then they want it yesterday
Some great SaaS you've experienced. I've been at 1s that say they want it yesterday but then realize it's too much work (already in the cloud) and just let it go until the next outage and complain again but yet again nothing gets done.
Of course you’re right a VPC or a CoLo would be better. However that’s not what most people think of “cloud”
Yes it’s possible to buy your own building, and your own DS3/OC3. And HVAC. And electrical. And backup generators for the HVAC. And the personnel to design and specify the racks and the hardware in them (all of the different configs you need). And to assemble and connect the equipment. And to maintain it when something breaks. And the network engineers to design your network and deploy and maintain it.
And do it again in a different place for geographic redundancy.
And, if you have any money and personnel left, then you can think about a virtualization infrastructure (because of course who would be stupid enough to buy VMware when you could build your own open source equivalent around HVM or whatever.
And now you’ve got like a tiny fraction of what the cloud can offer. And I guarantee you that the TCO is way higher than you expected and that your uptime is a 9 or two short of what a cloud provider would give you.
I’d you are running a single cloud-scale workload (Google Search or Dropbox or Outlook.com) then you probably can do better financially with your own optimized data center. But you almost certainly can’t beat cloud for heterogeneous workloads.
And the biggest benefit of all is savings in opportunity cost as your tech people can focus on your own unique business problems and leave the undifferentiated heavy lifting to others.