5 ms·

> Legacy apps need to be modernized but their owners can't afford/aren't willing to. It's not the mainframe holding these apps back... the problem is much much

by trimbo 6y ago

> Legacy apps need to be modernized but their owners can't afford/aren't willing to. It's not the mainframe holding these apps back... the problem is much much worse. I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology. Unfortunately, it does not happen in industries that are heavily regulated, and probably where we need it most.

OldHand2018 6y ago
If it aint broke, don't break it. In a business context, the outcomes that your software enable are the things that matter. If your legacy platform still works and your business can still accomplish the things it wants to accomplish, why add a huge expensive distraction? IBM still makes mainframes. You can still buy OpenVMS systems. There is no reason to believe that you will wake up one day and your technology will no longer exist. Don't hire people from Stanford or MIT. Recruit at 2nd tier schools and get them a year or two before you need them. They can learn all they need on the job, and they cost less, too.
- wmf 6y ago
  Ah yes, outcomes like payments taking over a day to go through and people not being able to receive unemployment.
  - sp332 6y ago
    Mainframes are not slow. IBM's POWER architecture has some downsides but it is no slouch in transactions/second. > payments taking over a day to go through That's due to the protocol. https://en.wikipedia.org/wiki/ACH_Network https://en.wikipedia.org/wiki/ACH_Network "when a real-time transfer is required, a wire transfer using a system such as the Federal Reserve's Fedwire is employed instead". > people not being able to receive unemployment That's probably not due to the mainframes. https://slate.com/technology/2020/04/new-jersey-unemployment-cobol-coronavirus.html https://slate.com/technology/2020/04/new-jersey-unemployment... That's probably an administration issue. https://www.citylab.com/equity/2020/04/unemployment-benefits-reopen-georgia-business-coronavirus/610321/ https://www.citylab.com/equity/2020/04/unemployment-benefits...
    - Lutzb 6y ago
      Z and POWER are two distinct architectures.
      - sp332 6y ago
        I know you can get different architectures in a mainframe, including Power. What's Z like?
        lboc 6y ago
        https://www.redbooks.ibm.com/abstracts/sg248851.html https://www.redbooks.ibm.com/abstracts/sg248851.html and http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf Should pretty much cover it :) Edit: missed http
        monocasa 6y ago
        Power is way closer to a Xeon than a mainframe.
  - goatinaboat 6y ago
    payments taking over a day to go through Consider that when you swipe your credit card and get payment approved in a store, that’s a round trip to the mainframe back at Visa HQ. Or when you withdraw cash from an ATM. Mainframes are perfectly capable of near-real-time operations at massive scale. The problems you mention are not technological.
