Serverless: I'm a Big Kid Now
simplethread.com
Serverless: I'm a Big Kid Now
1–10 of 71 posts
Re: Serverless: I'm a Big Kid Now
#2One 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.
Re: Serverless: I'm a Big Kid Now
#3One pain point I have is that functions as a service systems like Lambda have an special event format - this is sorted out by tools like Up which will install a small adapter and let you run your normal Http server in lambda. https://apex.sh/docs/up/
Besides this, the other service I like is Fly https://fly.io/ with lets me submit a container and runs that all over the world where necessary. Google Cloud Run does something similar, but its region locked. Fly is like global lambda for containers.
Between these tools and services, I’ve stopped caring about servers completely. Never need to install a package or use ssh again. I either submit just the app executable to lambda using Up (for light HTTP APIs) or send a container to Fly (for heavy servers, TCP, web sockets) and that’s it.
Re: Serverless: I'm a Big Kid Now
#4One pain point I have is that functions as a service systems like Lambda have an special event format - this is sorted out by tools like Up which will install a small adapter and let you run your normal Http server in lambda. https://apex.sh/docs/up/ Besides this, the other service I like is Fly https://fly.io/ with lets me submit a container and runs that all over the world where necessary. Google Cloud Run does som…
We got around the event format by using express in nodejs and a simple adapter for each cloud (azure is the hardest because no global log). Its fast enough for us and includes http access in local development
Re: Serverless: I'm a Big Kid Now
#5One pain point I have is that functions as a service systems like Lambda have an special event format - this is sorted out by tools like Up which will install a small adapter and let you run your normal Http server in lambda. https://apex.sh/docs/up/ Besides this, the other service I like is Fly https://fly.io/ with lets me submit a container and runs that all over the world where necessary. Google Cloud Run does som…
Fly is fantastic. The core product is solid (serverless distributed Docker) but they are still figuring out more features and ironing out the wrinkles. I've only been using it in development but I'm very happy with it.
Honestly, I don't think there's anything that compares at this price point and ease of use.
Re: Serverless: I'm a Big Kid Now
#6Isn'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 argue that it's more stuff you have to know about, not less; and when trouble hits, it can get very complicated to understand why.
(Not picking specifically on K8s; this applies to similar orchestrators/container tech).
Re: Serverless: I'm a Big Kid Now
#7One pain point I have is that functions as a service systems like Lambda have an special event format - this is sorted out by tools like Up which will install a small adapter and let you run your normal Http server in lambda. https://apex.sh/docs/up/ Besides this, the other service I like is Fly https://fly.io/ with lets me submit a container and runs that all over the world where necessary. Google Cloud Run does som…
[deleted]
Re: Serverless: I'm a Big Kid Now
#8> 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 ease of deployment. It really does. Code needs an environment. Lambdas punt on dependency management and environment. You have to build the environment for the lambdas using IAM roles, RDS, s3 -- out of toothpicks. All that stuff (security, storage) is already there for you in a VM.
I was talking with my brother in law about his serverless deployment of ~23 microservices he had carved up out of a Java Spring app. A small change anywhere in the code meant he had to redeploy all of it, not because of how the code was structure but that was the only way the build tools allowed him to do it. More problematically, the dependencies had to be built into every single lambda and made the build longer. (No, lambda layers didn't work for us. Way too complicated to figure it out.)
Honestly after going through tons and tons of pain to deploy these lambdas in both cases, it's just way easier to deploy on a VM. Maybe not for developers who just can't do anything if it's not done in their IDE, but from a broader, more globally-looking DevOps perspective, there are hidden costs.
Yes, it's easy to develop for lambda. But WOW, it's awful in deployment in comparison to just putting things on VMs.
Re: Serverless: I'm a Big Kid Now
#9Is Heroku severless now? (i.e. on-demand pricing, no capacity planning, etc.)
Re: Serverless: I'm a Big Kid Now
#10> 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 that manually.