Red Hat Tosses Its Weight Behind Quarkus

[phoronix]

Phoronix: Red Hat Tosses Its Weight Behind Quarkus

Following recent announcements, Red Hat is now ready in fully supporting Quarkus to enhance its Kubernetes support...

http://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-Fully-Supports-Quarkus

[treba]

While the technology surely sounds interesting, I still ponder if "serverless" is really a good term. It's somewhat descriptive - but also wrong in the end. Your code still runs on servers, no matter how many layers of abstraction you put between it. And it somewhat hides the fact that it's often not *your* servers the code is running on. So when I read it, I always think: "hypetech".

[aksdb]

While the technology surely sounds interesting, I still ponder if "serverless" is really a good term. It's somewhat descriptive - but also wrong in the end. Your code still runs on servers, no matter how many layers of abstraction you put between it. And it somewhat hides the fact that it's often not *your* servers the code is running on. So when I read it, I always think: "hypetech".

Yeah...
I mean it's kinda correct in the sense that your code is no longer actively serving anything ... but that's basically nothing else then good old CGI scripts
The big problem is that it suggests you don't need any server any more. Which immediately triggers managers that see "no costs for server hosting and maintenance? NICE! $$$"

[cen1]

Yeah...
I mean it's kinda correct in the sense that your code is no longer actively serving anything ... but that's basically nothing else then good old CGI scripts
The big problem is that it suggests you don't need any server any more. Which immediately triggers managers that see "no costs for server hosting and maintenance? NICE! $$$"

well.. it is true in the sense that you don't have any server maintenance overhead like updating bare metal or VM instances

[aksdb]

well.. it is true in the sense that you don't have any server maintenance overhead like updating bare metal or VM instances

But introduces other costs and risk. "What do you mean we can't get better than 100ms response time?!" "Sorry, but the function needs to spin up for each request first."

Or ... "why can't we do XYZ with the connection?" "the reverse proxy is not in our control and doesn't support it"

In those regards I think containers (via K8s or the likes) are a good middle ground. You still have not full control (over the underlying kernel for example), but at least you can control the user space and have (more or less) normal networking. Those "functions" (or "serverless code") is a bit too abstract for my taste.

Nonetheless, Quarkus also serves well as microservice framework inside Docker. I hope I can mange to port some of our Java/Kotlin services over and can then leverage native images (so the container redeployments don't hurt as much as they do currently).

[polarathene]

Your code still runs on servers, no matter how many layers of abstraction you put between it.

The big problem is that it suggests you don't need any server any more. Which immediately triggers managers that see "no costs for server hosting and maintenance? NICE! $$$"

Serverless absolves you of managing a VPS instance or many scaling issues, saving time/money from not dealing with security and maintenance which is nice if you trust the service(which provides the servers that offer to run your code on demand).

Definitely has limitations and may not perform as fast/reliably as your own tuned server(s), but gets your project up and running in production sooner which is a worthwhile perk. Generally, until things pickup, the on-demand costs will likely be most affordable, if your project becomes popular and is seeing constant activity, then it's no longer cheaper than a VPS(at least rent cost), and migrating may be beneficial there. k8s like aksdb mentions is great if you need scaling based on variable traffic rates/load.

Note that some serverless services don't have that limitation of spinning up for each request, some will cache the init portion and keep it hot for a little bit longer, or keep RAM available, and direct traffic to that instance for a duration until becoming a cold start again.

You can also leverage a mix of each option based on what suits portions of a project best.

[bug77]

While the technology surely sounds interesting, I still ponder if "serverless" is really a good term. It's somewhat descriptive - but also wrong in the end. Your code still runs on servers, no matter how many layers of abstraction you put between it. And it somewhat hides the fact that it's often not *your* servers the code is running on. So when I read it, I always think: "hypetech".

I think "serverless" goes well with "cloud". Both barely descriptive, both plenty misleading

[skeevy420]

Come to Quarkus
Quarkus fun
Come right now
Don't walk, RUN!

[Larry$ilverstein]

I still ponder if "serverless" is really a good term. It's somewhat descriptive - but also wrong in the end. Your code still runs on servers, no matter how many layers of abstraction you put between it. And it somewhat hides the fact that it's often not *your* servers the code is running on. So when I read it, I always think: "hypetech".

They're dumbing down the language for the next generation of developers, hoping they'll become dependant on black boxes and cloud tech instead of their own skills and knowledge. It's already starting to happen now.

[Jabberwocky]

They're dumbing down the language for the next generation of developers, hoping they'll become dependant on black boxes and cloud tech instead of their own skills and knowledge. It's already starting to happen now.

Lambda calculus was introduced by the mathematician Alonzo Church in the 1930s.

Anonymous functions are introduced using the keyword lambda, and anonymous functions are often referred to as lambdas or lambda abstractions. Anonymous functions have been a feature of programming languages since Lisp in 1958. In 2020 it is still called Anonymous or lambda functions by competent developers regardless of what generation they are from.