71–80 of 204 posts
I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…
Earlier quoted context omitted.
I think a lot of people have tried “serverless” and found it to present more challenges than it solves. How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? As far as I can tell, the answer is: You don’t, you use a different database. No-worries devops experiences are nothing new. See Heroku.
> How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? Exactly the same way you would with an EC2 instance...
Earlier quoted context omitted.
> How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? Exactly the same way you would with an EC2 instance...
Might not be that easy because only postgres can take a few hundreds of connections which won't work out if you have a few thousands of serverless functions? No persistent connection pools.
Wait, oops, you have state now.
I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…
Serverless is a buzzword for a distributed system you can't SSH into.
Hope DigitalOcean works to make this a first-class citizen on their cloud.
Earlier quoted context omitted.
Your right that the cold start times are not ideal. But you get a huge free request load per month. Put an uptime pinger on it and keep it warm. Or do what I do and write your functions in golang. My average cold start time is around 4 seconds. For the DB connection you put the lambda in the same vpc that the RDS exists in. Then you open the connection pool and reuse it if its active. Not that a new connection is a b…
Here's the problem. Uptime pingers work great if you have a low volume service. You keep 1, 2, or maybe 3 instances of the function warm, and you don't have to deal with cold start times. But there's 2 places that idea falls seriously flat. 1. This doesn't work if you were actually trying to build your API as microservices. You might have 60+ functions, some which call each other, and keeping them all warm is not rea…
Keeping Lambda functions warm is great until you have 2 or more requests hitting the function simultaneously. They won't queue behind the pre-warmed function, they will spin up additional Lambda containers to serve in parallel. Unless you don't expect to get concurrent requests, there's no effective way to pre-warm Lambda functions.
I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…
I think it's due to the fact that the terminology seems intentionally misleading at worst, and like a marketing buzzword at best. Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.
Everybody also knows that a wireless vacuum has wires inside it, the value prop is that the wires never get in your way. And so with serverless.
I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…
Lack of connection pooling for database connections means serverless architecture will never be used for serious data heavy apps.
Earlier quoted context omitted.
No offense but BS. What you have claimed is totally unsubstantiated, and not aligned with my experience working on highly-trafficked eCommerce applications. If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. I've also seen poorly written code written in statically typed languages. It really comes to who is writing the code, what kind of standards…
> If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. You can! You totally can. But, statistically speaking? You probably won't. Neither will I. And that's why the minimal level of guardrails I'll put up with in 2018 is TypeScript and I'd really rather have better.
But what the upstream comment said was just wrong: that because documentation and database are statically-typed, then the application must be. It doesn't really make sense. See their use of "impossible".
For example, your database types or your application types aren't what your API documentation annotates. Your docs annotate your endpoint contracts, not the implementation detail behind them.
Serverless is great, but I am really loving Zappa for Python Flask and Django development with Lambda and API Gateway. Deployed our first production tool with it and it's been working great.
do you have any strong opinions re: differences between chalice / zappa? I was looking at these two recently and ended up going with chalice as the docs seemed a bit simpler and more readily accessible.