Developers December 9, 2019

Pros and Cons of building "serverlessly"

Grant Orndorff @orndorffgrant

I'm bullish on serverless. I know the name is annoying because yes, there are still servers, but from the serverless user's perspective, it doesn't really matter!

I built Coalesce on serverless tech and wanted to list some of the nice and not-so-nice things I've experienced with the services that I've used so far.

First, a quick list of the services I'm using for the Coalesce app (everything's on AWS):

  • Cloudfront + S3 for frontend hosting
  • Cognito User Pools for authentication
  • DynamoDB as the main database
  • API Gateway Websockets + Lambda for the backend connectivity and logic

Also, the marketing site is on Netlify.

Pros

  • Lack of server maintenance (this is the big one).
    • I basically don't have to worry about uptime. Even if something does go down, there's nothing for me to do except wait for Amazon to get it back up.
  • Performant and scalable out of the box.
    • Lambda cold starts aren't an issue any more (in most common scenarios, including mine).
    • Cloudfront + S3 is cheap and fast hosting that can serve globally (though I only have US & Canada turned on right now for Cloudfront).
    • DynamoDB is fast at scale as long as you architect the keys and indexes well.
    • API Gateway Websockets are the least battle tested on the list, but so far, they seem to provide all the benefits of websockets without the pain of dealing with them manually.
  • Insanely cheap at small scale.
    • Coalesce will run basically for free until I start getting more users.

Cons

  • Awkward development.
    • I settled on keeping a dev deployment running at all times that I develop against. I'll probably try to get everything running locally again at some point, but it was too painful last time I tried (specifically, Cognito and API Gateway Websockets make it hard for my app).
    • This can also make problems hard to debug. Generous logging helps.
  • Complicated architecture.
    • There are just more pieces than your average rails app that all have to work together nicely, and it gets complex quickly. Using infrastructure as code tooling helps a lot. I'm using serverless.
  • Documentation can be hit or miss
    • Netlify has great docs and Amazon has pretty good docs. My biggest pain point has been figuring out how to accomplish things in cloudformation since it seems that the cloudformation support is always a cycle or two behind service features.
  • Might get expensive at scale
    • These services will probably cost more than a traditional app would at some scale, but I haven't reached that crossover point yet.
    • I won't have to worry about this for a long time probably.

What other Pros & Cons did I forget? Do you think the tradeoffs are worth it? I've only used AWS really; how do GCP/azure compare and what other services should I be looking at?

