141–150 of 670 posts
Earlier quoted context omitted.
I use that a lot. There's the joke lambda spackle sticker ( https://www.thecloudpod.net/product/lambda-spackle-sticker/ ) but that's exactly the great use case.
Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
I was planning on trying out FastAPI + Zappa, but have not gotten round to it yet.
Earlier quoted context omitted.
I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution…
> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.
If the next lambda invocation happens within minutes of the previous one ending, you can carry forward a db connection from the older lambda, no magic needed. Just place your db connection object in global scope (nodejs).
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
Disclaimer: I work at AWS, however not for any service or marketing team. Opinions are my own.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…
Did you chose python for backend dev? Any framework like flask or django?
Also no preference of single-language for both backend and front-end, by using node.js backend?
Just trying to get into web-dev.
Earlier quoted context omitted.
I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution…
> Serverless provides a solution for that case as well, since you have almost unlimited resources. Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic. Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
There's a couple of sharp edges still but in general it just 'makes sense'. If you don't like TypeScript there are also bindings for Python and Java, among others, although TypeScript is really the preferred language.
Only tangentially related but why haven’t Unikernels become a thing? why does every container need a unix userland? Sure, I understand people need their libc but all the other bloat? Why?
Some of it’s nice. Most of it isn’t. Here are the pros: it’s great for quickly scaling up or down, and we don’t have to worry about physical infrastructure. Here are the cons:
Documentation is inadequate. The docs are often verbose, but outdated or incomplete in critical ways. There also seem to be very few resources/blog posts about how to use big aws features. I suspect there is a secret cabal of infrastructure engineers that hoard this information.
Replication of work is difficult. So much is done through the GUI. This seems really amateurish. How do you quickly capture the state of your entire aws configuration? How do you record and track changes? We have very little insights into our system.
Every microservice is a snowflake. Why do I have to use this apache templating language for api gateway? Weird. Who designed these libraries? Why can’t I rip as much as I want out of a queue? Weird.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
Wait until you get to work with the CDK, it's worse.