1. Improved spreadsheet clarity to make the migration blocker & PoC coverage clear
The goal of this improvement is you guys are clear to what system you'll migrate and what blocks you to do the migration. See the updates here https://docs.google.com/spreadsheets/d/1iCgVg6bMunf3OzAi9G3ABjNNeddAW030_dypRR2A7sg/edit#gid=1465737026
2. Estimate for migration effort / workload required by domain engineering
We'd like to propose an engagement model to domain engineer and provide a workload assessment.
Engagement Model: https://docs.google.com/document/d/1fHdV5MAfdvRe5B47yHowWS1usm0Tt89K5pE4dN1pVIE/edit#heading=h.l6ouwnx89og6
Workoad Estimate for each team: https://docs.google.com/document/d/1fHdV5MAfdvRe5B47yHowWS1usm0Tt89K5pE4dN1pVIE/edit#heading=h.yfmmufat2jdn
Please do give your input, especially related to our target to finish by Q2, or whether need to wait until Q3 (quite risky). Please also consider
3. Extended PoC deadline to Mid April to accomodate risk we found.
Our pipeline is GCP PubSub --> DataFlow --> DataStore. We found a risk related to DataStore due to latency SG-Tokyo. It is quite acceptable based on load test but just to be safe. Our mitigation plan is AWS DynamoDB or MongoDB.
If we need to change data store layer, we'll need another 2 weeks at best or 4 week worst case.
However, if our PoC result is good, we'll still deliver at Mid March as previously communicated.
Please note that:
So Prod Eng can safely plan with assumption of mid Apr for all the pending migrations due to dependency