HN Explorer

Ask HN: Can Google cloud spanner replace mainframes?

6 points by breatheoften ↗ HN
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.

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:

(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

Or

(2) replicating the bottleneck in giant oracle instance or some other non-scaleable data store that provides the same standard of consistency model

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.

3 comments

[ 4.0 ms ] story [ 9.2 ms ] thread
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.