Real-world Engineering Challenges #8: Breaking up a Monolith

Always interesting to read these experience reports, and it seems like an overall very well-managed migration.

> Talking with the team, I’m told they compared the service hour cost of operating the same code on Python and Go. The difference was an order of magnitude in favor of Go, which was up to x10 cheaper for certain types of requests.

I'd love to see the overall cost deltas. "up to 10x cheaper for certain requests" is quite vague and compatible with everything including an overall negligible cost improvement in the system operating expense.

> Moving to Go will undeniably be more effort than moving to Python 3, but the performance win alone makes it worth it.”

I believe they might have measured this internally, but the article never presented any data that justifies this assertion. Elsewhere they mention that they thought Python2->3 is expensive, but I am pretty skeptical it's a 100-man-year project to 2to3 1m LOC. I would be surprised at tens of man-years to be honest.

That said it's always difficult to measure ROI on these sort of refactors when there are multiple migrations being done at the same time; Python to Go, Monolith to Services, REST to GraphQL.

I do suspect that a polyglot approach might have been overall cheaper; for the long-tail of services especially where performance isn't critical, just extracting the Python code to a service, running 2to3, and slapping a GraphQL API to replace the existing REST one could end up being way cheaper. The risk of course is that you then have "legacy code", but if you have half of your services in Python it's less of a problem.

Taking this approach would let you get back to writing features sooner, rather than spending all your resource on migrating services where there isn't actually much bang for buck from moving to Go.