Nope.
Ask HN: Have you shipped anything serious with a “serverless” architecture?
21–30 of 207 posts
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#22Yes, at my last company we needed to generate Open Graph thumbnails that composited several images together. We decided to use a serverless architecture that basically shelled out to an ImageMagick command and then pushed the thumbnail to S3 which was served via a CDN. The main problem we ran in to was a lack of processing power, but the new options from AWS solved our issues. I'd definitely do it again.
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#23Yes, our entire email attachment -> image processing pipeline is serverless on Lambda, written in JS.
So far, we love it. It handles roughly 20k images a day.
You are right that Cloudwatch logs are a hassle. So we pipe all of the log events into Scalyr (and log JSON objects, which Scalyr parses into searchable objects).
In terms of error handling, Lambda retries once on exception. So we raise exceptions in truly exceptional cases (e.g. - some weather in the cloud prevents a file from being downloaded or uploaded). We have Cloudwatch alerts that notify the team for every true exception. Happens less than once a day.
In pseudo-exceptional cases (e.g. a user emails an invalid image), we simply log to Scalyr with an attribute that identifies that the event was pseudo-exceptional, and then set up Scalyr alerts to email us if the volume of those events goes above x per hour.
tl;dr - Cloudwatch + Scalyr with good alerts and thoughtful separation of exceptions from pseudo-exceptions is my recommendation!
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#24I have spent the last year and a half building a completely serverless production service on Lambda, API Gateway, and DynamoDB (along with the standard auxiliary services like CW, SNS, Route53, S3, CF, X-Ray, etc.). It was a lot of work establishing new patterns for many of the operational aspects, particularly custom CW metrics and A/B deployments with Lambda traffic shifting, but in the end everything is set up nic…
Excellent writeup. Are you serving client web traffic (if applicable) via Lambdas? Or deploying your web infrastructure to traditional instances managed through CF?
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#25Key parts of https://auth0.com is built on top of their public serverless offering Extend serving 100M+ authentications/day.
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#2699% off our sas analytics frontend is backed by aws lambda. I love not worrying about underlying infrastructure. We have close to 150 lambdas running our api. We do not use api gateway instead we use apigee. For logging we built a logging module that logs to kinesis then to s3 and elasticsearch. Hardly ever look at cloudwatch, those logs get expensive after a while so we only keep 3 days. We use node, python and java depending on needs. It's a good idea to benchmark your lambdas and determine the resource size, a little bump can have a dramatic difference in execution time but after some point you are just wasting $$$.
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#27Earlier quoted context omitted.
Lot's of empty claims. > some serious shortcoming and a lot more work needs to be put into these serverless platforms Not actionable at all > The approach they're taking I don't think will last No reason given > It really needs a redesign/restructure Nothing here too > And maybe they'll improve it enough by then to make it viable What makes it (un)viable?
That's fair. I'm the founder of a company building a serverless platform. I didn't want to write specifics because it may reveal details about our approach.
That sounds like a very pertinent thing to disclose when offering a critique of a competitor, particularly when you're not able to substantiate (for legitimate reason or otherwise)
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#2899% off our sas analytics frontend is backed by aws lambda. I love not worrying about underlying infrastructure. We have close to 150 lambdas running our api. We do not use api gateway instead we use apigee. For logging we built a logging module that logs to kinesis then to s3 and elasticsearch. Hardly ever look at cloudwatch, those logs get expensive after a while so we only keep 3 days. We use node, python and java…
Your last point is very important. At the very least start with comparing your function running with what it needs and then maxed out. Don’t forget warmup time.
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#29I have spent the last year and a half building a completely serverless production service on Lambda, API Gateway, and DynamoDB (along with the standard auxiliary services like CW, SNS, Route53, S3, CF, X-Ray, etc.). It was a lot of work establishing new patterns for many of the operational aspects, particularly custom CW metrics and A/B deployments with Lambda traffic shifting, but in the end everything is set up nic…
Excellent writeup. Are you serving client web traffic (if applicable) via Lambdas? Or deploying your web infrastructure to traditional instances managed through CF?
Yes, we're serving client web traffic directly with Lambdas via API Gateway. We have no traditional instances or non-serverless components of any kind in the core stack.
Re: Ask HN: Have you shipped anything serious with a “serverless” architecture?
#30My uptime monitoring project uses AWS Lambda heavily, almost exclusively https://apex.sh/ping/ — it has been great. I've processed 3,687,727,585 "checks" (requests really) with it, and I only had roughly 1 hour of downtime two years ago in a single region. Since then it has been stable.
I have 14 or so regions so doing the same thing with EC2 would have considerable overhead, though I can still imagine many cases where Lambda would not be cost effective, but its integration with Kinesis is fantastic as well, stream processing almost cannot be easier, and while people say Kafka is more cost-effective, with a bit of batching you can get a long way with Kinesis as well.