Why aren't we all serverless yet?

48 点作者 srvaroa4 个月前

47 条评论

I still find the DevEx of serverless terrible compared to the well-established monolith frameworks available to us.The YAML config, IAM permissions, generating requests and responses, it's all so painful to get anything done.Admittedly I speak as a software engineer primarily building CRUD apps, where frameworks have had decades of development. I can see use cases for event-driven applications where serverless may make life easier. But for CRUD, currently no chance.

评论 #42645839 未加载

评论 #42645810 未加载

评论 #42645850 未加载

评论 #42645835 未加载

评论 #42645840 未加载

评论 #42645878 未加载

评论 #42646041 未加载

baobun4 个月前

This misses the main factor, I think: Vendor lock-in.There is no unification of APIs - every provider has their own bespoke abstractions typically requiring heavy integration into further vendor-specific services - moreso if you are to leverage USPs.Testing and reproducing locally is usually a pipe-dream (or take significantly more effort than the production deploy). Migrating to a different cloud usually requires significant rewrites and sometimes rearchitecturing.

评论 #42645813 未加载

评论 #42646108 未加载

评论 #42650196 未加载

评论 #42645852 未加载

评论 #42645915 未加载

评论 #42646009 未加载

mg4 个月前

Because most applications have 27 active users per day and a $10/month VPS can handle 100000.

评论 #42645886 未加载

评论 #42645764 未加载

Olreich4 个月前

This article misses the most important reason to not use Serverless: Cost. It's way more expensive to run serverless than it is to run any other format, even something like AWS Fargate is better than Lambda if you keep your Lambda running for 5% of the time.The second one is even more important though: Time. How many of my systems are guaranteed to stop after 15 minutes or less? Web Servers wouldn't like that, anything stateful doesn't like that. Even compute-heavy tasks where you might like elastic scaling fall down if they take longer than 15 minutes sometimes, and then you've paid for those 15 minutes at a steep premium and have to restart the task.Serverless only makes sense if I can do it for minor markup compared to owning a server and if I can set time limits that make sense. Neither of these are true in the current landscape.

评论 #42646623 未加载

Trasmatta4 个月前

For me, it's because Rails has continued to be an excellent solution in every application I've ever needed to build, whether it's a project with 1 user or 10 million, or with a dev team of 1 or 100.Every time I try to solve a problem with anything other than Rails, I run into endless issues and headaches that would have been already solved if I just. used. Rails.

评论 #42645919 未加载

评论 #42654414 未加载

pjc504 个月前

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisibleThis is a good way to get nonfunctioning product. Or at least a lot of frustrating meetings.The thing is, "serverless" still has a server in it, it's just one that you don't own or control and instead lease by short timeslices. Mostly that doesn't matter, but the costs are really there.

recursivedoubts4 个月前

they constantly try to escapefrom the complexity outside and withinby dreaming of abstractions so perfect that no one will need to be goodbut the latency that is will shadowthe "simple" that pretends to be

评论 #42645678 未加载

评论 #42647111 未加载

tw044 个月前

Because it's more expensive for less performance with less control.If it were 5% worse performance for 7% more cost, most people would probably not bat an eye.When it can be 50% less performant for 200% more cost, eventually someone is going to say: sure there's overhead to owning that but I will be at a major competitive advantage if I can do it even just OK. And it turns out for most businesses doing it at the scale they need isn't all that difficult to get right.

评论 #42646923 未加载

评论 #42646925 未加载

dgfitz4 个月前

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible. Serverless represents just about the ultimate abstraction for this mindset.I think the answer is in the first sentence. A lot of engineers make products that don't touch the internet. This concept is lost in the noise quite a bit.

badlibrarian4 个月前

Because we use Nix recipes to deploy our Datalog-ish backend connectors that talk to Amazon Elastic Beanstalk via a bespoke database we wrote in Julia that's deployed on Snowflake Container Cloud. But there's a missing backslash somewhere and nobody can find it because even ChatGPT cannot decipher the error messages.Maybe it's an expired certificate but the guy who knew how that stuff works built a 12,000 line shell script that uses awk, perl, and a cert library that for some reason requires both CMake and Autotools. It also requires GCC 4.6.4 because nobody can figure out how to turn off warnings are errors.

评论 #42645923 未加载

pluc4 个月前

Because serverless doesn't exist. Serverless just means it runs on someone else's servers, just like the cloud. And 10 years down the road people have forgotten how to run basic things, but Bezos buys Panama.

评论 #42645798 未加载

评论 #42645825 未加载

评论 #42646732 未加载

评论 #42645863 未加载

crzylune4 个月前

Serverless doesn’t mean no-server. It means someone else’s server. Their system. Their rules. Their way or the highway. No thank you.

评论 #42645954 未加载

评论 #42645953 未加载

fabian2k4 个月前

