
Ask HN: Can Google cloud spanner replace mainframes? - breatheoften
I’ve been reading about Google Cloud Spanner recently — and it seems like a really unique and incredible product if it is capable as it sounds.<p>It has me thinking — is the most viable migration path away from mainframes yet?  From my understanding — one of the things that contribute to the difficulty of migrating away from mainframes is the change in the consistency model — going from mainframe to pretty much anything else seems to involve:<p>(1) unraveling all the consistency requirements between the different mechanisms which manipulate mainframe data with sufficient understanding to port this logic into storage systems with weaker consistency models — hard and risky<p>Or<p>(2) replicating the bottleneck in giant oracle instance or some other non-scaleable data store that provides the same standard of consistency model<p>Does google cloud spanner provide a viable 3rd alternative here?  I am curious if others think that cloud spanner could represent the most viable way to migrate away from mainframes in 2018.
======
walshemj
No not really it cant run Cobol let alone Cobol that ran on systems before you
where born.

Google doesn't have to worry really about ACID but payroll and Bank
applications do.

~~~
breatheoften
Well definitely google cloud spanner doesn’t offer any features related to
COBOL — but it’s kind of hard to imagine that there are any projects which
want to both (1) migrate away from mainframes (2) keep using COBOL.

But if you’ve decided that your task of migrating away from the mainframe will
involve porting a bunch of cobol transaction processing code into some other
language ... seems you might be able to do relatively straightforward
rewriting of this kind of logic into some language that creates google cloud
spanner transactions ... At least much more straightforwardly than the kinds
of rearchitecting required if you had to factor in how the logic would need to
change to deal with weakening of the storage systems consistency model.

You could be correct in suggesting that the main difficulty of migrating away
from mainframes is the unfamaliarity of these codebases ... but what’s the
next hardest part?

And Google Cloud Spanner does offer ACID transactions ...

------
marktangotango
_From my understanding — one of the things that contribute to the difficulty
of migrating away from mainframes is the change in the consistency model —
going from mainframe to pretty much anything else seems to involve:_

First note, when it comes to getting old cobol apps off the mainframe, the
options are 'rehosting', 'migrating', and rewriting. Rehosting is taking your
cobol and data and running it all off the mainframe. A couple of companies
offer solutions to run mainframe cobol apps on the jvm (compile cobol to jvm
bytecode), or compile and run them on some unix flavor. Open/Gnu Cobol is used
this way by at least one vendor.

Migrating to another language involves rewriting in two main ways: source to
source translating the cobol to the other language, or actually defining a
project and doing a full rewrite from the ground up, using the idioms and best
practices of the host language. I've seen cobol applications source translated
to java using the RES 'open cobol to java' (on sourceforge for the curious),
and the resulting java code looks like assembler.

Also note that some of these applications are _massive_ in scope, they've
grown organically over decades to encompass business processes for entire
industries. There was never a single design document. So, rewrites are
generally out of the question. One can sometimes read about boondoggle
migration projects cancelled after $100 milions being spent, with nothing to
show for it.

Of your two points about data consistency, your first point is irrelevant,
your second point is really not relevant either. There three types of data
store on mainframes. Flat files, key value tables ie VSAM (think Berkley DB,
with fixed length records), and rdbms (either oracle or DB2) Note I'm leaving
out outliers like Datacom and IMS as they're very uncommon now. The database
is generally not an obstacle in re-hosting mainframe apps, or in source to
source translation. They can be a problem in a rewrite because the schema is
usually all jacked due to decades of cruft. VSAM can be replaced with dumb
tables in a db or berkley db as mentioned. The amount of data stored generally
isn't a problem, especially not nowadays.

But yeah, you've got a point, this legacy cobol situation is getting really
stupid at this point. I had the oppurtunity to ask a VP once "why source
translate to java when you can run cobol in a jvm like microfocus offering y?"
His response was "customers don't want to hear cobol, we had to go to java."
Nevermind the generated java was a nightmare, and technological dead end.

These types of migration projects used to be pretty common around the Y2K era,
but I see them coming back around again now, because as said, the situation is
getting stupid.

I tend to think now that a source to source translation to a more cobol style
representation in the host language, that would be maintainable and enhanceble
by cobol programmers with very little retraining may be the way to go. Then
you get to keep you domain knowledge and investment in legacy code. But no one
is doing this.

