3 ms·

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

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.

StillBored 7y ago
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.

StillBored 7y ago

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.