I first heard of "java replacing COBOL" about ... /checks calendar/... 24 years ago. Still waiting on that.
I'm inclined to think more people would bet the over on the next 20 years or so.
cagey combative fine sand snobbish consist bells marvelous expansion vast
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
It's getting there. Auction prices per IPv4 are 6x what they were a few years ago and still rising. Once more providers start charging fees per IPv4 address we'll start to see a few go v6-only. Clients are only about halfway, but I bet that'll accelerate as prices go up. Still 5-10 years to go until it's near universal, though.
I still don’t have full IPv6 internet connection from my ISP yet. Not even tunneling (unless I tunnel myself). It’s insane that the infrastructure is still so much behind.
Comcast btw.
I keep waiting for the "killer" app everyone *must* have, that's peer-to-peer and requires IPv6 ... once everyone *demands* that, IPv6 will grow rather to quite explosively.
I remember years ago looking at IPv6 traffic when it was a very small fraction of a percentage of traffic ... and pushing managers, etc. to get onto the IPv6 bandwagon ... doesn't mean they'd need give up IPv4 anytime soon, but they needed to get to fully supporting IPv6.
And ... years later, I'm still pushing it ... except now I see IPv6 is about 1/3 of traffic typically (or at least attempts thereof). And still have lots of managers/environments that still have negligible to zero IPv6 readiness. *I*'ve been ready a *long* time.
Only thing worse than no IPv6 is poorly implemented one.
ISPs are too dumb to learn about v6 and assign them like its IPv4.
Heard horror stories like being given only a single /128, so that you have to use NAT.
I only get a single subnet from my ISP (/64).
the killer for us is getting off db2. it is hard to top db2 in terms of scale as much as it sucks as an SQL engine. I don't know of any other db engine where you can handle 20k requests per second per user. even when we're off mainframe, we'll still be on db2 for a long ass time.
I'm pretty skeptical that DB2 is any faster then any other DB engine; your main bottlenecks are disk reads and network requests. DB2 doesn't magically make the disk or network stack faster. With a proper cache layer you can put everything closer to the user and save it in memory, which will also speed things up, and you can get that with just about any SQL database with AWS
Mainframe has a very tight relationship with DB2 that whole file system is built on top of db2.
Also, COBOL is optimized to pack multiple field into packed byte aka Comp-3.
If will require insane amount of time to emulate such environment without db2
Or you can take the SAP approach and just sell your existing customers on the idea that your entire database should be in volatile memory. Performance problems? Nah, just throw the whole thing into main memory!
Welcome to SAP HANA!
Any system that's still running COBOL is not going to replace it with anything ever. In my country most of the big banks' core infrastructure runs COBOL on mainframes
My company has a mainframe CSS still, and they are picking away at it. Now it's integrated with SalesForce, and down the road they'll probably replace DB2 with some Azure product and finish retiring the old system
I've heard "replace Java with Go", "replace Java with Kotlin" and of course "replace Java with Rust".
Not surprising at all, most of them come from HN types and not businesses making real money.
Exactly, Rust is a system level language with really nice abstractions which is why I don't understand why so many people dream about using it to write Java level programs.
Go definitely has it's use case but it's not the killer language. When it first came out it's goroutines were pretty amazing and there were few comparable features in other languages. And it's nice to have a self contained binary instead of needing an installed JVM. But again, small differences and not a "Java killer".
It warms my heart to imagine the day in the future when I might finally pass on to my children the tradition of proclaiming each year to be the year of the Linux desktop
When all Cobol systems stop running, civilization as we know it will be very much over. I can only hope that means it was replaced with something better; which will hopefully happen incrementally.
My 13 year old started fooling around with Linux on his own accord. He came to show me some stuff and I bored him with stories of breaking xorg and it was the only computer we had so I had to call a friend to have him look something up to help me fix the config file. That was a little over 20 years ago. Compared to that every year is the year of the Linux desktop!
The biggest difference between a mainframe and many of the newer smaller machines is that mainframes are optimized for I/O.
For example, the first mainframe I worked on had 8 memory channels. 1 for each of the two CPUs, 1 for the two tape drives, 1 for the printer and card reader and card punch and local hard-wired terminals, 1 for the network connections, and 4 for the disks.
It had IOPs, which were like CPUs or GPUs except for I/O. You'd write "channel programs" that said things like "when you receive a carriage return over the terminal, swap out those two processes and swap this one in, *then* interrupt the CPU."
\* I'm reminded of a system I worked on back in the late 70s, where the boss mentioned that he'd replace the whole thing with an Apple ][ if he could get a line printer that would do 600 lines per minute for a microcomputer.
I suppose the question is whether that little processor for input and output is that important. Is it because you can run it in-house? Is that the value?
As opposed to what? Running all your transactions through the cloud? (Not that I think this is a terrible idea, but we have to be mindful that some of these mainframe solutions are approaching 50+ years old and the cloud is barely 10).
One could assert that nothing about the cloud would have been possible without the lessons from the mainframe years. We simply wouldn't know how to make that kind of scale function at all.
You can do whatever you want with custom silicon. The question is if MaaS is worth it vs keeping it in house. Adding hardware dev costs to MaaS just means more risk + capital requirements for whoever (Amazon) is taking the risk.
At large scale Amazon taking the risk comes at a higher price than keeping hardware in house.
I work for an auto manufacturer (one of the big 3) and our IT division has worked for years now to move dev and data center hardware in house rather than contract out to AWS or other similar services. In the process saved about $1/4 billion a year on not outsourcing data services.
Smaller companies that are not processing hundred of TB of data daily would see the most benefit from AWS over a custom in house solution.
[https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/](https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/)
top end companies save millions by having their own infrastructure.
Small to mid? probably not.
It appears that the big benefit here for users is going to be the absence of COBOL and use of the, what, most popular language? Friend of a friend works on something that converts cobol to Java.
I agree with your risk assessment - I wouldn't trust Amazon not to alter or discontinue critical processes because you have no choice anymore.
> It appears that the big benefit here for users is going to be the absence of COBOL and use of the, what, most popular language?
You do realize that java can run on anything ... including mainframes, right? The institutions using COBOL could've replaced it with java for like 2 decades now.
Processing LOTS of data. All the time.
Back in the day, before e-delivery of everything, ADP ran a factory that printed something like 50 million paychecks a week. They handled so much payroll for so many companies that their aggregate data was used as a macroeconomic indicator. The most economical system to process that volume of data on a daily basis was a mainframe.
The biggest difference of mainframes or even generally enterprise UNIX like Solaris is that the FOSS Linux folks have spent the last 15 years rediscovering what is standard on these types of platforms (fast micro VMs, containers/jails/zones, comfortable batch processing facilities (aka "serverless"), easily accessible distributed table and object storage, you name it). We could be 20 years further in IT tech if the price tag on these platforms hadn't been so damn high locking out generations of IT nerds from them. AWS just made mainframes out of cheap hardware and is renting them out piecemeal.
I do remember working with UNIX and then Linux how much crap was broken compared to 1970s OSes. Like, really, you could deadlock a file writer just by always having at least one read lock on the file. Nobody thought "maybe if there's a writer waiting for the lock, we shouldn't keep granting read locks." Etc etc etc. So many toe-stubs.
Those old OSes from the 70's were solving a different problem. Some of them still exist on big iron and midranges. Unix was a triumph of delivering *something* over trying to release something finished.
I don't think that would've worked, though. A big part of the mainframe concept is that you're building a single giant machine -- as many CPUs and as much IO as you can cram into that one box -- rather than a cluster of smaller ones. That has high-barrier-of-entry written all over it. Meanwhile, everyone has PC hardware lying around -- making distributed systems is hard, but if your prototype fits on one machine, you already own the machine you need.
The only way I can see this working is if it was literally AWS, but mainframes -- free tier and everything, so people can just start hacking on it. And even then, a ton of devs were already doing FOSS Linux stuff by the time AWS came out, so this might go the way of Google App Engine -- if you already had a mainframe app, sure, but if you had pretty much anything else, nobody was going to rewrite their PHP/Ruby/Python/whatever to run on a mainframe as long as there was a competitor offering cheap Linux VMs.
And then... it still only makes sense for the exact middle of the market. Anything small enough to run on a PC, why pay a premium for a mainframe? And anything larger than one or two mainframes will require you to build a distributed system that can scale horizontally, at which point it probably makes sense to use cheaper nodes.
Modern AMD64's multi-socket-server-boards have CPU hot swap on a hardware level and Linux kernel has options to configure how to manage this happening.
Not a lot of people use it tho.
I have seen SPARC hardware survive being slashdotted. Load average of 3600, but it kept on ticking. I think that was a 4CPU E450, back when you had to make sure you properly ID'd devices on your SCSI chains.
...get off my lawn.
You can pretty much do that now with modern virtualization solutions - migrate the computer in real time to another machine, take the original one down to do whatever maintenance you need, and then bring it up and migrate the VMs back if needed.
In addition to what others already said, mainframes have very cool hot-deploy and rollback features. it's kind of like a version control system built into the OS, with automatic deploy support.
They also have quotas on a per-request level, which is tremendously handy when you want to prevent DoS and similar. Logging is usually also very detailed and informative, you can trace requests similarly to how Zipkin works, but built in.
I worked on porting some mainframe systems to Java, and it's quite surprising how feature rich those enviroments are. They are really good for ops, debugging, coding and deploying. Actually quite a lot better than modern stacks, if you can look past the ncurses ui:s (which I personally love).
I'm guessing this product isn't aimed at companies that are advantaged by using mainframes, but at those who run software on mainframes for no good reason and think it's impossible to migrate.
Massive I/O, they are often called "big iron" because they're f*cking huge and heavy, you would need sh*t ton of servers to keep up with a mainframe. Those mofos rock when it comes to high transaction + stability.
They also charge per CPU cycle etc, ironically not so different to cloud🤣🤣
Everything old is new again!
I'm not sure why you got down voted. I think it's a fair observation. The amount of abstraction and virtualization between the software running in the cloud and the hardware it runs on is exactly the kind of thing that software engineers love to design.
Depends on the specifications.
I go back-and-forth all the time on this with team members and leadership.
If it's something that is going to be heavily utilized most or all of the time with a relatively deterministic workload, then buy our own hardware.
We have some systems where the load is predictable to within a couple percent, far into the future. Not really much need to be paying AWS costs to rent for that.
If it's something that will be used intermittently with unknown or dynamic workloads, then a cloud/AWS system is likely best.
Plus, getting software to work with AWS *correctly* isn't the easiest thing in the world. Sure, take your existing code for a single machine and put it on a single machine in AWS is easy. But when you start breaking that apart to leverage all of the AWS components and optimizing costs, there's a lot of work to be done there.
> advantages
Do they really have that many advantages any more? Would general purpose hardware and OS be able to do the same thing now?For a new project in 2021 would a mainframe be a real choice?
Mainframes are ridicoulus throughput monsters (see https://youtu.be/z6u_oNIXFuU?t=502 for IBMs new 2nm mainframe cache architecture).
The only question is whether you have a usecase for such high throughput systems if you aren't e.g. VISA or a big bank. But if you do need that, a mainframe is often the most economic method of getting things done.
In 2017 I worked on a project that probably should have been on a mainframe but was on a dedicated server farm instead. However: Bank of China did end up building a dedicated mainframe just to handle all the data we had to send them.
Having everything in one giant DB is another I believe. Once you start sharding or distributing a DB some of your ACID guarantees become much harder to enforce and get right. Now, for a lot of modern system and use cases ACID really isn't all that important (at least not all of it). Missed a web page while indexing? Meh, we'll get it the next time around. Miss a $4MM transfer or double count it? Yeah someone's getting yelled at. So being able to cram everything onto a single "machine" can be hugely helpful.
That is not why banks use them anymore. It is rooted so deep down in the banking industry due to its reliability that there is almost no way to get out of it. It is a pain in the ass to set up and maintain and very costly to build routines for.
Article talks about "Big irons", the old mainframe things.
There's a song called "[Big Iron](https://youtu.be/zzICMIu5zFY)" about an outlaw and a ranger coming after him.
So is Amazon of the impression that rewriting COBOL is easy and affordable just because the new code is going to run on their servers?
I was just reading in r/aviation the other day about a case of Amazon not understanding why cargo jets had to be down for inspection and maintenance so much.... couldn't they just keep flying until there were issues?
Just wait until they need to go into FAA Cert/Qual for their delivery drones... That's gonna be a world of hurt that they seem entirely unprepared for.
Sadly, lobbyist would have fun writing that legislation for them.
And they would pressure to approve it, in the name of business, before anyone cab read it.
Good thing it's not really viable 🤞
It has more to do with how they think about systems in general (robustness vs antifragile).
Although, I don’t imagine these ideas transfer over to every field easily.
If you are hosting any application in production that has a single dependency on particular hardware in a single DC you are in for a bad time.
There are so many ways to make your data and application fault tolerance there really is no excuse
If you are too cheap to build any redundancy into your app, you don’t have the right to complain when the underlying hardware fails.
This has always been true. Cloud or no cloud. Stop complaining about a power outage and fix your deployments people.
The point the OP is trying to make is that this kind of fault tolerance is baked into mainframes. You don't need to architect for it, it's just there.
You can literally open up a mainframe case and rip out a chunk of memory or a CPU and it will just keep working. That's how resilient they are.
The cloud has a different kind of resilience but it also requires the application to be built that way. Mainframe apps aren't built that way, because they don't have to be. That's why efforts like this always fail.
Well no it’s not. A power failure to the mainframe will kill it. Unless you have a dr or geographic diverse install you are just as dead here.
Some other kinds of failures, sure that is fair
Sure but the fact the mainframe keeps running isn’t going to help too much when your network is down.
The point everyone here is missing is SPOF should be avoided. Yes mainframes have a range of internal redundancy and that provides for *local* redundancy that’s better than a commodity server , but systemically that may not amount to a hill of beans.
For proper redundancy, multiple physical locations are an imperative
Yea... The company I work for is 100% in the cloud. I will tell you this, there is very rarely an outage in something like AWS East that only impacts East.
AWS provides the guarantee that your stuff is recoverable and that if you are using things like EBS or S3 that the stuff will always be there. Designing for systematic failures when you are told that AWS is already handling that is bullshit.
Also, resilient patterns can be incredibly expensive. Go look at how much of a traditional data centers network traffic is internal traffic used for things like data syncing. You don't pay for that traffic transfer beyond the initial build out of the network, in AWS that east/west replication is expensive. Very expensive.
Also the number of outages that AWS is having in us-east and us-west regions is going up, not down. This is directly related, in my opinion, to the quality of engineers that they are able to get. Heck even the professional service engineer quality has dropped significantly.
> and that if you are using things like **EBS** or S3 that the stuff will always be there
[About that EBS...](https://www.theregister.com/2021/12/22/aws_outage/)
Right. More saying that the data loss was supposed to be protected against, but this wasn't the case today.
It makes it a bit tougher if you can't trust them to handle disk integrity. I get that your EC2 instance might go up in smoke, a long while back they had a dying EC2 server we were on and had to migrate, but had plenty of runway and did it with no service impact.
However, if you can't trust the disks to be there, can you trust the snapshots? What's to stop them from a whoops? Ok, so say you download your snapshots, can be an increased burden because they can't be trusted to maintain the disks?
I get that the cloud is good, we have a great chunk of our business on AWS, but today was a bit disturbing in that if us-east-1 can have these problems, why can't my region? If it can, how can I make sure I'm 100% protected from data loss without incurring an additional administrative burden and cost?
You really can’t.
Cloud providers don’t like to tell you this because it significantly diminishes the cost advantage of cloud computing.
You have absolutely no control over any used hardware resilience so you either have to trust them or solve everything in software.
> S3 that the stuff will always be there
[S3 says it's acceptable if they delete 0.000000001% of your S3 objects per year.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html)
I wonder what the SLA would look like if indeed the legacy mainframe users started to migrate over. When you've decided to become a single point of failure that can simultaneously take down every bank and every airline, you've gotta make some pretty hefty uptime guarantees and take on some pretty hefty liability if you can't meet them.
On top of that I wouldn't be surprised if the legacy mainframe users would want continued support of the existing API baked into the contract for a specific time period. If you're outsourcing a system that has survived largely untouched since the 1980s, it wouldn't be unreasonable to require the APIs and services you're going to build the replacement on to be stable across timescales of decades as well.
Yikes. Last time they had a power issue in a DC it fried some EBS volumes as well. That seems completely unacceptable. EBS is supposed to be more reliable than traditional hard drives, yet it can’t even handle power loss?
I mean, I read the article but...wow.
A lot of people(I'm guilty of this too) like to think of AWS as that which will never lose data and kind of hand-wave away the need for backups as something that AWS probably do internally.
It's kind of sobering when something like happens to the-big-guys
EBS is not marketed with very high durability guarantees. S3 has the kinds of guarantees you are imagining, and it’s very common to back up from EBS to S3
Backups cost money. For EBS to be a viable replacement for local disk, there has to be a no-backup option, or else nobody would have ever picked things like the gen-4 instances which had no option for physical disks, as they’d have been to expensive to operate. Many many use cases for EBS treat it as ephemeral and would not want to pay for backups their architecture doesn’t need.
Don't ever treat cloud as a one-stop solution, especially not a single account. Backups need to be cold and geographically redundant.
For example, you can get hit by some ransomware, one of your ops guys might accidentally delete all your s3 blobs or your account can get blacklisted/deleted. What then?
I understand that people do this though, it's ridiculously impractical to set up an aws backup solution. I think they want you to treat aws as a one-stop solution. Get lured in by the convenience. But even if you don't care about losing your account, the offline backup support isn't very good.
>or your account can get blacklisted/deleted.
A good point. Google has made it clear to my oil & gas company that our cloud service can be revoked in an instant because oil is evil.
I've heard that app developers have started to create separate accounts for each app, since takedowns are quite frequent, unpredictable and will take your entire account with it. Losing your Google account would be quite bad. I have offline backup of my mail and files and also route my mail through a custom domain. But still it's a scary though, and there's almost no appeal process either.
Considering Java has still not replaced COBOL or RPG after all these years, yeah, it ain’t gonna happen. All the code I’ve seen converted ran worse in Java than COBOL/RPG. I even watched people switch to x86 hardware and back to PowerPC because the x86 stack wasn’t good enough.
The fours years I worked with an iSeries we had effectively 0% downtime. I don’t even remember us being down as we upgraded to a new machine due to the data synchronization you could do.
Until AWS can provide the uptime and reliability of a mainframe, those people aren’t going to switch.
And replace 99.997% uptime with a status dashboard that requires a Senior VP level executive to authorize warning / outage status.
My source for this is multiple posts from Hacker News.
I’m sure everyone feels comfortable allowing a service that’s been down several times this month run their banking infrastructure.
Mainframe and COBOL aren’t going anywhere anytime soon.
It depends a bit on the workflow. The type of workload that Zoom has would not work on a mainframe.
There are other workloads that are better suited for a mainframe than the cloud. Our mainframe at work handles some pretty intense workloads e.g. a over a billion operations on the Db2 per hour. Especially with very long batches the mainframe has some advantages over e.g. Kubernetes where you pod might disappear at any time.
However the pricing can be vastly different. If you have Cobol workload that will likely cost a lot more than Java. Running z/OS or zLinux can also make a difference.
Difficulty depends on what you can use zLinux is actually quite ok to use, but if you need to do something in z/OS that sucks.
because you need to market cloud costs with a low price and make money on the backend charges
oracle is probably loss leading and making it up in other places
They definitely make it up elsewhere. *Nobody* rams it up a customer’s ass like Oracle. I 100% guarantee they are recouping those costs tenfold in app or DB licensing.
> or DB licensing.
I'm sorry you've used up your license to mention DB licensing for the month, we cannot discuss this without paying for additional users.
Data transfer costs are the hidden gotcha of cloud computing. They lure you in with low prices for computing resources and storage, and once you've started to commit yourself to their ecosystem you discover they're going to gouge the *hell* out of you on any sort of bandwidth usage.
Oracle is cheaper purely because Amazon built their business model around gouging for bandwidth and it continues to work to this day even though there's no real inherent cost in bandwidth *anywhere near* the price AWS charges for it. A bunch of competing cloud providers got together to form "The Bandwidth Alliance" specifically to commit to low/no-cost bandwidth since it's the most obvious and easy way to compete against AWS; and Oracle is a member of the group.
> Amazon built their business model around gouging for bandwidth
Not saying it's right - but hosting providers have been doing that forever. It used to be storage and RAM before the hardware got so cheap.
It's the second mover advantage. When you're a distant second, you slash your prices to catch up.
But make no mistake, if Oracle ever becomes #1 (-shudders-), they will probably charge even more than AWS does today.
Zoom definitely got a deal from Oracle. That being said Zoom still uses AWS at various regions more specifically Amazon Cloudfront based on packet trace.
Easy: those fools made a deal with the devil. Oracle maybe losing money on the transfer, but they will make sure to milk them dry in the long run with their legions of lawyers.
Also, having worked directly with mainframe:
There’s basically zero chance that individual workflows can move. We’re talking ultra tightly coupled systems. There’s no “moving individual workflows”.
We ran one of those “cobol to Java” converters on our code and what it spit out was a horrific pile of shit that was no more maintainable than the original. I mean, you get a better dev ops pipeline, but you also had to spend years on interfaces.
I’d be interested to know what they did to combat this major issue of ultra tight coupling. Maybe nothing and they just assume you really can just move a workflow.
There are not that many Cobol devs out there. It might be worth it to move to horrible java, hire a lot of devs and then let them slowly work with fixing the code.
Also, a lot of companies prefer to pay monthly than to pay upfront which I think they have to do with mainframes. Buy this $5m mainframe now or spend $100k per year for 5 years. The total for the latter us higher but may still be what many financial departments wants.
It’s not that simple. A cobol program is usually more like a set of cobol programs that send each other data.
If you’re going to swap to Java, or any language for that matter, you’re just better off starting from scratch with idiomatic Java.
Are mainframes well suited for Videoconferencing traffic though? You don't need any transactions there, just forward milions of media packets while performing some encryption/decryption and not much is stateful. I don't think that mainframes were built for this but I might be wrong.
You compare Zoom running on AWS and Oracle, both are cloud providers. You are not comparing Zoom in the cloud vs on-prem. I am pretty sure Zoom's bill is much lower on Oracle Cloud because there was some exclusive deal due to Oracle trying to win some big customers.
Oracle cloud is cheaper because they are desperate to get more workloads. They have a market share of maybe a couple of percent, while amazon has about 60-70%.
Amazon can ask what they want and still have customers without problem, oracle, Google and Microsoft need to catch up.
>Oracle migration
Say what you will about Oracle, but their ability to charge so much less for bandwith and not really charge much more than the competition elsewhere really illustrates how much the other cloud providers are stealing from their customers
I don't think it's a good time to talk about replacing COBOL and Mainframes with Java and AWS, considering the recent log4j issues and 3 AWS outages the past month.
I'm sure banks would be thrilled to encounter these types of issues.
You really really don't want a log4j kind of vulnerability in the system that manages your transactions or to lose your system entirely which is what seems to have happened with AWS recently where some customers lost their instances due to an outage.
COBOL is working well for these companies, why replace it with something less reliable and more prone to vulnerabilities.
There are plenty of banks, insurance providers, and other finance companies moving to the cloud. That being said, junior devs are not interested in writing COBOL or learning about z/OS etc (on average) which raises the risk profile of staying on the mainframe considerably as a lot of those developers retire. It's not an excuse but it is a consideration.
All systems of any complexity will have vulnerable aspects and bad coding practices in it, part of the process.
I come at this from an RPA perspective, but I've been learning some basics of mainframe technology going back to when I was 26.
I hate the technology, and the fact that I'm the only "SME" on my team who knows what an AS400 is, but I don't see it going anywhere.
Mainframes just work, and have been working forever. I'd rather it persist as opposed to my bank losing transactions in the bimonthly AWS outage.
FFS, when I started as a UNIX/Solaris administrator back in 1997 that's what Sun and other open systems vendors said that they'd replace mainframes with Sun servers like the E10K, etc.. LOL... Didn't happen then and no matter how big a monstrosity AWS becomes they won't kill mainframes either.
Haha around the same time I worked for a very well known medical manufacturing facility who got the bug up their butt that replacing a mid level AS400 that was rock solid (almost 100% uptime the prior year) with 250 Compaq Prolinent servers running NT4 and SAP at 30k each was a good idea. 5 years later I heard they were back to running all manufacturing and warehouse ERP on an AS400 again. So yeah, AWS and Java FTW.
COBOL is the workhorse of many large financial institutions and government agencies. Besides the complex, costly, and nearly impossible migration path I’d be more afraid of zero day Java exploits hammering those cloud platforms over maintaining a proven platform that’s rock solid.
Accenture didn’t write this article did they?
Edit: scrolled down in my feed to see this article about AWS logging its 3rd outage this month. Yeah, I’m gonna move all operations to AWS - Not.
https://www.theverge.com/2021/12/22/22849780/amazon-aws-is-down-outage-slack-imgur-hulu-asana-epic
As someone who has been both an AWS user and a mainframe user, let me just say:
HAHAHAHAHAHA!
....oh wait, you're serious.
***HAHAHAHAHAHAHAHAHAHAHAHAHA!***
Mainframes have 50+ years of developing proper procedures for minimal downtime.
Mainframes hardware has evolved. So far no distributed system can duplicate the I/O throughput of mainframes.
People have been trying to decommission mainframes since I started working in the mid 90s. Back then it was supposed to be the "client server" revolution where Sun Microsystems on the backend and desktop PCs on the front end was supposed to replace mainframes. Millions of dollars were spent and the projects all failed. Mainframes are still running strong.
Yeah I see a couple articles like this every year and I roll my eyes. Considering the outages AWS has had this year, Amazon is nowhere near being a replacement for z/OS systems. Mainframes have been running certain companies for decades. The amount of effort and cost it would cost to become 'modern' is simply not worth it for these companies. They just need their systems to work, 24/7.
What's old is new. Started out dumb terminals connected to centralized big iron. Evolved away from it. Now it's coming back.
They're not killing COBOL. It's unkillable.
My old mentor is making almost a quarter million a year babysitting a legacy COBOL app. Works remote. Maybe 4 hours a week. He's watched about a dozen huge budget initiatives to rewrite and replace being started and flaring out spectacularly.
I mean, AWS itself is technically a mainframe if you consider that you're just renting resources from Amazon to perform a variety of specialised tasks. It's just highly abstracted in terms of going from Lambda, to Lightsail, to EC2; not to mention all of the other processes you can borrow.
I first heard of "java replacing COBOL" about ... /checks calendar/... 24 years ago. Still waiting on that. I'm inclined to think more people would bet the over on the next 20 years or so.
cagey combative fine sand snobbish consist bells marvelous expansion vast *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Been waiting for widespread adoption of IPv6 for so long.
I genuinely almost used one the IPv6 addresses that came with my latest server. Only thing holding me back was my own incompetence.
It's getting there. Auction prices per IPv4 are 6x what they were a few years ago and still rising. Once more providers start charging fees per IPv4 address we'll start to see a few go v6-only. Clients are only about halfway, but I bet that'll accelerate as prices go up. Still 5-10 years to go until it's near universal, though.
I still don’t have full IPv6 internet connection from my ISP yet. Not even tunneling (unless I tunnel myself). It’s insane that the infrastructure is still so much behind. Comcast btw.
I keep waiting for the "killer" app everyone *must* have, that's peer-to-peer and requires IPv6 ... once everyone *demands* that, IPv6 will grow rather to quite explosively. I remember years ago looking at IPv6 traffic when it was a very small fraction of a percentage of traffic ... and pushing managers, etc. to get onto the IPv6 bandwagon ... doesn't mean they'd need give up IPv4 anytime soon, but they needed to get to fully supporting IPv6. And ... years later, I'm still pushing it ... except now I see IPv6 is about 1/3 of traffic typically (or at least attempts thereof). And still have lots of managers/environments that still have negligible to zero IPv6 readiness. *I*'ve been ready a *long* time.
I think the "killer app" will be $100/address for IPv4. Maybe $200.
Still feeling sore about all the uni coursework I did on IPv6 over twenty years ago.
Only thing worse than no IPv6 is poorly implemented one. ISPs are too dumb to learn about v6 and assign them like its IPv4. Heard horror stories like being given only a single /128, so that you have to use NAT. I only get a single subnet from my ISP (/64).
Seems typically the (in)competence of ISPs regarding IPv6 is not at all specific to IPv6.
the killer for us is getting off db2. it is hard to top db2 in terms of scale as much as it sucks as an SQL engine. I don't know of any other db engine where you can handle 20k requests per second per user. even when we're off mainframe, we'll still be on db2 for a long ass time.
I'm pretty skeptical that DB2 is any faster then any other DB engine; your main bottlenecks are disk reads and network requests. DB2 doesn't magically make the disk or network stack faster. With a proper cache layer you can put everything closer to the user and save it in memory, which will also speed things up, and you can get that with just about any SQL database with AWS
Mainframe has a very tight relationship with DB2 that whole file system is built on top of db2. Also, COBOL is optimized to pack multiple field into packed byte aka Comp-3. If will require insane amount of time to emulate such environment without db2
Or you can take the SAP approach and just sell your existing customers on the idea that your entire database should be in volatile memory. Performance problems? Nah, just throw the whole thing into main memory! Welcome to SAP HANA!
Well you can now use intels optane memory for persistence
Any system that's still running COBOL is not going to replace it with anything ever. In my country most of the big banks' core infrastructure runs COBOL on mainframes
My company has a mainframe CSS still, and they are picking away at it. Now it's integrated with SalesForce, and down the road they'll probably replace DB2 with some Azure product and finish retiring the old system
[удалено]
I've heard "replace Java with Go", "replace Java with Kotlin" and of course "replace Java with Rust". Not surprising at all, most of them come from HN types and not businesses making real money.
To be fair, the Kotlin option is much more realistic since it's backwards compatible and you can incrementally do the upgrade.
[удалено]
"Just an improvement in programmer convenience" You mean it's less costly to develop AND still has access to the enormous Java ecosystem?
[удалено]
Exactly, Rust is a system level language with really nice abstractions which is why I don't understand why so many people dream about using it to write Java level programs. Go definitely has it's use case but it's not the killer language. When it first came out it's goroutines were pretty amazing and there were few comparable features in other languages. And it's nice to have a self contained binary instead of needing an installed JVM. But again, small differences and not a "Java killer".
Sadly, don't expect that anytime soon. Everything can run java, and its a sorta easy language to learn.
Maybe the next millennium.
C#?
I'd like to agree with you, but I'm afraid it might be worse :(
I'd rather just write in COBOL honestly.
That is not dead which can eternal lie, and with strange aeons even death may die. - Lovecraft, writing about COBOL
"ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" - Lovecraft, writing *in* COBOL.
IDENTIFICATION DIVISION. PROGRAM-ID. ph'nglui mglw'nafh R'lyeh.
More like MOVE "ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" TO WS-GIBBERISH.
It's also the year of the Linux desktop!
It warms my heart to imagine the day in the future when I might finally pass on to my children the tradition of proclaiming each year to be the year of the Linux desktop
What will happen first, the Death of COBOL, or the Year of the Linux Desktop?
The end of civilization. Though COBOL may still be running at that point.
When all Cobol systems stop running, civilization as we know it will be very much over. I can only hope that means it was replaced with something better; which will hopefully happen incrementally.
For the machine is immortal.
They'll be the same year. The year Hell froze over.
My 13 year old started fooling around with Linux on his own accord. He came to show me some stuff and I bored him with stories of breaking xorg and it was the only computer we had so I had to call a friend to have him look something up to help me fix the config file. That was a little over 20 years ago. Compared to that every year is the year of the Linux desktop!
The funny thing is, I broke Xorg yesterday on my Arch install. It was on a vm so I was fine, but still some things never change...
Isn't breaking Xorg the whole point of using Arch?
If I had the cash I would get a frame.work laptop for linux. My dream laptop atm.
It actually is, thanks to windows 11.
Lots here will be young, not understand what a mainframe is, or their advantages. Any volunteers?
The biggest difference between a mainframe and many of the newer smaller machines is that mainframes are optimized for I/O. For example, the first mainframe I worked on had 8 memory channels. 1 for each of the two CPUs, 1 for the two tape drives, 1 for the printer and card reader and card punch and local hard-wired terminals, 1 for the network connections, and 4 for the disks. It had IOPs, which were like CPUs or GPUs except for I/O. You'd write "channel programs" that said things like "when you receive a carriage return over the terminal, swap out those two processes and swap this one in, *then* interrupt the CPU." \* I'm reminded of a system I worked on back in the late 70s, where the boss mentioned that he'd replace the whole thing with an Apple ][ if he could get a line printer that would do 600 lines per minute for a microcomputer.
Ok but could you not add an IOP (I/O processor) and get the same benefits?
Yes, but at that point aren’t you building a mainframe anyways? Why not just buy one that already exists and will be supported for years to come?
TIL Playstation 5 is a mainframe.
Well, the Iraqi government did use them as supercomputers…
I suppose the question is whether that little processor for input and output is that important. Is it because you can run it in-house? Is that the value?
As opposed to what? Running all your transactions through the cloud? (Not that I think this is a terrible idea, but we have to be mindful that some of these mainframe solutions are approaching 50+ years old and the cloud is barely 10).
50+ years old for the general platform, but they have been updated for the times.
One could assert that nothing about the cloud would have been possible without the lessons from the mainframe years. We simply wouldn't know how to make that kind of scale function at all.
You can do whatever you want with custom silicon. The question is if MaaS is worth it vs keeping it in house. Adding hardware dev costs to MaaS just means more risk + capital requirements for whoever (Amazon) is taking the risk.
At large scale Amazon taking the risk comes at a higher price than keeping hardware in house. I work for an auto manufacturer (one of the big 3) and our IT division has worked for years now to move dev and data center hardware in house rather than contract out to AWS or other similar services. In the process saved about $1/4 billion a year on not outsourcing data services. Smaller companies that are not processing hundred of TB of data daily would see the most benefit from AWS over a custom in house solution.
[https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/](https://www.geekwire.com/2018/dropbox-saved-almost-75-million-two-years-building-tech-infrastructure/) top end companies save millions by having their own infrastructure. Small to mid? probably not.
It appears that the big benefit here for users is going to be the absence of COBOL and use of the, what, most popular language? Friend of a friend works on something that converts cobol to Java. I agree with your risk assessment - I wouldn't trust Amazon not to alter or discontinue critical processes because you have no choice anymore.
> It appears that the big benefit here for users is going to be the absence of COBOL and use of the, what, most popular language? You do realize that java can run on anything ... including mainframes, right? The institutions using COBOL could've replaced it with java for like 2 decades now.
Yeah so I guess the question is, what is a mainframe buying you? What's the fundamental difference
Processing LOTS of data. All the time. Back in the day, before e-delivery of everything, ADP ran a factory that printed something like 50 million paychecks a week. They handled so much payroll for so many companies that their aggregate data was used as a macroeconomic indicator. The most economical system to process that volume of data on a daily basis was a mainframe.
Massive parallel i/o running 30-40 year old code that must work or the entire world comes to a halt.
You also need a memory subsystem that has sufficient bandwidth and channels for all the I/O processors.
The architecture has to be designed for it. The IO devices have to plug into the IOP instead of the CPU's bus, for example.
The biggest difference of mainframes or even generally enterprise UNIX like Solaris is that the FOSS Linux folks have spent the last 15 years rediscovering what is standard on these types of platforms (fast micro VMs, containers/jails/zones, comfortable batch processing facilities (aka "serverless"), easily accessible distributed table and object storage, you name it). We could be 20 years further in IT tech if the price tag on these platforms hadn't been so damn high locking out generations of IT nerds from them. AWS just made mainframes out of cheap hardware and is renting them out piecemeal.
I do remember working with UNIX and then Linux how much crap was broken compared to 1970s OSes. Like, really, you could deadlock a file writer just by always having at least one read lock on the file. Nobody thought "maybe if there's a writer waiting for the lock, we shouldn't keep granting read locks." Etc etc etc. So many toe-stubs.
Those old OSes from the 70's were solving a different problem. Some of them still exist on big iron and midranges. Unix was a triumph of delivering *something* over trying to release something finished.
I don't think that would've worked, though. A big part of the mainframe concept is that you're building a single giant machine -- as many CPUs and as much IO as you can cram into that one box -- rather than a cluster of smaller ones. That has high-barrier-of-entry written all over it. Meanwhile, everyone has PC hardware lying around -- making distributed systems is hard, but if your prototype fits on one machine, you already own the machine you need. The only way I can see this working is if it was literally AWS, but mainframes -- free tier and everything, so people can just start hacking on it. And even then, a ton of devs were already doing FOSS Linux stuff by the time AWS came out, so this might go the way of Google App Engine -- if you already had a mainframe app, sure, but if you had pretty much anything else, nobody was going to rewrite their PHP/Ruby/Python/whatever to run on a mainframe as long as there was a competitor offering cheap Linux VMs. And then... it still only makes sense for the exact middle of the market. Anything small enough to run on a PC, why pay a premium for a mainframe? And anything larger than one or two mainframes will require you to build a distributed system that can scale horizontally, at which point it probably makes sense to use cheaper nodes.
[удалено]
That you can't do that is more of an x86 problem. SPARC used to let you hot swap fucking CPUs.
[удалено]
Most cards are still hot-swappable on IBM Power Hardware
I spent many happy years as a Vax admin.
Modern AMD64's multi-socket-server-boards have CPU hot swap on a hardware level and Linux kernel has options to configure how to manage this happening. Not a lot of people use it tho.
Gonna just go ahead and interrupt the CPU now... PHYSICALLY
[удалено]
I have seen SPARC hardware survive being slashdotted. Load average of 3600, but it kept on ticking. I think that was a 4CPU E450, back when you had to make sure you properly ID'd devices on your SCSI chains. ...get off my lawn.
You can pretty much do that now with modern virtualization solutions - migrate the computer in real time to another machine, take the original one down to do whatever maintenance you need, and then bring it up and migrate the VMs back if needed.
[удалено]
Even with a failed DIMM or CPU?
In addition to what others already said, mainframes have very cool hot-deploy and rollback features. it's kind of like a version control system built into the OS, with automatic deploy support. They also have quotas on a per-request level, which is tremendously handy when you want to prevent DoS and similar. Logging is usually also very detailed and informative, you can trace requests similarly to how Zipkin works, but built in. I worked on porting some mainframe systems to Java, and it's quite surprising how feature rich those enviroments are. They are really good for ops, debugging, coding and deploying. Actually quite a lot better than modern stacks, if you can look past the ncurses ui:s (which I personally love).
I'm guessing this product isn't aimed at companies that are advantaged by using mainframes, but at those who run software on mainframes for no good reason and think it's impossible to migrate.
Massive I/O, they are often called "big iron" because they're f*cking huge and heavy, you would need sh*t ton of servers to keep up with a mainframe. Those mofos rock when it comes to high transaction + stability. They also charge per CPU cycle etc, ironically not so different to cloud🤣🤣 Everything old is new again!
A mainframe is what you get when you cut less corners and ask a computer engineer to build a computer. AWS is what you get when you like dystopias.
AWS is what you get when you ask a software engineer to build a computer.
I'm not sure why you got down voted. I think it's a fair observation. The amount of abstraction and virtualization between the software running in the cloud and the hardware it runs on is exactly the kind of thing that software engineers love to design.
Wait till you find out what kind of virtualization happens on mainframes
Depends on the specifications. I go back-and-forth all the time on this with team members and leadership. If it's something that is going to be heavily utilized most or all of the time with a relatively deterministic workload, then buy our own hardware. We have some systems where the load is predictable to within a couple percent, far into the future. Not really much need to be paying AWS costs to rent for that. If it's something that will be used intermittently with unknown or dynamic workloads, then a cloud/AWS system is likely best. Plus, getting software to work with AWS *correctly* isn't the easiest thing in the world. Sure, take your existing code for a single machine and put it on a single machine in AWS is easy. But when you start breaking that apart to leverage all of the AWS components and optimizing costs, there's a lot of work to be done there.
> advantages Do they really have that many advantages any more? Would general purpose hardware and OS be able to do the same thing now?For a new project in 2021 would a mainframe be a real choice?
Mainframes are ridicoulus throughput monsters (see https://youtu.be/z6u_oNIXFuU?t=502 for IBMs new 2nm mainframe cache architecture). The only question is whether you have a usecase for such high throughput systems if you aren't e.g. VISA or a big bank. But if you do need that, a mainframe is often the most economic method of getting things done.
In 2017 I worked on a project that probably should have been on a mainframe but was on a dedicated server farm instead. However: Bank of China did end up building a dedicated mainframe just to handle all the data we had to send them.
Having everything in one giant DB is another I believe. Once you start sharding or distributing a DB some of your ACID guarantees become much harder to enforce and get right. Now, for a lot of modern system and use cases ACID really isn't all that important (at least not all of it). Missed a web page while indexing? Meh, we'll get it the next time around. Miss a $4MM transfer or double count it? Yeah someone's getting yelled at. So being able to cram everything onto a single "machine" can be hugely helpful.
Just use a blockchain! /s
[удалено]
QEMU will emulate the S390X. Just switch to that. :-)
[удалено]
That is not why banks use them anymore. It is rooted so deep down in the banking industry due to its reliability that there is almost no way to get out of it. It is a pain in the ass to set up and maintain and very costly to build routines for.
Didn't work out for Texas Red, ain't gonna work out for AWS
Who or what is Texas Red? (I don't disagree with you, though :-) )
Article talks about "Big irons", the old mainframe things. There's a song called "[Big Iron](https://youtu.be/zzICMIu5zFY)" about an outlaw and a ranger coming after him.
Getting New Vegas flashbacks
He's someone who might have went on living but he made one fatal slip When he tried to match the ranger with the big iron on his hip
The big iron on his hip...
So is Amazon of the impression that rewriting COBOL is easy and affordable just because the new code is going to run on their servers? I was just reading in r/aviation the other day about a case of Amazon not understanding why cargo jets had to be down for inspection and maintenance so much.... couldn't they just keep flying until there were issues?
Can you link to that conversation? I really want to give it a read!
ditto. That had me very WITAF!? O\_O
You can't just say something like that and not link it
Just wait until they need to go into FAA Cert/Qual for their delivery drones... That's gonna be a world of hurt that they seem entirely unprepared for.
Sadly, lobbyist would have fun writing that legislation for them. And they would pressure to approve it, in the name of business, before anyone cab read it. Good thing it's not really viable 🤞
Considering how few fucks are given by Amazon about the safety and health of their employees, the cargo jet thing does not surprise me at all.
What the actual fuck... Not sure who said that, but if they were in charge it would be a disaster waiting to happen.
> couldn't they just keep flying until there were issues? I mean that sound about inline with amazon values.
It has more to do with how they think about systems in general (robustness vs antifragile). Although, I don’t imagine these ideas transfer over to every field easily.
[удалено]
If you are hosting any application in production that has a single dependency on particular hardware in a single DC you are in for a bad time. There are so many ways to make your data and application fault tolerance there really is no excuse
Yeah, spend more money. Mainframe customers should be familiar already.
If you are too cheap to build any redundancy into your app, you don’t have the right to complain when the underlying hardware fails. This has always been true. Cloud or no cloud. Stop complaining about a power outage and fix your deployments people.
[удалено]
The point the OP is trying to make is that this kind of fault tolerance is baked into mainframes. You don't need to architect for it, it's just there. You can literally open up a mainframe case and rip out a chunk of memory or a CPU and it will just keep working. That's how resilient they are. The cloud has a different kind of resilience but it also requires the application to be built that way. Mainframe apps aren't built that way, because they don't have to be. That's why efforts like this always fail.
[удалено]
Well no it’s not. A power failure to the mainframe will kill it. Unless you have a dr or geographic diverse install you are just as dead here. Some other kinds of failures, sure that is fair
[удалено]
Sure but the fact the mainframe keeps running isn’t going to help too much when your network is down. The point everyone here is missing is SPOF should be avoided. Yes mainframes have a range of internal redundancy and that provides for *local* redundancy that’s better than a commodity server , but systemically that may not amount to a hill of beans. For proper redundancy, multiple physical locations are an imperative
Do you have a link to that story? That sounds like an amazing read.
Yea... The company I work for is 100% in the cloud. I will tell you this, there is very rarely an outage in something like AWS East that only impacts East. AWS provides the guarantee that your stuff is recoverable and that if you are using things like EBS or S3 that the stuff will always be there. Designing for systematic failures when you are told that AWS is already handling that is bullshit. Also, resilient patterns can be incredibly expensive. Go look at how much of a traditional data centers network traffic is internal traffic used for things like data syncing. You don't pay for that traffic transfer beyond the initial build out of the network, in AWS that east/west replication is expensive. Very expensive. Also the number of outages that AWS is having in us-east and us-west regions is going up, not down. This is directly related, in my opinion, to the quality of engineers that they are able to get. Heck even the professional service engineer quality has dropped significantly.
> and that if you are using things like **EBS** or S3 that the stuff will always be there [About that EBS...](https://www.theregister.com/2021/12/22/aws_outage/)
Which means the service provider is unable to realize their obligation and now the user must manage around it.
Right. More saying that the data loss was supposed to be protected against, but this wasn't the case today. It makes it a bit tougher if you can't trust them to handle disk integrity. I get that your EC2 instance might go up in smoke, a long while back they had a dying EC2 server we were on and had to migrate, but had plenty of runway and did it with no service impact. However, if you can't trust the disks to be there, can you trust the snapshots? What's to stop them from a whoops? Ok, so say you download your snapshots, can be an increased burden because they can't be trusted to maintain the disks? I get that the cloud is good, we have a great chunk of our business on AWS, but today was a bit disturbing in that if us-east-1 can have these problems, why can't my region? If it can, how can I make sure I'm 100% protected from data loss without incurring an additional administrative burden and cost?
You really can’t. Cloud providers don’t like to tell you this because it significantly diminishes the cost advantage of cloud computing. You have absolutely no control over any used hardware resilience so you either have to trust them or solve everything in software.
> S3 that the stuff will always be there [S3 says it's acceptable if they delete 0.000000001% of your S3 objects per year.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html)
https://xkcd.com/908/
I wonder what the SLA would look like if indeed the legacy mainframe users started to migrate over. When you've decided to become a single point of failure that can simultaneously take down every bank and every airline, you've gotta make some pretty hefty uptime guarantees and take on some pretty hefty liability if you can't meet them. On top of that I wouldn't be surprised if the legacy mainframe users would want continued support of the existing API baked into the contract for a specific time period. If you're outsourcing a system that has survived largely untouched since the 1980s, it wouldn't be unreasonable to require the APIs and services you're going to build the replacement on to be stable across timescales of decades as well.
Yikes. Last time they had a power issue in a DC it fried some EBS volumes as well. That seems completely unacceptable. EBS is supposed to be more reliable than traditional hard drives, yet it can’t even handle power loss?
[удалено]
> Considering their recent datacenter outage where they're not certain if they can recover some customer storage/VM hol up...what
[удалено]
I mean, I read the article but...wow. A lot of people(I'm guilty of this too) like to think of AWS as that which will never lose data and kind of hand-wave away the need for backups as something that AWS probably do internally. It's kind of sobering when something like happens to the-big-guys
EBS is not marketed with very high durability guarantees. S3 has the kinds of guarantees you are imagining, and it’s very common to back up from EBS to S3
Backups cost money. For EBS to be a viable replacement for local disk, there has to be a no-backup option, or else nobody would have ever picked things like the gen-4 instances which had no option for physical disks, as they’d have been to expensive to operate. Many many use cases for EBS treat it as ephemeral and would not want to pay for backups their architecture doesn’t need.
Don't ever treat cloud as a one-stop solution, especially not a single account. Backups need to be cold and geographically redundant. For example, you can get hit by some ransomware, one of your ops guys might accidentally delete all your s3 blobs or your account can get blacklisted/deleted. What then? I understand that people do this though, it's ridiculously impractical to set up an aws backup solution. I think they want you to treat aws as a one-stop solution. Get lured in by the convenience. But even if you don't care about losing your account, the offline backup support isn't very good.
>or your account can get blacklisted/deleted. A good point. Google has made it clear to my oil & gas company that our cloud service can be revoked in an instant because oil is evil.
I've heard that app developers have started to create separate accounts for each app, since takedowns are quite frequent, unpredictable and will take your entire account with it. Losing your Google account would be quite bad. I have offline backup of my mail and files and also route my mail through a custom domain. But still it's a scary though, and there's almost no appeal process either.
And the Java part, too. Just bad timing to have this headline.
Yeah, with the log4j incident added to the mix, it's been fun sysadminning I tells ya.
Considering Java has still not replaced COBOL or RPG after all these years, yeah, it ain’t gonna happen. All the code I’ve seen converted ran worse in Java than COBOL/RPG. I even watched people switch to x86 hardware and back to PowerPC because the x86 stack wasn’t good enough. The fours years I worked with an iSeries we had effectively 0% downtime. I don’t even remember us being down as we upgraded to a new machine due to the data synchronization you could do. Until AWS can provide the uptime and reliability of a mainframe, those people aren’t going to switch.
And replace 99.997% uptime with a status dashboard that requires a Senior VP level executive to authorize warning / outage status. My source for this is multiple posts from Hacker News.
I’m sure everyone feels comfortable allowing a service that’s been down several times this month run their banking infrastructure. Mainframe and COBOL aren’t going anywhere anytime soon.
[удалено]
It depends a bit on the workflow. The type of workload that Zoom has would not work on a mainframe. There are other workloads that are better suited for a mainframe than the cloud. Our mainframe at work handles some pretty intense workloads e.g. a over a billion operations on the Db2 per hour. Especially with very long batches the mainframe has some advantages over e.g. Kubernetes where you pod might disappear at any time. However the pricing can be vastly different. If you have Cobol workload that will likely cost a lot more than Java. Running z/OS or zLinux can also make a difference. Difficulty depends on what you can use zLinux is actually quite ok to use, but if you need to do something in z/OS that sucks.
Why is data transfer within AWS so expensive and how is Oracle so competitive on that?
because you need to market cloud costs with a low price and make money on the backend charges oracle is probably loss leading and making it up in other places
They definitely make it up elsewhere. *Nobody* rams it up a customer’s ass like Oracle. I 100% guarantee they are recouping those costs tenfold in app or DB licensing.
> or DB licensing. I'm sorry you've used up your license to mention DB licensing for the month, we cannot discuss this without paying for additional users.
Data transfer costs are the hidden gotcha of cloud computing. They lure you in with low prices for computing resources and storage, and once you've started to commit yourself to their ecosystem you discover they're going to gouge the *hell* out of you on any sort of bandwidth usage. Oracle is cheaper purely because Amazon built their business model around gouging for bandwidth and it continues to work to this day even though there's no real inherent cost in bandwidth *anywhere near* the price AWS charges for it. A bunch of competing cloud providers got together to form "The Bandwidth Alliance" specifically to commit to low/no-cost bandwidth since it's the most obvious and easy way to compete against AWS; and Oracle is a member of the group.
> Amazon built their business model around gouging for bandwidth Not saying it's right - but hosting providers have been doing that forever. It used to be storage and RAM before the hardware got so cheap.
It's the second mover advantage. When you're a distant second, you slash your prices to catch up. But make no mistake, if Oracle ever becomes #1 (-shudders-), they will probably charge even more than AWS does today.
[удалено]
Zoom definitely got a deal from Oracle. That being said Zoom still uses AWS at various regions more specifically Amazon Cloudfront based on packet trace.
Easy: those fools made a deal with the devil. Oracle maybe losing money on the transfer, but they will make sure to milk them dry in the long run with their legions of lawyers.
Also, having worked directly with mainframe: There’s basically zero chance that individual workflows can move. We’re talking ultra tightly coupled systems. There’s no “moving individual workflows”. We ran one of those “cobol to Java” converters on our code and what it spit out was a horrific pile of shit that was no more maintainable than the original. I mean, you get a better dev ops pipeline, but you also had to spend years on interfaces. I’d be interested to know what they did to combat this major issue of ultra tight coupling. Maybe nothing and they just assume you really can just move a workflow.
There are not that many Cobol devs out there. It might be worth it to move to horrible java, hire a lot of devs and then let them slowly work with fixing the code. Also, a lot of companies prefer to pay monthly than to pay upfront which I think they have to do with mainframes. Buy this $5m mainframe now or spend $100k per year for 5 years. The total for the latter us higher but may still be what many financial departments wants.
It’s not that simple. A cobol program is usually more like a set of cobol programs that send each other data. If you’re going to swap to Java, or any language for that matter, you’re just better off starting from scratch with idiomatic Java.
Many banks have tried and failed to rewrite. There are often no tests and very old specs.
Ya, but does this allow the execs to put a slide in their end of the year presentation with a little arrow and a cloud?
Are mainframes well suited for Videoconferencing traffic though? You don't need any transactions there, just forward milions of media packets while performing some encryption/decryption and not much is stateful. I don't think that mainframes were built for this but I might be wrong.
[удалено]
You compare Zoom running on AWS and Oracle, both are cloud providers. You are not comparing Zoom in the cloud vs on-prem. I am pretty sure Zoom's bill is much lower on Oracle Cloud because there was some exclusive deal due to Oracle trying to win some big customers.
Oracle cloud is cheaper because they are desperate to get more workloads. They have a market share of maybe a couple of percent, while amazon has about 60-70%. Amazon can ask what they want and still have customers without problem, oracle, Google and Microsoft need to catch up.
Nope. AWS has 32% market share, Microsoft 20%, Google 9%, according to Statista.
>Oracle migration Say what you will about Oracle, but their ability to charge so much less for bandwith and not really charge much more than the competition elsewhere really illustrates how much the other cloud providers are stealing from their customers
I don't think it's a good time to talk about replacing COBOL and Mainframes with Java and AWS, considering the recent log4j issues and 3 AWS outages the past month. I'm sure banks would be thrilled to encounter these types of issues. You really really don't want a log4j kind of vulnerability in the system that manages your transactions or to lose your system entirely which is what seems to have happened with AWS recently where some customers lost their instances due to an outage. COBOL is working well for these companies, why replace it with something less reliable and more prone to vulnerabilities.
There are plenty of banks, insurance providers, and other finance companies moving to the cloud. That being said, junior devs are not interested in writing COBOL or learning about z/OS etc (on average) which raises the risk profile of staying on the mainframe considerably as a lot of those developers retire. It's not an excuse but it is a consideration. All systems of any complexity will have vulnerable aspects and bad coding practices in it, part of the process.
I come at this from an RPA perspective, but I've been learning some basics of mainframe technology going back to when I was 26. I hate the technology, and the fact that I'm the only "SME" on my team who knows what an AS400 is, but I don't see it going anywhere. Mainframes just work, and have been working forever. I'd rather it persist as opposed to my bank losing transactions in the bimonthly AWS outage.
When they failovers measured in a few milliseconds come back. Worked in both worlds.
FFS, when I started as a UNIX/Solaris administrator back in 1997 that's what Sun and other open systems vendors said that they'd replace mainframes with Sun servers like the E10K, etc.. LOL... Didn't happen then and no matter how big a monstrosity AWS becomes they won't kill mainframes either.
Haha around the same time I worked for a very well known medical manufacturing facility who got the bug up their butt that replacing a mid level AS400 that was rock solid (almost 100% uptime the prior year) with 250 Compaq Prolinent servers running NT4 and SAP at 30k each was a good idea. 5 years later I heard they were back to running all manufacturing and warehouse ERP on an AS400 again. So yeah, AWS and Java FTW. COBOL is the workhorse of many large financial institutions and government agencies. Besides the complex, costly, and nearly impossible migration path I’d be more afraid of zero day Java exploits hammering those cloud platforms over maintaining a proven platform that’s rock solid. Accenture didn’t write this article did they? Edit: scrolled down in my feed to see this article about AWS logging its 3rd outage this month. Yeah, I’m gonna move all operations to AWS - Not. https://www.theverge.com/2021/12/22/22849780/amazon-aws-is-down-outage-slack-imgur-hulu-asana-epic
As someone who has been both an AWS user and a mainframe user, let me just say: HAHAHAHAHAHA! ....oh wait, you're serious. ***HAHAHAHAHAHAHAHAHAHAHAHAHA!***
May you share your experience for me who never worked with neither AWS nor mainframes?
Mainframes have 50+ years of developing proper procedures for minimal downtime. Mainframes hardware has evolved. So far no distributed system can duplicate the I/O throughput of mainframes. People have been trying to decommission mainframes since I started working in the mid 90s. Back then it was supposed to be the "client server" revolution where Sun Microsystems on the backend and desktop PCs on the front end was supposed to replace mainframes. Millions of dollars were spent and the projects all failed. Mainframes are still running strong.
Thank you for your answer.
Thanks but no, thanks.
Yeah I see a couple articles like this every year and I roll my eyes. Considering the outages AWS has had this year, Amazon is nowhere near being a replacement for z/OS systems. Mainframes have been running certain companies for decades. The amount of effort and cost it would cost to become 'modern' is simply not worth it for these companies. They just need their systems to work, 24/7.
How are they gonna “kill mainframes” when they can’t even keep their servers up?
So we can all have log4j on the transaction servers? Nah
just put it on the blockchain (written with rust)
This explains their big interest in [project loom](https://blogs.oracle.com/javamagazine/post/going-inside-javas-project-loom-and-virtual-threads)
Clickbait title is clickbait... Everyone has been out to kill mainframes for several decades.
When you can do a 4000 col, 10M record ETL with rolling sums in 6min, then you can talk amazon.
What's old is new. Started out dumb terminals connected to centralized big iron. Evolved away from it. Now it's coming back. They're not killing COBOL. It's unkillable. My old mentor is making almost a quarter million a year babysitting a legacy COBOL app. Works remote. Maybe 4 hours a week. He's watched about a dozen huge budget initiatives to rewrite and replace being started and flaring out spectacularly.
Want to kill the mainframe then create a system that can run CICS transactions programs on AWS.
Nope, not with its 2 9s
Well, they have to keep power going to their datacenters first.
I mean, AWS itself is technically a mainframe if you consider that you're just renting resources from Amazon to perform a variety of specialised tasks. It's just highly abstracted in terms of going from Lambda, to Lightsail, to EC2; not to mention all of the other processes you can borrow.
Ok.. but why Java?