Singapore software maker says own hardware in colo costs $400M less than cloud Singaporean search engine optimization tools slinger Ahrefs has claimed that keeping its infrastructure on-premises, rather than using Amazon Web Services, will save it $400 million over three years. A March 9th post by one of the company’s datacenter operations execs, Efim Mirochnik, compared the cost of acquiring its fleet …
The advantage of cloud is its elasticity, serverless options, variety and spread. If your workloads can take advantage of those factors, the cloud can work for you. If all you want is a single data center with a fixed number of servers, then buying your own may make better economic sense. However, most mature organizations don't go to AWs and spin up a bunch of EC2s in a single AZ. Instead, they deploy using serverless, multiAZ and multiregion concepts.
The advantage of cloud is its elasticity, serverless options, variety and spread.
These options mostly exist for someone to find the right price point, rather than utility (maybe except serverless).
If all you want is a single data center with a fixed number of servers, then buying your own may make better economic sense.
If you have your own datacentre you can add or remove servers to your hearts content (and budget) and you can run all the things you have access to in the "cloud".
However, most mature organizations don't go to AWs and spin up a bunch of EC2s in a single AZ. Instead, they deploy using serverless, multiAZ and multiregion concepts.
They go to AWS because typically that's what investors require of them. There is unfounded fear that if something doesn't run on AWS then it's not a safe investment.
Quite. Just like how the FTSE100 for some reason makes demands of it's clients to move to SAP.
Find me any organisation, anywhere, which consider's it's deployment of SAP ERP a success I'll be amazed.
In my own line of work, cloud is not an acceptable solution for some problems; because the nature of the data is not allowed (even in encrypted form) to be left on a 3rd parties system where, a dedicated admin could do something with it we'd rather not see.
This policy is slightly backwards of course, in that the data does still cross public internet wires when going from site to site, regardless of whether the servers are cloudy or our own.
IT policies need to evolve somewhat to get the services one actually wants... Rather than just going AWS because history.
I've seen going all in with the serverless approach destroy a business. It's like the worst form of microservice complexity coupled with an arbitrary execution time limit. They at least avoided sone of the cold start delays by using a scripting language, but then the actual code ran incredibly slowly. They also had to use the "bulkhead" pattern - basically caching incredible amounts of data for each system, with the inevitable lack of data consistency.
This post has been deleted by its author
If you are a small user; need to create and destroy many ephemeral instances frequently; need to be able to quickly scale up or out and then quickly scale back down again; or have a workload that is large but only at specific times; or are able to take advantage of the long-term reservation discounts; then you should be able to do well in a cloud.
Companies with a very large and stable workload, who already have in-house knowledge, would likely find colo far cheaper, even if they have to hire a few more operations staff to manage it. There are also issues for companies based in a country without a cloudy datacentre who care about data sovereignty or low RTT.
I'm sure the cloud is good for some things that on-prem isn't and vice-versa, the trick is to get a hybrid that works for the workloads you need for them both. Cloud is great when a server goes titsup, just bring another online in seconds, in onprem you better have paid to have a spare somewhere or be ready to rebuild from the pool of UAT/dev servers, that in turn deprives the dev team of productivity. However on-prem means you more or less control costs and you plan far more efficiently to ensure you get good ROI rather than just throwing money at problems.
The key is what most of us have known for decades, despite the PR bullshit from all sides that the PHBs lap up like cats under a cow's udders, there is and never will be a one-size-fits-all solution within IT.
"... in onprem you better have paid to have a spare somewhere or be ready to rebuild from the pool of UAT/dev servers, that in turn deprives the dev team of productivity. However on-prem means you more or less control costs and you plan far more efficiently to ensure you get good ROI rather than just throwing money at problems..."
Yes and no. Even before the massive migrations to cloud, most companies had invested heavily in virtualisation. After all, what's the point in having a 64-core Xeon server with 128GB RAM sat around being say *just* a Domain Controller or print server etc?
So I'd argue there should* be some capacity baked in anyway.
*I know...should is doing a mighty large amount of heavy lifting in this context.
Ah yes, "Swings and roundabouts".
That'll be why the vast corporate behemoth I work for decided to go "Everything in the Cloud" which has meant mostly Microsoft's offering with the justification being that we'll save a fortune.
Less then 2 years in and we're already being told to be very careful with access due to our licensing costs having risen now that Microsoft have all our stuff.
Oh how I laughed.
I work at a tech company that operates around 24,000 servers. We also believe we're saving a lot of money. But large scale infrastructure does take a fair bit of in-house expertise compared to using the cloud. Just for example, there isn't much in the way so usable bare metal fleet management software, from either commercial vendors or an open source project. But even with the incremental engineering costs needed to provide the software layer, we still think we're saving a lot of money. And those savings will grow as our business expands.
Comparing straight EC2 costs to the cost of physical hardware is nonsense.
As has been posted, he does not mention whether he has used OnDemand, Reserved or Spot prices, which makes me think he maybe he has not investigate the possibilities.
On AWS you only need to provision what you need at any given time (an over simplification but sufficient here), the on prem hardware has to handle peak load comfortably, which means much of it will be idle most of the time. I have spent a lot of time (and money) balancing workloads so that hardware is used efficiently, this takes time and need constant monitoring, get it wrong and one day a vital process will crash/not complete. A 'data centre operations exec' should be aware of this and include it in any 'analysis'.
Then the CTO should be involved, because what about Kubernetes clusters, messaging, queues, notification services, CDN, managed database services ... , these all have to be configured and managed. Availability, scalability, load balancing, disaster recovery, are all much easier on AWS. They will all cost you in your on prem solution.
And then there is Serverless, this is very hard to provide on prem.
I could go on, but the red mist has started to disperse.
BTW: the 37 Signals story has largely been discredited, the use of AWS in that case was almost criminally negligent IMHO.
So if you cannot use cloud services efficiently , then yes go on prem. But stories like these that just put irrelevant numbers in your face are not helpful.
"Do you really think that an org with such a large AWS footprint isn't going to know the difference between OnDemand, Reserved, and Spot pricing."
I have now read the full article and yes they do know. They where using 3 year reserved instances, so I take it back (I should have read to the end).
"They call have costs in AWS, too."
Yes they do, I was referring to maintenance costs, these drop drastically, sorry if that was not clear.
I am not employed by a cloud provider. I am however responsible for architecting systems. This involves almost exclusively Private and Public Cloud solutions currently, but in the past I have worked on a lot of in house solutions.
All of our cloud migrations I have been involved with have saved the customer money. Before you 'bark' again, the private clouds are based on local data centres and a setup not dissimilar to the one in the article, but all of these are hybrid now and more workloads are heading to the public cloud.
Note: in the short term 'lift and shifts' have ended up horrible expensive. It is my job to ensure that this is rectified quickly.
I guess I actually do agree with Mr. Mirochnik as he say's this in conclusion.
"Also, abandoning a cloud infrastructure due to higher costs may not be what the engineering team wants. They may rightly view a cloud as a much easier and more flexible environment compared to old-fashioned brick-and-mortar data centers with physical servers."
My customers are the engineering team. They are focused on creates an environment where the business can grow and be flexible. If Mr. Mirochnik does not consider these engineers his customers, I can see why we disagree.
I see a great deal of fear in some of the workplaces I enter, they simply don't trust AWS or any of the other providers. But Cloud Computing is here to stay, make the best of it.
"An architect that didn't read to the end of the spec... I've never seen one of those before!"
Terry Pratchett had Bergholt Stuttley Johnson aka Bloody Stupid, who probably never read the beginning of a spec either :)
Architects of the Grand Design persuasion would be sufficiently educated not to "architect" anything - they might design and possibly design a hideous monstrosity but they certainly leave the "architecting" to their lesser bretheren in more dismal disciplines.
> But Cloud Computing is here to stay, make the best of it
Since the creation of the lowly "long bit of wet string" to connect Users and Machines, has there *ever* been a time when "buying hardware cycles without owning the whole machine" has NOT been an option?
Whether you call it timesharing the University Mainframe, dialling into WOPA, nipping out to the local Computer Bureau or using The Cloud, it all looks the same[1]: running your processes on Someone Else's Computer.
So, yes, Cloud Computing is here to stay, because it never went away in the first place.
And as has been the case from the beginning, you switch your workloads from A to B and back again as needs change and progress marches on: the department buys time on The Mainframe, then it gets its own Mini, then it buys time on The Cray, then it buys everyone their own PC, then they buy time on the Analytics Farm, then they buy commodity GPUs for their PCs, then they buy time on a rack of "AI (G)PUs"... (and that was a sensible department, following the cost-effective cycles; some just swing almost randomly from on-prem to rented, from in-house to out-house).
BTW does anyone else remember the stories from the late 80s/early 90s where CFOs had spotted that[2] The Company Mainframe was practically lying idle in between the Weekly consolidation runs, so they insisted that the spare time be sold? Only to get a shock because March came around and the CFOs found out that they'd sold off the time needed for their own End of Year consolidation to run in the gaps between a few Weeklies?
[1] yes, yes, the software to manage your rental has got better - well, more complex, at least - but aside from the difficulty of managing your workload via a web browser UI in the 1970s (and earlier, for that matter), notice how you are doing more of the work that we used to have included in the price? The Priests of The Machine had their uses.
[2] this story for illustrative purposes only, details may not precisely match reality, but you get the gist of it: there was a fad for selling "spare" cycles (which wasn't always thought through and, as always, it was the failures that got into Computer Weekly).
Leasing in North American business serves one purpose: to translate your capital expenditures into run-rate deductible annual/monthly expenses that you can write off 100% instead of fractionally over several years.
But that comes at a price: whoever is providing the leased hardware turns a profit at your expense.
We were largely forced to go to Azure because our capital budget got reduced to 10% of what it was previously. Cloud costs come from revenue budget, not capital..
(We do maintain some local servers - DCs, print servers and a few hyper-v clusters, but the majority of our servers now live in Azure)
yes, some of the hardware vendors we use on prem keep telling us about their lease options because all the bean counters want opex, but we don't get far into the costing exercise before it's clear that leasing the hardware would cost far more than owning.
We are pulling stuff back out of the cloud and putting on prem after finally doing real apples to apples cost analysis of our systems. It's not even close.
And yes, we have slack in our compute and storage environments, but it's enough that if we have very fast growth we can buy more servers and storage and get them up in running in less than a month.
.. migrating my home VM servers to either Azure or AWS. I did some quick and dirty sums (server A has a 500W power supply - assume full draw continuously [1] and the price of a unit of electricity, how much did it cost a month.. now do the same for the other servers..)
End result was about £70 per month.
Then I looked at the cost of implementing just the essential VMs in a secure fashion in AWS (Azure was a non-starter - they didn't allow FreeBSD VMs - don't know whether they do now) was well over £1000.
Not really much of a decision! Even factoring in the hardware cost amortised over the life of the server (one is 7 years old, one is 4 years) and other gubbins like the external disk array, self-hosting costs a pittance compared to cloud. Especially as I have a largely static environment.
And it's even cheaper at the moment because the older server is powered down because the RAID card fried itself and corrupted all the VMs hosted on it. Thank goodness for regular backups.. Next annual leave I'm planning to replace the RAID card and get it going again, even if it's only as a cold-standby spare.
[1] Obviously, it's not but that assumption made the arithmetic easier!! Looking at the server load, it barely breaking a sweat most of the time. The only reason I have two servers is for resilience as they used to be clustered together (before the older one ate its RAID card) in a Proxmox cluster.
I'm a paid up nerd, and looked at the same thing.
I have a Dell Workstation 3610, hardly cheap to run at home.
Priced what I need in Azure or AWS, and neither came close.
My various employers went for cloud ..the 'lack' of needing to employ an infrastructure guy made cloud cheaper.
Of course time has marched on, and they now employ several of them to manage the cloud.
Cloud is a fools errand for many.
Generally speaking the Singapore company is most likely immature in their technology usage and using the Cloud line a data center, focused on servers. If the company did a ‘lift and shift’ that was a poor choice with significant costs.
If the company had custom software and does business primarily on the web, than there is no reasonable comparison that would yield that level of savings.
Anyone who've run on prem server farms at scale...
1. Have you looked at software costs to manage these machines at scale? You think VMware or other VM is cheap? Are you really going to login into hardware/metal? Kubernates and all it's required services aren't cheap, esp if you include labor.
2. How about two data centers? You can't have everything in one fire zone or flood plane. Now you're talking expensive dual site networking at scale with reliability and redundant interconnects. In fact you should use two different ISP in case one have a systemic problem.
3. Have you looked into physical security, how much it costs and 24x7 backup power (enough for entire server room plus cooling system)?
4. How about extra servers and parts, so that if anything breaks you'll be able to replace it quickly?
5. Tried looking at Enterprise grade large storage array and the license costs for them? How about redundant controller so if one shorts you'll still have another?
6. After all that, have you seen the price tag to manage everything securely? Encryption by default? You know how expensive hardened encryption storage vault systems are?
7. How do you ensure your staff have sufficient separation of duties so one person's compromise doesn't take down the DC?
8. And I'm sure all access and SOP processes are security logged and audited by 3rd party, enough to use as compliance and regulatory defense?
9. I'm sure your backup system is top notch right, and you have ability to recover any data with 11 nines of confidence, or you need to design an entire subsystem for this? And restore are timely and predictable?
10. And then you need all the people to hire to do all the above, plus their supervisor, PM, test environments, training, etc.
11. And I'm sure you have funded the next hardware refresh (of every level, not just the VM but networking, new encryption standards, new firewall tech) everything up to date? Or are you still suddenly realized, like many dinosaur, they're still running 100Mbits cat5?
Dude, when I order two EC2 in AWS. I can straddle two AZ (two different flood planes) , cross region backup to another region entirely, restore in pilot-mode with just storage cost until i spin up the secondary region, shutdown the machines when not in use (like many companies when COVID shutdown, either have to double or half, depending), run spot for my dev instances of "what if" experimentation (what if i doubled the CPU or half everything but run with GPU, or run ARM, or try more memory cache or play with IIOPS) without committing to every known hardware combination before I'll know the results?
If AMD, Intel or Nvidia release a new computer, i can try it within weeks without committing to large sums, and when these generations before mainstream, upgrading my older ones to newer family is a 5 min restart, or change my mind in another 5 mins.
Are you sure we're comparing the same thing? Running a data center at that kind of specs, the cloud is way cheaper...
But yeah, mom and pop companies with single disaster plan, minimize everything else, just look at "now": sure, your "PC" is cheaper.
We have all the things in your list, with one exception, we use colo environments, which take care of the HVAC, Power, Physical security, and compliance for all of those things.
We are not a mom and pop shop, but we are also not a large business by any means. Redundant networking, VMware software, storage, compute, etc, etc, etc is about 1/5 of doing it at AWS. It's not even close.
We have some stuff running in AWS, and their instances to employee ratio is far smaller than the team that handles the traditional stuff, and the devops/SRE employees are paid very very well.
We'll agree to disagree. Companies I've worked with when "all in" is calculated, and that includes laying off infrastructure people as well as well those licenses and overhead, do save substantially. Just storage alone the ARR is 34% annually over 5 years. You don't even need to run file servers or hire the experts.
"We have some stuff running in AWS, and their instances to employee ratio is far smaller than the team that handles the traditional stuff, and the devops/SRE employees are paid very very well."
We work with companies whose goal is the singularity: instance count of zero. So smaller isn't a bad news/measure.
The measure of a DevOps team is how much functionality and business objective they produce in unit time, not servers. They're paid well because I've seen one team do the work of 5x their size. They're cheap in comparison, wish we can hire more. The only model that's even better is to move the business function to be satisfied by SaaS.
There’s no comparison of on-prem storage costs, vs. cloud storage costs. Theres a dreadfully high correlation between saving money when you look at your on-prem costs and compare to cheap cloud storage costs.
And that may break open a can of worms when it comes to your files on the cloud being at risk of ransom or some other nefarious breach. But thats why there’s good research and planning into how what kind of data and your use cases for the data. Is it at rest? Is it actively chunked about by a DB? Depending on answers there’s plenty of ways to provision tons of risk reduction using different tools. We’re looking at ShardSecure right now.
But back on track—there is zero comparison of storage costs (our biggest spend on-prem)!
"Mirochnik’s calculations included the cost of electricity, internet service providers charges, IP Transit costs, dark fiber charges, and the cost of operating internal network hardware."
Network hardware, thats like a switch right?... So not the servers themselves, or the support staff, or rack space?
What about installation? Patching? The cost of downtime? The cost of snafus? Sure screw ups happen in cloud, but when you're managing your own kit, the number of parts for shit to happen where you have to own it is so much bigger. Surely El Reg has left a few things off this person's list, or maybe it wasn't that big to begin with?
If you're a hardware operations manager in a software company, you need to tell a good story. When you save the company so much money surely you deserve a raise.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
