Is Serverless Just a New Word for Cloud Based? | Hacker News Reader

Is Serverless Just a New Word for Cloud Based?

percona.com

37 pointsbratao66 comments

It feels like most comments on this thread haven't really read the article, which opens up by defining the term. The problem is that it has an extremely bad title (any title that you more or less refute in your opening paragraph is a bad title).

A good title would probably be "Benefits and Risks of Going Serverless", which is a subhed that occurs later in the article.

The main issue is that "Serverless" is a really crappy name given there are actually servers involved.

Although confusing/misleading names might be good at getting attention because they prompt people to dig deeper to figure out what they mean.

The name "serverless" is fine. Everything is ultimately run on servers of some sort; the point of the name is that consumers don't manage (or really in many cases even need to be aware of) those servers in a serverless model like AWS Lambda.

The issue is that, on a first impression, "serverless" sounds a lot more like p2p than "developers/admins don't need to worry about managing the servers".

I disagree. I believe if you're thinking about how you want to deploy an application, you can say, "We want to be serverless in that regard: we want to manage as little as possible." It's on par with saying, "We want to be hardwareless in what we manage" and so you hire IBM, with a managed services contract, to deliver, install, maintain, and so on, your office IT equipment.

You're "hardwareless" from the management perspective, the cost center perspective, in that you don't own it, manage it, or maintain it, you simply use it.

I'll concede it's a bit of a mind bending term, though. You have to think of it from the right angle and in the right way (which means taking off your engineer hat to a degree.)

It's not just a question of managing as little as possible; it's also a question of the unit in which you want to scale and be invoiced (by invocation or by some broad unit of capacity).

I want to be invoiced as little as possible and as efficiently as possible. If I have a choice, when developing an MVP for something I have no idea the market wants, I want to be billed as little as possible, not every hour whether I use the kitchen sink or not.

This whole thread makes the point by itself. It shows how it pretty much requires at least a small conversation to understand what the term "serverless" means. This implies it is not self-explanatory at all, hence confusing and misleading.

requires at least a small conversation

I'm not super fond of the term myself but the only cases in which it seems to 'require a small conversation' is when people who know exactly what it means complain about how it doesn't mean what they think it should mean.

Or when the people who don't know what it means need to ask other people what serverless actually means.

No doubt. Just like every other unfamiliar term.

This applies to virtually every technology in existence. I've never had to explain what Serverless means to another engineer, only people, like management, who tend to be non-technical :)

Sure, you could also argue the same about all the words in the dictionary, because at some point everyone had to learn what the words they are using mean.

