4
13 Comments

Looking for directions on Serverless paradigm

Hey all, I'm looking for some general advice from those experienced with backend infrastructure development.

I'm currently working on a audio product/platform, I soon need to start developing the backend API which will be called from my JAMstack frontend and possibly a mobile app.

I know my way around AWS, Docker, ffmpeg, message brokers, DBs, etc. so my natural tendency would be to deploy an auto-scaling Kubernetes cluster but I feel like it's going to be a lengthy and complex process to get it working.

It seems like serverless is a good alternative to managing infrastructure via Kubernetes, can you guys share any gotchas and general advice on it?

Specifically:

  • Pros vs. cons
  • Cost differences in maintaining both kinds of infra.
  • Comparative learning curves
  • Pitfalls, caveats, gotchas, etc

Thanks,

  1. 4

    If you've never done serverless, there's a relatively steep learning curve, and it can be a lot like whack-a-mole... solve one gotcha, out pops another.

    If your load is very intermittent, serverless can be more affordable, but IME, the opportunity cost is too high if you don't have a solid reason to use a serverless approach, especially if you aren't comfortable with it. Generally speaking, you'll need (to potentially pay for) more services to support your serverless infra(monitoring, logging, etc).

    Pitfalls/caveats/gotchas of serverless include, but are not limited to, a fairly opaque interaction with your runtime, limited/expensive time to run, and "warm up" time.

    By comparison, you can KISS, and spin up a lone server for <$15/mo and throw your entire stack on a single box while you're building/validating your offering. Then when scale becomes an issue, start exploring serverless as a solution, to take the burden off that lone box.

    1. 1

      Are there any good sites to get lone servers for this price?

      1. 1

        Countless options really... AWS, Digital Ocean, Linode, Vultr, Heroku, etc, etc, etc.

    2. 1

      By opportunity cost, do you mean the one from having to later migrate to a more full-fledged (i.e. non-serverless) approach?

      1. 4

        No, I'm more referring to the cost of lost opportunities you incur by sailing in unfamiliar waters.

        In other words, by spending time learning a new methodology, you're losing out on other opportunities, like, finding market fit for your product, building the right features, or spending time with your family.

        If your motivation is to learn serverless, then dive in. If your motivation is to get to market, then go with what you know.

  2. 1

    I'll kinda go against the grain of what it feels like the current responses are saying and I'll say that I think going serverless can be a great, simple, quick way to go, and if you learn it now, you'll have it in your back pocket for anything in the future. The fact that you know your way around AWS, Docker, etc. shows that you likely have enough chops to not have too bad of a time figuring it out as you go and you might likely enjoy it.

    Just to give some background, I've been working with Lambda (nodejs) for the past few years and prior to that just straight node/express/hapi/etc. and I think the harder part with all of it is deciding on a direction for frameworks and whether or not to do GraphQL vs REST, typescript vs js vs go vs python, stuff like that rather than what metal it's all running on. Could you likely spin up a quick ec2 instance a lot faster than getting the same thing running on a Lambda? Yeah, the first time probably, because you've likely done it before, but after you've deployed to Lambda once or twice, I think it's actually simpler and faster. Especially when using the Serverless framework - http://serverless.com/

    After all is said and done, it comes down to what you're already comfortable with, what you'd like to be comfortable with, and whether or not you have a desire to try something new for this project or not.

    I'd say give serverless a shot, at worst, you could always easily move it to something "standard" later on if you decided to.

    From a scale and cost perspective it has been great for me. This is for an app with 10s of millions of monthly users and close to 100 million monthly sessions and almost a billion pageviews from both mobile and web clients. All hitting a lambda that I never have to think about. I'm a fan.

    I will however also say, don't over-engineer a non-existent product. Been there, done that, wasted countless hours. Build what you need today for your MVP and adjust as you go.

    1. 1

      I'm a sucker for contrarian opinions. 😉

      Honestly, my top priority will probably be minimizing compute costs, so whatever approach can save me from AWS killing my budget will likely be the way to go.

      This probably merits its own separate question but what budgeting/estimation approach did you use initially back when you didn't yet have PMF?

      1. 1

        We did a bit of cost analysis using Amazon calculators and our own spreadsheets, but at the end of the day it was a bit of a roll of the dice because we were going from REST to GraphQL, so our API footprint was entirely different. In the end, we're saving a good bit, but a lot of that is also because of how big our infrastructure was before with redundant hardware across the board - firewalls, hypervisors, network storage, etc. We were able to replace it all with standard AWS services while maintaining and increasing security and redundancy. I know, sounds like an ad for AWS, just happy with how it simplified things for us. Interested to hear more about your audio project. I was in the pro audio manufacturer and software world for many years.

        1. 1

          That's encouraging to hear. My project is in stealth mode ATM but it's an audio platform catering to music producers. My experience with audio comes mostly from implementing media tanscoding pipelines for a video streaming service that got acquired a few years ago. Happy to connect and tell you more if you're interested, you should be able to find my email on my IH profile.

  3. 1

    Thanks all for the great feedback. I guess the main motivation for my question was avoid going in an overly-complicated direction when there was some other no-brainer-kind-of approach available that I was ignoring.

    So far, from my (very limited) research it feels like serverless can be pretty constraining. I rather have more control on latency, tracing, perf, etc. even if it takes longer to implement.

  4. 1

    Since your product doesn't even exist yet, don't worry about serverless. Toss up a Rails app and validate your idea.

  5. 1

    From your words I understand that you intend the two choices to be disjointed. They really aren't. You can still think to deploy the infra the way you feel comfortable and slowly start to go serverless on what you think might be worth to extrapolate, based on:

    • a real advantage of having it serverless (it's not always clearly convenient)
    • non of the cons of serverless are a problem to you (cold starts, long running jobs, etc...)

    Good luck !

  6. 3

    This comment was deleted 8 months ago.

    1. 1

      Nice, thanks. 🙏🏼

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments