Hacker News new | comments | show | ask | jobs | submit login

I built a fairly large system using the Serverless "framework" on AWS. It's been running for over 8 months now with zero maintenance and zero service disruptions, with an ingress of ~50M events per day and providing a sleek ReactJS/SemanticUI frontend that the users seem to really enjoy. Being a side project, it's been relatively stress-free.

While the application is still very profitable, the cost is ~10x its implementation on traditional servers. I'm not going to argue the pro's and con's, just providing some numbers. At this point, we're working to optimize the original stack in order to reduce costs.

I will say though...honestly, working with Serverless and the AWS stack is a very pleasant experience.

Always great to see numbers. The running cost is 10X a typical deployment. Does that include any time you would have spent patching traditional servers?

Can you talk about the cost of your development time (one of the premises of serverless is increased developer productivity)?

Again, thanks for the real world numbers--always nice to see them.

The cost difference is purely based on hosting a similar stack on something like dedicated servers with OVH. However, as you would imagine, it would be far less robust unless we had a team of DevOps to manage it, and clearly that's where a big cost comes in. Although, managing a somewhat similar stack for my full-time gig, it's not terribly time consuming.

Development time was roughly the same: frontend work was identical to a standard enterprise-grade SPA app and backend is all Lambda functions, which would've been implemented similarly on, for example, NodeJS and Express (which is what as done anyway for testing).

The primary cost (~60%) is due to the high volume of API Gateway requests. (Edit: see below comment for reason and plans to optimize)


A HUGE time saving comes from being able to orchestrate AWS infrastructure easily via API and is well worth the premium in most cases. Our frontend application performs many automated management tasks of AWS resources such as S3, CloudFront, Lambda, Route53, etc... This of course does not directly relate to "Serverless," as it may be done by any application able to make API calls to AWS, however just the fact that it's possible for these resources is very appealing to a multi-hat developer with limited time on a side project.

I'd like to hear more about it too if you don't mind. I always figured the latency associated with starting up containers (i.e. what Lambda uses under the covers) would render user-facing apps unusable. Totally get it for batch processing, one-off events etc though.

We use Lambda for our event processing pipeline and also for our GraphQL API consumed by our clients (frontend management application, mobile applications, etc).

The GraphQL API is backed by DynamoDB and is served via API Gateway. The frontend was built using ReactJS and Relay. I am currently seeing anywhere from 200-450ms per GraphQL request on the frontend, which is more than acceptable as it's just a management frontend application...and of course it may be optimized using techniques such as prerendering, caching, etc...but these applications being super optimized is not a requirement.

Details on this would be great. We do a lot of serverless for content publishing and 3rd party api integration work... I’d love to hear more of how others use it at scale.

I can confirm a couple things. It seems like we spend a bit more time getting things to work as expected.

Troubleshooting can get expensive given the system disappears.

Telemetry on the lambdas needs to improve. Finding what’s eating time gets tough when you are looking to optimize. (A lot baked in to this statement but getting 800ms of compute to 400ms is sometimes important whilst staying on lambda)

Unfortunately I cannot provice much detail about the nature of the application, however I can say that we collect and process various types of events and perform automated actions based on them. The ingress begins at API Gateway, runs through a pipeline of Lambda functions, ends up in a Kinesis firehose, and ultimately in S3 for further processing. The primary cost (~60%) comes from API Gateway acting as the event ingress point, which was a design mistake...though at the time it did make things easier.

We're currently working on migrating the event collectors to a pure CloudFront based solution (inspired by SnowPlow) where the events will be submitted to CloudFront via signed GET requests and the CF logs will be streamed to the same Lambda-based processing pipeline. Doing this will eliminate almost all of the overhead of API Gateway (still required for certain events that cannot be collected via HTTP GET).

Have you evaluated x-ray for performance tuning? http://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.htm...

Mind sharing more details on the project? I'm always curious what sorts of ideas are good fits for serverless versus "traditional" web apps.

See above comments by me. Unfortunately I cannot go in to much detail regarding the nature of the application, but I've shared some extra details.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact