11–20 of 71 posts
One thing that bothers me about serverless functions is that there is virtually no concurrency. Once you return you have no assurance that your code will keep on working. If you want to perform actions that might be throttled (cloudwatch for example) and are not critical for the response, you cannot have a singleton processing them after you return, because they might not be processed.
> Serverless container services such as Heroku, Netlify, AWS ECS/EKS Fargate, Google Kubernetes Engine, and Azure Kubernetes Service IMO I don't think Heroku and others fit the serverless paradigm. To me serverless is about automatic scaling of performance and cost. With Heroku you need to provision capacity in advance, and you pay for it whether you use it or not. Heroku doesn't scale automatically either, you do th…
But I don't know much about their pricing.
> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…
Now, could a lot of serverless deployments do just fine on a single VM because they never get enough traffic? ...probably. To my mind that's the real problem with serverless: it's a premature optimisation that simply isn't needed in a lot of cases.
The developer experience (DX) will more or less get solved by over the top vendors. Serverless.com and Begin.com are doing great jobs at this so far. For any of the concerns about proprietary-ness - sure. But you're already locked in once you start using S3, or relying on any other technology decisions like which database you use. It's not currently free as in freedom to use some of these early serverless solutions,…
Isn't the article's vision of things like Kubernetes (and similar) a bit too idyllic? I've heard talks by experienced K8s adopters (I want to say "Kubernetes failure stories", but googling comes up with similar hits but not the specific talk I was thinking of) where they mention that when K8s goes bad, it has all the negatives or knowing the "traditional" tech stack plus all the failure modes of K8s itself. They argu…
1: https://medium.com/omio-engineering/cpu-limits-and-aggressiv...
> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…
I don’t dispute that serverless deployments are a mess. But I look at it the other way: they make you deal with scaling up front, whether you need it or not. RDS, S3, all that... it scales to huge volumes. Your single VM will not. You can set up auto scaling with multiple VMs but by that point you’re going to be dealing with a lot of the issues you have with serverless deployments. Now, could a lot of serverless depl…
But what I see a lot of is engineering teams making sweeping consistency judgements. RDS and S3 are great as services, everything should be a (micro)service. Our calendar feels amazing as a React SPA—everything should be built in React.
No. 90% of a product is just CRUD to support the 10% of magic that customers really value. Ship the 90% as a monolithic CRUD app and spend those cycles on that 10%.
> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…
I don’t dispute that serverless deployments are a mess. But I look at it the other way: they make you deal with scaling up front, whether you need it or not. RDS, S3, all that... it scales to huge volumes. Your single VM will not. You can set up auto scaling with multiple VMs but by that point you’re going to be dealing with a lot of the issues you have with serverless deployments. Now, could a lot of serverless depl…
> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…
For a new project, serverless seems to involve a ton of momentum-stealing upfront work before you can really get going, and thereafter you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot.
OTOH, for any real production application, a single VM instance is rarely sufficient if it's critical to the business, and even within a single machine there always seem to be a lot of ops tasks like setting up process keep-alive stuff, rotating and deleting logs, making backups, etc.
For now, either approach can work great. Long term I think serverless is the way to go, but it still has a lot of maturing to do (the good news is that pretty much all of the annoyances of serverless seem like very solvable problems).