"SQLite is serverless" is by no means a meaningless buzzword. The term had a clear meaning before it was coopted by the current web dev fad. SQLite does not operate on a client-server architecture the way e.g. MySQL or PostgreSQL do.

Just to back that up, it had a clear meaning because -less is a valid suffix to append to English words. When grandma runs out of cookies she is cookieless (when a website doesn't use cookies it is also cookieless). It doesn't have to be "in the dictionary" to make sense in conversation.

A quick search of usenet shows "serverless" being used in 1994. It wasn't a term or a buzzword, it wasn't common, it was just English: https://groups.google.com/d/msg/comp.os.linux.misc/r76oNl98C...

Yes, this is what I was trying to say. It wasn't a thing people would throw around like a buzzword but if someone used it in conversation and especially in context (like the SQLite page, which was written over a decade ago, does) people would understand what you meant.

> does not operate on a client-server architecture

That was never a common usage of the term serverless.

The linked article was written in 2007, for your information.

Software development didn't begin or end with web dev and the cloud.

You could make it persist if you have it uploaded somewhere. But then I guess thats not serverless.

"Serverless" is a garbage marketing term in general. It sounds sexy to nontechnical management folks who are used to hearing a bunch of expensive costs and the word "server" associated with them in some fashion. From that view, anything that gets rid of those pesky "servers" sounds like a win.

It is, I did Azure Functions which is their "serverless" solution. It's either a type of CGI 'trigger' which is not as impressive however, another 'function' can be triggered based on Database actions or file uploads in their Blob Storage. So it's just handy if you're all in on Azure, and probably other clouds because you can have code run immediately when events happen for certain services. Outside of that, I find it wasteful.

The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too.

> The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too.

This seems like a strange criticism. It appears that you want a full deployment of the platform on your local machine. But Microservices aren’t optimized to run on your local machine; they’re meant to be deployed to kubernetes/docker swarm/mesosphere.

I’m also no fan of Java but I don’t think it’s the language that is preventing you here? All speculation since I don’t know the details but it sounds suspiciously like the JVM is getting stuck trying to allocate heap during startup (this is just a guess).

And when you need to interact with other services in a disconnected way? You have to run them somewhere... and local should generally be an option, even if that's to a local single-node (mini)kube cluster.

There's nothing wrong with needing to run more than one thing while developing/testing and interacting. There are other options, but it's not a clearly bad approach.

That said, I would definitely lean towards Go or Rust myself if given the option (even though I have limited exposure to either) over Java. C#/.Net Core is in the middle imho. Even node works pretty well, but the tons of files thing bugs me sometimes. We're leveraging more node and C# where I work and I definitely prefer node... but for more services I do think that Go and Rust are probably better options.

In general, staging environments are the solution to cross service testing for Microservices. The expectation that a Microservice must be testable end to end locally is not one I would like to encourage. The whole point of splitting out a service this way is that individual services have very narrowly scoped, independent function and can be tested on their own, perhaps with mocked data.

One wouldn’t expect to run all of a companys entire pipeline locally on a single laptop. Expecting that for Microservices is similar.

Java has been used on servers since 256MB was common to use — Java is not a limiting factor in how lightweight you can get on modern Intel hardware, though it might need some tuning.

The bloat was in the framework used, not as much on Java itself.

Not true. While the term is hyped, it is done so for good reasons. It’s not just that management doesn’t want the pesky servers, it’s that most developers themselves don’t want or care for it. Devs want to use platforms that let them quickly deploy their code that implements business logic, and servers/kubernetes and other abstractions aren’t things many devs give a fuck about.

This is overly reductive. “Serverless” might be overhyped, but amongst devs and ops it is a perfectly good way to succinctly describe a very specific architecture with real merit. Paying for exactly the compute time i use is pretty sexy to me when I want to deploy and scale a side project.

I would say (X)aaS (whatever as a service) is probably a better term... like DBaaS in this case, vs Serverless as in in-process, which is probably a closer and better use of the term.

What was wrong with "managed"? It's pretty generic and transfers across many domains and also, more fairly descriptive of what's going on.

"managed" is an AWS instance or a digital ocean droplet. "serverless" is an entirely different thing.

"Serverless" is another level of abstraction and management, that's it. Are you proposing that a term collision adds too much confusion?

"Managed" hosting has been around for decades as have "managed" services, in general, long before Amazon even existed. EC2 brought a new level/layer of automation and management ontop of what colo datacenters used to do, provide scaling etc. To be clear I'm not saying it's simple but "managed" describes much of it.

I would argue that the architectural implications of using a "run individual functions on a remote pool of computing resources and build your client application around this pattern and only pay for the exact amount of compute time you use" is not sufficiently covered by the term "managed". I think there could have perhaps been a better name than "serverless" chosen, but that's the name enough people have agreed on to use when talking about this specific architecture that it would be difficult to use another one.

Agreed, I'm not big in devops, but I can see the usefulness of it if you're already part of a cloud provider, but like I said I only know of the capabilities of it in Azure, I'm not familiar with the capabilities elsewhere.

This perspective has always confused me. Would you say that structured programming was a garbage marketing term, since even though the programming language didn't have goto the compiled machine code has jumps and branches? I would hope not, because the point is that an interface is provided on top of the underlying structure so that you don't have to think about gotos outside of exceptional cases.

Not having to think about what servers in which datacenter are serving a request is pretty convenient. We can argue about whether the pricing for most serverless computing is bad, but as far as the term and the technology itself I don't see how this is different from any other abstraction.

The criticism is on the nomenclature, not what's being provided. "Structured programming" is... pretty well named IMHO. Serverless is a misnomer at best and borders on fraud/false advertising from the name alone.

The technologies are fine and there are potentially useful cases for it. It's no silver bullet though and is overhyped IMHO.

I’ve done that, by persisting to an S3 backend.. but there’s no concurrent access and it is all one big race condition.