However, "serverless" is pretty much the only concept (please post more examples if you know of any), which is used to talk about something that is not the literal meaning of the word (it's etymology).

The word "serverless" literally means "without server", but it's being used to mean something that requires a server.

It's almost as if ethernet connections had been branded/marketed as "wireless".

I didn't know what it meant until I read blog posts about it, and I'm technical. Now I do know, and I regret it. This usage of "serverless" is like something from The Book (the one in Anathem, not Erdős's book). A piece of wrong data that's wrong but you nevertheless have to hold onto it, throwing everything else in your brain somewhat out of alignment. Like a splinter in your mind, driving you mad...

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

I first encountered this adage in the ad industry.

"Your headline should never be a yes or no question, because people will always say 'no'".

Serverless is just a new word for single-serving computation.

Everywhere I travel, tiny life. Single-serving sugar, single-serving cream, single pat of butter. The microwave Cordon Bleu hobby kit. Shampoo-conditioner combos, sample-packaged mouthwash, tiny bars of soap. The people I meet on each flight? They're single-serving friends.

~ Fight Club

It's the gig economy for servers. Rather than a server having a stable comfortable job, it must get one piece of work at a time and only gets reimbursed for services performed, not for its availability.

Nicely put.

You could say, "Uber for Servers" - very apt description you gave it.

Which calls for an "Airbnb for servers", which will allow anyone to rent their phone for gigs in the server gig economy (at least until the servers unionize)

Botnet operators were so ahead of their time.

The current storyline of Silicon Valley I believe.

I used to run SETI@home [0] on my computer back in the early 2000s. Made for an interesting screensaver whenever friends were over.

[0] https://en.wikipedia.org/wiki/SETI@home

FlexCar for Servers.

Yes, at 5x the hourly rate of a full-time server.

So it's consulting for servers

But you're not paying the server to browse Reddit.

5x? where did you get such a bargin

In my mind, it's somewhere between shared hosting and having your own virtualized environment like an EC2 instances.

Serverless is Cloud 2.0. The goal is to abstract everything away, making it PFM so C-level execs at unicorn startups don't have to waste brain cycles understanding anything beyond their immediate "core competencies". And just like "the cloud" abstracted physical hardware, disks, etc. into PFM (you need a server, presto! an abstract server will appear when you cast the circle and wave money in Amazon's direction), so "serverless" abstracts away even this abstract server and its OS and software infrastructure.

The next step, obviously, is a softwareless infrastructure, allowing C-level unicorn execs to simply exert their will without going through pesky developers. Is this what the current "no code" trend is about?

What is PFM?

Pure F... Magic

Source: Worked with senior devs long enough to hear the term uttered before.

What "no code" trend?

QuickBase, Bubble, etc.

Ah, I believe they’re calling that Robotic Process Automation (RPA) now. Why bother to even look for the API docs for that shitty SaaS app? Just train Selenium to do it and feed it inputs, then hire some dude offshore to update the automation whenever some step breaks because they changed it on the other end.

Honestly it’s faster/cheaper than doing proper integrations most of the time, simply because the tools are already well-known to the users so there isn’t a lot of futzing around with unfamiliar tools or APIs.

It turns a technical challenge into a business challenge simply by automating the lowest common denominator through the stupidest possible means, and automating it through a point and click GUI. It’s the final nail in the coffin of the swivel-chair data analyst at most companies, however.

This is already happening widely across fortune 500s today... the bloodbath is being felt by the Indian offshore folks who are losing a ton of basic automation support / development work to these RPA tools (which can be operated by onshore management consultants doing operational design work).

What RPA tools would you say are the best ? Anything you'd recommend?

Depends where you are in the market and what other tools you’re using. I’ve seen it set up many ways; from just recording macros in SeleniumUI, hand-parameterizing them and running them on SauceLabs to being part of a full enterprise integration suite like Pegasystems.

I would say UIPath has a pretty good product at the low-mid range though. The high end tools require serious enterprise architecture capabilities like business process management already be in place. UIPath is pretty good if you just want to set up a simple API gateway, parameterize some flows and pass data back and forth.

This space is only now heating up, but IMO a dumb technology like RPA can be more transformative to the industry than we think simply because it’s not technologically elegant. It does solve a real business problem (need to keep deep technical knowledge in many many areas on staff) with a very general-purpose setup.

Serverless is basically "you write a stateless app and we'll take care of running it."

Like so many things in tech, it existed long before there was a catchy name for it. I'm sure Google wasn't even the first, but they were selling "Serverless" technology with App Engine 10 years ago.

CGI scripts anyone?

As someone who has been working almost daily with Lambda and other AWS serverless services for close to 2 years, it astounds me to see so much FUD and misinformation among one of the smartest technical communities that I know.

Serverless is about making as much computing power as you demand available on demand with a "pay only what you use" price model without demanding that you maintain the underlying systems. In addition, embracing this model tends to allow you to break out of the request driven model of needing to call APIs for everything. Instead, you enable a whole host of new event driven interactions between application components.

Even this article misses one of the more interesting advantages: scalability under varying load. AWS Lambda may cost more than an equivalent EC2 instance if run constantly, but it scales up and down almost instantly without adding cost. You just pay for the compute time. So, burst traffic is no sweat (up to your account limits or function configured limits). If your application has highly irregular load, Lambda can keep it more responsive while saving you money too.

And it is nothing like paying for shared hosting or other single unit, where you still have no horizontal scalability.

Serverless just means that we don't run the server ourselves, and that we often get a direct connection between the client and a database like FireStore, without anything in the middle.

Many tasks can be done with reduced security privileges directly from the client, by setting up some declarative security via something like Firebase Security Rules.

We don't even need a server for handling File Upload, that is handled by something like Firebase Storage. Of course that there is a server somewhere, its just that don't develop it ourselves but we instead use it as a service.

For tasks that require increased security privileges, or for things like video or image processing we can still spin up a node server if needed using something like Firebase Cloud Functions.

The end result is that we only end up writing minimal server code, and almost all of our code is client code. This does not mean that there is no server though, so the term is a bit misleading but it still captures well the fact that we only have to write a reduced amount of server code.

> Serverless just means that we don't run the server ourselves, and that we often get a direct connection between the client and a database like FireStore, without anything in the middle.

Umm.. there IS a server in the middle. With some form of docker image with some code on it.

Same as if 10 years ago you spun up a EC2 instances, or 1 year ago spun up a docker image on one of the many providers that supports such things.

How do you go directly from client to database with nothing in the middle while being unable to trust the client?

Policies are put in place in one fashion or another. You’d do this differently in DynamoDB or Firebase but basically you set up a rule like, users can only update records with a key matching their user ID. So that logic does end up somewhere. Instead of in a Lambda or Cloud Function the logic is “embedded” in the database. IMHO this is an anti pattern but what do I know?

ah I see, yikes. I agree with you. this is optimizing for some non existent problem (or at least a non obvious problem)

Just because you've never had to overcome or experience the problem, it doesn't mean it doesn't exist.

If you've ever had to develop an MVP from the ground up and build a business around it, services like this are critical to your acceleration, time to market, and budget.

that's why I said "or non obvious" I'm not totally sold on this saving time but I guess it could be argued depending on the expertise of the developer

> depending on the expertise of the developer

The more experienced the developer, the faster they are. The faster the technology enables you to be, the faster you'll produce something. Both go hand in hand.

An experienced developer would absolutely love Serverless for most problems they face. Having the option of doing as little Ops as possible and just solving problems in software is the very definition of a software developer (which certainly might be changing over time) :)

