Over the last weeks I have been having discussions with the discovery team and the service ops team about the future deployment of some static sites around the wikidata query service world.
Sites of interest:
- **Wikidata query service UI** (currently deployed on wdqsxxxx hosts)
- **Wikidata query service query builder** (currently under development)
Status Quo:
- The fact that the query service UI is deployed on wdqsxxxx hosts makes it harder than it could be to perform deployments. The deployment process is primarily controlled by the discovery team.
- The new query builder needs somewhere to be deployed
- The discovery team would rather not deploy more things to the wdqsxxxx hosts
- Many previous discussions around blubberizing the wdqs ui have said at times that k8s for static sites (if done separately) could be a waste of resources.
- Serviceops however said that it could still be okay? (TBA comment reference)
###Requirements
* Teams that manage / own the sites should be able to update the content of the site
>>! In T264710#6532140, @akosiaris wrote:
> * **Support for structured logging to stdout** to allow debugging issues via our ELK stack should be a requirement.
> * **Support for exporting metrics via prometheus or statsd should be a requirement**. This should allow debugging issues, establishing SLIs and SLOs and allowing to come up with a level of support and ownership of powered services. Failing that, it will be impossible to come up with a level of support and will make those static sites a best effort.
###Ideas
####A) Service per site
Each static site would be deployed as it's own service. (Possibly using a very templated base image)
Pros:
- Simple services
Cons:
- More hardware resources used
- More wiring overhead?
####B) One service to rule them all
Discussed in serviceops IRC channel in September / October 2020
A single image and service would be developed to host "all" static sites
- Content of sites within a single image
- Pros:
- Runtime resource minimization
- Self contained service
- Cons:
- Single point of failure for all static sites
- Complex image to be created, managed and maintained
- Content on swift or some other shared storage
- Pros:
- Runtime resources minimization
- Cons:
- Interaction with another service (swift?)
- Single point of failure for all static sites