Simple monoliths are much easier to reason about and debug. And the costs are much easier to estimate.Serverless functions are quite interesting for certain use cases, but those are mostly additions to the main application. I'd hesitate to build a typical web application with mostly CRUD around serverless, it's just more complexity I don't need. But for handling jobs that are potentially resource intensive or that come in bursts something like Lambda would be a good fit.

qaq4 个月前

How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.

评论 #42645831 未加载

评论 #42645718 未加载

cesarb4 个月前

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible.We don't make buildings from Lego blocks. We do use modular components on buildings (ceramic bricks, steel beams, etc), but they are cemented or soldered together into a monolithic whole.In my opinion, "serverless" (which, as others have noted, is an horrible misnomer since the server still exists; true "serverless" software would run code exclusively on the client, like desktop software of old) suffers from the same issue as "remote procedure call" style distributed software from back when that was the fashion: introducing the network in place of a simple synchronous in-process call also introduces several extra failure modes.

tzury4 个月前

1. Speed 2. Price 3. Vendor locked-in* <a href="https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/" rel="nofollow">https://einaregilsson.com/serverless-15-percent-slower-and-e...</a>

callamdelaney4 个月前

It's not appropriate for high compute / long running workloads. Eg video transcoding. It's more expensive. Potentially higher latency.I worked for a company once whose entire product was built on hundreds of lambdas, it was a nightmare.

darthvervet24 个月前

Because tools like lambda are expensive Because it locks us into a cloud provider Because the architectures tend towards function explosion. Think CommonFuntions.java but all the calls are on the network. What could have been 2 containers and rabbitmq has become 50 lambdas and 51 sqs topics Because distributed observability is hard The ESB people became serverless function people and they brought their craziness with them. Im busy cleaning up what should be a fairly simple application but instead it has 300 lambdas. All that said, serverless managed services like databases are useful.

Saris4 个月前

For what I need it sounds overly complex and expensive, when a $5/mo VPS works just fine.Any time AWS is mentioned I know it's going to be some huge expensive setup.

zelon884 个月前

"Look at how streamlined our organization is. We have no infrastructure to manage!" -IT Director with 206 different contract renewal dates.

moi23884 个月前

You pay per compute, and thus you have unpredictable costs. People and businesses don’t like unpredictable things, we tend to avoid it.

locustmostest4 个月前

We're all-in on serverless / cloud-native for our platform (document management); it works really well for our model, as we deploy into the customer's AWS account.The initial development learning curve was higher, but the end result is a system that runs with high reliability in customer clouds that doesn't require customers (or us) to manage servers. There are also benefits for data sovereignty and compliance from running in the customer's cloud account.But another upside to serverless is the flexibility we've found when orchestrating the components. Deploying certain modules in specific configurations has been more manageable for us with this serverless / cloud-native architecture vs. past projects with EC2s and other servers.The only downside that we see is possible vendor lock-in, but having worked across the major cloud providers, I don't think it's an impossible task to eventually offer Azure and GCP versions of our platform.

anthonyskipper4 个月前

I built a serverless startup (GalaticFog) about 8 years ago, had to shut it down. Market never developed. There were some obvious lessons learned.First most companies thought they needed to do containers before serverless, and frankly it took them a while to get good at that.Second the programming model was crap. It's really hard to debug across a bunch of function calls that are completely seperate apps. It's just a lot of work, and it made you want to go monolith and containers.Third, the spin up time was a deal killer in that most people would not let that go, and wanted something always running so there was no latency. Sure workload exist that do not require that, but they are niche, and serverless stayed niche.

wink4 个月前

There's a huge grey area of "I want the response of a warmed up lambda" and "I don't have enough hits that it is actually warmed up" - pair with using certain language "runtimes" like the JVM and there you have it.

Vt71fcAqt74 个月前

>Something I’m still having trouble believing is that complex workflows are going to move to e.g. AWS Lambda rather than stateless containers orchestrated by e.g. Amazon EKS. I think 0-1 it makes sense, but operating/scaling efficiently seems hard. […]This isn't really saying anything about serverless though. The issue here is not with serverless but that Lambda wants you to break up your server into multiple smaller functions. Google cloud run[0] let's you simply upload a Dockerfile and it will run it for you and deal with scalling (including scaling to zero).[0] <a href="https://cloud.google.com/run" rel="nofollow">https://cloud.google.com/run</a>

jvanderbot4 个月前

We've looked at these tradeoffs over and over at places I work.There's always part of the stack (at least on the kinds of problems I work on) that is CPU intense. That part makes sense to have elastic scaling.But there's also a ton of the stack that is stateful and / or requires long buildup to start from scratch. That part will always be a server. It's just much easier.For my own projects, I prefer lambda. It comes with zero sysadmin, costs zero to start and maintain, and can more easily scale to infinity than a backend server. It's not without costs, but most the backend services I use can easily work in lambda or a traditional server (fastapi, axum), so it is a two-way door.

synthc4 个月前

'Serverless' has it's uses, but not for everything- Serverless can get very expensive - DevEx is less than stellar, can't run a debugger - Vendor lock-in - You might be forced to update when they stop supporting older runtime versions

