3 ms·

Datapoint: I'm using serverless because it lets me deploy a new API endpoint in a matter of minutes. There is 0 configuration, and deployment is a single comm

Datapoint: I'm using serverless because it lets me deploy a new API endpoint in a matter of minutes. There is 0 configuration, and deployment is a single command. I also have my own servers running some of my APIs, the difference how much work I have to do is huge. Serverless on Google Firebase is literally "export a function, now you have a new endpoint!". There is, quite literally, nothing else to do. I can move 5x-10x the speed with serverless. There is less (almost 0) infrastructure to maintain. Yes, it costs more, although the math with Google Firebase Functions is pretty trivial, everything is bundled under 1 service, and sending data around between Google cloud services is free.

anderspitman 7y ago
Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?
- com2kid 7y ago
  > 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.
  - learc83 7y ago
    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.
    - com2kid 7y ago
      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.
      - learc83 7y ago
        >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.
        com2kid 7y ago
  - anderspitman 7y ago
    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?
    - com2kid 7y ago
      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.
      - anderspitman 7y ago
        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.
        com2kid 7y ago
        The time saved is time thinking about doing anything else other than "I want to write code". :)
drdaeman 7y ago
> 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.

anderspitman 7y ago

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

com2kid 7y ago
> 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.
- learc83 7y ago
  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.
  - com2kid 7y ago
    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.
    - learc83 7y ago
      >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.
      - com2kid 7y ago
- anderspitman 7y ago
  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?
  - com2kid 7y ago
    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.
    - anderspitman 7y ago
      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.
      - com2kid 7y ago
        The time saved is time thinking about doing anything else other than "I want to write code". :)

drdaeman 7y ago

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