Is Cloud the New Mainframe? (medium.com) 86
Long-time Slashdot reader theodp writes: IBM mainframes were the original onsite private cloud," begins retired software engineer Billy Newport in Is Cloud the New Mainframe? And while there were many things to like about the mainframe (including "crazy high availability numbers which today's cloud vendors can only dream of"), cost was not one of them. "As the application usage grows," Newport explains, "the bill grows and the control of the bill is largely in IBM's hands. You use more, you pay more [...] Unfortunately, while compute is elastic, budgets are not [...] Inevitably, customers try to migrate workloads from the mainframe to 'cheaper' platforms but these projects can be very expensive to do and they do fail more often than people realize."
"Today's Cloud kind of looks exactly the same as the mainframe scenario," Newport warns. "Companies have rushed to get on the cloud with the cool kids. I predict many companies will try to rush to reduce cloud expenditure and will find migrating onsite to be an expensive proposition if it's even possible.
"Today's Cloud kind of looks exactly the same as the mainframe scenario," Newport warns. "Companies have rushed to get on the cloud with the cool kids. I predict many companies will try to rush to reduce cloud expenditure and will find migrating onsite to be an expensive proposition if it's even possible.
The old dream (Score:5, Insightful)
The "dream" of having this centralized massive computer where people connect their dumb terminals to and pay rental for computing time.
Many names, many disguises, from time to time this nightmare comes back to life like dracula on that konami franchise, and it has to be put down again before its too late.
One day the megacorps may get to dumb people enough to finally accept it instead of just fighting it tooth and nail as has been for decades.
Re: (Score:3)
But we aren't connecting dumb terminals to the cloud (with some exceptions). The cloud is far more analogous to the commodity servers in a company's data centers today than it is to mainframes. Moving away from mainframes was in part because commodity servers gave more flexibility, and the cloud provides even more flexibility than owning your own servers. The cloud is a continuation of the forces which moved us away from mainframes in the first place, not a movement back towards the mainframe.
Re: (Score:3)
The Mainframe
Re: (Score:2, Insightful)
You've missed the point. These days, commodity hardware underneath your desk is 90% more-powerful/more-capable than whatever commodity hardware you are actually leveraging in your timeshared cloudy contract
Yeah but nowadays, all that power is required to run the modern version of a dumb terminal, bloated web browsers running bloated "cloud" web applications. /s
Re: (Score:2)
These days, commodity hardware underneath your desk is 90% more-powerful/more-capable than whatever commodity hardware you are actually leveraging
I'm not wearing pants. Where are you going with this?
Re: (Score:2)
Cloud makes sense where a business has rapidly changing needs, so it's not worth buying and operating enough servers to meet the maximum capacity requirements that only come into play rarely.
Remember when sites used to get Slashdotted? CDNs solved that, because a site can go from 10 hits a day to 10 million and back again, and the CDN has the capacity to handle the spike.
The other advantage is not having to maintain servers and software yourself. Securing them can be challenging, especially for public inter
Re: (Score:2)
Again, cloud servers...handling...the security, is preferable.
As Microsoft just demonstrated with their most recent major security breach.
Re: (Score:3)
But we aren't connecting dumb terminals to the cloud (with some exceptions).
True, but Cell Phones are the new "dumb" terminal. These days I am doing work for these Large Companies as a Data Entry Clerk for free. Decades ago, I would call someone and say "I want to make an appointment" or "I want to...", that person would interact with their systems.
Now, I sometimes need to spend hours messing with forms on my Cell Phone. I would not mind if I was paid for that. So, I am giving Companies my labor as a Clerk.
So yes, Cloud is the new "Mainframe", already people are paying for Disk
Re: (Score:3)
The cloud makes our computers dumb terminals, a bit more cosmetics, but still dumb through our web browser interfaces or by supplier limited applications that demands use of cloud connectivity to work. A lot of home automation devices demand cloud connectivity to work, so if you lose your internet connection you can't turn on the light at home anymore and your cloud provider will of course know when you are at home.
Re: (Score:2)
Oh, you mean like SaaS? Or streaming media (no need to actually buy storage, like a CD or DVD...)?
not just IBM (Score:5, Informative)
IBM was not the only mainframe maker. There were also Univac, Honeywell, and even RCA in the US, and others in Europe.
Re: (Score:2)
Sperry, Burroughs. It's a long list. Ok, some of them merged together.
Re: (Score:2)
Don't forget CDC. What beasts those were!
Re: (Score:2)
Re: (Score:2)
Don't forget CDC. What beasts those were!
Yup, running NOS [wikipedia.org] -- which, based on my experience with it/them at NASA LaRC, way back, stands for "Not an Operating System." (As opposed to being an admin on their Unix systems -- Convex, Cray 2/YMP, DEC (Ultrix), and Sun anyway ...)
Re: (Score:2)
I never used NOS, but NOS/VE was my first experience with having internet access: crec telnet... Local uni had dial in to the Cyber 8600(?) for a couple years, till they scrapped that behemoth, and replaced it with a vax 8800 I think.
Re: (Score:2)
I used NOS/VE at NASA LaRC too on their CDC systems. I greatly preferred being an admin on the (previously mentioned) Unix systems on their Super-computing network, as it was what I was most familiar with it, having used 4.3BSD (VAX 11/785) and SunOS 2/3/4 at ODU.
Re: (Score:2)
Re: (Score:2)
I don't think DEC ever manufactured mainframes. Closest maybe would be VAX. Not sure about HP.
Re: (Score:2)
Am I missing something? (Score:2)
This article's "ah ha" moment is scaling up costs more money, therefore onsite is better in the long-term? I think he's missing many major points, such as liability, resiliency, global CDN, and basic business practices like budgeting for scaling, both up & down.
Re:Am I missing something? (Score:5, Interesting)
There are appropriate use cases for both cloud and data center. There is some overlap but not as much as there is difference.
Most of my jobs were at places with pretty high 24x7 uses but inevitably some genius new CTO would sell cloud to the board of directors so he could put his stamp on the business and fluff his nest.
Who was responsible to figure out how to move from data center (often multiple global dc) to cloud? Yup, me.
First thing was doing a rough cost estimate for building brand new dc opex (3 year) + capex budget for each. For my loads the price difference over 3 years was typically about 8x more expensive to have cloud. Stretch it to 4 or 5 years and it only got worse for cloud because there was lots of dc hardware that was good for 5 years but rental costs never go down.
Then once in you're cloud it's really easy to lose track of some random cost when you've got thousands of line items going on so nor you have to pay someone for tools to watch and manage your expenses because the Amazon ones suck. It doesn't behoove them to provide effective cost management tools for large scale deployments.
Then you've got to do daily/weekly/whatever review of your cloud usage to make sure you're not flying off the rails so you're spending more time doing paperwork and budget review than in a data center where costs are static.
And of course since everything is easy to pop up and shut down, the CTO wants you to give some devs access to spin up their own servers or even fill environments. Naturally they don't shut them down when done or tell you when they're done so during a review you're looking at a huge ass line item and ask dev manager about some environment and the answer is "oh, I'm not sure, you should ask them if they still need it". Which they don't but it's been running for weeks for no reason.
I've successfully and happily used cloud for long term backup storage, as a DR site, as a secure site for contractors to do work, and as a small well defined site for specific devs teams working on a well watched and managed project. But for 24x7 not very bursty loads, good luck. I wish you well if you moved your entire environment into cloud for non-trivial sized environments.
Otoh, if I had very bursty traffic or needed it for a one off like Christmas season sales or similar then cloud would be fucking awesome. Spin it up after thanks giving. Turn if off after new years. Winning.
Obviously, ymmv, but this has been my experience over the years.
Re: Am I missing something? (Score:5, Insightful)
Re: Am I missing something? (Score:4, Insightful)
Precisely. Cut out the marketing. It's "your own computer" vs. "someone else's rented computer". The rest is an economic discussion about real costs.
Re: (Score:2)
Precisely. Cut out the marketing. It's "your own computer" vs. "someone else's rented computer". The rest is an economic discussion about real costs.
The "marketing" fluff of the "cloud" is that you can offload management, so you aren't taking care of the HW or even much of the software.
In reality it doesn't work that way. You lose the control but you don't gain any advantages.
Re: (Score:2)
There's a discussion in there. There are some minor advantages but some significant disadvantages that are not immediately obvious. The bottom line is that cost savings make you dependent on the cloud provider in perpetuity, and the expense of making yourself capable of shifting to a new provider when the deal gets worse eat up whatever administrative savings there are.
Re: Am I missing something? (Score:2)
And owning a datacenter is quite expensive.
Re: (Score:2)
The cost of building and operating a datacenter for a static environment is actually quite reasonable. What gets expensive is when you did it wrong in the first place or your needs change drastically. Many companies got caught with their pants down having grossly underestimating their reliability requirements and had to spend stupid sums of money to address it. Many companies tried to cut costs by skimping on maintenance and process management. Cloud or Co-Lo work for different things, but the CTO or CFO's
Re: (Score:2)
Re: Am I missing something? (Score:2)
Re: Am I missing something? (Score:3)
Most clouds, including AWS and Azure donâ(TM)t have automatic global redundancy. You put your data in a single âregionâ(TM), which often actually means a single datacenter. As many have noticed over the years, even Amazon is not resilient to weather events and software/hardware failures. If you want multi-region redundancy, not only does it cost money, you also have to add transfer fees from region-to-region and that costs money.
As others have pointed out, itâ(TM)s just shared hosting. I
Re: Am I missing something? (Score:2)
Re: (Score:2)
They'll all certainly sell you very classical VMs, just with more room to scale them up or down or bring more online than you probably have at home; but you are starting to look at architectural changes if you wander into the "managed instance" or "serverless" offerings(Cosmos or Aurora DB; AWS Lambada or Azure Functions; S3 buckets; etc.)
Obvio
Re: Am I missing something? (Score:5, Insightful)
...the CTO wants you to give some devs access to spin up their own servers or even fill environments. Naturally they don't shut them down when done...
This is the biggest problem I see with the cloud. It's that unknown cost increase risk. And it applies to all parts of the topic. In addition to what you said, Devs take shortcuts in their coding because they have "unlimited" resources. They stop caring about scaling or cpu cycles. It just needs to pass the testing. They also go JIT on all processing; no more efficient batch processing or dedicating a single CPU to do one task for the next 30 min. Each atomic action is its own process accelerated by the number of resource workers you apply to it. This ends in high overhead at the hardware level that you eventually pay for.
Management basically encourages this because they want quick turn around and high execution. They get this image by thinking we reduced infrastructure demand turnarounds, without realizing that developers also spent that time thinking about program algorithms and design and collaboration and investment costs and ROI.
I want to add that availability isn't that great with the cloud. When you go cloud, all the pieces are very high availability. But your devs start making a huge complex web of connections and dependencies. And your end2end product issue now encompasses a complex network of functions, infrastructure, vendors, service desks, and ticket tracking.
Even for scalability, if your transaction set is in sync with your competitors or suppliers, the cloud does a poor job of seasonal scaling. Everyone wants it at the same time and that region does slow down (ie: retail in the US) at that time. It works wonderfully when you are offset because you are basically time sharing the hardware.
To me, Mainframes were costly because of being underutilized, and the Cloud is costly because of inefficient over utilization.
The way I see it, 2+2 always has a minimum cost. And getting closest to that minimum is sometimes on prem backend, smart clients, or cloud depends on the situation. It's always a mix of the various infrastructure.
Re:Am I missing something? (Score:5, Interesting)
I am primarily a cloud architect, but I have very rarely seen examples where lifting and shifting an on-premise suite of applications to the cloud is a good idea. For the most part the only times I see it as beneficial is when a significant re-architecture / re-design is taking place, and the company is taking advantage of cloud services far beyond just having virtual machines in the cloud. The business value has more to do with lower development costs and faster speed to market than long term maintenance costs.
Re: (Score:3)
Cloud architect? I never heard that term. I am simply an architect who can implement solutions on the "cloud" if needed. I can't imagine the difference between a good architect and a "cloud" architect...
Re:Am I missing something? (Score:4, Informative)
Cloud architect? I never heard that term. I am simply an architect who can implement solutions on the "cloud" if needed. I can't imagine the difference between a good architect and a "cloud" architect...
Don't be a jerk. I don't have cloud architect in my title, I simply have most of my experience and expertise over the past decade in architecting solutions for the cloud. Knowledge of their specific services is very useful in developing solutions for the major cloud vendors, and generic architects without this knowledge almost always make significant mistakes. It isn't something even genius architects can pick up quickly for a project.
Re: (Score:2)
I can't imagine the difference between a good architect and a "cloud" architect...
You're certainly not a recruiter, then!
Re: (Score:3)
We basically use our own cloud nowadays. Basically, clusters of redundant proxmox servers running in several datacenters. You pay a fixed price for each hardware server you use and that's it. Much cheaper that way and no vendor lock-in at all.
Re: (Score:2)
Proxmox the greatest invention since sliced bread.
We have a local hybrid/cloud provider here where you can rent servers or cloud instances with specific servers. Their support is very good as is the reliability. What is flaky is the ProxMox install image. Always in Beta. Fair enough, ProxMox is so good it would be competition for them.
Re: (Score:2)
We install genuine proxmox from CD through IPMI.
Re: (Score:2)
selectively analogous (Score:2)
"...and will find migrating onsite to be an expensive proposition if it's even possible."
How so? Considering how "today's Cloud kind of looks exactly the same as the mainframe scenario", why wouldn't migrating away from "today's Cloud" kind of look exactly the same as migrating away the mainframe scenario"? Retired software engineer, wonder why?
Re: (Score:2)
Consider that New York State's unemployment registration system (as of 2023) was still running "antiquated" software on mainframes (IBM z-series I think). The original s
It's all marketing (Score:4, Insightful)
Cloud was just a marketing name given to using somebody else's computers.
Not even the same ballpark (Score:2)
The only thing cloud services and mainframes have in common is that there is some central service that "dumb" terminals connect to.
That's it. That's like saying motor oil and champagne are the same because both are liquids.
Re: (Score:3)
Well, mainframes did work, they weren't storage. The Cloud is both like a data center for pure storage and minimal processing, as well as hosting your own servers (why pay and write off the cost when you can rent forever?).
Re: (Score:2)
What do you mean by "did" work? They work now and all over. I guarantee you interact with a mainframe for every banking transaction, flight, hospital encounter, etc.
You just can't get the concurrency and IOPS on anything else. Our business would not be able to operate without our mainframes.
Re: (Score:2)
Sorry, "work" meaning they did computations beyond just storage and retrieval. As opposed to many remote servers which just keep your data.
The decision criteria (Score:5, Insightful)
If you are running a business that depends on computers, but do NOT require those computers to be located at multiple sites, you'd like your data available if your Internet goes down, and you either have a local IT support contractor available or are large enough to afford your own staff... on site is the way to go. If your HQ being disconnected from the Internet means no work getting done, then on site is the way to go. If you want to be able to restore a failed server ASAP rather than waiting for 3rd party support, on site is the way to go.
If you're a small business who can handle the occasional outage, maybe you want to have a lot of WfH without worrying about the office's ISP, if you don't want to think about data recovery or security, if you can't afford your own IT staff - then you go with a 'cloud' solution.
But you always have to remember that 'cloud' means someone else you probably don't know and can't necessarily force to prioritize you now holds your business's data in their hands.
Re: (Score:2)
When was the last time your company lost access to the Internet (and the power was still on)? These cloud providers have outages which will affect your company far more often than the Internet will be down.
It is worthwhile to do risk management which includes Internet outages, but the chance that your AWS or Azure instance is down or having significant performance degradation is far more likely than an Internet outage.
Also, this isn't the 90's. If the Internet goes down you are probably losing a lot of busi
Re: (Score:3)
>When was the last time your company lost access to the Internet (and the power was still on)?
You'd be surprised. I see it fairly frequently... in fact, I see companies with connections they just shouldn't have in the first place, because they're in a rural or semi-rural area and aren't willing to pay for what they should have because it's too expensive. But occasionally there are clients I have who are in urban areas with crappy connections too. Often, but not always, that is again because they're no
Re: (Score:2)
You missed one area: Technical competence. It's easy enough for a large business to justify the cloud, they spent decades cutting IT costs, replacing experts with call centres, and generally underinvested in infrastructure, training, and capabilities of their IT department. You said it yourself "restore a failed server" a scenario that has come up often enough that suddenly the cloud "experts" look very enticing indeed. The sales pitch "what if you didn't have servers to fail!"
Re: (Score:2)
Re: (Score:2)
Interesting that you saw my post as promoting cloud services. That's not what I was doing at all, I think it's for people who can't afford to do their IT properly.
And just as a formality, I should mention that you can stuff your condescension up your ass.
Re: (Score:2)
Interesting that you saw my post as promoting cloud services. That's not what I was doing at all, I think it's for people who can't afford to do their IT properly.
And just as a formality, I should mention that you can stuff your condescension up your ass.
Considering over 90% of businesses are "small business who can handle the occasional outage," and that's whom you encourage can "go with a 'cloud' solution," -- YEA, YOU'RE LITERALLY PROMOTING CLOUD based on every pitch deck and every other media advert since the pre-cloud days of Rackspace (remember them?). And if you didn't realize that over 90% of businesses are "small businesses" then that's really on you.
I'll give you privacy as you already know where to put your ill-advised condescension.
Re: (Score:2)
You certainly have a talent for escalating your dickishness. Shame it didn't occur to you to just not be a dick in the first place.
I expect you're just a dick in general and can't help it.
Re: (Score:2)
You may be projecting your own sense of embarrassment or flustration over the unintentional recycling of their selling points but the underlying point remains the same: While attempting to contain your advocacy for cloud providers and services, you inadvertently highlighted how 90% of
Re: (Score:2)
The two primary scenarios where I see cloud being used:
One, small and medium businesses that don't consider IT to be their primary business and where using cloud services means they need fewer qualified IT people, which are difficult to find and want to be paid not peanuts.
Two, large distributed IT projects where "cloud" doesn't mean Office365, but infrastructure-as-a-service, with a team of DevOps people developing cloud applications.
These two things are very different animals, but they're both called "clo
Containers and Browsers break his paradigm (Score:3)
Similarly to the last time, one of things that is going to drive suborganizations away from the cloud is the way the cloud has become ensconced in a bureaucratic priesthood just like occurred in the mainframe era. Back then you had suborgs going rogue and buying a VAX for their team to cut their reliance on the mainframe. This allowed them to cut their budgets, but a big motivator was it removed the control of the priesthood. I think we will see similar behaviors with the cloud. The cloud relationship, like the mainframe relationships is landing at the corporate HQ where "big decisions" are made. This more than anything is the root cause of cloud malaise that I am seeing.
The cloud is a trap (Score:5, Insightful)
It was designed by businesspeople in order to maximize profit and limit choice
It's designed to be a roach motel, easy to get into, impossible to leave
It reminds me of drug addiction. Feels great at first, until you try to quit
Re: (Score:3)
Only if you become dependent on the services. The issue from the beginning was API lock-in. Minimizing that is the right choice. Anything that is PaaS is to be avoided, or only used with some kind of middleware to permit a switch to a new provider (including local hosting) as needed. Otherwise, your comment stands.
Re: (Score:1)
Re: (Score:2)
Why are you quitting though? You said it, feels good. The reality is in many cases cloud services provide something that was missing: competence and a fully developed platform. AD server gone down? Ha! Who still uses AD, we have a cloud here! Forgot to backup your staff's data? No worries, it's all synced magically on the cloud.
You think I'm joking but the reality is decades of cost cutting has made a large contingent of IT departments completely incompetent.
Current buzzword at my workplace (Score:2)
History repeats itself (Score:5, Insightful)
because people don't learn.
Those of us old enough have known the mainframe world know how liberating personal computers have been when they appeared on the scene: finally you could have YOUR computer running YOUR code on YOUR own terms, and not have to deal with the BOFH with the overinflated ego running the big iron to get time on the mainframe at stupid rates.
The personal computer yanked control away from the fatheads and the rent seekers and gave it to the people!
Those of my generation have been saying for years that the cloud is the new mainframe: one day cloud customers would realize they've been locked in by their cloud vendor and they've been paying through the nose for services they could very well run on their own premises, at least partially, for much cheaper, if only they hadn't fallen for the lure of the short-term savings of not managing and administering their own IT.
That day is coming. Hate to tell you I told you so. God forbid anyone ever listened to those who have more experience...
Re: (Score:2)
Lots of companies are looking critically at their cloud computing bills. Not to mention the hilarity that happens when someone posts the customer list on an unsecured cloud server. More and more software packages are advertising their non-subscription model as a feature too.
Re: (Score:2)
... they could very well run on their own premises, at least partially, for much cheaper ...
Have you dealt with the nightmare that is IT?
You might think we'll just run a server on premises but you're missing the thousands of details that will run you ragged dealing with IT.
Re: (Score:3)
Have you dealt with the nightmare that is IT?
Yes.
You might think we'll just run a server on premises but you're missing the thousands of details that will run you ragged dealing with IT.
So what? I'm not talking about getting Joe-the-accountant to manage the server on his spare time. There are people whose job it is to do IT right. Just like heart surgery and space exploration are very complicated subjects and there are heart surgeons and astronauts to do the job.
The point is that when you do your own IT - meaning you hire people who build and manage your IT infrastructure correctly, at least the part that covers the base needs of your organization if you still want to retain the cloud
Re: (Score:2)
Sounds like you haven't dealt with IT.
If your project depends on some IT person doing a lot of things right, good luck.
There is zero incentive to help you in any way. If everything works great, IT won't even be mentioned.
And, they have every leverage against you since your project completion depends on them and you have really nothing to offer them.
If you do the IT yourself or if the IT team are your underlings, maybe. But, any big institution IT is an absolute nightmare to deal with.
Re: (Score:1)
Shifting back, called "edge computing" (Score:2)
The shift from cloud back to server closets is already happening. Only, this time they are calling it "edge computing".
Yes, there are lots of nuances like processing a sensor network on-site and only sending aggregate to the cloud, but ultimately it means that less stuff is going to the cloud. And if cloud goes down for any reason, you still get to access the on-site elements...
I agree... (Score:4, Interesting)
I agree that migrations to on-prem will happen - some already have and I read about one every couple of weeks. But I was thinking about another similarity to the mainframe environment recently. Back in 1980, when I first wrote Cobol on a mainframe, we'd submit our compile/link/run jobs, and wait for the printout with the results. Since this was a college environment, that wait was often a couple of hours, unless it was the end of a semester, in which case you may have to wait until the next day.
All my work is in the cloud these days, usually involving AWS services such as API Gateway, Lambda, DynamoDB, etc. I do consulting work for large corporations, and they usually have a build pipline. So when I'm working on code, I get compiler or linter errors locally, but then I have to give my code to the pipeline and let it build and deploy it. The wait is usually 15 to 30 minutes, but it can be longer if the pipeline has insufficient resources. I've waited hours for a deployment to complete on on occasion.
In the hey-days of the 90's and early 2000's, most things ran on your local workstation, which was a low-latency heaven. Unfortunately, I fear we've come full circle!
Please Preserve the Personal Computer (Score:5, Insightful)
AI is better local (Score:1)
Nah! (Score:3)
For modern applications the premise of this story may be somewhat true, but for the world's banks, insurance companies, and governments, the mainframe will remain where it is at. Why? It's very simple. IBM mainframe operating systems are completely backwards compatible with the very first iteration of DOS/360, released in 1966 and IBM mainframes are completely hardware compatible with the first 1965-era IBM 360 mainframes. In short, you can run programs written in 1966 on the most modern IBM mainframes without recompiling the programs and they will work exactly as before with the one notable exception that they will run several orders of magnitude faster. The 64-bit Intel (and AMD) CPUs can execute anything from the DOS era but no modern operating system will support it. The same can be said about 16- and 32-bit Windows apps given that support for those has now been removed. MacOS? Nope. Linux? Nope!
Now, in theory, you could install the Herclues emulator in the could and run your mainframe apps in the could but I wouldn't recommend it. Hercules emulates the IBM instructions, meaning it's much, much slower than Big Iron. Keep in mind that modern IBM mainframe CPU's now run at 5 ghz. Also, you might have trouble getting access to an operating system to run on it. Older IBM mainframe operating systems are in the public domain and those can be used for many legacy tasks but if your newer apps require features present in a modern one, you're out of luck because IBM is not going to let you keep it in order to run it on a competitor's environment.
In short, if you are a company or an organization with a large software code base and you've been using mainframes for your computational needs, cloud computing does not offer much of an incentive to move to it.
Clever dumb terminals (Score:2)
But the "dumb terminals" are usually very capable, powerful desktops and laptops.
Even Arm and RiscV SBCs are becoming powerful and very power efficient.
The "cloud" is just keeping us tied to corporate money making machines when we really can do it ourselves.
My partner pays subscriptions for "cloud" Office 365, a "cloud" accounting package and "cloud" web presence
for her consultancy, beats me why she would do it.
She follows advice from The IT Crowd against the advice from the BOFH.
Platforms fail more often than people realize (Score:2)
Crazy high uptime? (Score:2)
And while there were many things to like about the mainframe (including "crazy high availability numbers which today's cloud vendors can only dream of"), cost was not one of them.
Did this guy actually work on a mainframe? I did, and I can tell you that uptime wasn't all that great. As a "computer operator" I had to often take the system down to perform various maintenance operations or system updates. By contrast, Azure runs at about 99.995% uptime. https://www.zdnet.com/article/... [zdnet.com] This is in line with my own experience in both Azure and AWS...the systems almost never go down.
Almost nobody does their own hosting right (Score:2)
Companies complain about the cost of Azure and AWS. But the only reason they can self-host cheaper, is that they cut a lot of corners. They don't do proper updates, or backups, or geo-redundancy, or power or internet redundancy. So sure, you can do things "cheaper" yourself, but at much greater risk of downtime or breach, and lower resilience in the face of disaster.
Thanks Betteridge (Score:2)
No, of course not.
On-premises cloud is the new mainframe.
Cloud is just CPU time (etc.) as a service.
When you say mainframe what you are saying is a monolithic system that takes what you throw at it and offers extreme reliability. You can have that with your own in-house cluster built with full redundancy. That is essentially what a mainframe is, in a box. Instead of multiple identical nodes doing various jobs as needed, they have sub-processors inside the box to do specific jobs. Each approach has its own b
What a timely post. (Score:2)
We haven't had a good "is cloud the new" discussion in, what? A decade? How very timely of us.
Developer laziness (Score:1)