> I wonder what people will say in twenty years about our NodeJS, AWS, microservices and JavaScript systems.

The same we're saying today about Object Pascal, Business Objects, Cold Fusion or DCOM:

nothing at all.

Here's a $500k-$1mil government contract for custom ColdFusion programming:

https://www.fbo.gov/index?s=opportunity&mode=form&id=65b571a...

Get your bid in!

> The proposed contract listed here is a 100 percent set aside for Women Owned Small Business concerns. The Government will only accept offers from this (sic) small business concerns. All other firms are deemed ineligible to submit offers.

Well what about the other couple-dozen genders that seem to have surfaced in recent years? =)

fun times, coldfusion vs netobjects

Hopefully in twenty years that kind of complexity has been abstracted out of existence.

Microservices may still exist as an organizational concept but I'd be stunned if we're still thinking about things like containers in 20 years.

Every generation of developers thinks their stuff will be replaced at some point but then they realize it's still used twenty years later. Happended with Y2K, Linux timestamps and a lot of other things.

Nothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so probably nothing. Do you think a lot about some old BASIC Accounting Software?

There are probably only two languages which might face similar problem as COBOL: C and Java. For now they are both actively maintained and used for new projects - so we are fine for at least next 50 years.

My (limited) experience under a government contractor sadly contradicts this: the primary requirement for many projects is to fit inside of a server rack and "just work" when hooked up to power and the network. None of my work was in NodeJS, but I'm positive that JavaScript will be floating around the backends and frontends of our government's services for a long time.

Question is: what bad would happen if you pull out this project from rack?

In most cases, you'd probably make the employees at whatever agency or department very unproductive for the next few days (or however long it takes to find the server and plug it back in). The kind of projects I'm talking about are usually internal and critical for getting the right data to the right people within an agency.

So its is not critical from country/world perspective...

At what point does something become critical, in your book?

The kinds of services I'm describing are critical to the normal functioning of government agencies. They're running now, and they'll probably be running for the next 25 years (at which point another contractor will upgrade them to something new and shiny).

When problems/lack of it influence life(life != work) of many people.

- If power grid goes down you are facing riots.

- If systems on your new shiny Boeing go down you are facing deaths of dozens of people.

- If your military systems goes down you are facing russia ;)

If employees of government agency works less efficiently(is it even possible?) for some period of time (few days, months?) - nothing wrong happens. That's why it is possible to change those systems every 25 years. They will be less productive after software change, they will face new bugs in transition period. A lot (but not all!) of work those agencies do exist only because of some stupid laws (example: in my country you have to have special permit to cut down a tree on your land - I know someone who had to start building their house year later because they couldn't get permit to get rid of one tree, another one: you cannot inherit some types of parcel if you are not a farmer - you have to either become farmer[of course virtually - but it takes few months] or change parcel's type [it's not always possible and it's also few months of fighting with bureaucrats ]).

Depends on the government agency I'd say. For example: unemployement or social security checks going out, VA Hospital systems, etc.

NodeJS and Javascript yes, but critical things absolutely run on AWS.

Running on AWS and doing it correctly so that one of the many regional outages does not cause you an issue is really hard and is a software problem. On the other hand using a system of tested proven code that runs on a system that is redundant by design at the lowest level of component (a mainframe cluster) where the software does not have to have knowledge of the redundancy is a bit simpler.

I really think people miss this very important point. Redundancy is transparent for 99.9999% of the software you run on the old big iron systems. For something like a modern application on AWS you have to know, understand and code for the infrastructure.

We're talking about two different issues here. First is the architecture/software of a mainframe system, with all of its redundancy and scaling. Second is the issue of hosting and maintaining your own hardware. On the first issue I'll admit I don't know enough about mainframes, perhaps they provide redundancy transparently to the programmer, but I'm a bit skeptical. Perhaps you simply think the redundancy is transparent because you understand the mainframe infrastructure deeply and internalized it? The second issue I'll push back on.

If you just want to host your servers on EC2, the SLA is 99.95% uptime. So that's about 4 hours of downtime due to outage a year. Put your servers in a multi-AZ autoscaling group and you're pretty solid. Bonus points for having autoscaling groups in more than one region. If you don't want to use any of the other services AWS provides, you can simply use them as a basic hosting service and get pretty amazing uptime. I've never used an old mainframe system, can you get greater uptime than that? Including hardware failures, power outages, network outages?

There was one point in my life when I was working for a large mainframe company ;) A bank wanted to move a system to a new site. The uptime on that system was 11 years. Uptime on a mainframe system is pretty much considered 100%

4 hours downtime a year is just way to much for some systems.

Just have a google for "mainframe uptime".

Yes the software is abstracted from the HW redundancy. You can pull CPUs with running code in systems and things keep working. Really - walk up and pull the CPU out. No impact to running code.

Heck you can run your private cloud on one:

https://www.fool.com/investing/general/2015/01/24/heres-why-...

Of course it depends on your definition of "critical". There was AWS outage ~2 months ago and banking systems around the world worked pretty well, same with military, big factories didn't stop because of this outage, planes were still flying etc.

It was inconvenient for some people (quite frankly I didn't even notice anything - I've read about that in my RSS reader few days later ;)) but nobody died(excluding heart attacks), countries didn't collapse, wars didn't start because of this.

The outage was for S3, and only in the us-east-1 region. Any critical system should have multi-region fail over. Yeah, factories and planes and stuff are critical and wouldn't use AWS, mostly because those are embedded systems that shouldn't even rely on an Internet connection. But as for banking, Capital One is a huge AWS customer for example.

DISCLAIMER: probably should have mentioned this earlier, I'm an AWS employee :)

We're one of the largest JS users in the world, and I'm pretty sure we'd fall into the category of "critical" (in terms of impact, not end-of-the-world).

C, Java, C# and/or VB.NET.

Python seems to be sticking around.

I suspect that in 50 years, Haskell will still be the up-and coming thing.

I don't think Python has entered the kind of domains where they tend to keep the same version of the system around for 50 years: military, finance/banking/insurance/accounting, healthcare, etc.

I mean, it is present there, but most of the time it's part of some glue or automation, it's not part of the core systems.

Those are usually Cobol, C/C++, Java and .NET. Or some proprietary language in case they were crazy enough.

In wholesale finance Python has been deployed for core systems over the last 10 years. For example JP Morgan's Athena platform goes well beyond glue or automation and handles pricing, intraday risk, EOD risk, etrading and STP. Hundreds of millions of dollars have been invested in the build out, and it will be around for decades.

Python, like COBOL and Excel is a good language for people who program as part of their work but are not professional programmers: data analysts, scientists, some finance types, etc.

Compare that to C where buffer overflows are common, Rust where the type system is a high art, Java where thread-based concurrency "just works" so you can get in trouble using it, etc.

Microservices are here to stay, especially in large engineering orgs. NodeJS and Javascript, on the other hand, I'm not so sure about... Many of the engineers I know view this technology as a "cancer" when compared to Java, Go, etc. Their reasoning is that Javascript doesn't offer the safety or maintainability that other languages do.

Microservices are just the new bandwagon name for Sun RPC and DCE.

Every couple of years people decide to redo distributed computing stack.

It's like a technology time bomb. If businesses are struggling to cope with a limited subset of basic programming languages like Cobol and assembler, they are going to have a nightmare dealing with obscure frameworks.

I'm actually surprised that graduates can still enter the web industry without receiving specialist training - that's how graduates are dealt with if they go down the Cobol route and work for one of the big IT multinationals who maintain these sorts of systems.