Just an ad article. "Did you also encounter skill issues while building web applications? Try my platform."
post
My app went from a single code base that handles a million different actions to a million code bases that each handle a single action, but they still all depend on each other and still are tightly coupled, but now they're spread out across 50 disparate cloud services so maintenance effort only got worse.
I'm not an architect, but I do dislike how much of development work has AWS wrangling, dealing with the architectural hoops that are mentioned in the article
When I built Viduli
And there it is. The reason for the whole article.
Article exactly describes how I feel about next.js -ers.
So far none of them was able to explain to me why lack of connection pooling is A good thing. I doubt they even know what that is. If you build a website in server less - you might as well use php because it will beat node.js in raw speed on those conditions and you are handicapping it similarly.
Nah, anyone that pretends BitTorrent is worse than their server-based thing is just foolish
That’s a super interesting read, like, there have been a few services I used that were inexplicably awful in the exact ways described and I was bewildered by how bad it was.
Maybe I have been lucky, but I've never seen a company (including "cloud-native" ones) use serverless (code compute) like this. Lambdas only ever get used for tiny, atomic functions in my experience. Never heard of or seen someone try to do a 20-minute video conversion in lambda.
Any tool misused is a handicap, and I feel like the architecture presented here isn't making it clear that serverless code compute was ever right for this task.
For instance, if video processing is being done on a constant or consistent, non-ad-hoc basis, why is serverless being used at all? Who made that decision? If it's infrequent enough that it doesn't make cost sense to run a whole dedicated instance, why not have a Fargate node (container) or something that encapsulates the "background worker" portion of the process? That would let you have an equivalent "simple" flow as in the original process diag, but without the limitations of doing everything in Lambda.
Lambda is great for things like building SOAR flows, e.g. disabling network access to a compromised instance, taking a snapshot, pulling logs, etc. Infrequent, able to combine cloud infra and host-internal actions, and fast. That's a perfect use-case for Lambdas.
This reads as if someone doesn't understand cloud compute, iac, and so on, and just got frustrated trying to learn and explore the paradigm.
That's fine, but blaming "serverless" or aws lambda is like blaming a multicore cpu for having to learn threads and subprocceses.
Everytime I see serverless used - it's always some illiterate frontender building next.js on lambdas. Always slow as molasses, always inflexible af.
It sounds like the problem you describe is not with the concept of using serverless/faas cloud compute and adjacent services, but with the design and implementation done by some engineers you work with. That may be due to time constraints, lack of familiarity, engineering skill, or some other reason.
I've seen terrible containers, terrible vms, terrible bare metal servers. I've written good and bad myself. And yes, I've seen (and done) great implementation of serverless. It's all just tools to be used.
no comments (yet)