The original promise of the cloud was that it was cheaper than on prem. For many companies this has turned out not to be the case. Having worked on a cost optimization product for the past year (https://vantage.sh) my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so.
In particular it is difficult and stressful to understand all the knobs to turn within each cloud provider. It's a very AWS thing to put a lot of effort into lowering their customers' bills and I do think it makes for longer lasting business relationships.
> my belief is that the cloud _is_ cheaper than on prem but it is difficult to configure it to be so.
It takes discrete effort in the core planning of your architecture. You cannot look at AWS resources (or any other cloud provider) as an all-you-can-eat buffet. You have to look at your requirements, look at the viable options that may support your requirements and take into consideration cost associated.
Without looking at cost during design your company/service/team will have a bad time at some point. There are also some really specific things you can do to lower costs but require knowledge and understanding of a myriad of technologies.
you can and should look at them as aN "as little as you can eat buffet" option.
the cost transparency is a huge part of the value of cloud, even if it cost the same as on prem, the transparency is huge, but it's even more valuable if you make smart choices with that transparency.
of course often folks just ignore costs until al of the sudden it's a huge pain point.
Our team typically expects some cost consideration given in design documents. This way we know that some attention was given to it and it's a good starting place for discussing costs during design review.
I write event (think food festival) software. 9-10 months out of the year there is almost zero traffic, 1-2 months have mild traffic, ~2 weeks are higher traffic, and then 1-5 days (during the event) are very busy.
I'd be hard pressed to find anything other than my current stack (Lambda/DynamoDB/S3/Route53/APIGateway) that costs as little. In the off-months my costs are ~$5 if that and in the month of the event that might get as high as $15-30. I cannot imagine being able to host it locally/colocated (for the month of the event) for that cheap and that doesn't even touch on the hardware cost (I'm thinking just electricity and co-locating costs).
Yes, I'm a small fish and this is just my side business but for me the cloud is way cheaper. Anything with very spiky/uncertain load can be good candidate for the "cloud" but a big part (IMHO) of making the cloud work is using the managed services and using them smartly. If all you do is spin up EC2 instances then no, the cloud is probably not going to be cheaper in the long run.
I think you're almost always gonna pay far more for cloud compute than on-prem. It's pretty standard for companies to have roughly 2x the "peak" load than "minimum" load, so while with on-prem you maybe have to over-provision by ~1.5-2x, that's greatly outweighed with how much more expensive cloud compute is vs. on-prem compute. The only exception is companies with extremely spikey demand - e.g. if your peaks are more like 10x or 100x your troughs, then yeah, cloud is probably cheaper from a pure compute POV.
However, unless you use HUGE amounts of compute, cloud is probably the right choice, because you probably save a tonne on salaries by going the cloud route. It's way easier to properly operate a managed DB than your own (especially in terms of no-downtime upgrades, no-downtime scaling, backup/recovery, etc.), same goes for managed file storage (S3 type things), same goes for managed pub/sub, same goes for managed K8s/whatever, same goes for managed load balancers, etc. For a lot of startups, total cloud spend is equivalent to just a few fulltime Engineer salaries, and they also use a tonne of cloud services, getting that all running well without AWS (or Google Cloud, Azure, whatever) would take way more than a few fulltime Engineer salaries.
FWIW, the last company I worked at (~1000 people), as our AWS bill was getting into the millions annually, we tried migrating off AWS, onto a colocation setup. I didn't work on that project myself, but my understanding is they spent a bunch of engineering effort on it, were still nowhere remotely close to being able to truly move off AWS, ultimately canned the project and moved all the colo stuff back to AWS. I think a lot of engineers underestimate how much effort it is to provide the kind of cloud services Amazon/Google/Microsoft provide, at comparable levels of reliability and ease of use. It's A LOT of effort.
With fixed hardware, you're always planning for max workloads.
The systems are scaled up for the "Black friday" sales event.
With cloud, you will plan for the steady state and just boost it up when you need to.
The anti-pattern is usually that when on-prem hits 80% load, some engineer is usually tapped to weed out all the slow code to push past procurement delays.
While in cloud, people just throw more hardware at it and ignore low hanging performance problems which are costing them money (& unlike the on-prem, fixing it will immediately reflect in the budget the next day).
At low scale it can definitely be true. My startup spends $0 on ops salaries because it's possible for an AWS-proficient backend dev to not need more than an hour or two a week to maintain the entire production infrastructure. Our AWS bill costs us less than it would take to hire a person to run on-prem physical infrastructure.
Not sure if you consider small startups to be realistic scenarios, though, so perhaps this doesn't count.
Their peak demand is insane, especially at race start, and is only sustained for a few hours for ~20 weekends a year.
AWS have already built a live streaming stack for their other customers with DRM and support for a wide variety of platforms. And there are other features like live rewind, restart, live to VOD etc.
It is also relatively straightforward to serve new countries, you don't have to build data centres all over the world, just stand up your infra in a new region.
Four jobs ago I worked on a search engine for a large national sales company. They'd sparingly ran TV ads. When they ran a TV ad their traffic would 10x immediately then a mild smooth increase over the next month or so. Would it have made sense for them to operate on prem machines that could handle their peak capacity, when they only needed their peak for hours per week?
A) a user base with usage that varies significantly over time
and
B) an architecture that can actually scale significantly up and down during the same time period
So if you have lots of web back ends and business logic and general workers for jobs that can just be shut down when there's no capacity needed, there's a ton of savings available in the cloud.
If you have a big monolithic architecture or some other organization where everything is just on all the time, the cloud makes less sense as a cost savings.
I once wrote an internal chat bot which was used less than 2 seconds per day, but was actually supremely useful as it really simplified some process or another and took a fraction of a second to run each time. The actual cost to run this in the cloud was approximately 1 cent per year. If I didn't have this cloud capability it would be hundreds of dollars per year to host or thousands of capital in machines and maintenance to host myself.
I do agree that it’s a shrewd move to build relationships but I also don’t think that it’s clear cut that companies are spending more to be in the cloud versus the cloud costs being much easier to see compared to on prem TCO, especially when it comes to staff time or the costs projects take on when they’re limited to the services their IT department is capable of building and operating.
A huge confound here is that in any environment these kind of metrics are proxies for a lot of cultural health, so it’s easy to find places hemorrhaging money on AWS without having an easy way to know whether the same managers would have wasted comparable sums internally because e.g. the root cause was letting Accenture send a bunch of 25 year olds to design whatever adds the most expensive terms to their resumes, so while it was AWS today a decade ago it was a $10M Hadoop cluster holding one MacBook Pro’s worth of data.
For my tiny startup, the cloud is two to three orders of magnitude cheaper. We could not exist were it not for the cloud, AWS in particular.
Last week I had a call with the AWS support team helping me get some costs under control with improved architecture and optimizing how I pay for compute. Based on our chat, I believe I can reduce costs by a third, which for us means multiple more months of runway, critical time to find P/M fit.
At my old job, cloud costs were out of control, mostly because there was a huge effort to “lift and shift” the existing systems, rather than redesign them with the cloud in mind.
Yeah, labor. The team needed to manage the variety of infrastructure required to provide the same functionality and availability as the various AWS services we use would have been well beyond prohibitively expensive.
I've worked in cost optimization initiatives in several teams, and how they get themselves in a money pit has different causes (e.g. lack of skills in the team, speed to market, etc.). From experience most teams that haven't done cost optimization have huge opportunities for savings (in one of my teams we reduced cost by 90% while 3x our traffic, and we still had a few optimization opportunities that we decided not to pursue).
On prem has less flexibility on cost reduction, and if cost has already been incurred, at best they can reduce their bill moving forward.
If you look at TCO, and include opportunity cost for those on-prem services where you might be caught behind the supply chain eight ball for weeks or months, then I think you're right. But you have to look at all sources of costs on both sides.
And it's certainly possible to configure any cloud provider in a way where it is much more expensive than a corresponding on-prem solution, and it's also possible to do the reverse.
Where things get interesting is where you compare all sources of costs on both sides, and both sides are as cost optimized as you can feasibly make them. Then you are a rare unicorn indeed.
Cloud is a service that moves CapEx to OpEx. What ever cost savings it may provide is a side effect of this move. If you moved to cloud and do not see any savings, that means you have sized planned your capacity well. But there are a lot of businesses that cannot plan ahead for various reasons, and cloud provides value to them.
it's an interesting evolution since in the industry the perverse incentive is to not invest in efficiency since it would blow up revenues charged per volume.
snowflake is going through such a crisis, since they have a bill for volume model.
So long as Software Engineer timing is not respected or tracked (compared to other engineering disciplines), in times of economic downturns, it will always be popular to shit on cloud.
People stop caring about the elasticity, about the operationial overhead to their people, additional 9's of availability, even about feature delivery velocity.
Tech companies turn into accountants looking at X $/Month in the cloud vs Y $/month from "buying a couple of servers".
Then you have "luminaries" like DHH and Elon blogging about how much leaner and better their services are as a result (never mind that twitter is now a buggy mess where everything is eventually consistent and breaks half the time)
In particular it is difficult and stressful to understand all the knobs to turn within each cloud provider. It's a very AWS thing to put a lot of effort into lowering their customers' bills and I do think it makes for longer lasting business relationships.