We would like to create a migration endpoint for ORES that translates ORES calls to the corresponding ones for LiftWing and returns their results.
In the process of migrating ORES we want to be sure that anyone who uses ORES will redirect their traffic to LiftWing. However we can't control that everyone switches at the right time before we start to decommission ORES.
Such an approach has the two following main benefits:
- We respect the community and the users by not putting a hard stop on the usage of ORES and decommision it in a graceful and respecful manner.
- By creating such an application we can control when we can make the switch and LiftWing launch is not blocked by lack of adoption/migration.
The initial proposal is to deploy a FastAPI application on our Kubernetes cluster (a deployment and a service) that will translate ORES calls to LiftWing.
The two main reasons to implement the above with FastAPI and k8s are:
- Ease of Development: it is easy to create a microservice with FastAPI that can handle async connections.
- Scalability: If this application receives more traffic we can scale it in k8s by adding more replicas.
After we switch on LiftWing we can use ores.wikimedia.org as the endpoint of this application, monitor its traffic and communicate with the applications/users that still use ORES to transition to LiftWing.
Once this is done, the application can be deprecated.
