AUG
Sandboxing
The 10gen runtime environment uses application layer sandboxing to isolate each client environment running on a physical machine. This method is quite different than using operating system virtual machines.
We like this approach as it is more elastic and fine-grained than “booting” VM’s on demand. We want to abstract away the whole concept of a machine. We want users of the cloud to get away from the work of OS configuration, security hardening, and environment scaling.
The foundation of our sandbox is the Java virtual machine (JVM). Much work has been done on the JVM and security. We are trying to leverage that work, and build additional provisioning and quota management layers atop it.
There is a cost of course: you can only execute code which will run within the JVM. We think it is well worth it for the gain in flexibility. If we encounter a special need for an existing software system that will not run on the platform, that program can be ran on a virtual machine hosted somewhere, and we can communicate with it via web services.
Comments
Jong Hian Zin
You can control JVM memory allocation, but how do you limit per-application memory consumption?
Eliot Horowitz
Our main method is by walking the Scope object. We start tracking once either a certain amount of memory has been allocated, or a certain amount of time has been passed. Then we can walk the scope and count memory usage. There are also some people working on openjdk to do per thread memory tracking, which is also a good method which we could adopt later.
dwight
Another technique would be to "quarantine" an environment if it appears to be acting odd. We can run multiple java processes on a box, so we could isolate a particular environment/client. We are not doing this yet (haven't found it necessary so far).