Hacker News Reader

Comment by nn3 | Hacker News Reader

I'm idly wondering how today's "modern" Java* micro-service buzzword driven setups will look to someone who has to maintain it 40+ years later.

Maybe COBOL and mainframe wasn't that bad after all.

View on HN

I think this depends on how it is maintained over time. If there are a collection of Java microservices maintained by dedicated team. And over time they upgrade from JDK 11 to JDK 13. Add features, fix bugs. Rewrite some services in Go. Then rewrite some in whatever the hot language is after Go. Then port to ARM. Then migrate from AWS to the next thing. And so on. If that is what they do, I think they will be fine. A dedicated team, constantly maintaining and evolving the system.

On the other hand, if they write the Java microservices now, running on JDK 11, on Intel x86-64, and then never touch it for 40 years. That will be like some COBOL+mainframe setup that no one knows how to fix, change, upgrade, redeploy, etc.

The tech companies using microservices generally have teams that constantly evolve their products, and over time they end up completely replacing services with new services, underlying infrastructure with new infrastructure, and so on. They will be fine with their Java microservices.

Governments that fund a project once and never touch it again, their technology will always be hard to maintain in 20+ years.

Actually, what you describe is a bigger problem than simply static maintenance. Overwhelmingly what happens is that, that "rewrite some services in go" and run them on AWS frequently means that the project is never 100% rewritten in go on AWS because some part gets moved to GCE or whatever in a couple years, and then someone else takes over with different priorities, and they never finish your go/aws migration, etc, etc, etc. In 40 years your project is now written in a dozen different scripting languages, running on a Rube Goldberg number of different platforms.

I've worked with people migrating off these machines, and yes they are everywhere in any business/goverment older than 20 years. Companies/Government orgs to this day have hpux/solaris/aix/zos/ztpf/nonstop/iseries/vms/NT/etc systems all over their critical infrastructure because those were the great/new technology at some point.

For whatever reason, overwhelmingly the rewrites turn out to be much more difficult than originally expected. Particularly as the original platform/software gets older. The people working on the original software stack weren't idiots, nor did they spend their days playing tetris. If that software has a couple man-decades worth of effort put into it, your probably not going to be able to rewrite it in less and maintain its functionality and quality.

At the very least they won’t require the physical presence of a mainframe and that’s something.

An as/400 can be about the size of a normal desktop case.

I don't think that's the point. Whether the machine is small or big, the physical presence is the pain point

will our clouds be running in 30-40 years? will they expose the same APIs?. There is a hidden pro that there will be a maximum "unnattended" lifetime to a lot of todays software.

No, instead you depend on AWS to not change their API for 40 years. I'm not sure it's an improvement.

They will require different cloud providers to still provide the same interfaces. Good luck with that. You also need different package repositories to still work. I think a mainframe is a safer bet.

The upside is that having to tweak things every 5 years (say) will probably make it less likely that things will just work for decades, until they collapse in a screaming heap.

It feels to me that a system that doesn't tolerate massive technical debt is a better system.

I think the same phenomena exists with Linux and dynamic linking. Linux is incredibly less crufty than Windows because userspace compatibility isn't so long-lasting, APIs can be deprecated, garbage removed.

Mainframes are now often running as VMs these days.

Reply on news.ycombinator.com