DaiPlusPlus 6y ago
> I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology. The worst part is that a clean, entire rewrite isn't necessary: while everyone's familiar with a gradual refactor (module-by-module), fewer people seem to be aware of how better a proxied gradual rewrite is: where a single module/area in the old system is rewritten in the new system, but the old system's exposed interfaces remain the same and simply proxy or pass-through to the new system (to support existing clients and use-cases) while new clients can access the new system directly. It's an approach I used for a rewrite of an old ASP.NET WebForms application to ASP.NET Core (famously the two are very incompatible: old WebForms *.aspx markup and stateful Page classes (don't forget `__VIEWSTATE`!) simply cannot even be refactored to work in ASP.NET Core: the only way forward is a total rewrite: but when an old .aspx is replaced, there's an `IHttpHandler` that takes its place and proxies the request to the new ASP.NET Core system and end-users are none-the-wiser (and by "proxy" I don't necessarily mean like a HTTP reverse-proxy - 90% of the time the new .NET Core code was running in-proc and invoked as a normal library reference because it targeted .NET Standard and so ran on .NET Framework 4.x instead of only the .NET Core runtime). Now I know I can't compare a line-of-business web-application to a billion-dollar IBM-powered banking/insurance/public-sector - but I believe the same principles apply. Provided the original application _can_ be decoupled internally (thus to allow that proxying in the first place), then a gradual in-situ rewrite should be doable.
- swibblewonk 6y ago
  I think that last part is exactly the problem. Many legacy systems are poorly modularized and so large with such complex interactions that it's hard to figure out where to start cutting.

by trimbo 6y ago

OldHand2018 6y ago

If it aint broke, don't break it. In a business context, the outcomes that your software enable are the things that matter. If your legacy platform still works and your business can still accomplish the things it wants to accomplish, why add a huge expensive distraction? IBM still makes mainframes. You can still buy OpenVMS systems. There is no reason to believe that you will wake up one day and your technology will no longer exist. Don't hire people from Stanford or MIT. Recruit at 2nd tier schools and get them a year or two before you need them. They can learn all they need on the job, and they cost less, too.

wmf 6y ago
Ah yes, outcomes like payments taking over a day to go through and people not being able to receive unemployment.
- sp332 6y ago
  Mainframes are not slow. IBM's POWER architecture has some downsides but it is no slouch in transactions/second. > payments taking over a day to go through That's due to the protocol. https://en.wikipedia.org/wiki/ACH_Network https://en.wikipedia.org/wiki/ACH_Network "when a real-time transfer is required, a wire transfer using a system such as the Federal Reserve's Fedwire is employed instead". > people not being able to receive unemployment That's probably not due to the mainframes. https://slate.com/technology/2020/04/new-jersey-unemployment-cobol-coronavirus.html https://slate.com/technology/2020/04/new-jersey-unemployment... That's probably an administration issue. https://www.citylab.com/equity/2020/04/unemployment-benefits-reopen-georgia-business-coronavirus/610321/ https://www.citylab.com/equity/2020/04/unemployment-benefits...
  - Lutzb 6y ago
    Z and POWER are two distinct architectures.
    - sp332 6y ago
      I know you can get different architectures in a mainframe, including Power. What's Z like?
      - lboc 6y ago
        https://www.redbooks.ibm.com/abstracts/sg248851.html https://www.redbooks.ibm.com/abstracts/sg248851.html and http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf Should pretty much cover it :) Edit: missed http
      - monocasa 6y ago
        Power is way closer to a Xeon than a mainframe.
- goatinaboat 6y ago
  payments taking over a day to go through Consider that when you swipe your credit card and get payment approved in a store, that’s a round trip to the mainframe back at Visa HQ. Or when you withdraw cash from an ATM. Mainframes are perfectly capable of near-real-time operations at massive scale. The problems you mention are not technological.

DaiPlusPlus 6y ago

> I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology. The worst part is that a clean, entire rewrite isn't necessary: while everyone's familiar with a gradual refactor (module-by-module), fewer people seem to be aware of how better a proxied gradual rewrite is: where a single module/area in the old system is rewritten in the new system, but the old system's exposed interfaces remain the same and simply proxy or pass-through to the new system (to support existing clients and use-cases) while new clients can access the new system directly. It's an approach I used for a rewrite of an old ASP.NET WebForms application to ASP.NET Core (famously the two are very incompatible: old WebForms *.aspx markup and stateful Page classes (don't forget `__VIEWSTATE`!) simply cannot even be refactored to work in ASP.NET Core: the only way forward is a total rewrite: but when an old .aspx is replaced, there's an `IHttpHandler` that takes its place and proxies the request to the new ASP.NET Core system and end-users are none-the-wiser (and by "proxy" I don't necessarily mean like a HTTP reverse-proxy - 90% of the time the new .NET Core code was running in-proc and invoked as a normal library reference because it targeted .NET Standard and so ran on .NET Framework 4.x instead of only the .NET Core runtime). Now I know I can't compare a line-of-business web-application to a billion-dollar IBM-powered banking/insurance/public-sector - but I believe the same principles apply. Provided the original application _can_ be decoupled internally (thus to allow that proxying in the first place), then a gradual in-situ rewrite should be doable.

swibblewonk 6y ago
I think that last part is exactly the problem. Many legacy systems are poorly modularized and so large with such complex interactions that it's hard to figure out where to start cutting.