maxheld83
commented
4 years ago should comment on particularities of shiny:
- actually needs dynamic scaling, though mostly in the direction of to 0 😏. Especially relevant when app is shown to groups, seminars etc.
- the whole point of shiny is to reduce time to value, and to leverage data scientist skills (rather than full-stack dev). So we should absolutely reduce the amount of general dev/ops overhead (Kubernetes, running your own server/vm, even running shiny server (pro)/rsconnect should all be avoided). The present muggle design avoids all of these.
- shiny is inherently stateful and (related) runs on WebSockets, both of which don't fly with serverless/FaaS products such as google cloudrun. So we're a bit in a weird spot.
- shinyapps.io also adresses all of these concerns (scales to 0!), but it does not
- use images, so reproducibility is dodgy (packrat)
- no good way to pass secrets to connect to external services
- pricing may not be competitive (?) (probably is, if you factor in developer time).
both for our internal cost justification, as well as potentially for other people, I'm going to document why/how to set up shiny in a public cloud PaaS.
Currently, we're going with Azure.
Notes:
always oncannot, in fact, be switched off. If disabled, this results in adocker pullto get the app out of idle, which takes so long (>10 mins) given current speeds that any client HTTP request has long timed out. So that is an unuseable option, and it's a bit weird that they even offer this for docker based deployments. Might make sense for non-docker Azure Web Apps, where binaries are much faster or better cached or whatever. Relevant discussion: