GraalOS: Containerless instant-on cloud functions for Java
graal.cloud
graal.cloud
So instead I will just point out to: https://www.oracle.com/a/ocom/docs/graalvm_enterprise_commun... where Oracle shows how GraalVM AOT apps are slower than simply running on normal JIT JVM unless ... you use the "GraalVM Enterprise Edition". I guess it always is some kind of sales pitch with them.
At first I thought this was going to be a unikernel model like MirageOS[1] is for OCaml, and now I’m disappointed[2].
[2] Let’s be fair, I was going to be disappointed because of needing an Oracle license anyway.
But still only providing marketing information.
It sounds like they are interleaving GraalOS feature with the Oracle cloud feature, eg. for the "Run On Demand" and "Applications, not Containers".
"Serverless" stuff like the (proprietary) Lambda or (open source, https://fnproject.io/) Oracle Cloud Functions are based on a few ideas:
1. Use Linux syscalls+x86 as the target ABI/ISA. Thus programs are Docker containers and because the kernel is a bit too much C to trust, maybe also custom virtual machines for sandboxing.
2. Because downloading a full blown Linux userspace and starting it up inside a new virtual machine can be slow, then add a variety of hacks on top to try and make a start/stop model look like an always on service. For example by having always-on instances (which means serverless now has servers again), by using Docker layers, idle timeouts and other stuff.
GraalOS asks the following question: Is there a way to do server-side computing better if we toss Linux and x86 as the API?
This question just leads to more questions:
• What do we replace it with?
• What are the benefits?
GraalOS starts by saying, let's replace Linux/native code with the Java specifications instead. This gives you a relatively large and consistent yet open source surface area for doing all the server-side basics you need like IO, threading, memory management and so on. You can then layer Truffle (from the same team) on top to get other languages like JavaScript, Python, Ruby, WASM, Rust or C++ (via LLVM bitcode) and so on. All of these running on top of the JVM rather than Linux.
In this model the JVM isn't an operating system, exactly, but it might as well be because you don't have access to the underlying kernel at all. There's no way to make system calls in this model that aren't mediated by the standard libraries of your language. And this is enforced via two very different sandboxing technologies:
1. The server controls the compiler.
2. Intel MPX and whatever the AMD equivalent is.
Controlling the compiler is how you implement software level sandboxing. Because all code running on the CPU is created by your own compiler which the developer cannot choose (like in a browser), you can implement and impose whatever policies you like. The most obvious is no syscalls, no unsafe memory accesses and so on. But then you may want more than that, for example, how do you stop Spectre attacks extracting secrets from the address space? To which the answer can be the CPU's "Memory Protection Keys". This is a very, very fast and lightweight way to do a kind of in-process context switch. You can associate page ranges with a "key" and then put that key into a special register to control what memory ranges are currently accessible. It's like an additional set of permissions over what the kernel has set up. Because you control the compiler, you can ensure that only system code can alter the current memory protection key, and then this lets you compile and execute untrusted code without worrying about speculation attacks.
So that's the theory, what's the benefits?
The first benefit is that you don't need containers anymore. GraalVM has the "native image" tool that produces native Linux standalone executables from JVM apps, like Go does. And those JVM apps can be interpreters or JIT compilers for other Truffle languages as well. So now, you no longer need to drag around half an Ubuntu install for each app you run. It means programs can be moved between servers way faster because there's less to copy, and anyway Oracle Cloud has notoriously excellent networking, from what I've read, so new instances can be spun up much faster than before. And native images start ~instantly because they are fully native code and have a persisted heap snapshot computed as part of the build process, so they effectively start already initialized. And then finally in some cases they can do snapshotting post-startup too, for fast suspend/resume, and the compiler knows how to do MPX keys.
So with all this done, you can produce a server side infrastructure in which programs are just shared libraries loaded and unloaded into pre-warmed HTTP servers, yet still isolated and protected from each other, and because things are way faster you can actually just start and stop these servers genuinely on demand on a per-request basis. There's no need to charge users for idle minutes as you try to avoid a shutdown/startup cycle. In turn that means a lot of complexity just boils away.
BTW, I just checked and it turns out that Oracle's "free cloud" deal applies to functions as well. You get like 2 million free activations a month or something, and 400k "gigabyte memory-seconds". So if that pricing is sustained with this then it means a lot of types of JVM servers will just be completely free to host, because native image also reduces memory consumption a lot.
At least that's my guess as to what's going on. But it's not launched yet, just announced. I guess we'll have to see what it's like for real when it's available.
There is part that describes it as "fast" that could be a bit misleading, though it does qualify even that.
The main point of native image is that it cuts drastically on launch and warmup time.
https://blogs.oracle.com/cloud-infrastructure/post/ultrafast...
Perhaps that's a better link than the home page actually.
It's easy to dismiss Oracle technologies (because ... Oracle), but we should consider the implications.
As a reminder, Oracle won the Java enterprise database market for a decade by embedding Java in the VM, and optimizing it internally.
This stack (GraalVM producing OCI-functions-compatible functions running on their function container) is similar: it uses (relatively) open standards, but the GraalOS container can optimize the GraalVM code for a given processor (or even memory).
I doubt they've done much publicly other than cobble the stack together, but it tracks the product-evolution razors-and-blades approach that JavaSoft started in 1998: the GraalVM AOT can be free, and running on the cloud is possible (via OCI-fn containers), but cloud optimization can cost.
So they can build share using GraalVM that they can harvest in GraalOS.
And functions as a server depend implicitly on data services running in the cloud, i.e., databases. Migrating use-cases there builds their legacy business.
That's the pitch, I think.
The army of Java is never more than 1-3 years behind every sophisticated new approach :)
> Copyright © 2023, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks. Other names may be trademarks of their respective owners.
Footer of graal.cloud
Next.js! Nice!
Graal, JavaBeans, IDEA, SpringBoot (seems like a word, isn't), etc?
It's kind of grating, I think it's a big part of why I hate Java.