171–180 of 207 posts
https://aprl.la https://itunes.apple.com/us/app/aprl-mens-clothing-network/i...
In fact, we had one of our API running in EC2 which recently migrated to cloud functions.
Used as a backend for 2 webapps , one is for viewing geospatial data and 1 for creating transport scenarios.
@ mabl (mabl.com) we've been running a serverless backend on Google Cloud Functions for over a year. It's handled 600M function calls/month without much trouble. Our findings are: * Eventually you need to promote a function to legitimate service for cost savings (e.g. GCF ️ AppEngine Node service) • You need a buffer (e.g. GCF outscales services it calls) such as Pub/Sub • Multi-repo/project layout is best for deploy…
So yeah basically serverless is just too expensive. It's cheap or free for low volume, to get you hooked, but for any "serious" service it is too expensive.
Earlier quoted context omitted.
I've felt the same way. Serverless is most appealing when you're starting out and have low traffic. It enabled us at ipdata.co to have the most global infrastructure possible with the lowest latencies at an insignificant cost. At some point I believe when we're big enough we might switch to using servers in all the regions where we currently run APIG+Lambda.
The advantage of Serverless to me seems that it already forces you in a somewhat sane design and separation of concerns so all work out into the lambda functions should be easily translatable into a different architecture.
I 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…
Does Lambda have a good version control or CI workflow? My biggest question is how to develop severless functions with a team of developers.
Earlier quoted context omitted.
So yeah basically serverless is just too expensive. It's cheap or free for low volume, to get you hooked, but for any "serious" service it is too expensive.
Developer time is the highest cost. Building and deploying a function in an hour minimizes time to market and opportunity cost. Lifting and shifting to a dedicated service like AppEngine is a "good problem to have" once the function's usage exceeded specific thresholds. However, if you never reach said thresholds (e.g. only a few thousand calls a day), you didn't spend the time/money setting up a service backed by de…
Earlier quoted context omitted.
Agreed, it doesn't make much sense hearing "serverless". Like, is data being served to a client or not? I haven't done much reading up on it but it basically sounds like someone else is hosting and executing your code?
To my understanding, it mean you write endpoints and only endpoints. You don't have to configure an OS, or even write the code that says "bind to port X and start". You just say "when you get this request, do this". Which is a neat abstraction! But there's still a server, you just don't have to manage it directly.
Earlier quoted context omitted.
Indeed, I always get the feeling you need some sort of exit strategy to a traditional model for when your service starts lifting of. Never did the cost calculations though.
That gets to lock-in. The stacks are super proprietary. Porting away from AWS to another serverless cloud vendor (e.g. Azure) would be a major project. Porting to a server-ful architecture would be a full rewrite.
I 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…
what is the business model around this - I mean 18 months to get "set up nicely" strikes me as hard to justify to upper management that is not invested already
Earlier quoted context omitted.
Indeed, I always get the feeling you need some sort of exit strategy to a traditional model for when your service starts lifting of. Never did the cost calculations though.
That gets to lock-in. The stacks are super proprietary. Porting away from AWS to another serverless cloud vendor (e.g. Azure) would be a major project. Porting to a server-ful architecture would be a full rewrite.
Edit: We also broke the stack into a number of independent microservices, each with their own API, DB, and dedicated CI pipeline. This would allow us to incrementally migrate chunks in parallel without disrupting the entire service.