100% agree. We've just finished to roll out our implementation in Go migrating a subsystem from PHP and receiving around 150req/second and demultiplexing those request to 1500-2000req/second to legacy backends.
The key to the success of the project was that the API was an exact match, and we could compare both implementations for exact requests. The deploy strategy of the new version:
- Reply the real traffic to the new Go service comparing the results with the old one
- Then implement a toggle feature than enabled different traffic sources to use one backend or the other
- Keep changing backends to the new system and ensure that metrics were unaffected
Having e2e and integration tests for the Golang project was of a huge help, since we could fix all differences using TDD.
Although we changed some of the implementations to take advantage of Go constructs, just a 1-to-1 replacement would have had a huge performance impact.
The key to the success of the project was that the API was an exact match, and we could compare both implementations for exact requests. The deploy strategy of the new version:
- Reply the real traffic to the new Go service comparing the results with the old one - Then implement a toggle feature than enabled different traffic sources to use one backend or the other - Keep changing backends to the new system and ensure that metrics were unaffected
Having e2e and integration tests for the Golang project was of a huge help, since we could fix all differences using TDD.
Although we changed some of the implementations to take advantage of Go constructs, just a 1-to-1 replacement would have had a huge performance impact.