Team and I moved the entire application to “Serverless” ahead of the festive season. Time to see what the scaling hype is all about 🌝

  • 3
    Scaling as well as:
    Fault tolerance
    Pay for resources
    Developer productivity
    We've been using AWS services in a serverless architecture for the last 3 years and it's pretty sweet
  • 3

    "Serverless" does NOT give you:

    - Inherent fault tolerance
    - Inherent availability (what do you even mean? your lambda functions work even if lambda is down?)
    - Lower costs (quite the opposite)
    - Developer productivity only if you're writing Johnson & Johnson's Baby's First App code. Try to debug a sufficiently large application with lambdas. You're going to aggravate your development team.

    Also, functions "scale" because the infrastructure is already scaled (that's the service that AWS provides). Autoscaling on its own is usually buggy, overprovisions and is a really hard science to get right.

    I cannot wait for "serverless" to die.
  • 2
    @junon disagree
    If my lambda function dies or the server it runs on then AWS will bring up a new instance and I don't have to do anything.
    If an availability zone (data centre) in AWS goes down, it automatically switches me to another one. I don't have to do anything.
    My entire compute, database and build costs (as well as everything else to make an application run) was about 130$ for 6 months. I paid 0.01 over that time for lambda. For a better comparison you have to include how much you pay full time server admins (total cost of ownership).
  • 1
    Of course there are challenges with serverless development but I don't they are insurmountable and it's a relatively new thing to be doing. Tooling around debugging, monitoring, etc. will only get better. The developer experience can be a bit frustrating at times but I really think it's worth it for all the 'free' stuff you get
  • 1
    One last point...
    FaaS does not equal Serverless. It's the combined architecture of using services from by the cloud provider (or a third party like twilio or Auth0) to do all the things you would normally be configuring yourself. Email, queuing, event bus, logging, etc.
  • 3
    Your false dichotomy of "serverless or full-sysadmin-team" is nonsense.

    As an architect, I don't buy anything you've just said.
  • 2
    There's a lot of workloads that don't sync well with FaaS. Ideal workloads are those that hold little state and complete quickly.

    Full services in FaaS/Dynamic infra? I've seen it eat my lunch on jvm spin up/spin down, and the rates aren't great for sustained workloads. The scale units generally don't mesh well with the workloads I need. I use a blend of EKS with lambda as glue code.
  • 2
    @SortOfTested totally agree. Can't use serverless solutions or patterns for every use case.
    I just fear that some people haven't understood it properly and instantly dismiss it (@junon) based on biases without a reasonable argument against it.
  • 1
    Serverless is a very poorly defined term IMO. It doesn't mean that there's no server, or that it will scale better, or anything like that.

    For developers, serverless would mean that there's no server *maintenance* to worry about. That is someone else's job, somewhere else.

    It may end up being more expensive than doing it yourself, but a hosting provider or whatever will likely be better at doing the maintenance. But scalability.. there's only so much you can do with an arbitrary piece of code that needs x resources. Memory? You can only scale it vertically really, i.e. just add more. CPU? If your application is serving x amount of requests and takes y amount of time for it, your CPU might need to be upgraded too.. that upgrade path is very finite. Maaaybe you could deploy another node that does exactly the same and then load balance between the 2 to make it possible to scale horizontally. Serverless or not, those are probably things you'll have to think about.
  • 0
    Interested to know why you changed to Serverless?
    How long did the full switchover take?
    Which cloud provider are you using?
    What patterns did you use?
    What issues did you have?
  • 0
    @dan-pud Don't insult me. I never insulted you. I know about FaaS quite well. I worked at a very well known company designing, from scratch, the system that ran functions.

    They are not feasible for workloads beyond the simplest of applications.
  • 2
    @dan-pud Our team did a cost analysis and decided that serverless is going to be cheaper in the long run.

    It’s a niche B2B payments app and the usage patterns often peak during festivals and certain externals events. So it wasn’t exactly a constant workload. Thus it made sense to try out serverless.

    We were on IBM cloud before so had to migrate almost everything to the AWS ecosystem (Cloudfront + S3 + lambda + dynamo). This all started at June this year. ~5 months.

    Endpoint config was PIA, had to hack a lot of systems to reduce time-outs/latencies. We still don’t have a proper devOps workflow, just hacking things as we go along. Oh and testing the full app was tricky as hell.
  • 0
    I'm assuming you were using API Gateway for your endpoints? REST or HTTP?
    Did you use swagger?
    What about cloudformation?
    For the testing did you find anything that worked well in the end?
  • 0
    @dan-pud Most of it is RESTful , the legacy integrations have HTTP endpoints (we didn’t touch this) and we did use cloud formation of course but not swagger. There are a set of in house tools that are roughly alternate to swagger.

    As for testing, it was and still is a bunch of unit tests using local stack and few integration and smoke tests. I’m not a part of QA team but know that they sell haven’t found a good workflow.
Add Comment