In 2006, Amazon debuted EC2. 15 years on, HashiCorp says firms blowing their cloud budgets is all part of the fun Fifteen years ago, Amazon rolled out the public beta of its Elastic Compute Cloud (EC2), ushering in a new era of cloud computing ... and overspending on clouds of every flavour, according to a Hashicorp report. EC2 was a relatively simple concept. Applications ran on a virtual CPU, "the equivalent of a 1.7 GHz Xeon processor …
This post has been deleted by its author
in that, once you are in, you can never leave unless you die.
Azure and other ones are almost as bad.
They have your business by the short and curlies. I wonder why this has not become a verifiable business risk? What is the 'Plan B' for companies that are locked inside?
Well you see, if the parasite kills the host, then the parasite dies. Cloud service providers know this, so they make sure not to charge too much. They want to kill off the smaller companies, but keep the whales alive. I bet a coke, a Mexican coke made of real sugar because it's the Lexus of coke, that the managers of the cloud services use their sales metrics to determine which companies to invest in, so they have some fat portfolios of tech stocks that they know are doing well.
What complete nonsense, it's perfectly possible to use a cloud service for hosting and not be locked in. The higher you go up the stack the harder it is but as a small company we've successfully moved databases and compute between clouds for better prices and/or performance. Much to my chagrin it was TO AWS not away.
Not complete nonsense unless you're willing to architect for true multi-cloud and therefore only use the services that are common. Then do a lot of the heavy lifting in running apps and services yourself
Do I use the CSPs k8s offering or run my OpenShift? In one scenario I can move freely to other clouds but I'm carrying the effort to run, manage, patch, support OpenShift
For me, I want to make as much of running the service AWS's problem but accept lock in as a consequence
As I have stated before :-
Given the costs of cloud services vs the cost of own hardware there are only a few cases where use of the cloud is a good idea
For almost all sustained workloads it is cheaper to use your own kit rather than rent services from a cloud provider.
Good reasons for using the cloud
1) Short term peak (under 3 months)
2) Insufficient internet bandwidth at own premises
3) Keeping development and testing well away from production
4) Temporary substitute for unavailable systems (eg after a fire)
Reasons for NOT using a cloud
1) Cost - in under 3 years (under 1 year in many cases) running the job on own hardware will be cheaper than the cloud price
2) Legal constraints - any company in the EU that allows personal data to be on a cloud controlled by US firms is in danger of massive fines due to the EU GDPR and the US CLOUD act.
3) Data security - if the access to the cloud application is not set correctly then massive data breaches are all too easy - this again raises the potential of nasty fines to companies that trade in the EU due to GDPR. Data breaches on own kit behind a firewall are usually due to an attack (rather than the stupidity that has left so many Amazon storage buckets with world access).
4) Lock in to one cloud supplier. It is far too easy to embed implicit assumptions about the available facilities into applications resulting (for example) in an application that works on AWS but needs extensive rework to run on Azure.
PLEASE before committing a job to "the cloud" price the costs of own kit vs cloud kit over the expected timeframe. Include the costs of 2,3,and 4 above in the analysis before committing to the cloud.
Icon for directors looking at the unexpected drop in profits due to cloud costs ===>
Last post made some great comments about cons of cloud for pricing and article states cloud as convenient, but from my experience it's a little more complex in most cases.
I mean really the assumption here is ths is just a cost centre - which maybe we have the bean counters to partially thank for :) - but really "convenient" is, to whatever extent, the ability to change, move faster, take opportunities or (or reduce opportunity cost)... potentially do the right thing or actually reduce hardware costs.... I mean actually at some level just to compete with other companies with the same level of convenience... the old world really used to be about lead times as constraints for me....
Basically mainly it doesn't matter if your IT is half the price if your competitors are leveraging the cloud to do everything quicker.
Having said that, it's all about context and potential responsiveness is not the same as actually effectively changing rapidly... Nor does on premise mean lack of responsiveness with a highly performing infrastructure department.
Personally I've seen a lot of uncontrolled cloud spending and lack of actively managing those costs (or the complexities of systems that drive those costs). Imho it mostly comes down to how effectively / quickly you can and do change your systems for the most important things - be that new systems, scaling for load or reducing costs through optimisation, d commissioning or replatforming.
You may think this is bollocks but it's just what i believe from my experience... I'd probably agree with you on the specifics of your experience...
Yes, I'm a dev, don't hate me :)
Problem is it's too damn easy to use resources a business doesn't need.
Amazon themselves tout it as a way to avoid the usual acquisition approval processes to acquire computing resources, replacing it with an on-demand system
"Trade Capital expense for variable expense".
Dropbox moved away from AWS as they say it's cheaper for them to run their own datacentre's :
https://www.datacenterknowledge.com/manage/dropbox-s-reverse-migration-cloud-own-data-centers-five-years
At the end of the day there is nothing magical about the cloud, as is said it's just "somebody else's computers", it's good for some businesses, especially start-ups that may need to expand (or contract) quickly, but it's not ideal for everyone
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
