I really loved serverless for while, particularly in the early days, when building small projects. But AWS Lambdas, for example, is constant maintenance hell for larger applications, including building and dependency issues, debugging and slow deployment.
One feat is still amazes me - my AWS Lambda React webapp example (Todo with server rendering) which were deployed in 2019, still works as today, and I have not changed, or redeployed it since.
> AWS Lambdas, for example, is constant maintenance hell for larger applications, including building and dependency issues, debugging and slow deployment.
Maintenance hell is a symptom of the frameworks in use, not Lambda. If you’re using stable tools, you can go years before doing a 5 minute runtime update and then go years.
Debugging and deployment speed are a stronger argument - the best balance I’ve found is to mandate modular design and local development so developers can work locally except when they are troubleshooting environmental interactions. Framework complexity also matters here - if you’re deploying a heavyweight app using AWS SAM your deployments will be at least 1-2 orders of magnitude slower than a simple Lambda.
Lambdas do require runtime updates. This means nothing happens for a relatively long time and then suddenly the lambda stops working. If you don't have many dependencies, upgrading the runtime is easy. But if one of dependencies requires an older runtime, it's better not to wait until the last moment.
> If your workload is truly intermittent and stateless, and you want zero operational effort, serverless can work.
And it works pretty well. A lot of internal and external JSON APIs are a good fit.
I've found the article ok, but it would have been a much nicer read without all the emotional stuff and just kept - serverless is pushed as panacea but actually isn't a good fit because...
I run a few serverless stacks on AWS Lambda, have been for years and slept well all the time. Serverless is forgiving. Things heal and don't stay dead like it can happen with anything that carries state like a container.
That said, I do prefer the development model of containers. Run them anywhere. That said, has it's own limitations. For example, he claims to be able to run state within container. Doesn't make sense if you want to scale out. Persistence is a problem. You can't run DBs on ECS Fargate for example.
And the worst aspect of running containers is: in bigger orgs the standard will probably be K8s. And that has nothing to do any more with the simplicity of containers as mentioned in the article.
Containers don't carry state. They can be made to do so if you wish but there's nothing inherent to them that does it.
> in bigger orgs the standard will probably be K8s. And that has nothing to do any more with the simplicity of containers as mentioned in the article.
K8s can be very simple if there's a platform team ensuring great developer experience. I appreciate that this is likely rarer than you or I would like though.
Agreed, this is a thinly-veiled ad for sliplane, even if I generally agree with the sentiment regarding serverless (though wouldn't go as far as calling it a scam, it has it's usecases, just not for me)
The way I view serverless such as AWS Lambda, and services like SQS and SNS, in that you're supposed to use it to program the cloud environment, not to stick your business apps in it.
Readit News
One feat is still amazes me - my AWS Lambda React webapp example (Todo with server rendering) which were deployed in 2019, still works as today, and I have not changed, or redeployed it since.
Maintenance hell is a symptom of the frameworks in use, not Lambda. If you’re using stable tools, you can go years before doing a 5 minute runtime update and then go years.
Debugging and deployment speed are a stronger argument - the best balance I’ve found is to mandate modular design and local development so developers can work locally except when they are troubleshooting environmental interactions. Framework complexity also matters here - if you’re deploying a heavyweight app using AWS SAM your deployments will be at least 1-2 orders of magnitude slower than a simple Lambda.
And it works pretty well. A lot of internal and external JSON APIs are a good fit.
I've found the article ok, but it would have been a much nicer read without all the emotional stuff and just kept - serverless is pushed as panacea but actually isn't a good fit because...
That said, I do prefer the development model of containers. Run them anywhere. That said, has it's own limitations. For example, he claims to be able to run state within container. Doesn't make sense if you want to scale out. Persistence is a problem. You can't run DBs on ECS Fargate for example.
And the worst aspect of running containers is: in bigger orgs the standard will probably be K8s. And that has nothing to do any more with the simplicity of containers as mentioned in the article.
Containers don't carry state. They can be made to do so if you wish but there's nothing inherent to them that does it.
> in bigger orgs the standard will probably be K8s. And that has nothing to do any more with the simplicity of containers as mentioned in the article.
K8s can be very simple if there's a platform team ensuring great developer experience. I appreciate that this is likely rarer than you or I would like though.
(IMO, if it can get a fly.io like command line experience, it will thrive more.)
Overall there was a lot of trial and error and no clear way to test everything locally in the container.
Deleted Comment