As a software architect, I hate serverless. Not because it doesn't work, but because it forces design constraints that cripple your application. Here's why always-on servers matter.
  • ranandtoldthat@beehaw.orgEnglish
    12·
    1 hour ago

    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.

  • t3rmit3@beehaw.org
    2·
    4 hours ago

    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.

  • megopie@beehaw.orgEnglish
    9·
    13 hours ago

    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.