Live data from Hacker News

Serverless: I'm a Big Kid Now

simplethread.com

41–50 of 71 posts

Re: Serverless: I'm a Big Kid Now

#41
post #38

> Security – The operating system installed in a container is usually short-lived, very minimal, and sometimes read-only. It therefore provides a much smaller attack surface than a typical general purpose and long-lived server environment. Is this true? I always thought things like Docker are massively insecure because they don't respond to the threat landscape that well, since they are kind of 'frozen in time' and k…

If you're deploying your own application, you should probably build your image from a known maintained base image, rather than from a community supported one, and then periodically rebuild it - it's like how you'd have to redeploy your app if there was a security issue in one of your dependencies. I wouldn't recommend using any of the public Docker images outside of local dev environments

Re: Serverless: I'm a Big Kid Now

#42

> 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…

> 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,

Those aren't microservices, by definition.

Re: Serverless: I'm a Big Kid Now

#44
post #39
post #3

One 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…

You can now deploy apps on Cloud Run to different regions and use Google's HTTPS Load Balancer to traffic them with a serverless endpoint group.

CloudRun is a no-go for apps that need custom domains as they have a 50 domain limit which cannot be increased.

https://cloud.google.com/run/quotas

Re: Serverless: I'm a Big Kid Now

#45

> 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…

> 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, Those aren't microservices, by definition.

> not because of how the code was structured but that was the only way the build tools allowed him to do it

Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith

Re: Serverless: I'm a Big Kid Now

#46

Earlier quoted context omitted.

> 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, Those aren't microservices, by definition.

> not because of how the code was structured but that was the only way the build tools allowed him to do it Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith

It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context.

Regardless, it doesn't sound like microservices, it sounds like a distributed monolith.

Having built a product out of microservices and lambdas I definitely have not found that build tooling has ever forced a full redeploy. I suspect this is just a case of converting a monolith to a microservice being much more difficult than people realize.

Re: Serverless: I'm a Big Kid Now

#47

> 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…

> that was the only way the build tools allowed him to do it

What build tools? We have over 60 Lambdas and aren't aware of any issues like this. We literally had to build extra tooling to be able to push more than one Lambda simultaneously so I'm a bit confused how is this related to the platform.

The only "build tools" Lambda itself has is literally a file upload and a version promotion.

Re: Serverless: I'm a Big Kid Now

#48
post #25
post #15

Serverless: so grown up that Google App Engine launched 12 years ago and hosts several huge, valuable services. The question of whether serverless is ready answered itself years ago. The remaining questions for prospective adopters are whether it meets your requirements, and are you mentally ready to adopt it (because cramming legacy concepts into serverless never works).

And in reverse, it can be surprisingly tricky to convince serverless advocates that it's not so new and GAE fits their definitions.

To most people, serverless==lambda. That's where most of the conversation lives and dies.

Re: Serverless: I'm a Big Kid Now

#49

> 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…

Ugh, these arguments frustrate me, but here I go getting sucked into another...

> 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.

I'm sorry but if this took you 6 weeks then you're doing it wrong. To be fair, I haven't tried using CFTs and Ansible for my serverless deployments, but then again these seemed like big time overkill to me. Your experience seems to back that up.

Look, I don't want to say infrastructure-as-code is a bad thing, but don't blame the infrastructure when it's your choice of tools that is the problem. The AWS CLI makes it so easy to write a bash script to deploy a small project. But hey if you think an extra 6 weeks is worth it to use Ansible, then by all means...

Re: Serverless: I'm a Big Kid Now

#50
post #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 th…

Exactly. This is a massive misunderstanding of what serverless is. I came here to write 'no, no, no' but you already have.

> Serverless container services such as Heroku, ... AWS ECS/EKS Fargate, Google Kubernetes Engine, and Azure Kubernetes Service provide you with an environment where you can build a container

Not building or managing a container is why you're using serverless.

Post reply on HN