[derrekl]

One of the stated lessons learned is: we'd still be on node 0.10 if we weren't using microservices. I've worked a lot on huge monoliths and microservices. Being "stuck" on a version has less to do with monoliths/microservices than it does consistent update practice. If you are using FOSS and schedule periodic updates of the core language and the apps dependencies you'll prevent yourself from getting stuck on old versions. If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). Opening tickets against dependencies as the core language updates helps both you and the dependency owner by helping them test and get out ahead. Not only will you prevent from getting stuck on old versions but you'll also have the latest security updates. Note: you don't have to be on the bleeding edge but you should strive to be, in my opinion, no more than 6 months or so from the edge.

[Jtsummers]

> If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices).

What does go away with microservices (or, in my case, a suite of applications since my stuff doesn't run online), is that each portion only deals with its dependencies. If I have two applications or services X and Y. X depends on D depends on language/library version N. Y has no such dependency, Y can migrate to N+1 while the issues with D are worked out (changing the dependency, fixing the depency, removing the dependency).

In a monolithic application, this is more difficult or impossible. You gain a lot with a monolith, but you lose the flexibility to maintain components as individual components.