See the entire conversation

Java is having trouble fitting into serverless because Java (EE) *was* "serverless"; deploy functions that call into opaque service APIs and rely on some container to scale and replicate everything. It would be interesting to see a cloud-native Java container that has no edges.
39 replies and sub-replies as of Aug 30 2018

"was", as in it isn't any more? 😕 still is, but are people doing a lot of new EE apps these days?
Ah. Gotcha! I see where you're going. However, there's many things in EE that are used frequently, which technically means there's tons of EE apps -- even if they don't use EJBs. (e.g., JSP, JSF, RESTful API, JPA, EL, JMS)
And, if I just went into "explaining the basics to a recruiter" language on you, sorry about that.
Oh sure, I understand. I just mean the idea of a big fat EE app that would be similar to a "big fat serverless app" is less typical than it was when I did EE architect stuff a decade ago.
JINI / JavaSpaces well over a decade ago enabled distributing objects over a network and loading classes the receiving JVM had never seen including alternate versions of classes it had already seen. Sadly little marketing from Sun due to "Sun West" vs. "Sun East" internal rivalry
Yes, I'm wondering if what we need is a higher-level concept of a distributed JVM that can live and scale elastically without intervention. Each one would have its own local heap, run its own functions, but to the user they'd be one big JVM/Java container.
This kind of architecture was discussed by Gemstone early in its work with Java, ca. 1997-8 but Sun wasn't ready to think about such things at the time. That would have done great things for Gemstone/J
Ah yes, that's true. They did have a mostly-opaque distributed VM. I remember it being demonstrated for their Ruby impl that never went anywhere.
Weblogic clustering basically gave you that 15+ years ago as long as you used the right APIs that could support it.
Yes indeed. The big difference then is that you get strict resource isolation with containers where JVMs were shall we say "the wild west" if you got a rogue element in there.
There's another angle to this...EE had all these artificial restrictions you "had to" follow because there were no hard boundaries between "functions". Sometimes it was worth breaking rules. With FaaS/serverless you can't break them...walled garden all the time.
Look at the people making monolithic lambdas though. Same thing. Bad programmers everywhere.
Or sharding the hell out of an app because it's the right thing to do, and burning all their cycles trying to coordinate functions that should be in the same environment to begin with. I'm having a lot of lightbulbs with this whole thing today.
Which brings me back to JINI / JavaSpaces...
Haven’t seen a Jini reference in a long time.
An early vision of IoT
Early IoT was used to pitch JINI to a large degree because the EE products were internal rivals and had the enterprise brand and partners. Nothing about JINI is ill suited for the enterprise. In many ways its better suited than EE. We see a form of that now with "microservices".
I was thinking the other day that deploying containers to k8s with a service mesh starts to feel a lot like deploying J2EE apps to Glassfish back in the day, but with even more moving parts.
Yeah exactly that, and also without the benefit of a shared heap. You pay for each function's container separately. Do we need a distributed JVM?
I haven't tried much of anything since I did CORBA and Web Services apps in the late 90s 😀 What's old is new again! So this is basically the glue layer between all your serverless servers, yeah?
s/serverless servers/containerized services/ and then yes :)
Yeah I'm new to the serverless/Faas jargon...bear with me :-)
No worries, the terminology changes every few days anyways :)
With a key design goal being low latency between external stimulus and your designated handler code running; no JVM warm-up or dependency-injection reflection craziness required. The hard part would be to make it elastic & horizontally scalable.
Yeah exactly...make the "cloud JVM" be the "serverless" container, localizing functions/services that should be localized to a shared memory space and avoiding remoting costs. This could potentially be done as a layer atop existing Faas/SL systems. Not EE...Cloud Java.
Google App Engine?
Yeah that's got some of what I'm thinking about. Something that can be transplanted to other clouds would be better obviously. I'm trying to figure out what the path forward is for "cloud Java" without having to AOT compile and revert to Java 1.6-era coding patterns.
I’m loving it. It supports Java 8 and basically has no restrictions anymore.
I need to get my hands dirty with actual user-facing apps again. It has been too long.
I need to see what a JRuby app looks like there.
You've got the right idea, but the wrong stack.
Yeah, tight squeeze. Right language, maybe. The runtime + JDK baggage is a bugger though.
Isn't that appengine standard Java?
Yeah it does generally fit that description, but it's not transplantable to other clouds nor to a locally-administered server.
Nor is any serverless thingy - that's the point
But that was the point of Java were supposed to be able to move to any container and use the same APIs. We've gotten back into lock-in territory and rent everything. They tricked us into accepting proprietary runtimes. A true "cloud Java" would be the same on any cloud.