I still don't see where the savings of time come in. What you lose in "ops" you gain in configuration and assuming you don't have eidetic memory that has a time cost.

What configuration? I use AppEngine for a personal project I'm developing, and besides the app.yml file, which is about five lines long, I don't configure a thing. In fact, I don't even have to stand up databases to use one: I just make the API call to store the data and it's handled for me. Literally zero configuration.

That's in the standard environment. Even in the Flexible Environment the configuration is equally nonexistent.

Give AppEngine a try: I honestly believe you'll consider it the true definition of Serverless.

That awkward moment when it is 2018 and you call serverless "new"

Isn't this 2015's topic?

Serverless means you don't have to run the server. Even in the cloud you are running the VMs. You still have to deal with the OS, updates, apps and security.

PAAS takes it one step further, SAAS completely takes servers off you hand. You only deal with the app.

Serverless is probably sitting between PAAS and SAAS, function or code as a service. So maybe we should call it CAAS or FAAS. Serverless sounds nicer but is too vague and meaningless.

At my job we are moving some resource expensive functions to AWS lambda, for us it is quicker to instantly horizontally scale and address load than to spin up a new instance that could take a minute to get added completely.

Moving everything into lambda doesn't make sense, but for instant horizontal scaling it makes some parts of our app much more responsive and parallel.

The interesting thing about serverless for me is that although it's compelling to run services without needing to "manage servers", other tooling has largely closed that gap.

When I'm scripting a system deploy to AWS (for example), provisioning and deploying a Docker image to ECS, or even an AMI via Packer is a roughly equivalent amount of development work to configuring a Lambda.

And, usually a container or EC2 instance will have much better performance and cost characteristics than serverless. The exception is services that can benefit from a "scale to zero" capacity, which is great for personal projects but doesn't fit very many production apps.

for me the biggest value to serverless functions is how nicely they tie in to the ecosystem of a cloud provider. using them to respond to storage events on s3 or database events or auth events is super easy and powerful.

A nice middle ground is hiring the hardware eg. dedicated servers. Then you can install whatever software you want on them. And you can hire servers in many data-centers for redundancy. You get full control of the software, but don't have to worry about hardware, Internet connection, power, etc. If there are problems on one server you just revert traffic to another. Migrating from one provider to another is super easy, compared to serverless, SaaS and PaaS.

It means someone else's server, wrapped in a nice package.

> someone else's server

Isn't that what cloud meant in the first place... and to be honest "nice package" sounds a little bit like a container.

No, it's a new word for time-sharing.

Serverless == task based

In the AWS context it means stock Linux container on demand.

Serverless is a long word for P2P.

At least, that's what makes most sense.

Serverless should mean P2P, but it actually means "outsourced servers"

"Serverless" is unrelated to P2P, although you could write serverless P2P apps/services. (Yes, I said "serverless services".)

"Outsourced servers" would be considered IaaS[1], which is sort of the most basic cloud-level computing abstraction. Abstraction levels increase as you make the leap to PaaS[1] and finally FaaS[3].

[1] https://en.wikipedia.org/wiki/Infrastructure_as_a_service [2] https://en.wikipedia.org/wiki/Platform_as_a_service [3] https://en.wikipedia.org/wiki/Function_as_a_service

No. It changes the essence of how we develop today. You don't even have to think about instance types or anything, you only have to think about your code, everything else is someone else's problem.

For all the wonderful people -1-ing this, care to elaborate why am I so wrong?

Reply on news.ycombinator.com