Also, I wrote about the benefits of "serverless" on founder and user peace of mind on the Coalesce blog https://www.coalesceapp.com/blog/serverless-how-i-sleep-at-night/

  1. 4

    As a self-taught developer for the purpose of building my own web apps, the whole concept of serverless has been a godsend and probably the reason why I dared take the jump to get out of the noob-friendly Wordpress ecosystem and now developing my own MVPs and products with much more freedom.

    The reason is because I've had HUGE nightmares with managing my own servers (on Linode) and the plethora of configurations, threats, maintenance, and costs to worry about. I guess "managed hosting" was an option, but even that has a lot of pitfalls and the costs are not negligible.

    So I've been working in the Firebase ecosystem and I absolutely love it. So far using Firestore for the DB, Cloud Functions for some logic, and Cloud Scheduler for the odd cron job . Hosting is done on Netlify. So far it's all free and I've modeled it so that the site would have to get super popular to even have to pay a penny. Analytics, performance monitoring, authentication can all be added in literal minutes. There's so much more available in the ecosystem and constantly being worked on by super bright minds and you as a user don't have to worry about any of it and can plug-in to different services when/if the time comes if you wish.

    Sure there's vendor lock-in, things could get expensive at scale, and you're at the mercy of these company's whims...but for indie hackers these should be really far down your list of concerns.

    I personally think it's the future, if not the present, and while its cumbersome to develop for certain types of apps (currently) for others I think it's a no brainer, especially for the indie hackers out there who aren't backend wizards. I see 3 tiers of development: no-code devs, serverless devs, and monolithic devs - and I really like the middleground that serverless offers.

    1. 1

      I have also been playing around with firebase/gcp recently for one of my project. It's so cool.

      I have a question here - why netlify when firebase itself has hosting?

      1. 1

        I set it up so that whenever I push commit to private Github, Netlify automatically deploys it. It's really awesome, Firebase probably has a similar feature but haven't gotten around to it yet. I actually recently looked into Firebase hosting and like how easily you can roll back previous versions as well so might end up going with them when I fully launch... If anyone is looking for content ideas, comparison between these cloud hosting providers would be awesome!

  2. 4

    I'm not a huge fan of bootstrapping up starting with server less. Its always been my experience that the best use cases for server less / micro service architecture show up when you begin having difficulty scaling one aspect of your design. In general, this is usually a good problem to have.

    At early stage, I prefer to be able to share code throughout my architecture and keep my time available for rapid feature development if needed. If something needs to get broken out into a micro service - Great! That means people are using the product.

    You said "I basically don't have to worry about uptime. Even if something does go down, there's nothing for me to do except wait for Amazon to get it back up." - but it's important to note that you can still be the reason you are down when using server less (bad db migration, poor deployment, failing logic, etc).

    1. 1

      I would love to hear your thoughts on an article of mine: https://www.pheuberger.com/serverless-for-startups/

      I think serverless is already great before running into scalability issues.

  3. 2

    The biggest con for serverless is state. If you can model everything as stateless event-driven functions it will work well. If you're building something very stateful it's going to be a bad fit. There's a couple projects out there that are looking to pull out a lot of common code that microservices and / or serverless functions need : https://cloudstate.io/ and https://dapr.io/

    1. 1

      Have you heard of AWS step functions? They're fully supported by the serverless framework and the ideal way to implement state machines and great visibility into your workflows when running on AWS. https://aws.amazon.com/getting-started/tutorials/create-a-serverless-workflow-step-functions-lambda/

      1. 1

        I haven't looked at those before. Interesting. Unfortunately I'm unable (at my current job) to tie anything directly to AWS-specific features.

        1. 1

          Gotcha! Yeah, in this case you have to rely on 3rd party services.

  4. 1

    I've started to use Netlify functions for our live streaming app and haven't noticed any performance related issues. I'm beyond ecstatic about the time-to-deploy that comes with using Netlify compared to us managing our own deployments with Django.

    With that being said, I've not had any experience with large functions or running them at scale yet as we only have a few users.

    As I mentioned, the biggest upside is how simple to setup, develop, and deploy our API is now.

    1. 1

      That's great to hear! I haven't tried out Netlify's functions yet but I'd like to play with them.

      1. 1

        I'd highly recommend trying them out. Their cli literally allows you to write code, netlify build, then netlify deploy. Wayyyy easier and more refined than many options out there.

  5. 1

    While it may be cheap early on, it can be extremely slow to startup your functions. To the point of degrading the customer experience. The biggest risk, in my opinion, is the underlying mindset of pre-optimizing for scale. So many startups I’ve worked with have fallen into that trap.

    1. 1

      There are ways of mitigating against cold starts in serverless. Some cloud providers allow you to keep functions warm for a fee. Use of caching can help. Or you can easily write a scheduled task to 'hit' the function periodically to keep it warm.

    2. 1

      Totally agree about the worthlessness of pre-optimizing for scale and I'm definitely a victim of that mindset to some extent. I have learned a ton about this tech though, which makes it fun and worth it for me.

      I haven't run into slow startup times. Even cold starts are <1 second. I used to have my lambdas in a VPC and experienced 3-4 second startup, but I've heard AWS has brought that down a lot recently as well.

  6. 1

    GCP serverless (Cloud Run) specifically is very good for running your apps. It lets you run any docker container. Very easy to work with and deploy. I have my product running on Cloud Run + manager MySQL on GCP and it's been great. Previously I ran on my own VM on GCP, it worked well but I did not want to worry about server going down and dealing with SSL certificates. I haven't tried serverless stack on AWS thus can't really compare.

    My suggestion, use what you know. You can spend way too much time trying to figure out how to use a certain stack. Also, think if you really need all these technologies such as DynamoDB that have very specific use cases. Why not use RDS instead of DynamoDB? It makes you application much easier to run locally for testing also and can move between cloud providers if needed later.

    1. 2

      Cool! Yeah Cloud Run looks like the GCP equivalent to AWS Fargate - I can't comment on how they compare since I haven't used either, but I also strongly considered going down the "serverless container" route. It's cool to hear that you've had a good experience.

      I also like the suggestion of using what you know, especially if your optimizing for time-to-MVP. For me personally, I need new things in the mix or I get disinterested pretty fast, so using new tech is a hedge against getting bored and not finishing the project at all.

      Specifically for DynamoDB vs RDS: for me, going serverless was first and foremost about completely eliminating ops/sysadmin work from the project. It was kind of a challenge for myself that I might have taken too far. RDS has a tiny amount of maintenance involved, basically just ensuring the instance is big enough, but that's more than I wanted. I experimented with Serverless Aurora but it was a pain (massive cold start times). Running dynamodb locally isn't that hard, but designing the data structure is certainly more involved than a typical SQL database. I'm also not worried about vendor lock-in; I just don't think it should be a concern in the early stages of a product imo.

  7. 1

    A couple of thoughts. First of all, what do you think of mostly managed solutions like Render? They're definitely more expensive than Digital Ocean or Linode, but they're probably cheaper than whatever "serverless" stack you've got (free for static sites, too!). They'd let you develop your Rails app or whatever locally and then deploy it to them and keep a simple architecture (with the important bits in version control rather than in AWS config panels).

    Secondly, I recently interviewed Derrick Reimer and he talked a bit about his new startup, StaticKit, which is basically aimed at creating a dev-friendly experience for people with static/serverless sites. You might find some useful things there...

    1. 2

      I actually haven't heard of Render and it isn't coming up in my searches, do you have a link? It sounds interesting!

      I have heard of statickit (I listen to the Art of Product podcast fairly often) and I think there's definitely room for more friendly use-case specific offerings that are an abstraction above lambdas. I'm actually strongly considering launching a small product in this space that would be complementary to something like statickit.

      (also I just subscribed to your podcast :))

  8. 1

    This comment was deleted a month ago.

    1. 2

      Awesome, thank you for the mention Alex! 🙌

    2. 1

      And yes, good point with regards to cloud to on-premise. That's pretty much the killer argument against serverless. If that's ever on anybody's roadmap, they should stay away from serverless.

      1. 1

        Not necessarily. KNative is a Kubernetes native framework / platform for building serverless functions and Cloudstate.io is building a K8s platform for stateful serverless functions. Both of those could be brought into an on-prem Kubernetes environment.

        1. 1

          Good point. I usually don't think of Kubernetes in a serverless context, but it definitely belongs.