> because it lets me deploy a new API endpoint in a matter of minutes

I've seen many projects that do the same without serverless just fine.

It's always been there, unless you had some enterprise-grade stacks. I was able to do this in early 2000s, with PHP and FTP, in a matter of seconds. Just upload that api/new_endpoint.php.

Not like this timing is the big deal, unless you really need to add those API endpoints real quick.

> I can move 5x-10x the speed with serverless.

I'd argue this is only applicable to the initial setup. There is one-time investment in designing your own infrastructure, but you can move fast on anything well-designed.

And it's not like serverless designs are immaculate. Just recently I was listening to Knative introduction talk and my obvious question was "what happens to event processing if servers that power this system fail and processing job just dies without a trace". Turned out, there are no delivery guarantees there yet. My conclusion: "uh, okay, blessed be the brave souls who try to use this in production, but I'll check out in a few years".

> There is less (almost 0) infrastructure to maintain.

It doesn't run on some sci-fi magitech in a quantum vacuum. The servers and networks are still there.

The benefit is that you don't have to design them. Saves you some (possibly, lots of) bootstrapping time when you're about to make your first deployment and ask yourself "how" and "where to".

The liability is that you can't - so when things break your can only wait, or try to re-deploy in hope that it would be scheduled to run on some servers that aren't affected.

Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month.

As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test.

My long running and CPU intensive stuff is running on a VM of course.

I'm sure if I had spent several days learning yet another tech stack that I could create a system that let me deploy endpoints to a VM that fast, but I have Better Things To Do(tm).

I could also shove everything behind a single endpoint that has a bunch of options, but that brings in a separate set of problems.

Almost anything you were competent in would let you write and deploy and endpoint in half an hour (particularly in the early stages of app development), so I'm not sure that this is positive for serverless.

The amount of infrastructure I have to setup/maintain to do all of that is, well, nothing.

That is where the mental savings comes in.

When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.

There is nothing for me to maintain. Setting up a new environment is a single CLI command. No futzing with build scripts. Everything will work and keep working pretty much forever, without me needing to touch it.

The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.

(As an example, trying to tell my mobile app's build system that I want a build with production code but pointed at my test environment? Hah! Good luck, the build system is hard coded to only have the concept of dev/prod! I've had enough of that.)

It is frustrations like that Serverless solves.

>When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.

You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.

>The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.

It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.

>Everything will work and keep working pretty much forever, without me needing to touch it.

If you believe that, you haven't been doing this long enough.

> You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.

See below with Ander.

I don't have much infra, I don't need infra.

(I do in fact have a couple of VMs because I do have a service that is stateful.)

Not having to think about anything aside from "here is my code, it runs" is nice. Debugging consists of "did I write bad code?"

> It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.

For the few things I run on VMs I still have to manage secrets so they can connect to the right DB. I also need to point my apps to the proper environment. The app being dev'd on my phone needs to point to the dev server with the dev DB secrets stored on it. Same goes for the website on localhost, or the website on the development server.

In an ideal world I'd have a script that created new environments on demand and it'd wire up all the build scripts automatically. Every developer would trivially get their own VM and could switch parts of the software (website, app, services) to point to various environments easily.

Why in the bloody world some build systems hard code only 2 options in is beyond me.

> If you believe that, you haven't been doing this long enough.

Sure old runtimes will be deprecated, but let's compare that to:

1. Setting up nginx 2. Setting up letsencrypt 3. Figuring out why my certs auto-renew but nginx doesn't pick them up (Turns out default setup doesn't actually force nginx to pick up the certs!) 4. Learning about various process management tools for JS to keep my services running 5. Setting up alerts for aforementioned daemons. 5b. Probably involves configuring outbound email. 6. Realizing something went horribly wrong in 5b and my inbox is now flooded with alerts. 7. Writing scripts to automate as much of the above as possible. 8. This legit happened, there was a security fix to SCP on Windows that changed how one of the command line parameters worked, breaking my deployment scripts when running them from Windows. 9. Does Google really want to charge me per decryption to store my API keys in their cloud API key storage service? They have to make money, but ouch. 10. Security updates not just for code, but for the VM images.

Like, I get it, if my entire job is back-end development. But I want to write some functions that maybe hit double digit millisecond run times and throw away all their state after.

Firebase says "here, export some functions, we'll give you an HTTPS URL you can call them at."

That is the sum total of my relationship with the tooling. "Run my code." "Sure."

About the only other thing that works that simply is a headphone jack, and those are going away.

Again, none of this has anything to do with serverless architecture vs non-serverless architecture. There are many PaaS providers that would eliminate all of your complaints that aren't "serverless". They just manage the server for you. But you still write a normal app that you can easily run locally or port anywhere you want.

If you decide you don't like the service, you're app isn't tied to a proprietary API or architecture.

And you don't need to manage additional VMs for stateful services.

Only 2 endpoints per month? What exactly are you comparing to that doing it twice a month would waste way more time adding an endpoint vs serverless?

With Firebase if I need a new env I just type 1 command and get it.

With VMs I have the joy of managing my own keys.

VMs need security patches, updates, and I have to maintain images. I have to think.

It is hard to explain how simple firebase functions are.

There is literally no mental overhead. There is no worrying. There is nothing to maintain or think about, no settings up quotas or managing what machine something is running on or getting user auth setup. No certs that can expire or daemons that can crash.

I can come back 2 months later and count on everything I setup functioning just as I left it.

Some months I wrote a bunch of endpoints, I average 2 a month maybe, but if I am adding a new feature, I can pop out 3 or 4 a day, and then go on my way and work with the front end again.

Getting debugging up and running for them can be interesting (painful and bad), but everything else is just smooth.

I don't want to maintain a bunch of infrastructure, I want my users to ask for some data and get some data back.

If someone is doing non-trivial processing, serverless is probably not for them. But I have a bunch of 20-50 line functions that are all independent of each other and have 0 state.

I realize I'm paying a premium, but it is worth it to have this stuff that just works.

Ah ok so you're 100% serverless so functions are saving you all the headaches of running your own infra? That makes sense. It sounded like the time to add an endpoint was your main criteria and just seemed strange.

The time saved is time thinking about doing anything else other than "I want to write code". :)