I am impressed with this solution, insofar as was described in the press release. But I also have concerns.
My concerns mainly lie with choosing such a proprietary solution over one using more open-source standards. Both in the language selected, along with the backend (Oracle and AWS) being used.
Will there or could there be problems in the future, should the need arise to migrate off one or more of those proprietary platforms?
What will or could happen if there is a security issue that affects or targets AWS, Java, or this system in particular - are we "stuck" again with a potentially "broken" system that can't be easily moved because of vendor lock-in of sorts?
Should Oracle make further moves in the direction of "closing" Java - will programmers continue to learn the language and support it, or will they move to other, more open, solutions?
What happens if or when AWS or Amazon ceases to exist?
I just wonder if we haven't traded a largely unwieldy but mostly known issue of a mainframe and COBOL, for a seemingly known (but questionable) issue of AWS, Java, and Oracle.
Will we just revisit this whole problem again in 50 years?
If so, maybe then we'll make a better decision to use more open and auditable solutions (but I'm not going to hold my breath to that)...
should the need arise to migrate off one or more of those proprietary platforms
Fair point given how things usually go in the private sector. In the public sector, especially DoD, the rules of the game are changed.
What happens if or when AWS or Amazon ceases to exist?
Well guess what, they can't. It's now a national security issue so the necessary services will continue to be provided by a KTLO crew or DoD would facilitate a transaction where another company could absorb the needed technology and be contracted to support it. DoD is the biggest company on earth. FY 2019 budget is $686B.
DoD has a pattern of keeping mission critical end-of-life systems running and supported.
I'm currently advising the US Navy on moving some COBOL systems to Java. Those systems have been lovingly supported by lifelong Navy civilian employees for 40-50 years. Those people are now in retirement age and so they're "replatforming" to Java.
There really is no corollary in the private sector. The default for government systems has been the people who built it stick around and maintain it until they retire. For DoD the biggest risk isn't old technologies and changes in the private sector, it's brain drain when people retire.
You might ask yourself, what 20-something wants to work for the US Navy, as a civilian, and work on a Java implementation (ported from COBOL) for the rest of their career? Well, I'd like to introduce you to them. These guys could work anywhere but they like the Navy. They like that their work matters, it's important, and it's stable. The pay is below market but it isn't terrible. Keep in mind DoD isn't all in DC, many offices are in inexpensive places to live.
Frankly I'd love to work on systems with the meaningful impact that theirs have (non-combat in this case). Read about 18F and what it was like for the people who joined and how they stuck with it anyway.
Nothing is really future proof, though. If it makes if 5 years before any major changes, then it will be good. I don't disagree that eventually this could lead to the same kind of vendor lock-in, but, it is also performant, has support, and will work tomorrow with off the shelf parts. of course you could go with OSS, and while that might be a good technical solution, it doesn't necessarily make it a good business decision. AWS is available now, and its performance characteristics are well understood.
There's more here too. Amazon isn't "American" even though it's CEO is American and has many American employees. Multinational corporations owe no loyalty to anyone other than their shareholders, I mean, Amazon the corporation paid nothing in federal taxes last year. What happens when their bottom line contradicts keeping this country safe?
This underlines how so much of the work and contracts at the DoD don't really revolve around defending the US than being another way to hand out tax payer dollars to already well off corporations.
As if government officials do what’s best for the country and not what will allow them to get campaign contributions or make friends companies so they can leave the government and go into the private sector.
Considering amazon did all the I feel like the AWS target is reasonable. I suspect that the next time this sort of works needs to be done it will be easier than this round was.
My concerns mainly lie with choosing such a proprietary solution over one using more open-source standards. Both in the language selected, along with the backend (Oracle and AWS) being used.
Will there or could there be problems in the future, should the need arise to migrate off one or more of those proprietary platforms?
What will or could happen if there is a security issue that affects or targets AWS, Java, or this system in particular - are we "stuck" again with a potentially "broken" system that can't be easily moved because of vendor lock-in of sorts?
Should Oracle make further moves in the direction of "closing" Java - will programmers continue to learn the language and support it, or will they move to other, more open, solutions?
What happens if or when AWS or Amazon ceases to exist?
I just wonder if we haven't traded a largely unwieldy but mostly known issue of a mainframe and COBOL, for a seemingly known (but questionable) issue of AWS, Java, and Oracle.
Will we just revisit this whole problem again in 50 years?
If so, maybe then we'll make a better decision to use more open and auditable solutions (but I'm not going to hold my breath to that)...