We need a clear way for new service owners to communicate to Services and Ops the intent to create a new service and bring it into production.
Taking ideas from https://phabricator.wikimedia.org/T90487#1227730 I am suggesting the following:
- A clear description of what this service does. Preferably a link to a wiki page that clearly states what the service is for.
- A desired timeline for the introduction of the service into production.
- A link to a simplified proposed architecture diagram (possibly in the same wiki page as the description). The diagram should have:
- Request flow from:
- The browser(end-user) to mediawiki (if any)
- The mediawiki (or relevant extension) to the service (if any)
- The browser to the service (if any)
- The service to any other WMF service (if any)
- The service to any external entity e.g. translation APIs, web sites that could be used as citation etc. (if any)
- Jobs that might need to run via jobrunners (if any)
- Data store dependencies (if any)
- Anything else architecturally significant not covered by the above
- Request flow from:
No intermediate HTTP caching layers should be inserted for simplicity's sake, but if HTTP caching is off the essence it should be noted.
Lower level caching layers like memcached/redis should be added. It is highly preferable that the service should continue working if those are unavailable but in case this is impossible it should be clearly noted.
The idea is to have a very very clear diagram, or more if the service is complicated (which should raise eyebrows anyway) for everyone to understand at first glance so it can serve as documentation.
- Who's running point
Probably the service owner, but it might differ so we want that info.