151–160 of 163 posts
One comment out of that was interesting to me: >And it’s not all COBOL anymore. Today mainframe programmers use Python, Linux, node.js, Java, blockchain. node.js on a mainframe? That doesn’t strike me as being something that can uninterrupted for years.
Earlier quoted context omitted.
IBM runs a student competition to try get people into it: https://masterthemainframe.com/
Is there something similar available if you are no student?
And nobody keeps you from playing around and writing and compiling a few programs on your own. It's a virtual system which gets reset when they start a new round. And I'd assume they've set up proper resource controls so you can't damage stuff.
Let me add a shameless plug here: https://area51.stackexchange.com/proposals/118484/mainframes... It's a proposed Stack Exchange website dedicated to mainframes. It is in commitment phase, which means people need to come up and commit to support the site - with questions, answers, moderation, comments - in numbers sufficient to ensure its viability.
Maybe one should start a discussion on meta-stackexchange that the usual criteria are not a good fit for that one, because many of the committers don't use other stackexchange sites that much.
Earlier quoted context omitted.
That's not capitalism, it's our culture around capitalism. There is nothing inherent to capitalism that stresses short term growth vs. long term growth. For example much of the push for short term growth comes from the stock market, but the stock market (or public ownership at all) is in no way required for capitalism to work (and IMO it would probably be better without it).
Sorry, but that is entirely captialism. You don't get to take core aspects of the system and say it's not really part of the system.
Earlier quoted context omitted.
Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. With IaaS typical reliability issue is that whole location/datacenter/AZ goes down, with your own infrastructure the typical issue is that the colo-facility/datacenter goes down, which would be essentially identical save the fact that with IaaS there is significantly larger probability that the reason for going down is…
Are you replying to the right sub-thread? I was asking about cost. That said.. > Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. Although I'm a fan of running ones own hardware, I'm not sure I could make this claim. However, since I'd like to, do you have public data to back it up? > orchestration automation, which in the self-hosted case either isn't there or is und…
That said I believe that when your workload really necessitates such a big systems and if you can use all of the mainframes capability and have the capability to manage the mainframe (which requires Ops team with totally different skillset and mainly willingness to do such a thing), I believe that cost of mainframe will be comparable to IaaS, with self-hosted commodity HW being somewhat cheaper.
It is anecdotal, but when I used to work in more of an Ops role I cannot remember single time when server hardware failed in production without external environmental cause (there were flooded servers and servers that were DoA from manufacturer), it is somewhat surprising that this experience even extends to spinning rust harddrives, where most common causes of failure I've seen were flaky SATA/SAS connetors, followed by simply bad series (eg. Constellation ES.2) and then by extreme overheating.
Let me add a shameless plug here: https://area51.stackexchange.com/proposals/118484/mainframes... It's a proposed Stack Exchange website dedicated to mainframes. It is in commitment phase, which means people need to come up and commit to support the site - with questions, answers, moderation, comments - in numbers sufficient to ensure its viability.
It needs especially committers with sufficient reputation on other stackexchange sites, which is the only thing holding it back right now. Maybe one should start a discussion on meta-stackexchange that the usual criteria are not a good fit for that one, because many of the committers don't use other stackexchange sites that much.
My issue is with the developed software and database design. Although the software is custom written, many mainframe developers do not understand the concepts of modern programming and do not improve over time. Once they learn a concept (sometimes 30 years in the past), they continue to develop this way, rather than improving as it is outside their comfort zone. They are not open to new concepts or ideas. When you have a team of developers doing this over several decades, you end up with a big ball of mud. https://en.wikipedia.org/wiki/Big_ball_of_mud
Trying to port a big ball of mud to another language is very difficult, which contributes to mainframe developer job security and monolithic, antiquated systems. Modern developers are very particular to code portability, readability and modern concepts. Hopefully this is just in my experience and not common across other mainframe developers.
Earlier quoted context omitted.
> This is very hard to do for mainframes because of access to them. Bingo. I work in an AS/400 shop. I simply can't invest myself personally in the work because I know my access to that environment is predicated on working for this particular company. I can hone my Linux skills and even my Windows Server skills any time. I can bring it home. I can use it myself. I can own it. I can't do that with the AS/400. Just spi…
http://www.timeshare400.com . Starts at $15/month.
Earlier quoted context omitted.
Are you replying to the right sub-thread? I was asking about cost. That said.. > Problem with IaaS clouds is that it is strictly less reliable than having your own infrastructure. Although I'm a fan of running ones own hardware, I'm not sure I could make this claim. However, since I'd like to, do you have public data to back it up? > orchestration automation, which in the self-hosted case either isn't there or is und…
I started with some comparison of cost of big IaaS instances vs. mainframe vs. commodity HW and then got sidetracked on the reliability and ended up deleting the first paragraph :) That said I believe that when your workload really necessitates such a big systems and if you can use all of the mainframes capability and have the capability to manage the mainframe (which requires Ops team with totally different skillset…
> cost of mainframe will be comparable to IaaS
I'd be very interested in seeing even a rough cost comparison, since I have no experience with mainframes.
I also have, essentially, no experience with that first "if", which I'd say is a big one. Workloads that are (already) suited to that particular system design may be rare (and obviously getting rarer).
> self-hosted commodity HW being somewhat cheaper.
I'm pretty sure "somewhat" grossly understates it.
However, I realized that one of the problems here is that we're talking about these costs as if they're single numbers, rather than ranges.
For mainframes, it may as well be a single number, because there's only one vendor (for the latest hardware).
For IaaS and self-hosted, the ranges can be very broad, because it's very easy to pay a multiple of the minimum cost with merely a naive implementation. Trivial examples would be not leveraging "reserved instances" on AWS or not getting competitive quotes for self-hosted. In fact, if one removes the "commodity" constraint from self-hosted and allows "enterprise" hardware (especially storage), the top end of the range can easily balloon above the top of the IaaS range.
I've been assuming a comparison of the bottom ends of the ranges, but including the cost of the expert labor for each. What's difficult to know, of course, is how scarce the experts (capable of keeping costs near the bottom of the range) in each category actually are.
> I cannot remember single time when server hardware failed in production without external environmental cause
I think that's just a matter of too small a sample size.
> servers that were DoA from manufacturer
I wouldn't even count that, since it's not in production yet.
> it is somewhat surprising that this experience even extends to spinning rust harddrives
That's definitely too small a sample size, then. If you're not seeing at least a 1% AFR (realistically closer to 3%), you don't have enough of them or haven't been running them long enough yet.
> simply bad series (eg. Constellation ES.2)
That's not an external environmental cause, though, and counts the same as any other failure due to (presumably) a manufacturing defect (defined broadly), including RAM bit errors. It's merely something that can be engineered around with best practices.
None of this is to say that any of these inevitable failures are actually frequent or voluminous enough (even on, e.g., 5 year old hardware, which is ancient by most standards) to require outsized worry or effort/cost to mitigate/repair them.
Earlier quoted context omitted.
Try this: Ok, maybe this is a silly question, but I am {...}.... Question: what is a house and why would I want one? In my mind I think of it as a big, but inelastic, tent. If that's true, why wouldn't I want to just get multiple tents instead? A mainframe is the kind of computer you can buy and set up, turn on, and run for two decades (or more, if you like) non-stop. It doesn't need reboots, it most often doesn't ev…
Except when they do go down it can be a catastrophic business interrupting event. Which is why the cloud model of assume everything is going to break and all your hardware is disposable works much better (IMO).