Shiny applications and Kubernetes


I'm working in a project for a big customer in the public sector. We're providing a Kubernetes platform in AWS where Shiny applications are deployed to.

Currently there's a problem regarding performance. It seems, Shiny applications require a session so we had to enable sticky session. This causes issues on the performance side, such as bad load distribution among the pods and we cannot enable horizontal pod autoscaling. Disabling sticky session on the other hand leads to issues such as HTTP requests for .css files etc. returning a 404 in case they were being sent to a pod that the user did not originally connect to.

Is there a way to develop Shiny applications that do NOT require a session? And if it's possible, how? Or is it possible to handle the session on the application level?


Shiny applications are a combination of a UI that runs in a browser client that relies on the back-end server to execute code in R for which it needs, naturally, the R session. True to its origins as an interactive desktop tool, R is single-threaded, so it cannot just spawn processes as needed to keep up with demand.

The fine folks at Posit keep the lights on by licensing industrial-strength versions of their free open-source products that better manage the challenges of multiple concurrent users. I assume that if you were using the paid version, you'd be getting official, rather than community, support with this challenge. You might want to contact sales to get pitched on how the paid offerings might solve your problem. I feel reasonable confident that they won't oversell, because of the subscription model. And they are good folk.

I ran my first server in 1996 on an SGI workstation over a 56K fractional T1 and, on fewer cycles and less memory and storage than any iPhone, comfortably ran DNS, HTTP, HTTPS, SMTP, LDAP, certificate, proxy, reverse proxy and newsgroup servers concurrently without breaking a sweat. Because of light load and client side I/O boundedness. No one's I/O bound anymore, it seems, it's all CPU bound. Hence the need for bare metal speed, which is not something R provides.

This brings me to raise the question—what problem does Shiny solve for your client? If it's a production-level platform (think DMV database queries) involving typical business logic activities mainly revolving around arithmetic to do things like comparing this month to last month, Shiny's pretty face is nice, but R's capabilities are 99.99% wasted. Yes, R can do this stuff, but so can almost any other language. With WASM, you can even do it all in browser.

On the other hand, if it's research-level stuff to develop service demand volatility models, the boffins working on it neither need nor want Shiny. They want to do things in R on the fly using every known statistical tool that has survived contact with practice. That's R's "core competency"—the depth of its tool bench.

My take is that the places where Shiny is strong are in ad-hoc team level projects and in prototyping production apps, which are likely to be lightly loaded. My public sector experience is that their tech uptake tends to be a ponderous process. Which bring me back to the question: Is Shiny the right tool for this job?

Check out this blog post with thoughts about Kubernetes and shiny apps

In short, I think the deployment pattern with open source tools will include shinyproxy or a decoupling of the R backend as an API would be required.

Hi Madrian. Our production and publishing platform, Posit Connect, now supports off-host execution in Kubernetes.

I am on our public sector team. Perhaps your customer already has a Connect license? Get in touch with me and I can point you in the right direction.

This topic was automatically closed 54 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.