I don’t have insider information anymore and I haven’t worked at Heroku since early 2017. I had assumed they had already replaced the router.
There was two halves to hermes. The first was vegur, the proxying layer we had written and open-sourced. The other was hermes, the parent app that managed all state, certificates, auth, domains, and hooked it into vegur.
The things I imagine didn’t age well are probably:
- vegur
- a dependency on a fork of cowboy required for proxying needs
- a bunch of internal but public libs nobody in oss would maintain
- hermes:
- lager (outdated but shouldn’t break)
- aws libs (easy to update)
- bitcask (was used for per-host TLS cert stores)
- a bunch of internal but public libs nobody in oss would maintain
Interestingly enough, I recall a coworker and I delivered a functional HTTP/2 prototype version of the proxy back in 2016-2017 so there is definitely a way to do it. It used Joe Devivo’s libs that are loosely maintained and that I think Tristan since took over but don’t move fast. (Incidentally Joe and Tristan both were on our team there for a good while…)
So while I would expect the dependencies on a very old cowboy/ranch fork to be trouble, the main blockers in my mind would be the inertia of having lost most devs, and possibly bitcask.
Bitcask had a bunch of C code, it has seen a few updates in the last few years and maybe that was a blocker.
But unless things changed drastically since my time there, people internally were just not excited for Erlang anymore, and rewriting everything to Go (including Ruby and Erlang) was the objective starting somewhere in early 2016. All the people most excited about Erlang left before me, and a few stayed after my departure who were okay with it but that wasn’t their main thing.
Salesforce kept me on retainer for almost 2-3 years to help with rare logplex incidents before they fully replaced it (it took two if not three rewrite attempts to do it).
But like at that point I suspect any excuse is right to replace the old Erlang stuff, and the cost of updating OSS deps wouldn’t need to be high to tip the scales, even if it’s just forking to fix deprecation errors.
Either way I imagine that it’s not a question of “would it be too hard?” But one of how much work is it compared to the alternative they picked.
My assumption is they’re actively maintaining the Go stuff and they long ago decided to let the Erlang stuff rot. They decided that before I left and we had discussions about that.
I think they’d easily favor migrating rather than going back on the rot and wanting to re-staff teams to clean up and reappropriate our old libs that seemingly did the job running in prod mostly unmaintained for 7 years.