This is not what we're seeing (disclosure, I'm a founder at a cloud-cost management startup). Momentum is still towards the cloud, with some exceptions, given the amount of talent available to deploy there versus on-prem. The "move" to on-prem is like the "move" to alternate or hybrid clouds: it's a negotiation tactic with AWS et al.
When it's time to negotiate your enterprise discount program, savings plan(s), etc., etc. you need leverage, and that's what this is. Some companies spend multiple hundreds of millions of dollars with AWS alone and at that cost any and every tactic to bring down spend will get deployed.
Even with the discounts, savings plans, multi-year commit discounts, etc., the cloud costs are absolutely absurd if you are running stable applications where you understand the future growth, use, and demand. Yes, the cloud is the right place for 99% of apps out there, but the market is sending a clear objective out to all tech companies: become profitable and build a sustainable, high margin on your products. Every maturing company with predictable products must be exploring ways to move workloads out of the cloud. AWS took your margin and isn't giving it back.
Dropbox (from the a16z article) to me is the exception that proves the point.
What percentage of COGS is your cloud/infstracture spend? If your products don't look like cloud infrastructure (aka Dropbox), it better be very small. If you think cloud is costing you 1000% what it would cost on-premise, that's almost certainly a spend and architectural discipline problem, not a cloud problem.
Whether that's an important saving or not changes from business to business, but anything less than 1000% seems only achievable by customized discounts from the cloud provider.
I feel like this is comparing some cost-optimized on-prem scenario with a "idgaf, I'm prioritizing growth over cost savings" cloud scenario. Every company I've worked at has been way more concerned with growth to the point that the cloud spend is wildly careless, but we could easily reduce it by a factor of 10 with dramatically less effort than it would take to move on prem.
Is saving 50% also a worthwhile goal at expense of being on prem, and all the downsides? Asking honestly because that’s where my business is in terms of the decision. We won’t save 90% but we will save 45-55%.
Is your company experiencing rocketship growth or are you at the point where your growth has stabilized to a modest figure? It's probably best to pursue growth over cost savings, if possible. But not every company is in a position where a few more features can double revenue.
Still, I think it's hard to justify going anti-cloud in an effort to cut costs. Without a very skilled and experienced team doing the migration, the end result is very likely to be some hybrid setup that's the worst of both worlds. Especially if you're using a managed service, the open source alternatives might not be the drop in replacement that they claim to be.
Is your spend 2% of revenue? 5%? 50%? Saving 50% of 2% is almost certainly not worth the risk. The bigger your the percent and your revenue the more likely you should do it. Dropbox again is a good example.
There are a lot of variables, but unless the 50% savings isn't much more than enough to hire a very good ops team, then no, I can't imagine that is enough savings to make the trade-off worth it.
Remember that the choice isn't simply between AWS and racking your own gear. You can make big savings by just renting Linux servers from hetzner or similar. They install and repair the HW, you get ssh access just like with a cloud VM. You just have to make sure to monitor it so if there's a failure you can file a ticket to get components swapped out.
Speaking from a dev perspective: I prefer the cloud. There's less red tape to getting infrastructure provisioned if you work on a team that's outside of core product. Managed services give you access to serious compute capacity by filling out a 5 minute wizard.
Plus, most jobs today expect cloud experience. So there's an incentive for developers to push to use a cloud so they can grow into their next role.
> There's less red tape to getting infrastructure provisioned if you work on a team that's outside of core product.
This here is the compelling case for the cloud. It was always less about the features and the money save, it's that I now have 1 stop shop vendor, if I need a queue I can spin it up in 10 minutes, instead of filling out a ticket to internal IT getting them to put it on their backlog waiting until they have the cycles, and in the meantime I'm sitting on my thumbs.
I need a new server, in the old times it was a ticket, a budget meeting, two or three levels of sign off, a business case, on and on. Whereas in AWS or Azure I can spin up a box in about 20 minutes and be all ready to go, and happily start developing.
Just like MS was never about technical excellence, it was about being a pre-approved vendor that had everything you needed, so you wouldn't have to go through another vendor approval process. Same with the cloud now scaled down to a team size, I now know I am pre-authorized to spin up X number of resources without having to worry about security throwing a fit, or blowing an enormous amount of money.
>"There's less red tape to getting infrastructure provisioned"
Because companies do not like things going into assets category. Instead rent dedicated servers on Hetzner or wherever else it is price competitive and see red tape disappear.
>"So there's an incentive for developers to push to use a cloud so they can grow into their next role."
This is very lame argument. I am developer and a business and do understand both sides but sorry I run a business to make money, not to give them to Amazon and definitely not to be playground where developers can play with Amazon tech at owner's expense.
Because the claim is predicated on the wrong thing.
A company like uber is not looking at the price of a server but looking at the TCO of the products living in multiple verticals. TCO includes many things.
> Even with the discounts, savings plans, multi-year commit discounts, etc., the cloud costs are absolutely absurd if you are running stable applications where you understand the future growth, use, and demand.
This is true, but it doesn't preclude use of the cloud.
The core of the cost issue is, in my view, that software is still designed to run in a datacenter: always on, all code in a single process (yes, this includes microservices), expected to never stop mid-execution. That made sense when you owned the hardware and needed to fully utilize it for the duration of its life. This prevents the best cost-saving measure in the cloud: turning it all off.
People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank. Software development practices have to change, and in the meantime the cloud platform providers are going to make a pile of money as companies shift legacy software to the cloud without the needed re-architecture. We need frameworks and other technologies that, similar to the abstractions we now have for memory management, multi-threading, asynchronous I/O, etc. relieve the burden of reasoning around distributed, disjoint processes from the developer. Then we can finally realize the ideal of "only pay for what you need".
> This prevents the best cost-saving measure in the cloud: turning it all off.
However, the cost calculation is weird when you factor that 2 hours of cloud "on" can often pay for an entire day of "on" for a normal server.
All else being equal, which I'm aware is a contentious/controversial notion in of itself, even if I personally believe the colo costs for headcount are often greatly overestimated.
">People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank"
Alternatively do what I do (example of particular product I developed and nor run for a client):
Single exe in C++ talking to a local Postgresql database. Combo is capable of processing thousands of requests per second sustainably without breaking sweat (this will cover business needs for a next 20 years). Also standby always on server with replication. Daily backup to on premises backup server. Hardware for production and standby is dedicated 16 Core AMD with 128GB RAM and 2x4TB SSD. Each rented from Hetzner at about $100 each. Fronted by Clouflare, not sure about the price as Client pays it. All deployment / management / maintenance / backup / Point In Time Recovery is done by couple of scripts. Reinstalling whole thing on a totally new server takes running single script for about few minutes (at some point will take longer as the size of the database grows but would still be very manageable).
The cost on Azure for the equivalent processing power and features accordingly to their calculator is 10 times more.
This is great. Well most companies I migrate to the cloud are not running a single workload that fits on a single server.
Most companies that save a lot by moving to the cloud are the ones which have several workloads, multiple products, teams, and verticals. They got security requirements, compliance, logging requirements to name a few.
So yeah, if you only consider a most basic business that has a single website with a single use case and non of the above then Hetzner is a great option.
This is why there are containers and you can rent multiple servers as well if there is a need. Security requirements have nothing to do with being on the cloud. You just basically have to encrypt data at rest and satisfy couple of other things to get your SOCS2 label. Did it, no sweat.
>> but there are ways to utilize cloud infrastructure without breaking the bank.
You seemingly refer to a discounted mode of execution in AWS where your servers can be pulled off at any moment and there is no uptime guarantee. That only works because few use this mode. If everyone starts using it, the discount will disappear.
I haven't see that work out in practice, I've suspected that's mostly marketing fluff at this point. Anyone have counter examples?
We considered autoscaling web backends once. You've got to worry about capacity issues. You don't want a load spike only to discover EC2 has run out of the instance type you use. I've seen that issue 3-4 times in AWS now and it's painful when it causes downtime. Your app needs to have spikey load for the pricing to work, for us, even a strong day/night cycle didn't give enough "off time" to cover the higher hourly prices. Cloud vendors give steep discounts for always on usage. Your load also can't be too spikey, as spinning nodes up and down takes time. Making nodes start quickly can be a dedicated project.
I think we also looked into moving CI/CD servers to on demand, but some engineers worked too late into the night and others were up early. IIRC the "off period" was long enough to provide some cost savings, but not high enough to justify engineering cost.
Something like Lambda doing a "scale to zero" with a generous free tier looks cheap, but if you ever need to scale up you'll find it's quite expensive and your stuck with a weird architecture that's hard to move to something traditional. It is cool when an app fits the Lambda free tier, but that's not a good model for companies paying very large cloud bills.
The problem is that someone needs to do capacity planning, someone needs to buy servers. AWS has to pay the cost of an unutilized server by... keeping the hourly cost of on demand servers/cloud functions high.
> (disclosure, I'm a founder at a cloud-cost management startup)
Isnt it natural that your service gains more users at this time when everyone is trying to cut down on cloud costs... Cloud usage may be declining, but those who are still using it would want to cut costs...
There is still a lot of momentum because the 2nd and 3rd wave have yet to be burned.
Pre-COVID I was a at a F500 that had gotten screwed pretty hard by an Azure deployment than ended up costing TONS more than anticipated. Even after we made it clear it would be a lot of OpEx. "Sales engineers gonna play games" -- and they did.
New gig is just going down that path, and is, go figure, seeing the same problems. Burned by Azure, and now getting bilked for every last dollar by GCP.
Also don't underestimate the resistance of employees who built their careers only ever knowing how to do cloud - they'll make sure the cost reports and plans are always doctored in a way that cloud wins because that's the only way they know how to do their job.
> Also don't underestimate the resistance of employees who built their careers only ever knowing how to do cloud - they'll make sure the cost reports and plans are always doctored in a way that cloud wins because that's the only way they know how to do their job.
Seconded. We called in Accenture to tell us if we should do the cloud.
They said Yes. I was on the Solutions & Architecture team, and we asked to take a look at their numbers.
Found multiple errors in their spreadsheets. Math being straight up incorrect, or calling out pricing that didn't match what our SaaS sales guys gave us.
"Oh they're old reports". Okay fine, run them again with the new numbers, and slap the recent graduate who you forced to make this excel.
Again, the numbers came back strongly in favor of Azure. Took a look again, this time had some fruity macro and pivot table, and we couldn't clearly make out what they did to get their final $$$ figures.
3 months later we declared we were "cloud first". There was much speculation as to how much $$$ the directors and VPs got. In a different life I was in sales engineering and there was an unspoken rule about "referral agent fees" to 3rd parties who help us close deals...
It's often been the case that the late adopters of the Adoption Cycle show up after the early adopters have moved onto the next adoption cycle.
With computers it's also usually the case that the Late Adopters show up in the middle of the Trough of Disillusionment of the Hype Cycle.
It takes a long time for new trends to percolate through the management class. I had a gruff old engineer at an early job who used to joke that one of the executives must have gone in for a dentist appointment and read the 5 year old tech magazines in the waiting room, because we have a new initiative to start doing something that other people are already stopping.
This isn't remotely close to being accurate (backlash!). There is at least another 10-20 years of further, significant growth left in business cloud services before any meaningful turn back is/might going to occur. I have no personal stake in either direction, however when something is expanding the way cloud services continue to, and then to pretend there's a backlash occurring, it's quite silly. Some use cases don't make sense, some expenditures don't make sense, some data privacy risks don't make sense - that's not the beginning of a backlash, that's just standard business assessment.
We've hardly even begun the meaningfully productive AI side of cloud services for business, and that's going to be gigantic. TechCrunch is doing the equivalent of declaring the backlash against the Internet has begun, circa 2001.
Honestly, DHH and Basecamp have both struck me as being kind of old news for a while now. And he's the only other person I've heard making noises about the cloud like it's a bad thing.
I'm no expert, but I'm amazed how much server you can get for little money from a discount provider like Hetzner vs AWS. There's a large gulf between fully on-prem and using Azure/AWS that doesn't have the same personnel requirements. If business apps can be self-hosted on a dedicated box that's maintained by someone else, it's potentially a huge savings. At least, that's been my experience.
With Hetzner VMs and k3s one could run a k8 cluster with amazingly low cost. There are even ready-made repos that make it lighting fast to deploy and easy to maintain...
This is a real truth I've come to learn. I've worked in NOCs and the number of people on the planet who can successfully run on-premise hardware is... low.
Not to take a negative view, it's just an unsexy skillset and doesn't attract a lot of talent and attention.
Trying to hire for folks who can gracefully manage on-premise networks, power, and hardware is possible and extremely challenging. "Cloud," as it is today, is here to stay.
If nothing else, it seems a lot more stressful to be “the guy” when the storage/network/other catches fire and you are the one to deal with the mess. People already expect software to fail all the time, and there are reasonable ways to rollback in an emergency. People are far less tolerant for infrastructure failures.
I recently noticed a job posted, for cloud and on prem. Likely, the goal being high compute/large datasets on site, cloud otherwise.
The primary focus of this purely infrastructure position, is a coding take home. Now, infra as code is part of local cloud, but there is sooooo much more to handle.
But because they have no idea how to handle infra, they seem stuck thinking it's just a dev job. Even while they hire stating it is not.
Quite sad. So much knowledge lost, that they don't even know what to look, what to hire for.
The amount of people who knew how to run on-prem hardware even 50 years ago was fleetingly small, we have literal schools and training pipelines to skill people to run on-prem systems. The salaries offered are enough of a carrot to attract a sizeable workforce that pays for most of the cost of this education. Paying this workforce is not a sufficient burden to make on-prem non-viable.
I've been hearing this "Cloud will DESTROY on-prem because on-prem skills don't exist and standardised cloud technologies make it easy to hire from anywhere across the world!" narrative for years which seems to deny the reality that we managed to train people to run datacenters just fine for decades even if people are snobbish about the riff-raff running things these days. Larger companies long ago figured out they could work with schools to develop a mutually beneficial training and employment pipeline. A lot of managers seem to be too lazy to do such things and find it easy to simply delude themselves into thinking cloud is always the best choice instead of contemplating doing hard work like that.
Paywalled so couldn't read. Does this article mention who is doing this or give any numbers? I'm at a large, top 10 software vendor and this is not what I'm seeing at all.
The (wrong) conventional wisdom is that cloud is easy, simple, cheap and requires no investment in complex systems management. This is what your CTO likely believes.
In fact cloud is often complex, requires lots of highly specialsed systems management, is under powered and very expensive.
9 cents per gigabyte out if you’re lucky - that’s a startling price.
Machines are old and out of date and left behind.
Vendor lock-in is a real problem .. you probably can’t exit even if you want to.
And worse, clouds often don’t even have the computing resources you need with “requesting quota” and waiting for your “quota” to be granted some time in the next 24 hours, the opposite of elastic and scalable.
And if you need GPUs then the news for you is that gamers have vastly more powerful GPUs at vastly lower cost (even with Nvidia and AMD fleecing consumers on their next generation cards).
Rent a bare metal server from a second or third tier player. Or buy a couple of fast fiber connections and buy some 16/32 core machines with 128 gig Ram.
And honestly it’s not hard to run modern Linux machines, that’s an old crones tale.
requesting quota: poking the SRE or sysadmin to troll up and down the aisles of the colo datacenter sometime this week to find a QEMU hypervisor thats underprovisioned to the tune of $cores/$ram you want.
On AWS the default quota for GPU instances is ZERO.
Recently I had to do some performance testing. In the past I would have quickly started 5 or 6 instances of different types, run my performance tests, shut them down and be done within 2 hours.
Since AWS introduced zero quota GPU instances, I had to request quota for one specific GPU instance type in one region and then waited 24 hours till it was “approved”.
At that point I completely gave up on AWS as being a viable part of any GPU architecture.
It gets no less scalable or elastic than that.
I literally could have gone to the shop and bought a fleet of machines and built them at home in the time it took AWS to approve a quota of one GPU instance in one region.
But then you'd be back to paying pretty much cloud-like costs for your infra. The vmware suite (and similar tools) pricing is often not taken into account when comparing on-premise to cloud, which I find pretty ironic considering how much we talk about the hidden costs of the cloud. And the (crazy high) costs are usually tied to the numbers of cores/sockets you run, so not necessarily cheaper to scale.
Why not just run IaaS on the cloud? Maintaining a datacenter is expensive. Now I’m not sure if there are companies that provide management of actual physical infrastructure - battery backup, generator, cabling, certifications of premises etc.
Came here to suggest this - I'd have first run the numbers if running on a desirable cost IaaS to see if that was a comfortable middleground. It still amounts to self hosting everything yourself, except for compute, networking, storage - the basics (which are deceptively difficult when you account for secure access). And you get nice APIs to automate with still. Don't get me wrong, it might end up being more expensive at a threshold still, but do you really want to do your own... everything? Load balancing, DNS? What a total waste.
That said, some hardware companies have APIs to do most of that stuff - a little human runs out to fulfill your request if need be in some cases I think. Still like... much to worry about.
You drop off the box and they wire it up and give you remote console access. You can even schedule an on-site meeting with your equip as needed. Some colo partners will also keep replacement parts for you like if a disk or power supply goes bad.
You can usually pay the data center staff for their time to push a button or connect a few wires. Seems expensive at first when they quote you 50€/15 minutes but often way cheaper than somebody driving there and going through security to do the same.
Unless you don't want strangers touching your assigned rack, then you need to bring the key.
In addition to the other comments, after it's up & running some colos will also offer "remote hands" assistance, like replacing a failed drive. In that case ideally the enclosure will or can be made to make that slot's LED red or something so they know exactly which drive to pull.
As others have mentioned, there's usually a remote hands feature that you can contract out. If you wanted to, many colos will rack and wire up all your equipment for you, for a cost. It really depends on how much you're wanting to offload on to the provider. They might do it all for you, they might just give you a cabinet or cage with power and a network drops.
So much this! PXE is apparently too hard for engineers to learn to bootstrap a VM, but they'll go to $5k worth of training to learn Terraform to deploy a CRUD app and call that a win :/
I mean, PXE and bootstrapping VMs aren't even close to being what people use terraform for. VM provisioning, in general, is basically just one of the many (and also most trivial) steps in the usual Terraform deployment.
Most terraform flows are just as trivial as any workflow, create/update/delete of infrastructure. Not like we haven't had a hundred frameworks to accomplish that over the last few decades of onprem. Short term enterprise memory just believes there's only one way/place to do that now.
Didn't see your reply - but terraform can do a bit in the space of multi-cloud provisioning. I say a bit, because most of the work will be on the user, as your terraform plans are gonna be -MESSY- to support multi-cloud. It really isn't seamless or easy in my experience. AWS and Azure operate with enough differences that you'll have more exceptions to your workflow than actual steps. I find multi-cloud to be burdensome and an awful experience in general sadly, even with the "best" tools.
I’m not new gen. I’ve worked in telcos providing 5 9’s infra availability. A datacenter is not just servers. There is a whole host of civil, mechanical and electrical engineering that plays into it.
Edit: also OSHA rules, cable splicing, how to handle ladders, etc, etc.
Yes. I know, I work for a telco and have worked with central office switches and telco edge clouds. I know what goes into designing a data center to maintain 5 9’s availability. I don’t think it’s a level of complexity most companies need though.
So to your point it’s how the internet is run. But your midsize enterprise isn’t a telco. They have no expertise with this stuff.
> 9 cents per gigabyte out if you’re lucky - that’s a startling price.
For plain S3. Other methods have lower prices. All methods have automatic volume discounts and almost everyone has a free tier.
> Machines are old and out of date and left behind.
A problem I've seen on every single VM stack, regardless of where it is hosted.
> Vendor lock-in is a real problem .. you probably can’t exit even if you want to.
Build your model first, then map it into services, don't start with the services and map your model based on them.
> And worse, clouds often don’t even have the computing resources you need with “requesting quota” and waiting for your “quota” to be granted some time in the next 24 hours, the opposite of elastic and scalable.
I've only experienced this on services that have a potential for abuse. DNS and SMTP being all that I can remember.
> Or buy a couple of fast fiber connections and buy some 16/32 core machines with 128 gig Ram.
And "requesting quote" isn't a delay item here? I don't know anything about fiber, how to price it, or how to receive it... and the capitalization process on all this is going to eat up a bunch of my departments time.
> And honestly it’s not hard to run modern Linux machines, that’s an old crones tale.
It's much easier to just run a lambda. It's a great compute environment. It does 90% of everything I've ever needed.
> And honestly it’s not hard to run modern Linux machines, that’s an old crones tale.
I totally agree with that. I'm a dev, not a sysadmin. But I run several Linux servers and can set up the network(s), the firewall, the apps and all that. It's not that hard.
You can buy incredibly powerful machines today at a very cheap price. The 20 cores Asahi Linux ARM workstation, 128 GB of RAM recently posted here comes to mind... In the blog's author's word: "The Mac blew the AWS c6g.12xlarge Graviton instance with 48 ARM64 cores instance out of the water."
Or this slightly older blog entry about someone running 25 Gbps fiber to the home. Not to the office. Not to some colo. To the home. Sure, it's not available in many places, but that's quite something. That is someone, at home, having a personal pipe wider than what cloud instances do provide to most.
Heck, my brother, a poweruser (not a dev), just assembled a 7950X / 64 GB of RAM with a 4090 GPU. I think many, used to their laptops, don't realize how powerful such machines are (laptops aren't exactly known for running 4090).
It's honestly a bit insane to me that several devs have, at home, wider pipes and faster machines than what their apps are going to be deployed on.
I'm "only" at 2 Gbps FTTH and don't have a particularly fast machine (just ordered a 7700X / 32 GB of RAM / WD SN850X Black as suggested by someone else here yesterday) but even that is sufficient to make me question a huge lot of cloud instances offerings.
Both cloud and traditional datacenters have been growing for the last few decades. These "Cloud DESTROYS on-prem" and "on-prem DESTROYS cloud" articles are tiresome. Companies will do whatever saves them the most money.
I feel like the cloud backlash has been begun-ing since I heard of cloud, just like the container backlash has been begun-ing since containers became popular, I also fondly remember the systemd backlash, that was awesome. Personally, I'm still waiting for the object-oriented backlash that started begun-ing before the others to finish begun-ing.
I'm not really "out there" and "with it", but it seems the move has been away from classic OOP for a long time now. I never see new projects try to have the inheritance tree's that C# or Java have. I think small simple objects can be fine. It's when you get into metaprogramming with templates and multiple inheritance in C++ that I want to just run away.
I call that "90s era oop", probably because I got into programming in the 90s and quickly learned that it's considered bad. So from my view this "move away from classic OOP" has been occurring for my whole professional career (20 years now) and I think it's probably more a matter of individual ignorance (mine included - hence '90s era) rather than an actually changing state of the field.
Agreed, nothing to see here. I’d be happy to see more on-prem but my suspicion is companies are looking to cost-optimise their cloud infrastructure or negotiate better contracts, rather than a serious amount of industry movement to on-prem.
Good luck moving back to full on-premises. I think that in the last 10 years some people forgot how many problems you can have when you self manage a dc, or when you just “rent a couple of servers from somebody”.
Sure, hybrid approaches do work; keep your main infra in the cloud and supplement it with some cattle rented servers (that can fail with no prod impact) to handle predictable workloads.
But think it very thoroughly before getting fully back to “on my premises”. You’ll discover a world that you never knew it existed.
That's a good point, also unless they set up a hypervisor like proxmox, the cloud probably has their technicians used to just vaporizing problematic VMs and clusters, and easily extending and deploying new machines, which is so much more time consuming in the physical computing space.
EventBridge is probably a better option than cron. Unless you’re doing something crazy, you’ll be in the free tier. And if you need some compute, Lambda is right there (probably also in the free tier). Just keep an eye on CWL retention.
Love the idea that a bunch of managers who failed to control their cloud spend are now blaming the cloud for their failure to control costs. The problem isn't the cloud it's that they are just wantonly spending money without the proper controls / cost containment. In 5 years once they've figured out to do that properly they'll be migrating stuff back to the cloud, because all they are doing by migrating out of the cloud is converting the cloud spend costs into paying for more personnel to manage or develop features they would otherwise get for free in the cloud.
Cloud is a no brainer when you’re in growth mode. In that scenario, you’re always wasting incremental money in capacity by swinging from feast to famine.
For the parts of your business that are steady state, cloud can be dumb, if you care about spend. At any significant scale you can trade flexibility for control and reduce cost. The other benefit is capex vs opex and how that affects your taxes - cloud makes it easier to shift to a pure opex model, but it’s not an exclusive ability.
It depends on you however. It’s almost always a good deal to buy Office 365 or Google. If you have a heavy cyclical business, it’s probably smart to rent vs buy compute. Pay AWS October-December and turn everything off in January.
At the end of the day, any CTO who has religious beliefs about this stuff is an idiot. Execution and cash drive these decisions.
Moving applications on-prem kills its 'steady-state' status during the transition.
Plus there's some 8 fallacies going on here. The Cloud Providers generally make it very expensive to have some of your stuff in the Cloud and some on-prem. That's a challenge for most businesses, which I typically assert should be about 80% boring and 20% volatile/dynamic/interesting/on fire, because that 20% can soak up a lot of fees on chatter between the two classes.
That's by design. They want you all in or all out. They don't want you going back and forth. Whatever that was originally informed by (eg, the costs of their wires into and out of the Internet), that's where we are now and it seems to be considered a Good Idea.
If they change that they might keep some customers, but they'll also give others an easier exit strategy.
If cloud is only expensive when done poorly and it's not easy to do properly, then that's actually a problem with cloud.
If managing cloud is skill-intensive and you need a hire a person/team with specific skills in it, then you're no different from on-prem from a personnel perspective.
And those are growing pains. In 5 years time, maybe the proper controls/cost containment will be easier because we've seen how easy it is to fuck it up.
What's easier - managing cloud costs or managing a datacenter or co-located physical hardware and setting up and maintaining all the functionality you need to do proper CI / deployments / monitor uptime / data analytics?
With modern hardware the two are in practice not very different. You set up a server for your hardware to boot for to install the OS, tie it into your orchestrator of choice, and your users see the same thing. If a server fails you treat in instance failing, diagnose via IPMI, and either take the server off or reboot/power cycle (remotely, via IPMI), or tell your hosting provider to swap in new drives. If you spend more than a single digit percentage of your devops effort managing hardware in a co-located setup vs. doing the same higher level things you would in a cloud environment, you're doing something wrong.
All I'm saying is that most people are used to doing one and one is relatively new.
We're comparing an ideal version of cloud to practical versions of on-prem. When the ideal version becomes practical, it might be a no-brainer. But for now, companies are going to have to do what's best for them today.
I think the solution is midway: rent dedicated servers from hosting companies that handle the co-location, hardware failure and all hosting-specific issues.
So you run your own services on their hardware (as opposed to using cloud SaaS, where you rent both the hardware AND the service).
Competence isn't an unlimited resource. On-prem is nearly impossible to run without regularly taking your servers or storage or networks down with incompetent staff. Cloud costs will make your eyes water with incompetent staff who decide to run everything 24/7 on over-provisioned overpriced vms. At the end of the day "but if we had awesome staff (that also didn't ask for too much in salary) it would be like this and that" is an academic consideration because that's not the hand we're playing with.
Cloud is also so centralised that even if everybody collectively got better at optimising costs there's a serious risk that cloud vendors would just collectively fatten their margins. The inverse is also true, if on-prem suddenly became much easier to run, expect licensing and hardware costs to start creeping up from anybody with anything resembling a monopoly or cartel.
While there are plenty of folks who have reason to push a repatriation narrative, and there will always be examples (Dropbox!), I'll believe it's real when cloud providers like AWS and Google start eating into their considerable margin and begin meaningfully dropping prices again.
Hybrid was always going to be the end state of the cloud computing model. And it's not like the large cloud providers are being cut out in any way, like the title implies. They themselves all offer first class on-premises deployment and connectivity support as part of their offerings.
I think some mix two on-prem concepts here: 1) true on-prem DC which means HW, HVAC, UPS etc on premises with full HW staff and full network vs 2) old days bare metal which means colocation or stock rack offering in provider's DC, who takes care of all HW stuff under contract.
I am participating in K8s migration to on-prem HW in customer's owned server room. The scaling flexibility is close to none. Old time HW procurement processes take months. Blades need to go thru HW and NW Engineer's hands for a few weeks, before even K8s workers can be installed there, then apps scaled. This is for a project which has known requirements and performance expectations. Forget any of that if you are just privoting start-up.
But for anyone who just wants to "own" the data, the stack and to squeeze the maximum performance, then bare metal dedicated hosting or rack rental should be enough.
Agree with this. I would not want "true on prem" most places, not least because on-prem cost is driven in no small part by real-estate and electricity prices and salary costs near the colo, and for a lot of companies that means their on-prem won't be able to compete on price with colo or even managed servers with a provider. A lot of manage server offerings also offer requisitioning via API, rent on short term contracts (so still opex like cloud instead of capex).
But I also tend to favour hybrid setups these days, and most managed providers also has a cloud offering, which gets you the best of both if you have a decent provisioning setup and an overlay network:
The base load on managed servers at whatever commitment period gives you the best prices. The cloud instances provides elasticity. Done well your users/devs can't tell where one ends and the other starts. And because you have a cloud setup tied in, you can go pretty close to the wire on those managed servers - a lot more so than with a purely on-prem/purely colo/rented servers setup, increasing the savings from the managed servers even more.
I've had setups like this where we hardly ever needed to spin up any elastic capacity, but where having the capability meant the managed servers often got to 90%+ utilisation because we could let the utilisation rate get that high without issue knowing the system would spin up cloud instances if necessary.
Cloud is really good at what it does. There are definitely some business models it simply cannot accommodate, but I think these are in the minority now.
I used to be super-against cloud until I became the backstop for our entire IT infrastructure. It's really funny what happens to your beliefs when you take on ownership of more problems. Complaining about how Azure is 20ms slower than it needs to be on some storage service is nice, but are you prepared to personally take total ownership for that service's health by bringing it on-prem? Talking about how we could do it cheaper & faster in our house is super easy. Actually executing is a completely different story.
I won't even move back to on-prem Active Directory at this point. The convenience of having this managed centrally is unbelievable compared to where we were at a decade ago. Today, an employee can go to Best Buy, grab a completely new machine, connect it to our directory using the retail OOBE and start working productively within 20 minutes. Not one time does the employee need to bother an IT person during this process. Could you achieve the same with an on-prem setup? Absolutely. Would it take more money and time than we have available? Probably.
There are risks with going all-in on cloud, but I assert that those risks are almost always less severe than the risks endured with on-prem. When is the last time a cloud vendor made some last-minute change to a product or service that endangered their customer base? You typically have years to migrate off something a cloud vendor doesn't want to support anymore, simply because they have to make sure 10k other customers don't balk too. This is also why these products are so stable in terms of roadmap. Going with the herd is a proven way to protect yourself. Being the one shop still online when 99% of the clouds go down is probably not a realistic competitive advantage for your business.
I would conclude by saying that you should minimize the diversity of cloud products as much as is reasonable for your operations. Keeping AWS to just EC2, EBS, Route53, etc., ensures that any need to migrate to a different cloud provider is actually tenable. Put the intelligence into your application/product, not the plumbing around it.
> Being the one shop still online when 99% of the clouds go down is probably not a realistic competitive advantage for your business.
It depends. If you're just another Etsy store, or a SaaS that integrates with other SaaSes, then yes. The entire internet will be down if AWS is down and nobody will blame you.
But if your customers are using your app on a job site and they can't work without it, you'll lose everyone if you have a single outage of even a few minutes.
I have a client in this space and they've handled this by making the app work offline and by pushing a few high-value things outside of AWS to survive an outage of their main stack, such as access grants, and the app can start to use MMS to send its data by including a token with the photo and job info and then this gets synced later by actually adding the token receiver to a user list as if you'd added them through the main UI.
What a weak article, where is the data that supports their arguments? At this point tech press has become a parody and just spews out speculations.
Speaking as someone involved in cost reductions in cloud services, there’s definitely a push towards taming the large bills. However hardly anyone is planning to move for EKS/RDS/GKE to self hosted OpenShift/OKD clusters.
"You’re crazy if you don’t start in the cloud; you’re crazy if you stay on it."[0]
What were seeing is that some cloud native companies have reached a size and maturity where the on-premises move makes sense. That's all, no fundamental shift.
147 comments
[ 3.6 ms ] story [ 214 ms ] threadWhen it's time to negotiate your enterprise discount program, savings plan(s), etc., etc. you need leverage, and that's what this is. Some companies spend multiple hundreds of millions of dollars with AWS alone and at that cost any and every tactic to bring down spend will get deployed.
We had a global network operator talk to us about repatriating its ML workloads on-premises from Azure. Cost is the main factor, sure.
I don’t like Azure and won’t use them again but this seems like a smart approach for MS to take.
https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap...
What percentage of COGS is your cloud/infstracture spend? If your products don't look like cloud infrastructure (aka Dropbox), it better be very small. If you think cloud is costing you 1000% what it would cost on-premise, that's almost certainly a spend and architectural discipline problem, not a cloud problem.
Whether that's an important saving or not changes from business to business, but anything less than 1000% seems only achievable by customized discounts from the cloud provider.
Still, I think it's hard to justify going anti-cloud in an effort to cut costs. Without a very skilled and experienced team doing the migration, the end result is very likely to be some hybrid setup that's the worst of both worlds. Especially if you're using a managed service, the open source alternatives might not be the drop in replacement that they claim to be.
Plus, most jobs today expect cloud experience. So there's an incentive for developers to push to use a cloud so they can grow into their next role.
This here is the compelling case for the cloud. It was always less about the features and the money save, it's that I now have 1 stop shop vendor, if I need a queue I can spin it up in 10 minutes, instead of filling out a ticket to internal IT getting them to put it on their backlog waiting until they have the cycles, and in the meantime I'm sitting on my thumbs.
I need a new server, in the old times it was a ticket, a budget meeting, two or three levels of sign off, a business case, on and on. Whereas in AWS or Azure I can spin up a box in about 20 minutes and be all ready to go, and happily start developing.
Just like MS was never about technical excellence, it was about being a pre-approved vendor that had everything you needed, so you wouldn't have to go through another vendor approval process. Same with the cloud now scaled down to a team size, I now know I am pre-authorized to spin up X number of resources without having to worry about security throwing a fit, or blowing an enormous amount of money.
Because companies do not like things going into assets category. Instead rent dedicated servers on Hetzner or wherever else it is price competitive and see red tape disappear.
>"So there's an incentive for developers to push to use a cloud so they can grow into their next role."
This is very lame argument. I am developer and a business and do understand both sides but sorry I run a business to make money, not to give them to Amazon and definitely not to be playground where developers can play with Amazon tech at owner's expense.
A company like uber is not looking at the price of a server but looking at the TCO of the products living in multiple verticals. TCO includes many things.
https://www.columbusglobal.com/hs-fs/hubfs/United%20States/B...
This is true, but it doesn't preclude use of the cloud.
The core of the cost issue is, in my view, that software is still designed to run in a datacenter: always on, all code in a single process (yes, this includes microservices), expected to never stop mid-execution. That made sense when you owned the hardware and needed to fully utilize it for the duration of its life. This prevents the best cost-saving measure in the cloud: turning it all off.
People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank. Software development practices have to change, and in the meantime the cloud platform providers are going to make a pile of money as companies shift legacy software to the cloud without the needed re-architecture. We need frameworks and other technologies that, similar to the abstractions we now have for memory management, multi-threading, asynchronous I/O, etc. relieve the burden of reasoning around distributed, disjoint processes from the developer. Then we can finally realize the ideal of "only pay for what you need".
Can you give some example of that being the case?
However, the cost calculation is weird when you factor that 2 hours of cloud "on" can often pay for an entire day of "on" for a normal server.
All else being equal, which I'm aware is a contentious/controversial notion in of itself, even if I personally believe the colo costs for headcount are often greatly overestimated.
">People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank"
Alternatively do what I do (example of particular product I developed and nor run for a client):
Single exe in C++ talking to a local Postgresql database. Combo is capable of processing thousands of requests per second sustainably without breaking sweat (this will cover business needs for a next 20 years). Also standby always on server with replication. Daily backup to on premises backup server. Hardware for production and standby is dedicated 16 Core AMD with 128GB RAM and 2x4TB SSD. Each rented from Hetzner at about $100 each. Fronted by Clouflare, not sure about the price as Client pays it. All deployment / management / maintenance / backup / Point In Time Recovery is done by couple of scripts. Reinstalling whole thing on a totally new server takes running single script for about few minutes (at some point will take longer as the size of the database grows but would still be very manageable).
The cost on Azure for the equivalent processing power and features accordingly to their calculator is 10 times more.
Most companies that save a lot by moving to the cloud are the ones which have several workloads, multiple products, teams, and verticals. They got security requirements, compliance, logging requirements to name a few.
So yeah, if you only consider a most basic business that has a single website with a single use case and non of the above then Hetzner is a great option.
You seemingly refer to a discounted mode of execution in AWS where your servers can be pulled off at any moment and there is no uptime guarantee. That only works because few use this mode. If everyone starts using it, the discount will disappear.
Whether it can be made cost-effective in practice or not, I don't know - I haven't made the calculations. Just saying that's how I read it.
We considered autoscaling web backends once. You've got to worry about capacity issues. You don't want a load spike only to discover EC2 has run out of the instance type you use. I've seen that issue 3-4 times in AWS now and it's painful when it causes downtime. Your app needs to have spikey load for the pricing to work, for us, even a strong day/night cycle didn't give enough "off time" to cover the higher hourly prices. Cloud vendors give steep discounts for always on usage. Your load also can't be too spikey, as spinning nodes up and down takes time. Making nodes start quickly can be a dedicated project.
I think we also looked into moving CI/CD servers to on demand, but some engineers worked too late into the night and others were up early. IIRC the "off period" was long enough to provide some cost savings, but not high enough to justify engineering cost.
Something like Lambda doing a "scale to zero" with a generous free tier looks cheap, but if you ever need to scale up you'll find it's quite expensive and your stuck with a weird architecture that's hard to move to something traditional. It is cool when an app fits the Lambda free tier, but that's not a good model for companies paying very large cloud bills.
The problem is that someone needs to do capacity planning, someone needs to buy servers. AWS has to pay the cost of an unutilized server by... keeping the hourly cost of on demand servers/cloud functions high.
Isnt it natural that your service gains more users at this time when everyone is trying to cut down on cloud costs... Cloud usage may be declining, but those who are still using it would want to cut costs...
Pre-COVID I was a at a F500 that had gotten screwed pretty hard by an Azure deployment than ended up costing TONS more than anticipated. Even after we made it clear it would be a lot of OpEx. "Sales engineers gonna play games" -- and they did.
New gig is just going down that path, and is, go figure, seeing the same problems. Burned by Azure, and now getting bilked for every last dollar by GCP.
Seconded. We called in Accenture to tell us if we should do the cloud.
They said Yes. I was on the Solutions & Architecture team, and we asked to take a look at their numbers.
Found multiple errors in their spreadsheets. Math being straight up incorrect, or calling out pricing that didn't match what our SaaS sales guys gave us.
"Oh they're old reports". Okay fine, run them again with the new numbers, and slap the recent graduate who you forced to make this excel.
Again, the numbers came back strongly in favor of Azure. Took a look again, this time had some fruity macro and pivot table, and we couldn't clearly make out what they did to get their final $$$ figures.
3 months later we declared we were "cloud first". There was much speculation as to how much $$$ the directors and VPs got. In a different life I was in sales engineering and there was an unspoken rule about "referral agent fees" to 3rd parties who help us close deals...
It's not really a 3rd party if they are a director at the customer...
With computers it's also usually the case that the Late Adopters show up in the middle of the Trough of Disillusionment of the Hype Cycle.
It takes a long time for new trends to percolate through the management class. I had a gruff old engineer at an early job who used to joke that one of the executives must have gone in for a dentist appointment and read the 5 year old tech magazines in the waiting room, because we have a new initiative to start doing something that other people are already stopping.
https://d2908q01vomqb2.cloudfront.net/77de68daecd823babbb58e...
We've hardly even begun the meaningfully productive AI side of cloud services for business, and that's going to be gigantic. TechCrunch is doing the equivalent of declaring the backlash against the Internet has begun, circa 2001.
Maybe it's time businesses actually did some honest assessment on cloud providers and their services?
So many managers appear to think the cloud is powered by magic pixie dust.
https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
Also, from experience, going with a "smaller" cloud provider and opting for a dedicated machine can already reduce the bill by a huge amount.
The position of power of the big 3 - AWS, GCP and Azure* - gives them almost 66% of the market - that doesn't seem right.
https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...
Even Hetzner maintains a few repos for that:
https://github.com/orgs/hetznercloud/repositories?q=kubernet...
Not to take a negative view, it's just an unsexy skillset and doesn't attract a lot of talent and attention.
Trying to hire for folks who can gracefully manage on-premise networks, power, and hardware is possible and extremely challenging. "Cloud," as it is today, is here to stay.
The primary focus of this purely infrastructure position, is a coding take home. Now, infra as code is part of local cloud, but there is sooooo much more to handle.
But because they have no idea how to handle infra, they seem stuck thinking it's just a dev job. Even while they hire stating it is not.
Quite sad. So much knowledge lost, that they don't even know what to look, what to hire for.
I've been hearing this "Cloud will DESTROY on-prem because on-prem skills don't exist and standardised cloud technologies make it easy to hire from anywhere across the world!" narrative for years which seems to deny the reality that we managed to train people to run datacenters just fine for decades even if people are snobbish about the riff-raff running things these days. Larger companies long ago figured out they could work with schools to develop a mutually beneficial training and employment pipeline. A lot of managers seem to be too lazy to do such things and find it easy to simply delude themselves into thinking cloud is always the best choice instead of contemplating doing hard work like that.
In fact cloud is often complex, requires lots of highly specialsed systems management, is under powered and very expensive.
9 cents per gigabyte out if you’re lucky - that’s a startling price.
Machines are old and out of date and left behind.
Vendor lock-in is a real problem .. you probably can’t exit even if you want to.
And worse, clouds often don’t even have the computing resources you need with “requesting quota” and waiting for your “quota” to be granted some time in the next 24 hours, the opposite of elastic and scalable.
And if you need GPUs then the news for you is that gamers have vastly more powerful GPUs at vastly lower cost (even with Nvidia and AMD fleecing consumers on their next generation cards).
Rent a bare metal server from a second or third tier player. Or buy a couple of fast fiber connections and buy some 16/32 core machines with 128 gig Ram.
And honestly it’s not hard to run modern Linux machines, that’s an old crones tale.
Recently I had to do some performance testing. In the past I would have quickly started 5 or 6 instances of different types, run my performance tests, shut them down and be done within 2 hours.
Since AWS introduced zero quota GPU instances, I had to request quota for one specific GPU instance type in one region and then waited 24 hours till it was “approved”.
At that point I completely gave up on AWS as being a viable part of any GPU architecture.
It gets no less scalable or elastic than that.
I literally could have gone to the shop and bought a fleet of machines and built them at home in the time it took AWS to approve a quota of one GPU instance in one region.
That said, some hardware companies have APIs to do most of that stuff - a little human runs out to fulfill your request if need be in some cases I think. Still like... much to worry about.
Unless you don't want strangers touching your assigned rack, then you need to bring the key.
I knew the cloud marketing machine had done the new generation dirty. I didn't know it was this bad.
Edit: also OSHA rules, cable splicing, how to handle ladders, etc, etc.
If you buy colocation, it is tho.
So to your point it’s how the internet is run. But your midsize enterprise isn’t a telco. They have no expertise with this stuff.
For plain S3. Other methods have lower prices. All methods have automatic volume discounts and almost everyone has a free tier.
> Machines are old and out of date and left behind.
A problem I've seen on every single VM stack, regardless of where it is hosted.
> Vendor lock-in is a real problem .. you probably can’t exit even if you want to.
Build your model first, then map it into services, don't start with the services and map your model based on them.
> And worse, clouds often don’t even have the computing resources you need with “requesting quota” and waiting for your “quota” to be granted some time in the next 24 hours, the opposite of elastic and scalable.
I've only experienced this on services that have a potential for abuse. DNS and SMTP being all that I can remember.
> Or buy a couple of fast fiber connections and buy some 16/32 core machines with 128 gig Ram.
And "requesting quote" isn't a delay item here? I don't know anything about fiber, how to price it, or how to receive it... and the capitalization process on all this is going to eat up a bunch of my departments time.
> And honestly it’s not hard to run modern Linux machines, that’s an old crones tale.
It's much easier to just run a lambda. It's a great compute environment. It does 90% of everything I've ever needed.
I totally agree with that. I'm a dev, not a sysadmin. But I run several Linux servers and can set up the network(s), the firewall, the apps and all that. It's not that hard.
You can buy incredibly powerful machines today at a very cheap price. The 20 cores Asahi Linux ARM workstation, 128 GB of RAM recently posted here comes to mind... In the blog's author's word: "The Mac blew the AWS c6g.12xlarge Graviton instance with 48 ARM64 cores instance out of the water."
Or this slightly older blog entry about someone running 25 Gbps fiber to the home. Not to the office. Not to some colo. To the home. Sure, it's not available in many places, but that's quite something. That is someone, at home, having a personal pipe wider than what cloud instances do provide to most.
Heck, my brother, a poweruser (not a dev), just assembled a 7950X / 64 GB of RAM with a 4090 GPU. I think many, used to their laptops, don't realize how powerful such machines are (laptops aren't exactly known for running 4090).
It's honestly a bit insane to me that several devs have, at home, wider pipes and faster machines than what their apps are going to be deployed on.
I'm "only" at 2 Gbps FTTH and don't have a particularly fast machine (just ordered a 7700X / 32 GB of RAM / WD SN850X Black as suggested by someone else here yesterday) but even that is sufficient to make me question a huge lot of cloud instances offerings.
https://www.db.com/news/detail/20201204-deutsche-bank-and-go...
The problem is companies doing one thing have no idea how expensive is doing that other thing... grass is always greener on the other side.
I'm not really "out there" and "with it", but it seems the move has been away from classic OOP for a long time now. I never see new projects try to have the inheritance tree's that C# or Java have. I think small simple objects can be fine. It's when you get into metaprogramming with templates and multiple inheritance in C++ that I want to just run away.
Sure, hybrid approaches do work; keep your main infra in the cloud and supplement it with some cattle rented servers (that can fail with no prod impact) to handle predictable workloads.
But think it very thoroughly before getting fully back to “on my premises”. You’ll discover a world that you never knew it existed.
For the parts of your business that are steady state, cloud can be dumb, if you care about spend. At any significant scale you can trade flexibility for control and reduce cost. The other benefit is capex vs opex and how that affects your taxes - cloud makes it easier to shift to a pure opex model, but it’s not an exclusive ability.
It depends on you however. It’s almost always a good deal to buy Office 365 or Google. If you have a heavy cyclical business, it’s probably smart to rent vs buy compute. Pay AWS October-December and turn everything off in January.
At the end of the day, any CTO who has religious beliefs about this stuff is an idiot. Execution and cash drive these decisions.
Plus there's some 8 fallacies going on here. The Cloud Providers generally make it very expensive to have some of your stuff in the Cloud and some on-prem. That's a challenge for most businesses, which I typically assert should be about 80% boring and 20% volatile/dynamic/interesting/on fire, because that 20% can soak up a lot of fees on chatter between the two classes.
That's by design. They want you all in or all out. They don't want you going back and forth. Whatever that was originally informed by (eg, the costs of their wires into and out of the Internet), that's where we are now and it seems to be considered a Good Idea.
If they change that they might keep some customers, but they'll also give others an easier exit strategy.
If managing cloud is skill-intensive and you need a hire a person/team with specific skills in it, then you're no different from on-prem from a personnel perspective.
And those are growing pains. In 5 years time, maybe the proper controls/cost containment will be easier because we've seen how easy it is to fuck it up.
We're comparing an ideal version of cloud to practical versions of on-prem. When the ideal version becomes practical, it might be a no-brainer. But for now, companies are going to have to do what's best for them today.
So you run your own services on their hardware (as opposed to using cloud SaaS, where you rent both the hardware AND the service).
Cloud is also so centralised that even if everybody collectively got better at optimising costs there's a serious risk that cloud vendors would just collectively fatten their margins. The inverse is also true, if on-prem suddenly became much easier to run, expect licensing and hardware costs to start creeping up from anybody with anything resembling a monopoly or cartel.
I am participating in K8s migration to on-prem HW in customer's owned server room. The scaling flexibility is close to none. Old time HW procurement processes take months. Blades need to go thru HW and NW Engineer's hands for a few weeks, before even K8s workers can be installed there, then apps scaled. This is for a project which has known requirements and performance expectations. Forget any of that if you are just privoting start-up.
But for anyone who just wants to "own" the data, the stack and to squeeze the maximum performance, then bare metal dedicated hosting or rack rental should be enough.
But I also tend to favour hybrid setups these days, and most managed providers also has a cloud offering, which gets you the best of both if you have a decent provisioning setup and an overlay network:
The base load on managed servers at whatever commitment period gives you the best prices. The cloud instances provides elasticity. Done well your users/devs can't tell where one ends and the other starts. And because you have a cloud setup tied in, you can go pretty close to the wire on those managed servers - a lot more so than with a purely on-prem/purely colo/rented servers setup, increasing the savings from the managed servers even more.
I've had setups like this where we hardly ever needed to spin up any elastic capacity, but where having the capability meant the managed servers often got to 90%+ utilisation because we could let the utilisation rate get that high without issue knowing the system would spin up cloud instances if necessary.
I used to be super-against cloud until I became the backstop for our entire IT infrastructure. It's really funny what happens to your beliefs when you take on ownership of more problems. Complaining about how Azure is 20ms slower than it needs to be on some storage service is nice, but are you prepared to personally take total ownership for that service's health by bringing it on-prem? Talking about how we could do it cheaper & faster in our house is super easy. Actually executing is a completely different story.
I won't even move back to on-prem Active Directory at this point. The convenience of having this managed centrally is unbelievable compared to where we were at a decade ago. Today, an employee can go to Best Buy, grab a completely new machine, connect it to our directory using the retail OOBE and start working productively within 20 minutes. Not one time does the employee need to bother an IT person during this process. Could you achieve the same with an on-prem setup? Absolutely. Would it take more money and time than we have available? Probably.
There are risks with going all-in on cloud, but I assert that those risks are almost always less severe than the risks endured with on-prem. When is the last time a cloud vendor made some last-minute change to a product or service that endangered their customer base? You typically have years to migrate off something a cloud vendor doesn't want to support anymore, simply because they have to make sure 10k other customers don't balk too. This is also why these products are so stable in terms of roadmap. Going with the herd is a proven way to protect yourself. Being the one shop still online when 99% of the clouds go down is probably not a realistic competitive advantage for your business.
I would conclude by saying that you should minimize the diversity of cloud products as much as is reasonable for your operations. Keeping AWS to just EC2, EBS, Route53, etc., ensures that any need to migrate to a different cloud provider is actually tenable. Put the intelligence into your application/product, not the plumbing around it.
It depends. If you're just another Etsy store, or a SaaS that integrates with other SaaSes, then yes. The entire internet will be down if AWS is down and nobody will blame you.
But if your customers are using your app on a job site and they can't work without it, you'll lose everyone if you have a single outage of even a few minutes.
I have a client in this space and they've handled this by making the app work offline and by pushing a few high-value things outside of AWS to survive an outage of their main stack, such as access grants, and the app can start to use MMS to send its data by including a token with the photo and job info and then this gets synced later by actually adding the token receiver to a user list as if you'd added them through the main UI.
Speaking as someone involved in cost reductions in cloud services, there’s definitely a push towards taming the large bills. However hardly anyone is planning to move for EKS/RDS/GKE to self hosted OpenShift/OKD clusters.
I wrote a "Mist Computing" manifesto in 2015 while working at Google, capturing similar concerns at that time:
https://docs.google.com/document/d/1SYiDABLgOMljsWl2SDrz5jRL...
What were seeing is that some cloud native companies have reached a size and maturity where the on-premises move makes sense. That's all, no fundamental shift.
[0]: https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap...