5 ms·

> "… serverless platforms today are useful for important (but not five-nines mission critical) tasks, where high-throughput is key, rather than very low latency

> "… serverless platforms today are useful for important (but not five-nines mission critical) tasks, where high-throughput is key, rather than very low latency, and where individual requests can be completed in a relatively short time window. The economics of hosting such tasks in a serverless environment make it a compelling way to reduce hosting costs significantly, and to speed up time to market for delivery of new features." The crux so to speak. I wonder if this type of planning makes sense though? Can't I argue that good design, which imo has been around for ages and collected well in canonical books, aid in improving time to market for new features?

adzicg 9y ago
(I'm one of the coauthors of the paper referenced in the post) For me, charging for actual usage instead of reserved capacity actually aids in implementing those good design guidelines that were collected in books, such as low coupling and high cohesion of code, and this is what we wrote about in the paper as well. charging for reserved capacity creates financial incentives to bundle tasks and features into applications, creating runtime coupling (eg sharing the same /tmp dir, reusing security roles etc), even though they are designed to be isolated. charging for actual usage removes that incentive, so stuff that was designed to be isolated stays isolated when deployed.
- brianwawok 9y ago
  If you give me a monolith with well isolated packages vs a serverless app across 400 lambdas and ask me to fix a bug, i can bet you which one i can find it faster. Separation of concerns is easy to do without lambda or microservices. If you want separation of concerns write good code. Don't move your environment to a locked in circus.
  - wahnfrieden 9y ago
    I've seen surprisingly little on running "fat" services in a serverless (like AWS Lambda) environment. We're doing this at work pretty successfully so far: Django projects with many endpoints within a single Lambda function. There are limitations to work with (50MB compressed code) but they're quite manageable for some time, and so far a nicer problem to deal with than all the things we give up by abandoning serverless. So try adjusting your example to something like a dozen lambdas for an engineering organization of 50 devs, with each lambda service boundary roughly matching the team and product structure. Serverless enables the extreme (many tiny services with minimal upfront cost) but doesn't require it.
    - zengid 9y ago
      That might be a catchy phrase. "Fat functions", or a single function that holds a lot of endpoints in a single lambda (or another platforms' version of cloud functions). Have you had any issues with requests getting timed out, or managing the 'health' of the fat function?
      - vikiomega9 9y ago
        I figure a "fat" function goes around the idea of organizing your lambdas. Because then you potentially have a high throughput function.
      - wahnfrieden 9y ago
        No unusual timeout issues - our "fat function" has only marginal overhead, just the WSGI layer and method dispatching code to route the request to the appropriate view/controller. This should be single digit millisecond overhead. For health, there's certainly more noise now: we can look at overall invocation error rates (a metric lambda gives us), but they're across several endpoints within the lambda function. This is still an open question for us, but solvable.
    - maxxxxx 9y ago
      Sounds like each lambda is a microservice then?
    - brianwawok 9y ago
      Are you doing zappa or something else for your Django? This sounds better, and perhaps I could be on board with this. I went a different route, which is kubernetes for my Django + Celery. Over 75% of my load is "stable", so kubernetes + celery ends up cheaper than lambda for me. I can basically throw my web servers in my kubernetes cluster "for free".. but if I had just a webapp, I would feel better about my entire Django in one Lambda, or at least 1 entire "app" of my Django in one Lambda. My biggest gripe is warmup speed, 3 seconds for a cold request is pretty bad compared to the 100ms I have now in kubernetes.
      - 9y ago
  - kartickv 9y ago
    Can you share business logic between serverless functions? Like classes, functions and immutable data. If not, it's a severe limitation.
- vikiomega9 9y ago
  I understand, but is there a cleaner quantification of this incentive? Having said that tooling is key and I find it somewhat lacking to turn on a switch and run my code as a lambda to say compare costs and such.

adzicg 9y ago

(I'm one of the coauthors of the paper referenced in the post) For me, charging for actual usage instead of reserved capacity actually aids in implementing those good design guidelines that were collected in books, such as low coupling and high cohesion of code, and this is what we wrote about in the paper as well. charging for reserved capacity creates financial incentives to bundle tasks and features into applications, creating runtime coupling (eg sharing the same /tmp dir, reusing security roles etc), even though they are designed to be isolated. charging for actual usage removes that incentive, so stuff that was designed to be isolated stays isolated when deployed.

brianwawok 9y ago
If you give me a monolith with well isolated packages vs a serverless app across 400 lambdas and ask me to fix a bug, i can bet you which one i can find it faster. Separation of concerns is easy to do without lambda or microservices. If you want separation of concerns write good code. Don't move your environment to a locked in circus.
- wahnfrieden 9y ago
  I've seen surprisingly little on running "fat" services in a serverless (like AWS Lambda) environment. We're doing this at work pretty successfully so far: Django projects with many endpoints within a single Lambda function. There are limitations to work with (50MB compressed code) but they're quite manageable for some time, and so far a nicer problem to deal with than all the things we give up by abandoning serverless. So try adjusting your example to something like a dozen lambdas for an engineering organization of 50 devs, with each lambda service boundary roughly matching the team and product structure. Serverless enables the extreme (many tiny services with minimal upfront cost) but doesn't require it.
  - zengid 9y ago
    That might be a catchy phrase. "Fat functions", or a single function that holds a lot of endpoints in a single lambda (or another platforms' version of cloud functions). Have you had any issues with requests getting timed out, or managing the 'health' of the fat function?
    - vikiomega9 9y ago
      I figure a "fat" function goes around the idea of organizing your lambdas. Because then you potentially have a high throughput function.
    - wahnfrieden 9y ago
      No unusual timeout issues - our "fat function" has only marginal overhead, just the WSGI layer and method dispatching code to route the request to the appropriate view/controller. This should be single digit millisecond overhead. For health, there's certainly more noise now: we can look at overall invocation error rates (a metric lambda gives us), but they're across several endpoints within the lambda function. This is still an open question for us, but solvable.
  - maxxxxx 9y ago
    Sounds like each lambda is a microservice then?
  - brianwawok 9y ago
    Are you doing zappa or something else for your Django? This sounds better, and perhaps I could be on board with this. I went a different route, which is kubernetes for my Django + Celery. Over 75% of my load is "stable", so kubernetes + celery ends up cheaper than lambda for me. I can basically throw my web servers in my kubernetes cluster "for free".. but if I had just a webapp, I would feel better about my entire Django in one Lambda, or at least 1 entire "app" of my Django in one Lambda. My biggest gripe is warmup speed, 3 seconds for a cold request is pretty bad compared to the 100ms I have now in kubernetes.
    - 9y ago
- kartickv 9y ago
  Can you share business logic between serverless functions? Like classes, functions and immutable data. If not, it's a severe limitation.
vikiomega9 9y ago
I understand, but is there a cleaner quantification of this incentive? Having said that tooling is key and I find it somewhat lacking to turn on a switch and run my code as a lambda to say compare costs and such.