Am I right to hate serverless?
Posted by BigBootyBear@reddit | ExperiencedDevs | View on Reddit | 250 comments
Serverless SDKs make me feel like an idiot cause unlike just building something, using my years of experience, I have to learn the arbitrary way CloudCorp decided to do authentication with all of their dedicated CLIs, configs, abstractions and so on. It takes SO LONG to get into a good flow.
Unlike learning the finer details of a programming language feature, I feel little motivation in diving in the finer details of a cloud providers SDK cause there is no skill transfer to other tasks. And the APIs keep changing (which makes resources become stale very fast).
Thoughts?
Lendari@reddit
I literally work for Amazon and the advice from our internal BuilderTools team is not to use Lambda for services requiring < 100ms of latency
Deezl-Vegas@reddit
EC2 brother here. Im not sure what's going on here because I thought this was sort of the obvious take. Lambda exists for people who can benefit from a pay-by-usage structure. It is good for highly distributed systems, workflows, and lots of discreet jobs.
The entire point of Lambda is that there are innumerable tasks that basically need a network port and a container to fiddle and move some chunk of data. It's a bad idea to do that on a busy web host and it's a bad idea to rent a fleet of servers that sit idle for 90% of the time waiting for the big job to start. It's also annoying to bundle all the different tasks into some sort of job manager yourself. So we wrote a job manager. It doubles as a request handler so you can write your API and run it on Lambda. And it will even scale well. But Lambda is a shared resource and your specific code will not always live on the hot path.
If you need to rent a full time computer, come visit ECS. ECS Fargate has autoscaling. Nothing wrong with the old fashioned model.
And my strong recommendation is to know as much as you can about how stuff works. Abstractions are a scam. The marketing pitch is the marketing pitch. The implementation under the hood is the truth.
Blazing1@reddit
Serverless is great for automated jobs scheduled with cron. It's been amazing for me.
Lendari@reddit
Yes this would be a "background processing queue" and perhaps "zero compute". So it is a good fit by the CDO Builder Tools criteria.
Instead of scheduling with CRON theres actually a pattern in SQS to create a message that is "hidden" for so many minutes or hours (or days if your message retention is high enough). Then when it is processed another hidden message can be created by the processor befor acknowleding the previous message. This pattern achieves a higher availability/reliability than CRON and requires less domain knowledge to maintain.
Blazing1@reddit
Wat I'm just using cloud scheduler to trigger cloud run jobs lol it's easy and built in
mamaBiskothu@reddit
Yeah I tried to do something smart with lambda thinking it’s truly serverless and infinitely scalable, only to find out it can’t do more than 1000 parallel calls per account. Like what.
Necessary_Reality_50@reddit
Don't really buy that at all, and that's definitely not the recommended guidance.
It's trivial to configure a lambda so it has no more latency than code running in a container.
ogghead@reddit
You’re not accounting for the fact that Amazon is a Java shop. Ever try to make a Java Lambda hit a 100ms SLA?
hydrotoast@reddit
Has the VM warmup time been significant enough to justify AOT compilation (e.g. with GraalVM)? Or is the issue with general Java runtime overhead (GC tuning, object overhead, etc.)?
As an engineer optimizing distributed applications on clusters (Hadoop, Spark, ...), I am curious where the bottlenecks are in Lambda scenarios.
ogghead@reddit
I have certainly floated this idea — all reading I have done on the subject implies that GraalVM would help cold starts significantly — but the appetite isn’t there on my team
JulianEX@reddit
They aren't really a java shop its like the 3rd most common language used at Amazon/AWS
ogghead@reddit
AWS might be moving in different directions, but on the CDO side, Java is quite prevalent. You can’t get away from JS on the frontend, but that does not change the fact that a majority of backend systems run Java in CDO.
yegor3219@reddit
Only if it does not have to connect to a database, read some secrets beforehand and so on, i.e. things that a conventional server does only once and reuses for all subsequent calls for as long as it's running. In Lambda, if you want to eliminate this initialization latency, you have to use provisioned concurrency, dedicated db connectors, etc. Not quite trivial.
gtarget@reddit
The number of things they’ve added to Lambda to act more like a traditional service are almost comical. I hate that it’s start with Lambda, but add provisioned capacity and canaries so it stays warm so we can get kinda normal response times. So now our dev cycle is fucked, it’s frupid, and now it’s impossible to debug
gtarget@reddit
Eh, that’s kinda true. But there’s lots of services that don’t require sub 100ms response times and Lambda is still a bad choice. There’s a whole Coral on Lambda framework that makes people thinking running a complex service on Lambda is a great idea, despite it being impossible to test and debug locally, and your functionality is smeared across a bunch of Lambdas. The problem is the default is Lambda and you have to swim against the current to get people to build a plain ole service when it’s what you need. If it’s more than a single file, the cons of Lambdas outweigh the pros.
deviled-tux@reddit
That shit sucks so much it is honestly impressive. Shoving all the complexity of a long-running service inside a lambda including making the lambda init time worse than it already is!
Someone probably got promoted over that shit
bwainfweeze@reddit
I’m surprised the TPS threshold is that high. I would have figured a much lower threshold. To beat multi region EC2s.
Or very high variability. One of the candidates I was looking at was a periodic task, but the amount of data I needed for the workload was high and we didn’t have a good way to deliver it (long story)
babeal@reddit
Serverless is great for a single function out of band. But once it grows you will wish for a full framework and containers
messedupwindows123@reddit
agree
techdaddykraken@reddit
Serverless is awesome if you use Cloudflare pages, mainly because it: A) isn’t actually serverless, and B) CloudFlare has gone to great lengths to provide an excellent out-of-the-box experience.
Cloudflare offers media optimization, caching, serverless workers, LLM processing, short-term storage, DNS, server-side analytics, best in class security, firewalls, load balancing, SSL/TLS certs, deployment backups, uptime guarantees, middlewares/request intercepting, recaptcha,
And I’m literally just scratching the surface.
What is not to like?
Astro + Tailwind + Cloudflare really makes me feel like I have a future proof stack for the first time in a long time. Minimal dependencies, easy scalability and maintenance, highly secure, excellent performance, I see this becoming the Wordpress of the next 20 years.
imdavidmin@reddit
Serverless is a broad stroke of abstracting servers. I love something like Cloudflare workers where it's minimal proprietary non portable ways of doing things, and hate something like Elastic Beanstalk, where it's just a thin veneer over VM servers
DirectorBusiness5512@reddit
I hate it not because of that but because it just feels like a bunch of vendor lock-in garbage.
If it was FLOSS and entirely self-hostable then I wouldn't mind it as much (if I wasn't one of the SREs or infrastructure folks).
chazmusst@reddit
Yeh that's why I like Azure Functions. You can run it in Azure on a serverless model, and you can also run it locally in a docker container, or anywhere you like in a docker container.
worldsayshi@reddit
But it still doesn't behave the same when you run it locally. I've had functions running perfectly locally but failing when deployed. I'm still learning this though.
Whitchorence@reddit
Does anything?
worldsayshi@reddit
I feel like it's easier to control the difference between prod and non prod in Kubernetes. But maybe it's just because I'm more used to it.
Western_Objective209@reddit
can do this with AWS lambdas as well
snes_guy@reddit
And GCP has an equivalent called cloud run that runs containers.
So you can avoid the vendor lock in problem pretty easily. The problem is when the developers that came before you chose the non container servlerless option and now you’re stuck with it forever because your management doesn’t believe you that it’s easy to convert functions to the serverless container solution. (Yes, this happened to me.)
Adept_Carpet@reddit
But it's kind of a pain in the ass to do it. I've never a developer set it up without hitting some problem or having it be in some way different than the documentation describes (like a service shows up on a different port than the documentation expects, or some default is different).
Western_Objective209@reddit
It sets up with Jetbrains IDEs pretty painlessly, https://docs.aws.amazon.com/toolkit-for-jetbrains/latest/userguide/create-new-lambda.html I've never had an issue
kittysempai-meowmeow@reddit
When we switched our Azure functions to use the isolated model in .NET 8 we discovered they hadn’t bothered to add the support for Azure app config variables in function params like they did in the in process model yet. We had to move all our timer settings, input queue names etc into the actual Azure Function settings in the portal. So that our config would need to be split across two locations. (App Config substituted fine inside functions, just not for the actual Function method parameters)
/headdesk
Other than that I didn’t have too much trouble with them.
TimMensch@reddit
The sad thing is that the Serverless framework got bought out by Amazon.
It used to be cloud agnostic serverless functions. Now it's only Lambda, officially, though community packages still exist to make it cloud agnostic again. But it no longer feels as well supported.
Blazing1@reddit
Idk why Amazon just doesn't use Knative.
Spider_pig448@reddit
self-hostable serverless would be truly missing the point, no?
angellus@reddit
The main reason is just for local development and testing. The idea of serverless is great, no infra to manage. The issue is that it (usually) completely destroys developer productivity. Very few serverless things let you test locally (Cloudflare Workers is one I can recall, someone else mentioned Azure Functions). So now you have to deploy them whenever you want to test, which often means waiting 1+ minutes. Some platforms (cough AWS cough) even longer. So, your feedback cycle goes from near instant with other interrupted languages like Node.js or Python to multiple minutes. Even compiled applications are usually not as bad (unless it is Enterprise Java, lol) because it will cache code builds.
Blazing1@reddit
Alerting on cloud is absolutely trash. Just look at gcp. If you set an error alert it runs once until someone looks at it.
Easy to forget about something like that. Especially in the case if your container is run via cron
Whitchorence@reddit
On the other hand, it's relatively simple to have multiple versions of something that actually mirrors your prod env.
jesusrambo@reddit
Testing AWS stuff locally takes a little more thoughtfulness, but it’s not nearly as difficult as this makes it out to be
angellus@reddit
That is always what seniors says. "oh it is not that hard, just need to do this, this and this". And then they never setup processes and tooling so that is all done automatically as part of the SDLC.
So, juniors come along and never do it. Or anyone else really.
We had a few seniors making that same argument for manually installing and setting up our dev environment (Python/Postgres/Redis). "It is not difficult to install Python, Postgres and Redis and set up a virtualenv", sure because you are a Senior who has been doing this exact tech stack for 5+ years. But it still takes new people that are onboarded upwards of a week to get setup. I forced them to start using a docker compose and they hated it. But all of the new developers, tech leads, CTO, etc loved it because it took setup time for a new env from hours or days to 30 minutes.
jesusrambo@reddit
First, you’re describing a process failure in specific environments. Poorly documented processes and tooling is not a requirement of serverless
Your example is a false equivalence, and doesn’t really apply to this discussion. In fact, it’s a pretty good argument for serverless.
We use the best tool for the job, and expect the rest of our team to have the skills to learn it and be able to keep up 🤷♂️
Adept_Carpet@reddit
If I wanted to be thoughtful I could set up a server and then get the benefits around flexibility, performance, debuggability, etc that a server you manage gives you.
The whole point of serverless is supposed to be I don't have to think about how I deploy, I just write code and hit the button.
jesusrambo@reddit
You can intentionally miss the point if you want, it’s your loss. I’m not an AWS rep, I don’t need to convince you
dringant@reddit
We just wrote some adapters to run lambda handlers in a local web server, works great. Can do 99% of your dev work locally.
squngy@reddit
Not really, as it allows you to migrate to 3rd party hosting relatively smoothly if you want to in the future.
DirectorBusiness5512@reddit
If you're paying for stuff like AWS Lambda (proprietary cloud-based), you're paying for both SaaS (AWS Lambda) and IaaS (managed infrastructure).
SaaS and IaaS are two different things. If you own both the software and the infrastructure, you as a developer could still get the serverless experience as a developer (write your code using all the abstractions of serverless), but own your infrastructure too.
Does it defeat the purpose? If you're a developer at a startup, yeah, definitely. If you're a developer at a massive company where the infrastructure isn't your problem anyway beyond whatever you do with Terraform or something then no, it's fine and you wouldn't notice too much of a difference in the grand scheme of things.
DirectorBusiness5512@reddit
If you're paying for stuff like AWS Lambda (proprietary cloud-based), you're paying for both SaaS (AWS Lambda) and IaaS (managed infrastructure).
SaaS and IaaS are two different things. If you own both the software and the infrastructure, you as a developer could still get the serverless experience as a developer (write your code using all the abstractions of serverless), but own your infrastructure too.
Does it defeat the purpose? If you're a developer at a startup, yeah, definitely. If you're a developer at a massive company where the infrastructure isn't your problem anyway, no, it's fine and you wouldn't notice too much of a difference in the grand scheme of things.
Whitchorence@reddit
I think you'd miss a lot of the value in that having (for instance) AWS lambdas lets you tie into a bunch of other AWS resources as event sources easily. But it's also fair to say that fairly little of the code for serverless needs to be serverless-specific.
squeasy_2202@reddit
This should be solved at the code architecture level up front though. If you're not abstracting the application runtime away from your domain logic you've made a fatal flaw in your system design.
The last serverless service I built, i designed it with a runtime-agnostic set of controllers as the API that is called from whatever runtime. We worked on it locally with Docker and Flask, but it deployed to Lambda.
We add expansion joints when we pour concrete so that it will fracture where you intend (which it inevitably does). Apply this to your code architecture.
wuzzelputz@reddit
And it‘s expensive if you are really big:
https://zwischenzugs.com/2019/03/25/aws-vs-k8s-is-the-new-windows-vs-linux/
nosequel@reddit
Until a certain point. When you are REALLY big you get pretty killer discounts on AWS and then it suddenly becomes a good deal again.
fallen_lights@reddit
Until a certain point. When you are ULTRA big AWS really starts screwing you again and when you realize where you are—it's too late.
BiteFancy9628@reddit
See kubero
WheresTheSauce@reddit
Does this not defeat the purpose?
PangolinZestyclose30@reddit
I don't get this thinking.
Self-hostable doesn't mean you have to self-host on production, it means you can.
But perhaps more importantly, it means you can run it locally which is extremely beneficial for DX.
Thick-Wrangler69@reddit
We use azure functions + durable functions for stateful orchestration, and we self host on local k8s. That allows devs to use serveless patterns but we scale on our own infrastructure
lampshadish2@reddit
How are you self-hosting durable functions?
Thick-Wrangler69@reddit
We use the isolated worker model, containerize the function host and deploy in k8s. An azure storage resource needs to be present in the cloud to support orchestration and state management. We scale up/down the workers depending on demand.
ogghead@reddit
Fermyon Spin is a very interesting application of Wasm/WASI as a FLOSS self-hostable serverless platform
FoxRadiant814@reddit
That’s why I’m excited about Deno and Supabase
supercargo@reddit
I find all cloud-first runtime platforms pretty cumbersome compared to local development. At least with platforms like lambda they use normal languages or just containers. Consider yourself lucky if you’ve never had to deal with something like Salesforce where it’s a proprietary language that you can’t run or debug locally.
phipletreonix@reddit
As someone who’s never had to deal with Salesforce— excuse me, what?!
ksco92@reddit
Yes, I wouldn’t piss on Salesforce and anything related to it if I were on fire.
RandomOrisha@reddit
I've never done any development in a Salesforce environment and am really surprised to learn from all these comments that it's apparently trash. Grateful to be enlightened.
ksco92@reddit
My first ever encounter with it was to extract some data. Basically an object is a table. This was an events table for things happening in the system. This was utterly useless because timestamps are only down to the second. The moment 2 actions happened in the same second, you can’t be 100% sure which one happened first. I was like, bruh 🙁
SelfEnergy@reddit
Reminds me of my last job where they had ms precision but windows server with broken ntp so the clocks of the servers differed by 5 minutes...
forgotmypassword314@reddit
The rage I just felt on your behalf.... I'm so sorry!
unconceivables@reddit
I love when people ask "should I take this Salesforce job where I have to use this proprietary language in this proprietary ecosystem that won't transfer to anything else but it pays good."
Vendredi46@reddit
pay is really good though, even for entry level
unconceivables@reddit
Selling your soul usually pays well.
CARRYONLUGGAGE@reddit
That’s a little dramatic. Some people don’t care about learning everything about coding, and salesforce is large enough that I’d feel safe working in its ecosystem for many years.
It’s ok if people want to work with it and improve their quality of life significantly. It’s weird to tell those people they’re “selling their soul” as if coding in standard technology for another company isn’t the same. They’re all just jobs.
OnlineParacosm@reddit
It’s not really dramatic; this is a company that sold the concept of mass market expansion to any company with a pulse by over hiring SDRs to support AEs as a sales motion. That doesn’t work now that the bubble has burst, and the practice turned out to be grossly irresponsible. Instead of taking any accountability for this, they’re now “AI pioneers” replacing the entire AE/SDR motion with AI, effectively washing their hands of this dark past.
Couple this with the fact that if you “wing it” setup wise internally and don’t hire absurdly expensive Salesforce consultants to setup your instance: you’ll incur so much debt across all BUs that it would take years of professional help to fix. We’re talking attribution issues, sales teams chasing their own tails, no visibility into key data, the list is endless. I’ve seen marketing go into salesforce and create 15 minutes of post call work for salespeople to do, which turns your sales team into an unpaid data collection team to support reporting for the C suite - is that salesforce’s fault, or the company “misusing the software”? There’s endless cover for the company here.
Salesforce really needs to be studied how badly they’ve destroyed a market, people’s careers, and productivity for the sake of increasing growth at all costs.
CARRYONLUGGAGE@reddit
I think you’re misunderstanding.
The person I replied to seems to have an issue with Salesforce developers only understanding proprietary tech and calling that “selling their soul.” Likely because it’s non-standard, not great for learning and expanding their skill set etc. But working there and working at any other large corp in a traditional stack is no different morally. Most large corps have skeletons in their closets, just like Salesforce.
So saying they’re “selling their soul” just because someone is considering a proprietary tech stack and aren’t hyper focused on progressing their career is weird and dramatic.
OnlineParacosm@reddit
Don’t you think that Salesforce keeps it as closed and obscure as possible so that they can prop up a highly paid consultant force of Salesforce admins?
It goes hand and hand with generating demand for their product
unconceivables@reddit
That's exactly it. It's not just the fact that it's proprietary, it's the fact that it's proprietary because of all the reasons you mentioned. Salesforce is a horrible company with awful business practices.
CARRYONLUGGAGE@reddit
I think you’re still not understanding what I’m saying, I’m not defending Salesforce and their business practices.
The original context of the comment I replied to made it out to sound like taking a Salesforce dev job is so much worse than another SWE job and it’s “selling your soul” bc you’d be working in proprietary tech. But you could be “selling your soul” just as much by working in any large tech company that uses standard tooling too. Many of them have engaged in questionable business practices, squashing competition via acquisitions, etc.
SnooPickles1042@reddit
Well, depends. You can always transfer meta-skill, like If you manage to intoduce good testing strategy for this obscure proprietary framework after a month of studying it, your selling point on next interview would be "I've learned obscure proprietary stack in a month and increased productivity of the team in next month by x%" - if I were a manager of team struggling with testing of whatever hell - I'd hire you.
DerpDerpDerp78910@reddit
Pays well though cos it’s bullshit.
gyroda@reddit
Yeah, my company was advertising for a Salesforce dev and the salary was higher than the normal band for software developer (fixed term contract though)
moreVCAs@reddit
Plot twist: it’s on fire RIGHT NOW and begging for just an ounce of piss
IrishPrime@reddit
The only time I wouldn't piss on Salesforce is when it's on fire.
axiosjackson@reddit
I currently work somewhere with a team of dedicated “Salesforce Developers.” It is a gross inefficiency, but certainly not the only one that exists…
Ok-Mission-406@reddit
Apex is kind of like Java but with all the good things stripped out.
Jg-mz@reddit
Java at home*
TheSauce___@reddit
It's not like Java, it's a fork of Java circa ~2004-2009 with an ORM hacked into the JDK. It's also case-insensitive for some reason.
zaitsman@reddit
Yeah man, there is no debugging at all except ‘historical replay debugging’ and it takes up to a few minutes to deploy your changes. Salesforce is the worst DX by far.
LiamTheHuman@reddit
That feels like something no dev would ever want but it's sold to upper management who don't see any problem with it
Tee_zee@reddit
People specifically hire salesforce developers if they’re doing much with it. Not something you generally land in by accident
funkdefied@reddit
My company just moved their CRM to Salesforce and now I’ve accidentally landed in it lol
Tee_zee@reddit
Theyl hire a day rate contractor soon enough 😅
zaitsman@reddit
Yup, that’s how I ended up there.
Their proprietary shit is full of bugs, too, once had an issue where checking if collection contains a primitive was broken in a Set<> but not a List<>. That was fun.
Embark10@reddit
Safe to assume the money is good at least?
Zlatcore@reddit
i worked in outsourcing company - I was paid (per hour) around 11 euro pre-tax. My company billed me to Dutch company 35 euro, and the dutch company billed me to their end client 107.5 euro per hour.
So yeah, the money is good. Just not for everyone.
TheSauce___@reddit
Salesforce tech lead here, yes.
zaitsman@reddit
I am in a very unique situation where thankfully I don’t do Salesforce every day and work across many different tech (Swift/Kotlin/.Net/AWS to compliment Salesforce and on the other side node/react/kubernetes/GCP) so it’s hard to judge by my salary.
Supposedly it is good but you have to keep drinking the koolaid and keep getting certified and recertified which I’d never bother with.
I can say positively that I am never going to a job where this is a known requirement to work with Salesforce again.
unconceivables@reddit
It makes more sense when you realize it's made for consultants that charge by the hour. "Sorry, it's still processing. Ca-ching."
zshift@reddit
Salesforce and PeopleSoft with their shitty, custom languages
Top_File_8547@reddit
Do you think this is done for customers lock in? Even if they used an existing language I am sure there is so much behind the scenes that you would have a massive job reproducing all of the functionality.
BonnetSlurps@reddit
Salesforce is so old that I believe it's just what they could do back then.
SAP and other ERPs that I worked with around 20 years ago are also all like this.
There was some tradition of embedding open-source languages, but it wasn't as strong as it is today. I remember only TCL and maybe Lua having some traction. Even Guile in Emacs was too niche.
The fact that they didn't change it to something more palatable is what's more egregious.
bjogc42069@reddit
SAP uses ABAP which predates Java and Python by at least a decade. By the time either of those languages really got popular, SAP had already been around 20+ years. That's a lot of toothpaste to try and get back into the tube.
Salesforce came out in 1999 and they also invented their own version of SQL for some reason which I find much more egregious than inventing their own OOP language
Zeimma@reddit
Many do it for the hook into endless support. So in a sense yes it's for lock in but not directly.
olduvai_man@reddit
Learn from my misery and stay far away.
LimesAndCrimes@reddit
We are moving all our customer facing products onto not only Salesforce but a Salesforce wrapper product.
Your comment just reminded me how fucked we are.
WhiteXHysteria@reddit
We attempted to do similar with netsuite and is just so bad. There's no wonder there are a million 3rd party contractors specific to developing on those platforms. They can create garbage and you can't tell if apart from the native product.
ESGPandepic@reddit
It's hard to put into words how much I hate netsuite, even migrating away from it has been designed to be as painful as possible.
WhiteXHysteria@reddit
The whole point of all the proprietary bull shit is to make it harder to leave. I assume that once you are really engrained in their system they will jack up the price a good bit but we haven't gotten there yet even though the prices I've heard that we pay are insane.
wesleyoldaker@reddit
Isn't this how Oracle makes all their money?
LimesAndCrimes@reddit
For real. We're in a proprietary platform crisis right now.
BroBroMate@reddit
No source control either.
TangerineSorry8463@reddit
That's actually a problem we're solving at $Job right now - none of the schema and view definitions in Redshift are documented or version controlled. What is there is what we have. Any rogue actor or an accident could be the end of our data model.
funkdefied@reddit
That’s starting to change. I’m doing git-based devops at my job right now. Just don’t change Profiles
Blaze__RV@reddit
I developed a CD pipeline to deploy to Salesforce orgs. Even the minimal involvement of the Salesforce cli and connected app I had was so frustrating especially with the whole sfdc to sf transition that's been going on for basically forever.
ArgzeroFS@reddit
The required code coverage even for simple scripts is even more annoying.
edgmnt_net@reddit
Yeah, that's how you get those projects where you can only test stuff in production and most work is meaningless data shuffling.
Zlatcore@reddit
I was sure that I like all kinds of programming and any kind of it until I took the position of working on "demandware" old name for Salesforce commerce cloud. Took me about 2-3 months to start feeling both physically and mentally ill when I needed to go to work. I hated it so much. (I was still finishing my tasks and such). Then I got offered to take on a team and teach juniors to work at it so I quit tomorrow.
Eratticus@reddit
If Commerce Cloud feels like it was cobbled together by a bunch of people who didn't know what they were doing and then it was acquired and made an official Salesforce product then that's because it was.
duva_@reddit
Yes
Shnorkylutyun@reddit
Oh man, you remind me of one interview where all their development was made through a website's textedit form. No syntax highlighting, no debugging, nothing. Proprietary scripted language. They were begging for new developers as no one wanted to work there.
big-papito@reddit
You laugh, but this is how I learned coding. Back at the dawn of WWW we created websites through plain-text editors of hosting sites such as Tripod or Geocities.
That said, anyone doing this today just screams "amateur hour".
MentalWealthPress@reddit
Whhhaaaaaaaa
Adept_Carpet@reddit
QuickBase, for the longest time, enabled JS development through a JS injection vulnerability they decided not to fix.
Some guy in their developer forum (it was always the same guy, he was a real one) would find new ways to inject JS all the time and they would basically celebrate it as a new feature.
So you wrote your JS, then to deploy it you went to the place in the admin menu where you could customize your logo color and instead of putting a color you put the exploit followed by your code. Infinite customizability!
This was on a low code tool that offered HIPAA compliance as a selling point.
BonnetSlurps@reddit
MySpace enterprise edition!
ju4n_pabl0@reddit
Yes, Salesforce is pure evil.
kaiju505@reddit
As someone who has dealt with salesforce a few times over the years, fuck salesforce.
TimingEzaBitch@reddit
:old-man-yells-at-salesforce is number one emoji in our company slack.
Equivalent_Emotion64@reddit
Oh god that’s torture no wonder salesforce devs made so much last time I checked
PandaMagnus@reddit
Fuck Salesforce.
smeyn@reddit
I work on GCP. I view serverless as part of a spectrum:
Cloud function > Cloud Run > K8S > VM > Bare Metal
You need more control knobs on your set up? You move to the right of the spectrum. Your application has little need for sophistication? You move to the left. Your choice of what is appropriate depends on the needs of the application.
chloro9001@reddit
IMO cloud run is the hammer that can be used for every nail
mrobo_5ht2a@reddit
That's a pretty summary. I agree
chloro9001@reddit
Serverless is really overrated and we have already swing mostly back towards standard server programming
_throwingit_awaaayyy@reddit
Serverless isn’t a silver bullet. It’s a tool for small, fast, simple workloads. It’s great at what it does and you can build some really neat applications using it. You can chain serverless functions using logic apps or step functions. Have them scale up to work in parallel. All sorts of stuff. Most of the time you can do most anything in serverless apps that you can do with a monolith. It takes some thinking through. If serverless doesn’t match your workflow then keep the monolith. You could also run your app in a container and run that as a lambda or azure function.
uNki23@reddit
Too narrow / limited interpretation of serverless imho.
A setup like AWS Application Load Balancer + AWS Elastic Container Service Fargate + AWS Aurora + AWS EFS would allow you to run complete ERP systems without caring about any OS maintenance or CPU / RAM configuration and it’s also HA and almost failsafe (from an infra perspective).
Your comment kinda limits it to “Lambda functions”.
AWS SNS (pubsub), SQS (queuing), S3 (object storage), EFS (elastic filesystem), Aurora (RDBMS), ECS Fargate (containers) and many more are all serverless services you can run without ever thinking of a “server” and what comes with it (provisioning, scaling, maintenance).
_throwingit_awaaayyy@reddit
Ok
bluelexicon@reddit
Thanks for posting this, I actually love serverless and have no problem with the sdks but i really appreciate reading all the perspective in here. My only comment to your OP is really that imo it seems no different to learning anything else. Each server, framework, cli tool, or 3rd party api feels equivalent and I like the reliability of the larger cloud sdks. Of course theres versioning woes, and some providers require more learning than others but overall I’ve built better systems on event driven serverless architectures than i ever did on traditional containerized services like ec2 etc
sehrgut@reddit
Yes. This is just the most recent swing of the mainframe-to-onprem pendulum.
i_exaggerated@reddit
The main reason I dislike it is because corporate must have heard a pitch for it and now EVERYTHING has to be serverless. Like serverless is the main selling point. Have a function that runs constantly 24/7? Hello 25 million lambda invocations a month vs a micro EC2 instance.
8ersgonna8@reddit
25 million invocations would still be a few dollars a month. An on-demand ec2 instance would probably cost more. Aws (serverless) API gateway though, once you get past ~20 million processed requests you might spend a lot more than a ALB might cost.
spiderpig_spiderpig_@reddit
Be sure to add in the cost of keeping OS patched, maintained, correctly secured. How many dollars a month?
Responsible_Golf_235@reddit
Yes serverless is bs
Whitchorence@reddit
That seems like a silly reason to "hate" them. You could equally well say you "hate" Linux because you already know IIS. Does that sound like a well-reasoned position?
skesisfunk@reddit
I find the Go SDK for AWS lambda (+ Terrafrom to deploy it) to be very tolerable. In my experience it allows you to focus on the business logic that would still need with a container application and only write a very thin wrapper to make it work in lambda.
ASteelyDan@reddit
Several years ago I used this framework https://github.com/serverless/serverless it was pretty extensible and supported multiple cloud providers. We ran our services for 1M customers for a couple hundred a month and development was a breeze. I’ve use amplify on side project before. Lambdas are really nice if you don’t know for sure you’ll need compute resources, but otherwise I’d avoid them these days.
dongus_nibbler@reddit
I unknowingly walked into a startup that built half their infrastructure in lambda step functions on this serverless tool (100% the wrong solution to the problem they were trying to solve) and this framework caused me so many nightmares. I lost at least a week or two over a few months trying to fix failed production deploys (mostly corrupted cloudformation state and dependency resolution failures with bundled packages / shared layers between lambdas) until I finally threw the whole thing out and set up terraform.
I'm glad you had a better experience with it but hooo boy I have had a better time tracing DLL resolution failures in win 2000 on production servers with 20+ applications all using the same library lol
8ersgonna8@reddit
These days serverless framework is pretty dead. But the guys at serverless stack made a pretty neat solution. V3 runs on top of pulumi so no more CDK dependency.
i_dont_wanna_sign_in@reddit
Feel free to hate on it. Seems cheaper in the front end. Seems faster to deploy stuff, too, but in reality it REPLACES complexity of running a data center with different required skill sets moreso than removing/mitigating them. You still need network engineers, you need even more talented DevOps pools.
The bigger you are, the worse cloud is for your business, really.
Volunteer2223@reddit
Why is it worse the bigger you are?
i_dont_wanna_sign_in@reddit
The bill for infrastructure is specifically tuned to barely beat the margins for self-hosted as the entire cost. You can sometimes get around this with deprioritized services, but most business applications need to be prioritized.
Either way, cost to self-host goes down at scale (lots of wobble, though) while cost for hosted is pretty much constant. All depends on business needs but the overhead for cloud will always eventually eclipse colocation or owned data centers.
gnomff@reddit
FaaS have pretty limited utility imo - the cold start time/db connection pool issue is real even with provisioned concurrency and db proxy, and the limited run time can also be problem. Add onto that what a pita developing a billion little packages is and yeah, it's not great for a lot of stuff. I've found it useful mostly when I have something small and I don't care about latency too much (it can be ok for reading an sqs queue for example).
On the other hand CaaS for APIs is amazing - I worship at the feet of Fargate, and only drop to k8s or raw ecs when I have so many containers that it becomes a cost issue. Even then I give the architect (who is sometimes me) a side eye and ask why we have to have so many gd containers (sometimes it's a good reason, often it isn't)
titpetric@reddit
I love how cgi was bad for the general use cases because of performance reasons, and here we have cgi branded as faas. Weird, right? Faas is cgi with more steps
you're right to hate whatever you want
amackzie@reddit
Is the problem vendor locking specifically eh do you also mind say using something like kubernetes terraform etc
papawish@reddit
I hate serverless because it nakes me learn Cloud vendors details and pushes me away from the machine.
I LOVE serverless because I had some great success with it. It simple is the best option for low volume, low compute, low maintainance, high criticality tasks. I have about a dozen lambdas that run every hour, they've been for 2 years, haven't looked at them for 6 months. I know they'll keep running, to the point we removed on-calls in my team.
My ec2 machines fail from time to time, necessiting on-calls.
Left-Koala-7918@reddit
This isn't a serverless issue. The is true for learning any new framework or library. This is particularly bad when things don't work and the abstraction pair with poor documention makes debugging impossible. I work at a large tech company and we struggled with using another companies sdk. Given out size we had the luxury of calling the company and debugging with the sdk maintainers on the phone. But smaller teams and individuals wouldn't have that opportunity.
colinshark@reddit
I am pro-serverless when the company is going to finance all the development on testing, terraform, CI, and monitoring, which you need. It's beautiful when the whole stack is running perfectly. The same pattern/template can be reused. Quick to make changes and debug, too.
For my own services I run, I can do it cheaper without cloud, but the requirements are different.
SilencedObserver@reddit
Serverless is a lie to sell developers hardware they don’t have to understand
LiteralHiggs@reddit
"old man yells at cloud" swe edition.
sobe86@reddit
Yeah maybe an element of this, but we've been through so many of these as well: microservices, TDD, noSQL, agile etc. All of them turned out to be useful to an extent, none of them were applied sensibly when they initially became popular.
Thing is I think we're already past peak hype on serverless, it's not just OP who thinks you should not use serverless too liberally, the drawbacks are well known at this point.
LiteralHiggs@reddit
I was just making a joke. I get what they're saying and agree. When new tech fads come along management always seems to want to jam it into whatever project they have.
matthedev@reddit
There's been an evolution towards serverless computing (although serverless is a misnomer since the serverless function is still running on someone's server somewhere):
That doesn't mean the later abstraction always replaces earlier abstractions. Are you researching where serverless functions would be best used architecturally and most cost effective? That might help you feel like you're getting something out of learning the technology.
PartyParrotGames@reddit
I suspect there is skill transfer here. There is solid logic to how cloud providers structure their services and SDKs and that understanding is transferable to other contexts than serverless.
BiteFancy9628@reddit
People will do fucking anything not to have to learn Linux and docker. Boggles my mind.
nekokattt@reddit
Serverless has nothing to do with learning Linux or Docker. It is purely a way to run something simple quickly if you're already locked into a specific cloud vendor.
It is no different to using cloud VPSes. You could argue people using EC2 "will do fucking anything not to have to learn hardware and real physical networking".
BiteFancy9628@reddit
I know all about what serverless is. Its main selling point is it’s “easy”. It claims to simplify kubernetes and docker. I view it as overpriced and lazy. It’s fine for a quick POC. But I have little respect for senior engineers who refuse to learn Linux and Containers and want to deploy a script from powershell to “prod”.
Heroku is better if you have to have something like this.
nekokattt@reddit
Heroku is PaaS, not FaaS.
If you lack respect for developers for the tools they use, it is time to touch grass and get over your ego.
If it works and does the job, who the fuck cares.
BiteFancy9628@reddit
When every piece of the dev to prod pipeline runs in Linux it’s time to learn. Like I said it’s fine for a poc. But when your execs see the bill you’ll be dropping serverless anyway or doing your own with kedro or kserve. Gotta leave the windows cocoon eventually.
Confident-Alarm-6911@reddit
Serverless are just huge vendor locking machines. I see cloud providers as a cheap supermarket for developers - Food there is cheap, but of poor quality, however, most buy there. Those who care about health and value quality buy from local suppliers or make things themselves. Unfortunately, such large companies are practically killing the local market, because most would rather pay pennies for food full of microplastics and preservatives than add more and have something good, but also better health. The same thing is happening in IT and actually everywhere, we have the effects of a community that is driven only by gaining profits at any price, issues like quality or reliability do not count
nekokattt@reddit
This has always been the case though.
casualPlayerThink@reddit
Serverless is fun and cheap solution, easy to configurate, until the moment you have to debug a data stream across 15 serverless function. Then you start implementing 3rd party into it, and it will be hell on different levels :) Or a serverless is called half a millions times per day, then it will be expensive as hell.
Funfact: most of the times, a simple old VPS can do the same just in 24/7 and for like 5 dollar per month, not for 80-800 :)
sobe86@reddit
This is what I dislike about it too. I think you should generally try to go for a hub and spoke model if you're trying to do this, and have the hub node log the hell out of everything. Going for a daisy-chain / cascade models seems to be more common in serverless, but it is so hard to debug, and it adds a lot of overhead when trying to add intermediary steps.
big-blue-falafel@reddit
If you’re chaining them together why not use step functions?
duva_@reddit
Yes
sobrietyincorporated@reddit
Use SAM or SST.
FantasticVanilla5464@reddit
I feel like anything new you're going to have to go through learning curve.
I enjoy serverless because it's very quick and easy to spin up logic at an incredibly cheap price. Without having to much more config then an IAM roll with the permissions it needs.
The Lambda is the canvas for diving into the finer details and new tech.
donat3ll0@reddit
Serverless Dataproc is pretty damn nice. If you've done any serious tuning of a spark cluster, you would likely appreciate it.
My dog can stumble across my keyboard and submit a job with 80% CPU utilization. It's fantastic, and nobody has to deal with spark internals.
havok_@reddit
Which service is that specifically?
donat3ll0@reddit
Dataproc is Google's managed Apache Spark/Hadoop service. It can be quite useful for machine learning, batch, and streaming processing. I believe it is eMR in AWS.
Without serverless, you deploy a cluster to submit jobs. You are responsible for resources, auto scaling policies, and resource tuning, which can be at the code, job submission, and cluster layer. Tuning a job to be performant without overloading a source can be tricky. If you don't know spark and/or dataproc internals, you're going to have a bad time.
Varrianda@reddit
There’s really no reason not to use lambda(imo) if all your API/application is doing is standard CRUD operations. It’s just so easy to maintain, deploy, scale, and monitor.
Lambda falls apart when you have tight SLAs but low traffic, because then you have to deal with cold starts, but otherwise that’s about it. The only thing I wouldn’t use lambdas for is long running batch jobs, or occasionally if you need to do background processing after returning to the calling client. Obviously you just kick another lambda off async, but it’s easier to return and then just keep processing in a fargate cluster/standard container.
tronj@reddit
Your product and company does great. The business wants to expand internationally. You start selling to users in Saudi Arabia where your product has become a success. Saudi regulators pass a new law saying all cloud data must be hosted in the country. There is no AWS there and won’t be for years. You now have to re-architect and re-develop your entire product and your competitors take all your customers and your new international division fails spectacularly.
Varrianda@reddit
I mean, that’s not a worry for me. But also I struggle to see how this wouldn’t be an issue for any data storage solution on AWS/cloud?
a5s_s7r@reddit
Take a look at the SST framework. I’d say, it’s the better predecessor to the serverless framework.
It uses Pulumni under the hood, and is typesafe.
https://sst.dev/
quadraaa@reddit
As everything, it's a trade-off. Using serverless cloud offerings can often bring a lot of value.
ThigleBeagleMingle@reddit
Use AWS Lambda functions. It’s a container that can run for 15 mins and billed in 100ms increments.
Runtime supports 10GB and equivalent of 8 vcpu. More than enough for lotta problems
Famous-Composer5628@reddit
until cold starts start becoming a regular issue, especially when latencies need to be reasonably deterministic. And then, debugging the issue for latencies becomes non trivial and you have end up employing patchwork of solutions to keep stuff running all the time
JamesVitaly@reddit
Mmm cold starts aren’t really a thing if it’s always being used as it’s never fully cold.
InfiniteMonorail@reddit
That's not how that works and that's also 10x more expensive.
JamesVitaly@reddit
Yes it is how it works, when a lambda starts it can stay up for x number of minutes (warm ) and is exponentially faster after - you are still only charged for when it’s called ( not kept warm) so it doesn’t cost 10x anything
InfiniteMonorail@reddit
Also it's vulnerable to denial of wallet and I think you have to build your own auth unless you put something like a gateway in front of it (with its own limitations, timeouts, cost, and latency). This is the main reason I never considered it.
Drogon_The_Dread@reddit
No you just hate it as it makes you 'feel stupid', give it some time and you'll learn it's just another tool like everything else
steelegbr@reddit
This attitude is why some places still have dev and ops silos. There’s also some correlation with never upgrading frameworks, dependencies, etc. Different is scary. 😉
Serverless does need some different thinking. The instances are short lived, resource constrained and scale into mad spend if you’re not careful. But honestly, it’s all just squirting data into some entry point and spiffing out a result. It’s the wrong design for some problems but nowhere near as painful as you make it out to be.
squngy@reddit
Serverless is one of those things that solves 1 very specific problem extremely well, but adds a lot of complexity that most projects do not need, but they have it anyway because it is a buzzword that sounds impressive to management/investors.
notger@reddit
There is no such thing as server-less, it's just that someone else runs the server.
So naturally, you are adding one layer of obfuscation which makes things less flexible and easy to use.
Can't say I am a big fan but as with all cases, it is a trade-off.
dskippy@reddit
Congratulations!
You have reached the point in your career where you are done learning. You have amassed enough experience that you can convince yourself that that's enough. Learning new skills now feels like a chore that you feel entitled to avoid because you have enough experience.
You have unlocked the ability to refer to technology you don't understand as "new fangled whosiwhatsit" and you're now allowed to condescendingly dismiss anything you haven't learned as "what the kids are doing these days" as though that means it's bad.
You are now fit for a job as manager since you soon won't really understand how to do anything current given the pace of technology. But you'll have the clout to tell others to do it because you once knew how. You'll also make more money and do less work.
IndependentProject26@reddit
I don’t get the vendor lock in argument. Migrating a Lambda function to some other platform like Kubernetes is not rocket science. Not trivial but hardly difficult.
BloodSpawnDevil@reddit
I'm confused what problem it solves but that problem is why you should use it. There's no way the point of using it is to make it less complex and easier to develop. So your experience makes sense.
I normally have worked on small teams or by myself so prioritizing the ability to keep things simple and make it easy to develop is the way to go.
I have yet to see added complexity for any reason have any tangible benefit and usually results in such a poor codebase people want to throw it away before it even ships.
I could sum this up as someone thinks it solves a problem or provides a valuable feature and it probably doesn't.
jesusrambo@reddit
It’s not a magic tool that does everything, but many of the common complaints in these comments are just user error or misuse
In general, I find it makes things much harder to do the first time, when you’re learning the abstractions. Once you’re comfortable with them, though, that pays off in spades.
kevinw88@reddit
What problem are you or the company trying to solve with serverless? If you're t can't be articulated and quantified then it's hype driven development and yes you can hate it.
Ok-Hospital-5076@reddit
I actually like working in serverless XD. Its leaner , dont have to deal with complex design patterns , get to work with loose fun languages like JS or python without worrying much. we write very self documented code and lambas can be owned by individuals.
Down side is ofcourse vendor locking, every thing has to be a service. Cost will shoot up. But We dont really consider serverless as backends , its bunch of automation scripts glued together to work in sync .
WRB2@reddit
The majority of the cloud is made to reduce mistakes, reduce costs and speed delivery. Think of it like an Army manual for newbies, 3-4th grade level.
Server-less is Windows/Linux server-less. It made to perform a set of specific tasks very fast and not as flexible as the alternative. With that comes one good and one bad consequence. The good is it’s easy to get working for simple things. One bad is it’s a Black Box and when the provider wants to make a patch, well sometimes SURPRISE SURPRISE SURPRISE, as PFC Gomer Pile used to say.
Also what is does is further lock you into only their cloud. It’s almost as if we didn’t learn any lessons from Oracle.
psychicsword@reddit
I like containers especially if you configure it in a way that has multiple ways to inject the same config so locally it is just json or environment variables but in the cloud you are using some injection service.
What I really think is a pain are "function as a service" cloud offerings. I feel like the only place those should exist is in extremely event driven architectures and use cases but even then it seems like there are only a few places where it improves the economics of it.
jrodbtllr138@reddit
I also dislike serverless, but I hate it from the other side of the curve.
The classic “I hate this”, “wait this is cool and super useful, everything is a nail” to “oh wait, this sucks for anything beyond fast prototyping” curve
_nightgoat@reddit
I prefer not to use serverless if I can help it.
ToThePillory@reddit
I have mixed feelings on one hand it's great, no messing around with servers, you just deploy your code. On the other hand serverless can be a pain if you have needs not obviously covered by the platform. On your own server you can just install weird stuff and run it, you can't do that on serverless.
bnasdfjlkwe@reddit
But once you get the good flow, its amazing.
But yes, the initial setup and learning phrase is a cliff.
Gammusbert@reddit
Not enjoying development is your personal preference so go for it, the only time an issue would arise is if it was the right tool for the job and you refused to use it just because of your opinion.
gajop@reddit
I ike GCP's Cloud Run. It allows me to deploy a containerized app, written in basically any kind of language I'd like, using standard web tech - stuff that runs on my PC. It abstracts out scaling, and is cheap (effectively free) for little to no use, which to me is the win of serverless.
Rymasq@reddit
Serverless was meant for small microservice oriented development. If you are building something overly complex serverless is not what should be used.
To be honest, serverless is becoming more niche as k8s is the go to anyways and has more upside
ogghead@reddit
Ideally yes, but this goes out the window if you need finer control over performance. For example, to do something like warm network connections before an instance of a Lambda can handle traffic, you’ll generally have to rely on specifics of how the Lambda language runtime behaves.
Definitely agree on k8s having more upside overall though.
ivancea@reddit
Let me cut that phrase there, for academic purposes. That's how this sector is. You have to learn whatever you need to learn to solve whatever you need to solve in the best way you can.
And don't you dare think it's any different from learning X framework in X language.
There's also no skill transfer between Terraform and most other programming things. Yet you have to learn it when you have to use it.
I feel like you are targeting serverless just because "a company owns it". Analyze that thought
djnattyp@reddit
But it is - you're now completely at the whim of vendor X of when updates happen. When things break certain ways - you can't troubleshoot it directly, you have to open a ticket with vendor X.
And all the vendors do have subtle differences.
It's pretty comparable to doing low level development on proprietary chipsets - you're beholden to the vendor and usually locked into weird extensions that only they provide. "Skills" aren't that transferable because they all do things different.
ivancea@reddit
When there's a big in framework X, you have to search, potentially fork, and fix the issue. Which takes time.
When there's a bug on a cloud, there's a support that will either fix it for you, potentially in no more than a day.
They may appear like very different things, but they are not. Your time has a value, and so has the cloud support. But the support is already paid.
If the comparison isn't enough, let me try with another argument: not every skill had to be transferable. It's not a direct metric of how valuable it is. For example, knowledge in C is far less valuable nowadays than knowledge in Azure, AWS or Gcloud.
djnattyp@reddit
When there's a bug in framework X due to an upgrade you just downgrade to the previous version. No ability to do that with cloud.
LOL. Until they claim it isn't a "bug" but you're just "using it wrong" or "going beyond allowed parameters" or something... and the "fix it for you, potentially in no more than a day" part sounds more like a sales blurb than reality.
Until someone needs it... there's probably some dude making bank when some gnarly C code he hacked together back in the 90's for a bank that's never updated needs something added. Good luck using any "knowledge" of a cloud platform you used a few years ago - it shifts like the wind at the whim of the vendors.
ivancea@reddit
That works only if it's a new bug.
Many services in clouds are versioned.
I don't know which experiences you had, but I haven't had a resolution like that in my career. Well, I haven't seen many bugs in clouds like that really. There are always ten thousand users testing them before you.
But anyway, let's not enter into "what if Mr. Support has a bad day and hates me"; that goes nowhere.
Ok! You better keep that "important" knowledge hot, that maybe some company may need when the old dev dies, while I'll keep my cloud knowledge that thousands of companies need every day.
Really, let's be serious and not add magical examples like that.
RealSpritanium@reddit
Serverless = way too many servers. Always thought that was funny.
Necessary_Reality_50@reddit
Serverless is fantastic. Focus on your code without worrying about servers, load balancing, runtime environments, scaling. And for the vast majority of things it's basically free.
tom_earhart@reddit
I'm the guy who has never used cloud in 15 years of career. Load balanced bare metal all they way. My projects, including ones with millions of daily visits, never needed anything more and I have control over everything.
swapripper@reddit
What does your typical set up look like? On VPS now?
montdidier@reddit
He said bare metal- so no VPS if I interpret correctly
marmot1101@reddit
I disagree, depending on the project of course. It takes a lot of admin off the table and can be really fast for development and deployment. It can also be quite cheap in low volumes or tuned properly. There are some problems that are better addressed with more conventional technologies(vms and/or containers) so to me it’s not an either/or proposition. I appreciate being able to work in both worlds
One side note because others mentioned provider lock in: I don’t consider provider lock in at all. Unless someone had a very compelling reason for multi cloud it’s a huge amount of effort for not a lot of return, at least coming from the operations side of things. Pick a cloud and embrace the sharp edges. A cloud vendor migration is a major event, and will be a major event regardless of designing for multicloud or not.
thedancingpanda@reddit
Straight up -- this is whiny dev bullshit.
Serverless has a lot of positive aspects for many development teams -- cost for low volume and ease of scale is generally the angle. if it's thought of as a net positive for your team, then yeah, you've gotta learn the intricacies to make it work for you.
"But I don't want to learn some arbitrary SDK" is the whiny bullshit -- as Don Draper said so eloquantly: That's what the money's for. Get to work.
Honest_Pepper2601@reddit
It costs so much money god damn
axtran@reddit
Troubleshooting serverless is horrible, even with awesome tracing monitors in place. You soon realize most of this stuff is just marketing hype and not long term goodness
Obsidian743@reddit
Oh, I thought this was going to be a discussion about the actual technical and architectural problems with serverless...but you're about the tooling? Hah.
rvitorper@reddit
You are right to hate serverless. It is essentially servers with a nice packaging.
JoeBidensLongFart@reddit
Serverless is vendor lockin on steroids.
WheresTheSauce@reddit
Why does that make it hatable?
rvitorper@reddit
You can get burned with serverless. Lots of cases where people get DDoSed and end up with 100k bills.
Also, they are extremely expensive and sold as the next big thing, when in reality they are glorified servers.
You can essentially leverage the years of experience behind you when using servers, something you won’t have when using serverless.
Also, the architecture is very rigid. You have to go for a microservices architecture and dare you use more than the time limit or the ram limit.
I can also talk about vendor lock-in. You could spin up an Open FaaS cluster on k8s, but then again, aren’t you managing servers?
Cold start is also a bitch that forces you to do all sorts of workarounds to accomplish something that is non-existing in a server. It just works on a server without restrictions!
The serverless also forces you to have extra infrastructure that you wouldn’t need otherwise. Now you need a redis to cache things. And you are not able to leverage disk cache, for instance.
It is definitely very good on paper and for tiny things that are pre-revenue. Everything else, it is a PITA
WheresTheSauce@reddit
I share a lot of those same critiques, I just felt like you were arguing it was bad because the name was misleading and not for concrete reasons like you’ve listed here
rvitorper@reddit
Sorry for the misunderstanding.
I have been bitten by serverless a few times, but it is a nice technology. Google’s Cloud Functions and Cloud Run are among the best implementations I’ve seen.
I even have clients that I recommended serverless because it totally fits their needs: no need to manage servers, little traffic, limited and not growing scope.
In many cases, servers are the best way to go.
MagnetoManectric@reddit
Nah, I'm right there with you. I do however, see the point in all of it, as it makes deployment and scaling easier, but man, is it a pain in the ass to get setup, and you gotta deal with it constantly changing all the time, no time to get comfortable with anything....
Like, it feels unknowable compared to the good old days of a server application that ran on a tangiable machine, but for the stuff we do at work, I still wouldn't go back to that, in all practicality, comfy though it is.
FoxRadiant814@reddit
Global deployment and pay for use is too good to ignore tho. I’m really enjoying supabase and looking forward to starting deno. All FOSS
EarthquakeBass@reddit
I’m kinda the same way generally speaking, I’m a little like ok can’t I just use Linux or FOSS stuff that isn’t locked in to some platform so it’s actually a portable skill where you’re learning like a “real thing”. At the same time serverless seems like a good answer to what has become an industry wide bad habit of extreme over provisioning of infrastructure
ep1032@reddit
Cloud first means scalability will always be easy. And infra costs will always be proportional to total company product usage. Thise are two big items in the pro column.
The con column is that setting up this infrastructure requires orders of magnitude more complexity to do for the first time than any other type of infrastructure. And you are more or less locked to vendor lock in. Two pretty bog cons.
Scarface74@reddit
None of the cloud providers change their APIs willy nilly. Besides, not only can you now load a standard Docler image to Lambda, you’ve always been able to deploy your standard Node/Express, Python/Flask, .Net/ASP.Net API directly to Lambda
clairelocalhost@reddit
I actually enjoy it if it fits the project (primarily cloudflare workers, not lambda) and it’s actually more economical for one of my projects plus it gives me unlimited scale without having to think about it and runs on every cloudflare edge node. This project has a very spikey level of usage which is where I feel serverless can work well as I don’t need to bother with auto scaling servers or wasting idle resources.
There are absolutely downsides, often in local dev/testing and diagnosing production errors.
My background is more in sysadmin/SRE, but it’s nice not having to think much about a lot of the infrastructure management / upkeep as much.
credit_score_650@reddit
don’t learn, you don’t need it, stay with ec2 and ssh
InfiniteMonorail@reddit
idk but I stopped using API Gateway + Lambda after working with them for many years, too expensive and slow. Serverless RDS is also a bit niche. CloudFront, S3 are great. People seem to like Fargate. Dynamo is questionable. Cognito is so bad. Development takes longer and is harder to test. Sometimes things don't scale or you end up maintaining something anyway. It's definitely the right tool sometimes but it's never the first tool you should reach for.
Spider_pig448@reddit
This seems backwards. These APIs are abstractions. They enable you to do these complex things without having to have deep knowledge about them. I get being frustrated that you spent years learning these things and now find you don't need them, but I think that's a good thing.
Varrianda@reddit
No, it’s just another tool. Learn why it’s useful and what use cases it better than the standard containerized approach.
Serverless is much easier to maintain when compared to your standard kubernetes/docker approach.
lherman-cs@reddit
I used to like serverless, it's quick to setup, low maintenance, on-demand price. But, then the benefits tend to go downhill after the initial hump.
Testing is usually harder, the DX feels like an after-thought than something that was built from the beginning. I found setting up the testing environment to be harder to set up correctly, to the point that I got lazy and didn't test instead.
Pricing is also expensive. Nowadays, you can easily get a $5/mo machine that can easily handle 10,000 RPS with no cold startup latencies. Then, you can horizontal scale with k8s.
There's a lot more freedom from non-severless. There's no short CPU time. You can pick and choose software you like to integrate with. Testing is also easier to spin up locally, it motivates me to write as many useful tests as I want.
tarmkal@reddit
I used to be in your camp. But now, for almost two years I’ve worked in a project which is lambdas only. And I see the upside now. Once you learn the abstractions and properly set up your flows, you don’t think that much about serverless. Just something to get used to. Nowadays, even the small gigs I do in addition to my main job I seriously consider lambas. Specially if the job is something without proof that anyone will actually use it or how much usage it will get and if the “just keeping it up” budget is tiny.
xabrol@reddit
Dunno, aws lambda is so easy on nuxt 3 with aws-preset.
I just "nuxi build" and run my zip script, then upload the zip, refresh lambda url page, boom, it runs.
electro-cortex@reddit
I agree that DX is not that great (the tooling and the documentation, too), but I also think that these can be standardized somewhat in the future. OpenFaas is an attempt to tackle this, basically a way to run event-driven functions in Kubernetes.
Joooooooosh@reddit
Feel like serverless is useful for small teams projects that just need to get some stuff working.
Having worked in very large scale companies and small ones, at scale it’s MUCH cheaper to do a lot of things yourself but it requires more people.
So you either suck up the costs or get good at running a decent sized workforce. Pick your poison.
For me though, it’s hard to justify not just using a VM due to how familiar it is for most people.
anor_wondo@reddit
I am quite sure the amount of vendor lock in in serverless is more about business than about the concept itself
SirGreenDragon@reddit
I can't comment on serverless, but as a developer, you have to keep trying new languages and processes and flows to keep up to date. Always be learning. If you just stick to the tools and flows you already know, you will soon be out of work.
ExpertIAmNot@reddit
Serverless requires a significant shift in the way you mentally model and plan projects. In my opinion it’s sort of like the mental shift from Procedural Programming to Object Oriented Programming in the 2000(ish) timeframe.
You have to be willing to take a step back and understand a whole other way of looking at problems and solving them. Once you do that it gets much easier but if you aren’t willing to take that step back and understand the difference then you are probably doomed to have a really bad time.
yousaltybrah@reddit
It’s on purpose, each cloud provider comes up with their own way of doing things so you don’t just up and leave to switch to a cheaper or better option, since you’d have to learn things all over again. The learning curve is very much a business tactic.
indicava@reddit
Serverless backends are a tool, just like any programming language or tech stack. When used correctly they can certainly provide significant value in time to market, reducing cost, security, etc. Just depends on your use case.
OverEggplant3405@reddit
Yeah, I'm not thrilled about it either. I think containers are okay, but I'm not sure if that qualifies for serverless anymore. Everything else is expensive and specialized with hidden pitfalls that can trick you into racking up costs.
Demostho@reddit
You’re definitely not alone in feeling frustrated with serverless. It can be a huge pain when you just want to get stuff done, but you have to deal with all these layers of abstraction, SDK quirks, and constantly changing APIs. It’s like you’re not using your experience as a developer anymore—you’re just jumping through the hoops set by the cloud provider. And yeah, the lack of transferable skills is a real downside. It feels like you’re investing time into something that won’t really help you outside of that specific ecosystem.
The thing is, serverless is supposed to make things easier, but often it just shifts the complexity to areas like auth, config, and vendor lock-in. Plus, with the way everything is abstracted away, you’re more dependent on their specific tools and updates, which can be frustrating when APIs change, and you have to relearn everything. It makes it hard to maintain a consistent flow when your focus keeps getting pulled to work around these limitations.
That said, it’s kind of the reality of modern development now, especially when scalability and reduced infrastructure management are essential for a lot of companies. Whether we like it or not, serverless is becoming a big part of the job today. So even though it’s a hassle, learning to navigate it is almost necessary to stay relevant, especially as more companies adopt these solutions to simplify their infrastructure and cut costs. You can still hate it, but it’s definitely something that comes with the territory now.
Informal-Bag-3287@reddit
I disagree, having to deal with SDK's and to a certain extent external API's will always have frustrating moments. The fact that it's a cloud provider doesn't make it less or more annoying. If anything the cloud's popularity (for better or worse) makes it ideal for development since a lot of devs are forced to interact with it therefore providing examples such as youtube tutorials, medium articles and stackoverflow issues.