> 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…
It's not just "1 single VM" though, as you'll have to configure the applications on top of that. Configuring/installing a Postgres instance on a VM, nginx for your load balancers, iptables for your firewall, user accounts, an application server (could be as simple as forever for a NodeJS app, or Gunicorn or something for Python, etc). And if you want to automate that (as it sounds like you do), you're still writing a…
Serverless: I'm a Big Kid Now
51–60 of 71 posts
Re: Serverless: I'm a Big Kid Now
#52Earlier quoted context omitted.
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…
Right, I’m a big fan of the monolith, but that doesn’t preclude anything you just described. Absolutely use RDS. Absolutely use S3. Even on a low traffic app. 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…
It’s been many years since then and all this really did was bloat the client with metric tons of business logic, punch inconsistent holes through the API layer, and cause the entire web product to have abysmal load times (normal is somewhere in the 5 second range IIRC).
I think it’s understated how much damage the young technical leaders typically employed by early stage startups can really do. I can tell you this because I was exactly this person, and I got to see what following hype without doing actual mature research leads to.
Re: Serverless: I'm a Big Kid Now
#53I feel we need to move beyond the "serverless" nomenclature. Although, what would be better? Remote Lambdas ?
Lambda is a "Function as a Service" product and FaaS is (usually) serverless in nature. S3, DynamoDB, AppSync, API-Gateway, and Faregate are also serverless, but not FaaS products.
Re: Serverless: I'm a Big Kid Now
#54One 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
#55Is it really that expensive to keep a server running 24/7 vis a vis the development complexity of lambdas? It depends on your work load. And your trust level in Amazon of course.
No it isn't expensive to keep a server running 24/7. It's expensive to keep that server maintained.
rpm -qa | grep -i kernel && yum -y update && reboot && ..... After system comes back online, ensure the kernel is a newer version rpm -qa | grep -i kernel
Other utilities like ukuu for debian or ubuntu systems make updating the kernel a breeze.
If you're worried about specific packages, sure that can be daunting, so avoid updating software you are concerned about breaking ( keep an eye on security alerts for that software, which you should be doing anyway if you are using it on a VM container, or serverless... none are immune to vulnerabilities! ) and do not install unnecessary software.
Re: Serverless: I'm a Big Kid Now
#56> 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 now work in a company where they do things themselves, bare metal, and use ansible, ssh, etc pretty much basic stuffs.
I like this way more than my AWS/kubernetes insanity that my previous company had. It was so hard to debug, and everything needs a ticket.
Re: Serverless: I'm a Big Kid Now
#57I'll take issue with this one. I'm fully aware I'm weird, but I do actually enjoy managing servers. And with that effort spent managing servers, I buy the ability to actually create the environment in which my code runs, and interact and improve it over time, rather than relying on someone else's idea of what's good for my code. Moreover, I get the ability to dictate the security environment in which my code runs, instead of hoping my cloud provider is doing it properly enough for me (and not busy snooping on what I'm doing in the process).
I think what the poster means is "I don't want to manage servers, I want to write code." Which: fine. The world needs people who focus on writing good code. But I'm sick and tired of this attitude that coding is somehow more noble or better than the important work of building and maintaining the environment in which the code runs. You don't like it? Awesome, don't do it. But stop spitting on people who do, and who legitimately enjoy doing it.
Re: Serverless: I'm a Big Kid Now
#58Earlier 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
If your application does not meet any of those requirements then call it something else, as it clearly isn't a microservice.
Re: Serverless: I'm a Big Kid Now
#59Is it really that expensive to keep a server running 24/7 vis a vis the development complexity of lambdas? It depends on your work load. And your trust level in Amazon of course.
No it isn't expensive to keep a server running 24/7. It's expensive to keep that server maintained.
Re: Serverless: I'm a Big Kid Now
#60> 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…