4 ms·

It is hard for me to understand why anyone would build so many individual functions. Just build one function, put a router in it and then call out to as many in

It is hard for me to understand why anyone would build so many individual functions. Just build one function, put a router in it and then call out to as many individual handlers as you want. Then you're just deploying a single function to the PaaS and everything is simple.

report-to-trees 3y ago
In that case you are deploying a whole monolithic app to the Faas platform. This needs to be initialized on every cold start which takes longer the larger your code is. The main selling point (that I have experienced) in Faas is that you can have small, individually scalable functions that are quick to initialize and can be torn down after executing. If you have the whole app under one handler you would be much better off with a different architecture where the app is persistent and always running.
- paulddraper 3y ago
  That seems like a weird reason. You can lazy load your route implementations
  - report-to-trees 3y ago
    If you manage to lazy load your routes it may help with cold starts but I think you effectively lose the benefit of warm handlers since every request could use new code that needs to be loaded fresh. I've never attempted lazy loading inside a Faas platform but I think generally you would be better off creating small deployable chunks and letting the platform handle scaling them up / reusing as necessary. Less fighting against the platform and if you have to maintain strict boundaries to enable lazy loading only the needed code for each route it's a short step to deploying those as their own functions anyway.
    - latchkey 3y ago
      The article is about 15k functions. You know what is a lot worse than lazy loading? Getting 15k functions to deploy accurately. I've seem functions fail to deploy, are you going to fail the whole build if one of the 15k fails? What if functions depend on other functions? How about CI/CD where you're updating multiple times a day? How about when you update a single dependency across those 15k and you need to deploy again? I don't know what PaaS you've used, but at least with Google Cloud Functions, you can do a minimum number of instances. Set it to 1 and you never have cold start issues.
      - report-to-trees 3y ago
        I agree 15000 functions is overkill and I would never recommend something like that. I'm trying to explain why combining all 15k functions into a single Faas deployment is not going to be the best option either. There is a middle ground that will be much faster and cheaper all around.
  - MrRolleyes 3y ago
    [dead]
paulddraper 3y ago
The idea is that you decompose into modular functions that are integrated with your deployment platform and testable and observable.
- hinkley 3y ago
  This statement is true regardless of whether FAAS exists or you’re having a conversation over beers in 1999.
isoprophlex 3y ago
Left-pad-as-a-service, enterprise architect edition.
- hinkley 3y ago
  Oh, we need to fork Enterprise Fizzbuzz. I bet there’s no Lambda Edition yet.
hinkley 3y ago
Infinity being bad does not make zero or one better. They both suck.
hinkley 3y ago
To me this is just the latest iteration of things we've tried before. It's another event driven system (I think we called them Enterprise Service Buses and they only lasted a couple of years) and distributed FastCGI. We will repeat all of the same 'mistakes' (aka, consequences) of those systems and the documents produced during the Trough of Disillusionment will read like a madlib of existing documents. It all kind of works while the fanout is low, but these systems have such long feedback loops that the team doesn't really learn how to avoid the degenerate cases and the whole thing limps along. The system isn't just allowing emergent behavior, it depends on it. Which is a special kind of insanity I've never been comfortable around. Really, just write some code that does exactly what it says it does. It seems remedial at first but once you get going you start finding ways to add features that were difficult before and it all comes out in the wash.

report-to-trees 3y ago

In that case you are deploying a whole monolithic app to the Faas platform. This needs to be initialized on every cold start which takes longer the larger your code is. The main selling point (that I have experienced) in Faas is that you can have small, individually scalable functions that are quick to initialize and can be torn down after executing. If you have the whole app under one handler you would be much better off with a different architecture where the app is persistent and always running.

paulddraper 3y ago
That seems like a weird reason. You can lazy load your route implementations
- report-to-trees 3y ago
  If you manage to lazy load your routes it may help with cold starts but I think you effectively lose the benefit of warm handlers since every request could use new code that needs to be loaded fresh. I've never attempted lazy loading inside a Faas platform but I think generally you would be better off creating small deployable chunks and letting the platform handle scaling them up / reusing as necessary. Less fighting against the platform and if you have to maintain strict boundaries to enable lazy loading only the needed code for each route it's a short step to deploying those as their own functions anyway.
  - latchkey 3y ago
    The article is about 15k functions. You know what is a lot worse than lazy loading? Getting 15k functions to deploy accurately. I've seem functions fail to deploy, are you going to fail the whole build if one of the 15k fails? What if functions depend on other functions? How about CI/CD where you're updating multiple times a day? How about when you update a single dependency across those 15k and you need to deploy again? I don't know what PaaS you've used, but at least with Google Cloud Functions, you can do a minimum number of instances. Set it to 1 and you never have cold start issues.
    - report-to-trees 3y ago
      I agree 15000 functions is overkill and I would never recommend something like that. I'm trying to explain why combining all 15k functions into a single Faas deployment is not going to be the best option either. There is a middle ground that will be much faster and cheaper all around.
- MrRolleyes 3y ago
  [dead]

paulddraper 3y ago

The idea is that you decompose into modular functions that are integrated with your deployment platform and testable and observable.

hinkley 3y ago
This statement is true regardless of whether FAAS exists or you’re having a conversation over beers in 1999.

isoprophlex 3y ago

Left-pad-as-a-service, enterprise architect edition.

hinkley 3y ago
Oh, we need to fork Enterprise Fizzbuzz. I bet there’s no Lambda Edition yet.

hinkley 3y ago

Infinity being bad does not make zero or one better. They both suck.

hinkley 3y ago

To me this is just the latest iteration of things we've tried before. It's another event driven system (I think we called them Enterprise Service Buses and they only lasted a couple of years) and distributed FastCGI. We will repeat all of the same 'mistakes' (aka, consequences) of those systems and the documents produced during the Trough of Disillusionment will read like a madlib of existing documents. It all kind of works while the fanout is low, but these systems have such long feedback loops that the team doesn't really learn how to avoid the degenerate cases and the whole thing limps along. The system isn't just allowing emergent behavior, it depends on it. Which is a special kind of insanity I've never been comfortable around. Really, just write some code that does exactly what it says it does. It seems remedial at first but once you get going you start finding ways to add features that were difficult before and it all comes out in the wash.