helle2534 个月前

I understand the appeal of serverless, especially for small stuff (we have a few serverless projects at work, and I've built some hobby projects using Lambda), but ime DevEx is such a dealbreaker. Testing changes or debugging an issue? forget about it.Without tooling to run a serverless service locally, this is always going to be a sticking point. This is fine for hobby projects where you can push to prod in order to test (which is what I've ended up doing) but if you want stronger safeguards, it's a real problem.

demarq4 个月前

Before we all go into why lambda doesn’t work, remember that companies are happily handing many many millions of dollars to AWS each year, and will continue to do so for some time.

deivid4 个月前

IMO, the dev workflow is significantly worse, integration testing is harder and I don't see the value on "scale to zero", when the alternative is a $5/mo VPS.

评论 #42646486 未加载

fifticon4 个月前

The optimistic tone at the start of the article might just be a hallucinatory strawman set up. But as a probably old dog, I fail to see the allure of these technologies(*).When I read the copy trying to peddle them, to me it sounds quite like someone saying "Heey.. PSST! Wanna borrow 5000$ in cash, I can give it to you right now! Don't worry about 'interest rates', we'll get back to that LATER".When I build stuff out of 'serverless', I find it rather difficult to figure out what my operation costs are going to be; I usually learn later through perusing the monthly bills.I think the main two things I have appreciated(?), is(1) that I can publish/update functions on cloud in 1-5 seconds, whereas the older web services I also use, often take 30-120 SECONDS(not minutes, sorry) to 'flip around' for each publish.(2) I can publish/deploy relatively small units of code with 'functions'. But again, that is not quite accurate. It's more like 'I need to include less boilerplate' with some code to deploy it.. Because to do anything relevant, I more or less need to publish the same amount of domain/business-logic code as I used to with the older technologies.Part from that, I mostly see downsides - my 'function/serverless' code becomes very tied-to-vendor. - testing a local dev setup is either impossible or convoluted, so I usually end up doing my dev work directly against cloud instances.I'm probably just old dog, but I much prefer a dev environment that allows me to work on my own laptop, even if the TCP/IP cable is yanked.Oh yeah, and spit on you too, YAML :-) They found a curse to match the abomination of "coding in xml languages" of 20 years ago..

评论 #42645902 未加载

pjmlp4 个月前

> Microservices made a canonical example of how easy it is to miscalibrate that bet. Since the trend started ~15y ago,....What started was the rebranding from distributed systems.We have had Sun RPC (The network is the computer, a slogan now owned by Cloudflare), DCE, CORBA, DCOM, RMI, Jini, .NET Remoting, SOAP, XML-RPC, JSON-RPC,....Client-Server, N-Tier Architecture, SOA, WebServices,...Apparently the new trend is Microservices-based, API-first, Cloud-native, and Headless with SaaS products, aka MACH.

评论 #42655579 未加载

gchamonlive4 个月前

Shameless plug.I work for a community project that is building a descentralized orchestration mechanism that is intended, among other things, to democratise access to serverless open compute while also being cloudless.Take a look at the project at <a href="https://nunet.io" rel="nofollow">https://nunet.io</a> to know more about it!

deweller4 个月前

For anyone here struggling with AWS Amplify or AWS CDK - I recently discovered <a href="https://sst.dev/">https://sst.dev/</a> for serverless deployment.It doesn't solve all problems (tt isn't a CRUD framework) - but it does make the developer experience much better as compared to Amplify.

bdcravens4 个月前

Lack of vendor-agnostic solutions, and ridiculous amounts of configuration. It explodes complexity.

SavageBeast4 个月前

I always found the whole thing odd personally. The Venn Diagram of people who both need to run a service in the cloud AND cannot manage an EC2 instance is a seemingly small set of people. I never saw the advantage to it and its got plenty of drawbacks.

rasengan4 个月前

I think it’s all about cost analysis. That said, there are definitely some services that are worth outsourcing, like smtp, until you get to a certain size.Separately, when you factor in data privacy, your decision making tree will certainly change quickly.

jamesponddotco4 个月前

Why would I care about serverless? I love managing and working with bare metal servers.

tomrod4 个月前

Why should I be serverless? I like servers. I like containers. I like options.

hawski4 个月前

Isn't a shared host with php serverless for all intents and purposes?

bearjaws4 个月前

Because most companies have incompetent OPs and leadership, that Cargo Cult themselves into more tech debt.

umitkaanusta4 个月前

to me it seems much more intuitive to think in terms of actual servers. lambda seems like chicken nuggets but i wanna eat -say- a decent rotisserie not nuggets.

devmor4 个月前

It’s expensive. Even considering dev and ops hours.

bananapub4 个月前

it's annoying and expensive

fghorow4 个月前

It's too bloody expensive. QED.

mrayycombi4 个月前

"A death star of death stars".

JohnClark13374 个月前

Because some of us need to have the servers that the "serverless" people use.