Convopage
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? 😕
Well...it 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.
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.
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.
Haven’t seen a Jini reference in a long time.
An early vision of IoT
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?
Have you tried Linkerd2? We are actively fighting that feeling. Incremental installs, lightweight, zero config. Would love your thoughts linkerd.io/2/getting-star….
Getting started
Linkerd has two basic components: a data plane comprised of lightweight proxies, which are deployed as sidecar containers alongside your service code, and a control plane of processes that coordinate and manage these proxies. Humans interact with the service mesh via a command-line interface (CLI) or a web app that you use to control the cluster. In this guide, we’ll walk you through how to deploy Linkerd on your Kubernetes cluster, and how to set up a sample gRPC application.
linkerd.io
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 :)
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.
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 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.
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 EE...you 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.