4 ms·
Serverless applications suffer from a few under reported drawbacks: - Local development is complex. Does one provision a full cloud environment per developer?
by patsplat 8y ago
Serverless applications suffer from a few under reported drawbacks:
- Local development is complex. Does one provision a full cloud environment per developer? Emulate a cloud environment locally? These are solvable but it's a grind of special cases.
- Limited customization. Eventually one needs to customize the language / libraries of the lambda. Again these are solvable with a grind of special cases.
- Limited execution model. Not all compute tiers are the same. Some quickly assemble results from a database. Others run for a long time. Others build up a model in RAM before delivering results. Serverless optimizes for some but not all models.
Unlike serverless / lambda, all of the above can be addressed by containers.
- Containers have orchestration solutions for local development and deployment
- Containers are designed to support customization
- Containers can be deployed to run in many different ways.
Not to be a booster, but in my experience containers are the scalable compute architecture.
- deleted 8y ago[deleted]
- jiveturkey 8y ago> drawbacks: > ... Serverless optimizes for some but not all models. How is this a drawback? General purpose things are equally bad at all things. If serverless is optimal for some models, those are the places you use serverless!
- patsplat 8y agoPlease, share the use cases where serverless is the optimal choice. Because I've tried it. For problems like thumbnail generation which is literally the canonical example [1]. And even in that case, found myself switching the workload back to containers to control the exact version of imagemagick to prevent a color gamut bug. 1. https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example...
- romeisendcoming 8y ago> ...containers*scalable, etc... Depends on your domain. Say you are containerizing nodes sharing KVM hypervisor resources with full VMs. The container application in use is resident on a file served backend, heavily dependent on SQL RDB for input, result outputs to file and db and application programmed using MPI via openmp. Processing is in real time and time sensitive. One size doesn't fit all. Containers are web tier solutions. They require too many compromises and work for a truly global solution.
- patsplat 8y agothat sounds like an interesting architecture and problem set but don't see how 'serverless' would help
- romeisendcoming 8y agoReplied to the previous poster who postulated that containers were the new everywhere. They aren't and they won't be. Serverless is an attractive prospect: Provide a function and lvalues and get a result. Adaptation: You just need to break out everything to the point where you can farm it to function(lvalue) = ret.