> 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.)
>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.
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.
