We are splitting RESTBase in two components - the (public) REST API router and the storage service (cf. {T220449}). This task is about deploying the front-end REST router in Kubernetes.
== Service Info
**Service name**: RESTRouter (name still under discussion, cf. T220761)
**Owners**: @Pchelolo and @mobrovac (#core_platform_team)
**Repository**: `mediawiki/services/restbase`
**ETA**: by the end of Q4 FY18/19
**Description**: RESTRouter is the routing part of (the current) RESTBase. It accepts external requests, validates them (performs access checks if needed) and performs all the business logic related to the request: it looks up the storage for possible data hits and, if needed, issues requests to back-end services to complete the requests, sending the response to storage prior to returning it to the client.
== Deployment Plan
RESTRouter will effectively take over request handling from RESTBase, so we will need to divert traffic to it without interruption.
First, we deploy RESTRouter to k8s. Next, we expose the storage routes in RESTBase (cf. [PR #1103](https://github.com/wikimedia/restbase/pull/1103)) and test RESTRouter for load (options include synthetic traffic, mirroring, using only background updates/internal requests). Then, we include RESTRouter as an additional back-end for RESTBase. We do more load-tests. Finally, a new LVS is created for RESTRouter and Varnish and all back-end services are instructed to use the new LVS end point instead of the current one. In the post-deploy clean-up step, we remove public route handling from RESTBase, effectively turning it into the back-end storage service.