[HN Gopher] Is Cloud the New Mainframe?
___________________________________________________________________
Is Cloud the New Mainframe?
Author : as17237
Score : 21 points
Date : 2024-01-26 20:09 UTC (2 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| dusted wrote:
| Give it a bit of time, and mainframe become the new cloud, but
| only after a cycle of "everything on site[1]". This is not an
| industry that learns from the past when scrap can be acquired by
| relentless fashion grifting.
|
| [1] Edited as I discovered that premises is not simply plural of
| premise [2]
|
| [2] English is not my first language
| CharlesW wrote:
| FYI, "premise" is a foundational idea or statement, so in this
| case you want to use "on premises" or "on prem".
|
| The premise of my response is that you'd find value in knowing
| the difference and will take it in the positive spirit in which
| it's intended.
| api wrote:
| My biggest personal gripe with developer culture is how utterly
| historically ignorant it is.
|
| There's a general recency bias in the field where computing
| knowledge works like a social media feed. New ideas and new
| projects are at the top, and old stuff just falls off the
| bottom regardless of merit. Then someone re-invents it, often
| claiming credit (not deliberately dishonestly because they are
| ignorant), and then it runs its life cycle and scrolls off the
| bottom. Repeat, forever.
|
| There are a small number of things like very popular languages
| and OSes that have staying power but the rest of the ecosystem
| is fads and churn.
|
| There is some progress under the churn, but the actual progress
| is almost in spite of the fashion chasing. The churn just
| forces us to do a ton of extra busy-work re-implementing the
| universe constantly and chasing fads to remain compatible.
| hprotagonist wrote:
| Hasn't this been obvious for a decade or more?
| mxuribe wrote:
| Perhaps obvious for you and I (and some others too), but not
| for everyone...Because i'll make the assumption that you and I
| (and some others too) are living in the future. But, like the
| saying goes: the future is already here, its merely unequally
| distributed...Or something like that. ;-)
| foobarian wrote:
| I mean... the very first few sentences of the Multics paper
| intro say it:
|
| > One of the overall design goals is to create a computing
| system which is capable of meeting almost all of the present
| and near-future requirements of a large computer utility.
| zwieback wrote:
| No, mainframe had almost exclusively dumb clients, at most some
| local display trickery but cloud is way, way more distributed. I
| think the main point is valid though: distribution of SW is now
| much easier, the stacks of floppies of my youth are luckily a
| faint memory.
| bytearray wrote:
| Cloud is the new mainframe, Kubernetes is the new job manager,
| microservices are the new COBOL.
| moandcompany wrote:
| In many cases its the new mainframe, but with more opaque, and as
| a consequence more fragile, abstractions
| g9yuayon wrote:
| IBM Mainframe was an answer when computers couldn't vertical
| scale fast enough. Cloud is the answer when our systems couldn't
| horizontally scale fast and reliably enough. So, the real
| question is: can we really scale our need of computation again on
| a single computer or on a set of computers with low enough cost
| to render Cloud unnecessary?
| KaiserPro wrote:
| > Cloud is the answer when our systems couldn't horizontally
| scale fast and reliably enough.
|
| Not quite, the cloud forced you to figure out how to scale, do
| reliability and all the hard parts, mainly because AWS didn't
| offer any features like zero downtime VM transfers or any kind
| of pracitcal storage migration.
|
| The point of the mainframe is that its almost like a really
| fucking huge lambda function host. You sling your app on the
| mainframe, ask for resources and let it run. If you run out of
| capacity, buy another mainframe and link it to the old one.
| Need a new region/reliability zone? pay a license, install a
| fat network link and jobs a goodun.
|
| There are videos of where HP/IBM literally blows up a mainframe
| to prove its auto failover skills.
|
| THe cloud is a poor proxy of what a mainframe _could_ do at its
| best. But its a reasonable facsimile of what a main frame did
| at it's worst.
| candiddevmike wrote:
| And this tight coupling of code/process/data/apps to the
| platform is why mainframe migrations have a strong tendency
| to crash and burn. Folks should look at mainframes as a
| cautionary tale of "platforms".
| akira2501 wrote:
| > can we really scale our need of computation again on a single
| computer
|
| That door has been closed to chips built on CMOS for a long
| time. It's why we started scaling horizontally in our chips by
| adding more parallel cores.
|
| > to render Cloud unnecessary?
|
| The advantage with cloud is, the machines can die, and I'm not
| severely impacted. A new lambda machine will spool up, will be
| sent my function, will receive a copy of the asynchronous event
| to start working again.
|
| This, personally, is why I love the cloud. I no longer have to
| worry about the mapping of code to the hardware that will run
| it. I pay up front for designing my code around the
| architecture, but I win every time it runs in that I have
| essentially zero maintenance overhead associated with it.
| as17237 wrote:
| Scalability from cloud providers masks inefficient code. In my
| opinion there are a lot of applications that can significantly
| reduce resource utilization if enough attention and care is
| given by the developers.
| foobiekr wrote:
| Cloud was actually the answer to "how do I give more
| virtualized compute to people without hiring more expert server
| and networking admins."
|
| The rest is noise.
|
| Startups aside, most enterprise teams match the following: apps
| don't need to scale massively (scale up is enough and a
| surprising number of large, well-knwon services are entirely
| based on scale-up architectures behind the facade), most don't
| need dynamic scale, and most aren't even going to be started
| and stopped dynamically.
|
| But hiring people who can run a network, only to have them sit
| idle most of the time or - and this is common - doing things
| and as a result breaking things, and people who can run servers
| and VMware and so on, and firewall, and WAN connectivity, ...
|
| A lot of these things are, in fact, trivial, but vendors made
| them stupid and hard and painful to set up and doubly painful
| to troubleshoot. Cloud exploited that situation.
|
| Things aren't a _lot_ better now but they're somewhat better,
| and now the economics of cloud are starting to get looked at.
| g9yuayon wrote:
| > how do I give more virtualized compute to people without
| hiring more expert server and networking admins
|
| I put these into the bucket of productivity and low cost. And
| this issue arises when we need to scale our business, in
| particular our computation.
| johnklos wrote:
| For all the redundancies that exist, "cloud" isn't reliable and
| therefore can't replace the mainframe. Then again, most things
| don't need mainframe level reliability, which is why Microsoft
| Teams (and other Microsoft services) is problematic today.
| kmoser wrote:
| It's not just a matter of reliability: mainframes allow tighter
| coupling between different parts of your application, thus
| faster performance, since everything is (or can be) essentially
| on the same hardware that is optimized for data processing.
| Cloud services are getting closer to bridging the gap, but for
| some applications mainframes will still be the only way to go.
| One main advantage that cloud has is you can distribute things
| into services that can be hosted anywhere: the same cloud
| service, a different cloud service, etc. Yes, you can do that
| with mainframes, too, but in the past mainframe software wasn't
| written with that flexibility. Today, everything is all about
| distributed microservices.
|
| As to the article's premise that people are getting locked into
| cloud services as they used to get locked into mainframe
| services, you could make the same argument about any tech:
| write your app with language X, and you'll have a hard time
| translating it to language Y. Write a low-level app that runs
| on Intel chips and you'll have a hard time porting it to
| Motorola. That's the nature of software development.
| api wrote:
| It's a haphazard half-baked re-implementation of a lot of
| mainframe ideas with an extra helping of YAML and more rent
| extraction schemes. Plus it lets a whole generation think they
| invented these things (virtualization, containers, orchestration,
| containerized deployment, dynamic block storage, ingress/egress
| controllers, terminal aggregators, ...).
|
| Now that people are getting sick of cloud I'm sure we are going
| to re-invent personal computing now with entirely new terminology
| and re-implementation of all the original ideas. Just please no
| YAML.
| quonn wrote:
| How can it possibly be more rent extracting than the mainframe?
|
| Also openness, choice of vendor, invisible hardware and
| virtually unlimited scalability are different.
| KaiserPro wrote:
| If you are running serverless stuff then kinda.
|
| in terms of expense, then also maybe, but the point of a
| mainframe is that you got scaling and reliability as part of the
| cost, without having to think about it too much. The cloud puts
| most of the responsibility on you. you still can't live migrate
| processes from VM host to another VM host in AWS.
| GMoromisato wrote:
| The article implies that Cloud is bad in the same way that
| Mainframe was bad. But I think we need to distinguish between the
| technology (HTTP-based, public internet services) and the
| business model (subscription-based SaaS). The latter may be bad
| in some cases, but the technology is here to stay. No one is
| going back to proprietary client-server systems.
|
| In fact, I think we can learn from the Mainframe. Mainframes had
| a much more cohesive and unified platform. I wish we could write
| a unified program (not a decoupled frontend/backend) and have it
| run on an abstract, scalable substrate (which happens to be
| implemented on a distributed system).
|
| Shameless self-promotion: I wrote about this a while back:
|
| Rise of the Hyperplatforms: https://gridwhale.medium.com/rise-of-
| the-hyperplatforms-d4a1...
|
| GridWhale and a Brief History of Computing:
| https://gridwhale.medium.com/gridwhale-and-a-brief-history-o...
___________________________________________________________________
(page generated 2024-01-26 23:01 UTC)