The world was promised 'cloud magic'. So much for that fairy tale Much of the IT community has been willing to tolerate – even encourage – magical thinking about cloud, and plenty of us believed. I did for a moment a couple of weeks ago when I saw what appeared to be a brilliant demo of drag-and-drop hybrid cloud storage management: from a screen that depicted on-prem and cloud volumes, a …
I've been through it, lived it and come out the other side. Despite warning them, everything went into cloud. Internal data centre was closed down, building that contained it was closed, office moved out.
2 years later, production infrastructure is being rebuilt in co-location data centre, cloud is only going to be used for dev and test.
It's the attractive pricing and flexibility of servers that pulls in the thicko bosses, but the shock of the pricing of the extra stuff needed to do it properly that embarrasses them.
> the shock of the pricing of the extra stuff needed to do it properly
... which, in some cases, is you and your cohorts in the trenches. I.e. the big bosses making the "all cloud all the time" decisions are sometimes looking to save (their bonus) money by cutting headcount, and cloud company marketing is often only too happy to perpetuate that false savings.
Colo or datacenter, virtual or cloudy or concrete, somebody still has to run things.
anonymous - because I"m looking for a new contract at the moment :o)
Cloud is the biggest piece of overpriced shit in a LONG time & in IT; thats saying something.
MS, Amazon are promising WAY past what they can deliver, and TRY to get performance stats of any of them to actually hold up to their SLA's. Oh you wanted the uptime we promised & you're NOT willing to wait the 4 hours during your busiest trading period while we wait for one of our Indian call centres to call you back? oh sure.
Apart from the hidden costs (oops a developer uploaded a few TB of data the wrong way, here's a £100K bill in transfer fees) you have ZERO control of the quality of support or the engineers looking after your business. Now, a CIO might happily sign off that risk because he/she is going to bugger of in a couple of years before anyone notices they sold a crock of shit to the firm, but if you're a perm engineer, YOU are going to be left holding the bag at 4am trying to get hold of support. and trying to figure out why your business has gone down because the Vendor didn't mention their datacenter is having some maintenance downtime or forgot to buy enough diesel for an outage.
4 years ago I was talking to a couple of guy from a major outsourcer at a training course for Synergy and they were saying most of their work was migrating back OUT of the Cloud because of costs.
even if you ignore the costs, the loss of control of giving the existence of your business to Microsoft or Amazon is a risk too far
Same here. Was always going to be the case and we are paying eye watering monthly costs which make the old on-premise fixed budget cycle now seem tiny. Was sold the bollocks, the managers bought the bollocks "why aren't we in the cloud" now we have a monthly 80k bill running just a few applications poorly.
We're in the middle of a multi-year effort to send everything into the cloud. Everything.
I suspect that if I hang around long enough I'll be able to witness it all coming back, but I'm looking for a new gig so probably won't be.
About as well as can be expected, thanks for asking.
So if I have got this right:
1. Companies are annoyed at paying fixed server running costs regardless of usage so they move to the cloud.
2. As more companies more to the cloud the available servers goes down.
3. Companies sign commitment contracts guaranteeing them to a fixed number of servers.
4. Economy has a downturn and usage drops, but due to the commitment contracts they are stuck paying for severs that they are not using
So are they not just back in their starting position but now with added overhead?
No, they're further behind as before they at least owned the unneeded servers and could put them aside for future proofing, repairs or just sell them. Now they're still paying out the money, only jt's even more money (just spread out over a longer period), but own nothing and can recoup nothing. It's the age-old rent vs own dilemma. Own and be responsible for yourself, or rent and be beholden to someone who only cares that you pay the rent, not that you get what you're paying for. You're still paying the same costs only now you're also paying for someone else's maintenance and profits. And, let one auto-payment fail, watch your business disappear.
Don't think it really happens? My company will turn off your 100GB data links on a Friday afternoon, and we won't turn them back on until you work with a finance person the following Monday. If you don't clear it up quickly, we send disconnect orders to other providers and you're not getting your service back till you pay the bill in arrears, disconnect out of contract charges, and new install charges with a month-long reinstall wait unless you want to pay expedited install charges.
18 months ago I crunched the numbers for full infrastructure upgrade where I work. Over 5 years the costs came out at over £500k more for cloud, not counting any expansion.
But bosses had heard that cloud was going to save the world.......
So we have a "Enterprise Cloud Solution" - our kit in a datacentre
The cause of, and solution to, all of your business issues.
Pay a third party to manage your core contact with your clients along with infrastructure and backups. Then be amazed as on-prem options are discontinued. Finally, once all your info is stuck in the briar rabbit datacenters, the monthly fees begin climbing. Shareholders need to see improved profits quarter after quarter. Not your shareholders, the Cloud providers'. Their Christmas Party Fund will be topped up nicely.
Be of no doubt. The next step is to replace the on-prem IT staff with cheaper (monthly fee based) Cloud support staff. Why have pesky independent IT staff looking after your infrastructure? All they do is ask embarrassing questions and highlight flaws. You need marketing department approved 24/7 support from Mumbai that only takes five times longer to get a ticket escalated. No complaints about overtime, no training expenses, no HR worries. Just a flat monthly fee for all your IT support needs. The accountants will love it.
They'll appreciate us only when when we're gone. Then freak out at the expenses when they try to rebuild on-prem.
"The next step is to replace the on-prem IT staff with cheaper (monthly fee based) Cloud based people"
Some years back, a public body client transferred its IT provisioning to a third party data centre, including transferring its IT staff to that third party. Not surprisingly, they couldn't get the same level of service that had when it was in house, but it seemed cheaper (opex wise) at the time. I didn't stay long enough to see how it panned out long term, but I guess it got more expensive eventually. So the problem doesn't always have to be "cloud" - just outsourcing to profit-making third parties.
That reminds me of the BT to ComputaCentre fiasco. I contracted for CC at one point and was amazed at the extortionate costs and work they were able to bill BT for; who happily paid out. It was part of their restructure when they sold off buildings to rent them back and TUPE'd a bunch of engineers over to CC.
On-prem, things are much more difficult to manage. We went for a long time on-prem, we had an infrastructure team costing millions in salary per year, but there was always too much for them to do. We had a Ceph cluster, but the performance on it truly sucked as it was run way too close to capacity. We had 3 racks in a DC in Park Royal, but 2 of them were only half full because we couldn't have that much power or cooling. There was constant work for Infra to keep buying new servers, creating new VMs and transferring services from one to another caused constant maintenance work for the software dev teams. Getting a VM was a crapshoot, as we had more demand than capacity, so some servers were overloaded.
Now that we do this stuff in cloud, we don't get so much work for the Infra team to deal with. DB ran out of space? We just get charged some more, rather than replication failing, applications failing, someone allocating more space to a VM and fixing replication. Containers run in kubernetes, with allocated CPU and RAM expectations, and k8s moves them around as needed, spinning up new spot instances as needed. You never get a shitty performing container. We don't have to worry about S3 running out of space or performing poorly or any of those class of issues. We still have our Infra team, but instead of firefighting, they are managing everything and working with software teams. IaaC allows us devs to specify and commission our infrastructure as needed, with their approval.
It costs more, but we get more done, and it performs better too. Software engineering costs vastly outstrip our infrastructure spend, so making that side of things more efficient has a greater effect on the business than anything else - we're quicker to market with our features that sell for money that pays for everything else. Its more reliable - we've had many AZ failures in the cloud, we've never had one that stopped business.
I don't know the costs, and frankly, I don't care. This just works a lot better for everyone involved, except maybe the bean counters, and they can get stuffed.
"We don't have to worry about S3 running out of space or performing poorly"
Except downtime, service degradation, issues with the transit links to their data centers, Cloudflare having a hiccup, or a third party package developer deciding to delete their Github account or losing the key to a ransomware attack.
Cloud comes at a high cost not only in dollars, but in complexity and uncontrollable downtime.
The impact on you depends on how your services are architect, and what scale you operate at. The closer you are to being Amazon sized yourself the less difference it makes, as you will have most of their problems anyway, and they will offer you much better pricing as size brings it's own leverage. I don't have that leverage, and in going to something like AWS I need to mitigate dozens of new risk categories I don't have on my own systems or with smaller scale providers. And even though I wouldn't last a day on the AWS devops team, I can manage our systems with less annual downtime than Amazon because I have so much less complexity to deal with.
AWS is such a complex system it is pretty much impossible to run on a day to day basis without those risks, and even if it were possible there is no incentive for Amazon to invest in more than barely good enough to meet their service levels, because money. So if downtime to the tune of hours is going to cost my client or my organization much pain I'm going to build it another way, because when AWS goes down, I can't walk into a server room and start kicking iron around in a rack. I can sit on my hands punching refresh on my inbox and the outage page.
"Cloud comes at a high cost not only in dollars, but in complexity and uncontrollable downtime. "
AWS has never gone down in its 16 yr history. There have been service outages, a few notable ones as well. There have even been whole regions that have been down, but once or twice in history, for a few of hours. Service outages are regional, not global. There are some global services, but the global aspects of the services, for example, IAM, are the control plane operations, not the data plane. So if IAM has a global outage, you can't create new users, but you can continue to authenticate in the region you operate in.
High availability in somewhere like AWS is a tick box for some services, like RDS SQL. Ticking the box creates a new replica in a new Availability Zone, configures and monitors synchronous replication and auto recovers from failure. A different tick box spins you up a read replica in another region. In other services, HA comes out of the box, like S3, where when you store an object, the underlying control plane replicates the object to three Availability zones as standard. Each AZ is miles apart, with independent power, cooling, network, and transit centre. Ticking the box allows you to replicate S3 buckets to a different region.
It's a lot simpler to have Highly Available workloads than trying to do this yourself. AWS recommends you design for failure; they have a well-architected tool to help you and make you think. There are many reasons to argue against Cloud, I argue that Availability is a plus for Cloud, not a detractor, it's so easy to make your workloads span multi-AZ Multi, Multi Region there is no excuse other than paying hard-earned cash for the privilage.
Yes, and if you are building your own redundant system you have to stand up a second box in a second datacenter. Which also multiplies cost - redundancy is expensive! Who knew??
The main financial advantage of Cloud is it largely transfers you from Capex/Opex to Opex. While Cloud can also bring savings, it is down to the customer to build things in such a way as to realise those savings.
There are other (non-financial) advantages to Cloud, and there are disadvantages as well. Naturally, advertising plays to the advantages.
At the end of the day it is always caveat emptor - you need to understand what you are buying and why. If you are just making the decision on "cost" then it is usually going to be a bad decision.
If your application can't handle a regional service outage, then you must be architecting thinking that there never will be a service outage. Otherwise, you would have had controls to keep you up and running. AWS will tell you that's a bad idea.
If S3 goes down in London, why wouldn't you fail over to Ireland, which is simple to do if you have replicated the data (by ticking the box)? If you lose a VM because a physical Server/Rack/Switch/DC/AZ goes down, AWS ELBs kick in and direct users to the AZ that's working. (by ticking the box).
The whole point of this stuff is to make it super easy to do. You don't need to rent a colo for DR, and you don't need to set up networks, VMware farms, replication, manage capacity, or upgrades, it's all done for you, and all you need to do is tick the box. If you are down because of a regional service outage, you're doing it wrong, and you didn't tick the box that says keep my shit running when AWS shit goes wrong.
>> If you are down because of a regional service outage, you're doing it wrong,
Or perhaps because the VP of IT didn't authorize spending the money on a backup availability zone, because they weren't told by the cloud marketing folks that those redundancies cost actual money. They were too busy focusing on "opex is the big win!".
It's not that cloud in and of itself is bad; the technical benefits you mention are tangible. It's that cloud is (deliberately?) mis-marketed as a panacea to decision makers who should know better, but don't. AWS et al know their target audience: it's the boardroom, not the poor IT sods who have to try to make things work, and need to care about those necessary features and functions and details, which cost real money.
"AWS has never gone down in its 16 yr history. There have been service outages, a few notable ones as well. There have even been whole regions that have been down, but once or twice in history, for a few of hours. "
An immediate contradiction of yourself. Do I care if some schleb a thousand miles away is up when I'm down? Absolutely not. When I'm down it's MY business not making money, and all the uptime in the world makes no difference if only my service is down. Whole regions down for hours? That's a LOT of customers who are down and not making money. That's like saying California has no rolling blackouts when only 99,000 people at a time are down. Do I care that a city 20 miles down the road has power while my ice cream is melting?
Therte's a world of difference between paying for on-prem HA and paying Amazon for equivalent HA. The cloud setup is more expensive to architect, and for the use cases I have worked on, significantly more expensive to migrate to.
There's also a world of difference between AWS as a whole being considered as the entity of importance when looking at availability. Plenty of AWS segments have become unavailable to the end user, which is directly causing customer downtime.
It's the equivalent of measuring someone's workrate by the amount of hours they're alive, and not the amount of hours they're present in the office. Two completely different metrics. You've presented one metric that is effectively meaningless to most customers of AWS, who have suffered specific outages as a result of AWS downtimes.
AWS is not a panacea by any definition other than yours.
let me guess, you're in your 20s and haven't REALLY worked in the enterprise environments.
A well run Cloud environment needs to be MORE tightly controlled by the Infrastructure Team than internal hardware.
If your infrastructure team isn't able to track storage and order new kit before it runs out, then thats their fault or the finance department.
YOU might not care about the bean counters, but I bet you'll care REALLY quickly when the Cloud spend goes through the roof, the applications are too expensive to pull out back in house and they fire a load of developers to bring down costs.
Surel, this article was aimed at the typical IT Pro who misses hugging their racks or polishing them. Using the cloud to run infra is a colossal waste of money, you choose a cloud platform for its PaaS offerings. In a cloud native world, Developers rule the roost, unlike the days when Bob&Alice would ask for 10days to provision a server. The way I see it is more and more PaaS adoption will be the pathway for public cloud adoption.
Sorry, I have seen another side of this argument and we have been successful in not only keeping costs low, but getting maximum value - keep the ops folks out , run no VM's all will be fine.
Spot on. If you use the cloud to basically buy VMs, and shift your on-prem kit into a cloud provider nut-and-bolt for nut-and-bolt, and then keep on hiring all the same people to maintain it all, then yes, your costs are going to be stupid.
But that's not what the cloud is for. The cloud is the tool that enables you to fire your DBAs, and your Linux specialists, and your Kafka administrators, and your networking guys, and replace them with off-the-shelf services like persistence, container hosting, messaging, and connectivity. THAT is when Cloud starts to make real financial sense. It's not about moving capex to opex, it's about taking a huge chunk of your existing opex - staff liabilities - and moving into a different opex. Although unlike staff, this one has an SLA attached to it, and predictable long-term pricing.
Quite apart from that, Cloud often 'appears' expensive not because it is, but because the costs are actually visible. An awful lot of on-prem deployments rely on being cheaper because there is a hidden "assuming we are hiring all the right people with all the right skills to maintain this shit", which more often than not is not the case. So a line-item on a cloud invoice is instead moved to a risk - your on-prem solution is cheaper right up until the day everything blows up and the specilists who know how to fix it resigned 12 months ago and were never replaced.
Anonymous because for the apparently increasingly aged Reg readership, this will be hard to hear...
"your on-prem solution is cheaper right up until the day everything blows up and the specilists who know how to fix it resigned 12 months ago and were never replaced."
As opposed to "your cloud solution is cheaper right up until the day everything blows up and the specialists who know how to fix it were fired 12 months ago and were never replaced.".
You can get away with de-skilling your IT for so long, but it will eventually come back to bite you.
(And cloud systems look like being the next decade's legacy systems if there's no-one to maintain them).
"It's not about moving capex to opex, "
Bollocks. That is precisely how cloud is often marketed and sold to corporate decision makers and their accounting department.
"The cloud is the tool that enables you to fire [IT staff]"
Oh yes, and that too. The accountants and execs like that part as well.
Nevermind, leaving your tech estate in the hands of a 3rd party company who does not share your priorities or concern for your products.
I don't consider myself a rack-hugger, I just want to provide a service. However, it's not as simple as you claim. You ask for Cap-Ex to expand your on-premises capacity, and it needs to go through a whole approval process. I think minimum in our chain is 9 people, and normally about 11. Meanwhile your request sits and waits.
If you time the request right, just after some capacity is purchased, it can be provisioned quickly. Otherwise, Infrastructure group gets the blame but Management is the root cause.
The cloud can help with the agility aspect. And it can provide some insight in cost. But it's not a magic bullet. I don't think anyone would apportion out the cost of an individual cloud router, probably just a portion of the "infrastructure". (Dilbert, ca1999: Infrastructure is what everyone wants but no one wants to pay for)
Lift and shift of static workloads is by far the worst way to go cloud. Refactoring applications to take advantage of cloud elasticity is the way to go. Or SAAS.
Now, with our Change Advisiory Board, we have 10 steps of IT approvals to get, as well as 10 financial approvals, just to provision a server in the cloud. There is not a thing on the planet that can't be made worse by Management.
Off premises data centre in unknown jurisdictions.
Funny it looks just like a mainframe to me.
Same lack of control over your resources.
Same data under the control of your data.
Only without the painstakingly (over a very long time) developed management tools.
"It'll be cheaper."
I've never seen a salesman tell a potential customer "Oh yeah it'll cost a fair bit more." Bu***hit. Won't happen. No salesman will do that. Ever.
And when the costs grow.....
"Well we made some assumptions that don't appear to be correct in hindsight. Sorry about that. Here's the bill anyway. And if you don't pay up we'll cut off your access to your data. Your our b**ch now"
"...Funny it looks just like a mainframe to me..."
I came to say exactly this!
For a few decades, there was a massive push to get a computer in every home and on every desk to give you, dear users, control.
As with all things we've gone full circle.
I worked for one company who had their own power station on site because they ran a massive manufacturing plant.
And yet the MS salesdrones repeatedly tossed out the line "you save a stack of cash on electricity and cooling when you move to Azure..."
$300 per month for an SQL db that runs slower than it does on a 10yr old desktop.
Azure is overengineered, forcing simple setups to have a ton of little tweaks and additional modules to get running properly and secure. Add in the nightmare that is MS's naming conventions and their menu system.
Absolute rubbish
I can fully confirm this. Tested Azure deployments of Linux machines, the hardware offers performance at 2014-2015 Xeon level in benchmark tests. It is abysmal for the prices that are charged. Also pricing schemes are sickening, The hardly usable base model is cheap, usable configurations with like 2 cpu's and 8GB become expensive quite fast.
The premium they charge for "easy" is high. On top of this comes the uneasy feeling about the obligatory processes included in the distro's that are deployed in the cloud, they run with the highest privileges.
The success of cloud is also caused by the fact there is no middle ground between doing everything oneself and using cloud.
Hosting services have a huge opportunity to provide services taking away the main headaches resulting from owning physical infrastructure.
Bookkeeping rules encourage transition to cloud as well, it is weird that paying for debts is considered bad but monthly cloud payments are valued higher than doing periodical investments in self owned computing assets.
Headline» The world was promised 'cloud magic'. So much for that fairy tale
On the contrary, haven't you seen the profits made by the cloud providers?
The Cloud is indeed a fairy tale for Amazon, Microsoft and friends.
The purpose of companies is not to be honest, think about their customers' best interests or even improve the world but to make money and this is exactly what the cloud providers have done.
Cloud must be used right.
Any VM / lift&shit you buy will be way more expensive in the cloud. We used to say 8 hours/day was the break-even point and if your on-prem hardware lasts over 3 years, it was even less you could afford to run cloud.
But, some cloud services makes sense. Running scalable cloud apps, databases etc. And you should be aware what yopu get included. You don't need anybody maintaining the stuff below.
But infrastructure as a service is bad,.
Over 40 years of working in and with IT has shown me that there's nothing new under the sun. The cloud is, and will always be, facilities management with your valuable data in somebody else's hardware. Now the big providers have got your data and software you are their hostage. Apart from pretty pictures of butterflies and unicorns on the GUI there is so much that we do today that we could just as easily do on a green-screen (multi-colour you AS400 folks) system. The cloud just like a fancy GUI is a fiction dreamed-up at a time when providers were feeling a financial pinch and needed a new revenue stream, and we all fell for it.
Who would have thought that releasing control of spend from the centre to the edge where people didn't care about spend could have any issues?
Surely we all know that big tech vendors can always be trusted and have our best interests at heart!!
Imbecilic IT leaders rushed into the cloud without any semblance of due diligence and ignored any naysayers because "Vendor X told us that lifting and shifting will reduce costs"
Looking forward to endless posts from cloud vendors parroting the inaccurate line that cloud is cheaper using a comparison from 10-years ago that was wrong at the time
This may be a little long but i think background is required..
I have spent most of the last 3 years with my team, Me + 1, preaching that you need to test resiliency (DR). Since this is a very large org, it was decided all IT, with limited exceptions would be migrated to "The Cloud".
The App Dev teams all look at you like" you do not know what you are talking about" when you mention it early on in the dev cycle.
The cloud is always on, we are in multiple compute zones, we can auto failover if there is a problem.
Me: Are you in multiple geographically dispersed zones?
Them: no no need to be the cloud is always available.
Me: So you decided not to follow the corp architecture guidelines for mission critical applications.
Them: We were not willing to incur that expense.
Me: What happens if the datacenter where this is located becomes unreachable?
Them: Can't happen.
Then you know what happens next, the Zones became unavailable and only those who followed the corp standard and actually tested the recovery, were able to continue with on like nothing happened.
The others had to explain why they did not and having a email trail from the Resiliency Team to the various businesses that did not follow standards and resiliency test had a lot of explaining to do and there were a few head that rolled.
But since I am just an engineer and don't understand tech, I was ignored, but not anymore...
My other favourite answer to the DR question for cloud apps is "If AWS is down,our customers won't care because so much else will be down."
Or if you ask the smoking hole question, the answer is, "If northern Virginia is a smoking hole, our customers will have much bigger concerns than their data being completely gone."
And the correct response is, "It doesn't have to be large smoking hole in Northern Virginia, just a very small smoking hole in the right place.". Buildings do occasionally burn down without taking the surrounding 30 mile diameter with it.
Customers always make a false comparison when looking at the price of a cloud vs home grown architecture. They fail to consider that a cloud architecture includes access to unlimited compute and storage on demand across the globe. Compare that to what you would have to pay to replicate that architecture in your own.
But with great power comes great inefficiency if you don't know how to architect for a cloud native architecture. That is where the true savings come in.
To take best advantage of the cloud your team has to adopt a new way of application development.
If you don't take full advantage of what the cloud vendor has to offer then you are gaurenteed to have run away bills.
Just check out The Duckbill Group for dinner great war stories.
I called the digital stack SMAC - Social Mobile Analytics Cloud - and warned about the gotchas in moving from onprem to cloud in https://gtm360.com/blog/2017/02/24/thriving-on-chaos-of-smac-architecture/ five years ago. Just realized that, by rearranging the names of the technologies, the digital stack could also be called SCAM. This reminds me of what Malcom Gladwell said about prospectuses of toxic structured financial products sold at the height of GFC: “It’s like saying, ‘We’re doing some really sleazy stuff in footnote 42, and if you want to know more about it, ask us.’ And, gee, that’s the thing, nobody did.” The SCAM in cloud was hidden in plain sight! It's our fault if we missed it!!
I've been using Azure and AWS in equal measure, and it's astonishing how quickly you rack the costs up.
You have to be watching it every day.
Just the other week, I wanted Azure SQL to push executed query history into Log Analytics....
It's a logging system for goodness sake....
I was staring down the barrel of 1000 of your finest Sterling PER DAY, but only after someone questioned the extra 6000 that appeared in the Cost Analysis screen.
That it was spotted was purely accidental, because they went to the Costs for something else and spotted the 'anomaly'
Callling it an OpEx vs CapEx ?
No! Call it for what it is, a sinkhole of cash - however you account it.
Over the past years, the company I work at has moved most of its infrastructure to the cloud (mainly AWS), and I was surprised to find that the fabled cloud was actually shockingly
- Slow (my laptop outperforms some of the VMs we get)
- Unstable (some sort of outage roughly once per month)
- And apparently the cost savings are also not that great
The IT admins I spoke with could not really refute the above claims, yet our direction remains unchanged. For some reason, the higher-ups still believe that cloud is the best thing since sliced bread. Were they hit with some kind of hypnosis ray, I wonder?
I still hear many developers and IT managers drinking the Cloud Kool-Aid, thinking it will save them a bundle, when in reality it will burn a hole in their wallet. This is all due to the excellent marketing both Microsoft and AWS have spun on them.
Renting a modest VPS is ussually much cheaper and you can host as many websites on them as the compute capacity will allow. If you need more disk/memory/compute capacity it's ussually just cranking a slider to the right and you're done.
I sell cloud infra for a living.
On a VM by VM basis cloud can look more expensive (especially when you ignore the hidden costs of on prem).
However what I often see is customers wanting to compare like for like. It does not make sense. On-Prem you have to size for
peak to make sure you have enough infrastructure available when you need it. In cloud you don't need to do this, You can spin up an
instance is seconds and shut it down (not shutting down is also a cause of increased cost).
But also consider lead times for new infra. How much does it cost you, when you have a bunch of consultants sitting around waiting for
delivery of that new storage array, new rack of servers and setting it all up?
Are your developers empowered to try something, or do they need to go through a long winded negociation to get hold of some more infra
which may have to be procured and if what they want to do does not work it's sunk cost. You don't really have the concept of a throw away instance when you are on-prem.
Then look at security. It is no longer true that on-prem is more secure compared to cloud. Is your investment in security anywhere near what the hyperscalers pay?
We have clusters of systems with headroom in both cpu and memory. If memory hits 80% across the cluster, we start the server acquisition process. It does not take long to get a server to the colo, racked and added to the cluster. The longest part of the process is the approval from the bean counters.
The hypervisor we use also has compression and deduplication for memory built in. Our storage array also has deduplication and compression built in. Some app servers deduplicate at rates of 90% when it comes to storage. If we turn them off, we pay nothing. Our storage environment also provides SSD level performance to every VM. Go look at the cost to provide a single AWS EBS with 20k iops. Now multiple that by 10s or 100s
And yes, we have some systems that are busier at different times of the year than others, but we are always constricted by memory, not cpu or storage resources. We have 20% free at all times, so even if we need to clone a bunch of VMs to keep up with demand, it's already built in and no additional cost is incurred.
All of this is available at 1/5 the cost of doing same in public cloud. The only hidden costs not included in that figure are the staff to support it. We also have cloud only apps in our company, and while they don't have infrastructure staff, they have SREs which is just the new term for systems engineering, and they don't work for less money.
As to security, your statement is just plain wrong. The security at public cloud vendors is only as good as their staff, and they are also a much bigger target. I also don't believe that if one of the major cloud vendors had a serious breech that the public would find out about. Of course they spend more money than we do on security, but that does not translate into our environment being less so.
I get that cloud is a good choice for some apps and some environments, but the nut of this article is that the magic bean notion that cloud would be cheaper in any way is just absurd. The absurdity is that it isn't even close. Devs make like it better, but for some reason that never translated into asking the question of why devs can't have an environment in house that would be as easy to deploy with. The bean counters where I work are asking that question now as we spend 5x more for cloud instances than we do for on prem.
Back when I started at my current job, we set up a Jenkins server and build slaves to run our builds. It ran perfectly happily on three ancient desktops hidden under a desk in the lab. It even failed-over nicely when one of the slaves died. A load of the other builds then got moved to the cloud, but my stuff stayed on-prem because no-one was prepared to pay for AWS for my project.
One new company, two new sites and four servers later, the lineal descendants of that setup are still running perfectly happily as low-priority VMs using the spare CPU cycles on our file server. It costs us basically nothing beyond 2-3 days a year for me to go round applying updates to the various VMs.
My shop got suckered into a very bad hosting contract, the company fleeced us and they kept jacking up the prices. There was a "coup" in management if you will and after much working out it's actually saved us tons simply porting all the servers direct into Amazon hosted instances like-for-like. We've no intest all the microservcies codswallop, it's just pure simple hosting. It forced us to have a good rake through hundreds of hosts and sort out the crap, decom, remove, co-lo, amalgamate and we're far better for all the hard work now. Cloud stuff is expensive and if you're not saving anything, don't even bother but for some it can be a useful option if you're coming from a very old, stagnant set up that needed some TLC.
I was skeptical of cloud infrastructure from day one because in my entire career I had never and have never seen anything close to the hard sell behind the cloud.
We all know what this was about: companies forcing customers into recurring revenue models even though they're no longer adding much (or any, or even negative) value to their products so that they can maintain their P/E ratios and stock prices.
That being said, there are many companies that can benefit substantially by moving their infrastructure to the cloud. These are the companies whose CIOs and Vice Presidents of IT are so thoroughly inept and run such bloated, inefficient trash fires of departments that moving literally anything further outside of there sphere of influence can save lots of money.
AWS, Azure, GCP etc, are the best run DC's on the planet.
Use them as intended - Cloud Native - and you will benefit.
Use them for IaaS, and prepare to suffer a "Denial of Wallet".
Shift and lift, not lift and shift.
Customers should build SDDC's on-prem but keep Dev and Test + initial release (1.0) of apps in the public cloud. Plan to run all apps from V 1.1 up on-prem but using software-defined network / storage / compute / etc as if it was public cloud.
Have several customers doing this.
Because you can optimize for those as you know exactly what you need and what you will need. In these places, a three-month long capex approval process followed by another three months of server builds and configuration is simply ok because these requirements are not urgent. Of course, assuming you don't hit any capacity limits on other places, such as power, air conditioning, rack space, etc because then you'll be facing a much larger capex increase and setup process on that case. But that's not a problem on your 5- or 10-year-old application because you really know what is going to happen in the next year.
Things are quite different on dev environments or on places that cannot easily project their growth. You cannot simply wait three months to get a product feature rolled out or expand some capacity limit. In the on-prem world, you either have planned a year in advance for those events, or you're dead. In a cloud this is not usually a problem.
Also, on an unrelated note, all comparisons I've seen for on-prem vs. cloud costs tend to favour on prem by quietly ignoring some infrastructure costs. Rarely I've seen all of real estate, power, cooling, cleaning, staff, bandwidth, backups and redundancy (for all of these) properly accounted for. On prem assume "zero" on some or all of them because they draw from some already amortized on prem item.
I only just came across this article the other day and found it very interesting not just for the article itself but for all the comments.
You can pick cloud evangelists and those who work for the big three cloud providers a mile away.
I do find it amazing how worked up people get over this debate and personally find IT tech pros now fitting into two categories with this.
You have the die hard cloud evangelists / cloud providers who are stubbornly holding to the "ra ra cloud" catch cry and refuse to be convinced otherwise.
You then have the IT pros who yes, still work with on prem kit but who have the skills to know how to mesh solutions all together.
For the cloud evangelists who think the cloud is going to feed every starving child in the world and going to bring forth unicorns and rainbows all day everyday, just take a breath.
Yes, the cloud does have it's advantages and has shaken the industry up.
However, to say that public cloud is cheaper and more secure than on premise is just plain wrong.
There are WAY too many examples of cloud bill shock now and look at the exponentially growing rates of cloud repatriation because of it.
AWS and Azure have cloud economics that are so bloody confusing and extensive that most of their own staff don't even understand them.
They also don't care for helping customers optimise the costs as it doesn't help their profit margins - "oh well, you consumed this service now cough up" is really becoming tiresome for a lot of customers.
I am seeing this is my region all the way from SMB up until the top companies - it's not limited to a particular environment size.
At least people with decent on premise technical skills can help mesh on prem environments with public cloud for decent hybrid environments or even build public cloud only environments as they have the technical fundamentals understood.
I consider myself cloud pragmatic and if a public cloud service for a customer with the right use case makes sense, then awesome - use it.
It should be another tool in the box and used as such.
I am sure people here remember when Gartner 10+ years ago was predicting most workloads and data were going to be in the cloud by the 2020s.
How wrong was that?
I would love to know the payday Gartner had for skewing that market research for AWS and Azure.
I do recognise cloud can be very effective with workloads that can be spun up and down dynamically as needed and even better, removed quickly when no longer required.
Then you are very likely going to see financial benefit.
However considering a number of workloads these day need 24x7 availability, I'm sorry but if it's not SaaS and some PaaS offerings, it doesn't add up cost wise.
I also don't buy into the myth that cloud is way more secure.
Sure - the cloud vendors invest a lot into security but look at the size of their environments.
The attack surface is so vast, I refuse to believe that have every entry point covered.
Also considering public cloud API is becoming one of the most common attack vectors as well (some global security analysts have this as THE number one attack vector) that does start to take the gloss of this shiny solution.
Also look at the cross tenancy vulnerabilities that Azure and AWS uncovered last year.
Again they will tell you we got to them before hostile actors but I pose the question - did they?
We all know that very smart hostile attackers will breach, see if they were detected and if not, stay in for very long periods of time.
They will be very patient and meticulously plan when they will strike and how.
Do we have sleepers sitting inside AWS / Azure just waiting for the right time?
I use cloud, albeit sparingly (moreso after the LastPass hack), within my own company and will use it where it makes sense.
However, I don't think I will ever recommend to a customer to go 100% public cloud but if it's the right tool for the right job, go for it.
I also predict within the next 5 years or so , one of these providers is going to be so crippled by a massive multi regional, global hack that will have such far reaching implications, that the cloud industry will be shaken to the core.
My two cents worth :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
