181–190 of 291 posts
66$ for running a AWS Lambda with 128 for a year seems very expensive.
If you're running at 100% of the time, don't use a Lambda. If you're running for 10 seconds a day, a Lambda is cheaper than owning your own hardware. Similarly, if a car rental costs $20/day, it would be silly to say that that's expensive because it will cost you $73,000 after 10 years. The needs of a car rental and car ownership are different.
agreed.
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
Earlier quoted context omitted.
Today, for a nonstop workload you might save money with Fargate or ECS.
Yeah, I'd be curious to see how much money we'd save with Fargate.
Someone mentioned step functions above. All of our steps run on spots. We also have some tasks like you have that read off queues and do processing, which also all run on spots.
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
Your lambda function can be a container
Earlier quoted context omitted.
From the research I did, here's how languages stack up in Lambda runtime (lowest first): 1. Python & JS 2. Go 3. C# & Java I couldn't find any data on Rust. The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime…
I’m not sure I’m interested in a hello world benchmark if it takes Python 5 seconds to import its dependencies in the real world.
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
The lock-in comes more with the other AWS products you end up using such as CloudFormation and DynamoDb, but not Lambda which in most cases can be wrapped around an Express server or similar and could be hosted anywhere
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS
I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.
Dependencies for the dynamic languages matter A LOT! Take a look at what it'll cost you for requiring the AWS SDK in Node.js, for your cold starts https://theburningmonk.com/2019/03/just-how-expensive-is-the...
Personal benchmarks puts Rust as the most optimal language that I've tried to run on AWS Lambda so far.
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
After using lambda quite a lot recently I think the vendor lock-in argument is overstated, especially with things like Serverless framework. The lock-in comes more with the other AWS products you end up using such as CloudFormation and DynamoDb, but not Lambda which in most cases can be wrapped around an Express server or similar and could be hosted anywhere
All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…
The perceived lock-in is really no different than consuming other technologies. You make a trade-off on what you want to manage vs. handoff to a managed service. For many customers the benefits are well worth it.
It's fine that Lambda wasn't for you, but you aren't being clear here about what issues you saw, just waving the lock-in boogey man so many misunderstand.