Deployment strategies and tenancy

#1

Hi all. So we are at the stage of deployment in adopting theia in-house. We’ll have N users needing to spin up IDE’s which would connect to in-house code repo services for them to author , edit , and execute code against running engines in our kubernetes cloud.

I have some assumptions I’d like to check with you guys :
My assumption is that we would never want users to share the same theia backend as it stands. It would be fighting the architecture of theia to try and make theia soft multi tenant. We’d have to make all backend services free if user state and essentially in the cloud. Correct?

The better model is hard multi-tenant like gitpod where each user has its own back end. Correct?

In a pure docker implementation , it’s pretty easy to implement via remote engine API. You have a landing page container which uses remote engine api to spin up a theia container , and manages the lifecycle.

In terms of kubernetes implementation it doesn’t feel like the natural case. Does anyone have any views on this? It feels to me that session affinity for one theia pod is a bit against the ethos . There isn’t anything in kubernetes that really deals with that other than session affinity service and ingress controllers. Feels like you’d end up to do the same as my standalone docker approach but using the kubernetes API to manage this tenancy model.

Any comments on where you guys see theia heading in the future that may impact my decision ?

Thank you very much

[original thread by Max Hillaert]

Questions about Theia
#2

[Max Hillaert]

Follow up question. What exactly is stateful in the backend? I see that preferences are saved on filesystem, which could be mounted on the cloud. But what else is user specific and would disrupt user experience when they suddenly get switched to another theia instance if they refresh the page

#3

[Max Hillaert]

some of this is addressed at https://spectrum.chat/theia/dev/is-theia-multi-tenant-in-any-way~e92b1c24-e086-46c4-a35d-00a7ff951f18https://spectrum.chat/theia/dev/is-theia-multitenant-in-any-way~e92b1c24-e086-46c4-a35d-00a7ff951f18

#4

what else is user specific and would disrupt user experience when they suddenly get switched to another theia instance if they refresh the page

#5

Though not saved in the backend, the workbench state just before closing the browser window is saved in the browser’s local storage, associated to the “origin”, which contains the URL of the backend. So if the user was working on a backend, closes the window, and connects again but gets “served” a backend with a different URL and or port, the previously saved workbench state will not be restored.

#6

Theia is not multi-tenant and your analysis is correct in that it is designed to be single user and you should build a what you called “hard multi-tenant” solution around it. The hosting and multi-user part is out-of-scope for Theia so there is no intend to change this.
You can build your own solution or use an existing one such as self-hosted Gitpod or Eclipse Che 7.

#7

[Max Hillaert]

Thanks guys. We are building our own.