document shinyPaaS best practices

[maxheld83]

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:

• Azure
  • The flag always on cannot, in fact, be switched off.
    If disabled, this results in a docker pull to 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:
    • https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/31660276-cache-the-downloaded-container-image-in-the-contai
    • https://social.msdn.microsoft.com/Forums/azure/en-US/fe8fe287-5e53-4785-80e8-dae2d66afd94/web-app-for-containers-linux-pulls-docker-image-after-sleep?forum=windowsazurewebsitespreview

[maxheld83]

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).

[maxheld83]

heroku, at least via the (popular?) hero-buildpack-r is not ideal, because it does not use docker, but also relies on rsconnect-alike magic.
https://github.com/virtualstaticvoid/heroku-buildpack-r/