[HN Gopher] GraalOS: Containerless instant-on cloud functions fo...
___________________________________________________________________
GraalOS: Containerless instant-on cloud functions for Java
Author : mike_hearn
Score : 78 points
Date : 2023-09-22 11:34 UTC (11 hours ago)
(HTM) web link (www.graal.cloud)
(TXT) w3m dump (www.graal.cloud)
| local_crmdgeon wrote:
| Why is the naming for Java stuff so ... like that?
|
| 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.
| edem wrote:
| You hate a tech because of ... how unrelated participants of
| the ecosystem chose their names? Why?
| ushakov wrote:
| Seems like a similar concept to V8 isolates used in Cloudflare
| Workers and Deno
| yMMe2WYE_D wrote:
| Plenty of "Learn more" buttons and I still don't know what the
| GraalOS is about.
|
| 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.
| mike_hearn wrote:
| There's not much info out there but I'll describe what I got
| from reading the blog posts and searching for it.
|
| "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.
| jabradoodle wrote:
| Not to defend orocle but AOT java is for reduced startup time
| and memory usage and that is quite clear from the docs.
|
| There is part that describes it as "fast" that could be a bit
| misleading, though it does qualify even that.
| nithril wrote:
| There is as well that blog post introducing GraalOS [1]
|
| 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".
|
| [1] https://blogs.oracle.com/java/post/introducing-graalos
| zaltekk wrote:
| The best I could tell is that it just makes a Docker image for
| you to deploy to EKS. I'm struggling to see why it's got OS
| tacked on the end... it would still seem you're running Linux
| and possibly they've changed some of the userland?
|
| At first I thought this was going to be a unikernel model like
| MirageOS[1] is for OCaml, and now I'm disappointed[2].
|
| [1] https://mirageos.org/
|
| [2] Let's be fair, I was going to be disappointed because of
| needing an Oracle license anyway.
| lern_too_spel wrote:
| There's no more Enterprise Edition. It's free.
| https://blogs.oracle.com/java/post/graalvm-free-license
| norswap wrote:
| GraalVM without native image is comparable or faster to
| Hotspot.
|
| The main point of native image is that it cuts drastically on
| launch and warmup time.
| [deleted]
| mike_hearn wrote:
| There's a blog post with more information here:
|
| https://blogs.oracle.com/cloud-infrastructure/post/ultrafast...
|
| Perhaps that's a better link than the home page actually.
| w10-1 wrote:
| Thanks for the link.
|
| 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 :)
| postexitus wrote:
| Oh the great lengths Oracle has gone to to hide that GraalOS is
| related to them. Not one single Oracle logo in sight.
| duiker101 wrote:
| Tge first thing I saw when opening the page was a big cookie
| popup with the oracle logo
| scoresmoke wrote:
| Yet they have a copyright notice in the footer: Copyright (c)
| 2023, Oracle and/or its affiliates.
| xyst wrote:
| No logo but there is a (c) text lol
|
| > Copyright (c) 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
| flkenosad wrote:
| LOL okay I'm out. Cool idea but can't be trusted.
| kaba0 wrote:
| Unless you are writing this from some self-created 8bit
| computer, while living in the jungle, you have definitely
| been exposed to millions of that.
| misja111 wrote:
| How is this different than a classical application server such as
| e.g. Tomcat?
| weego wrote:
| It's their equiv offering of AWS Lambda. So the difference is
| on demand use vs 750hours/month billing cycles.
| kaba0 wrote:
| It can run many different programming languages, like Java, JS,
| Python, Ruby, any LLVM-based PLs (C, C++, Rust) of WASM-based
| ones.
| Alifatisk wrote:
| Can I compile a Ruby (TruffleRuby?) or maybe a whole Rails
| application to a native image? In that case, is GraalOS meant to
| host these native images?
___________________________________________________________________
(page generated 2023-09-22 23:01 UTC)