4 ms·

I get the impression there is a lot of impedance mismatch between the ability to host functions in the cloud, and the tooling and ways of thinking required to m

by dash2 5y ago

I get the impression there is a lot of impedance mismatch between the ability to host functions in the cloud, and the tooling and ways of thinking required to make this work. Like, suddenly you can't just debug your code; debugging is magic and requires special tools. And you can't just use a recursive solution: recursion might literally cost you per call. Not that the shift is bad, but just that our tools and thinking haven't quite caught up to it. I get the same mismatch in a tiny way, when using Google colab to teach Python. It's very easy to get started, it solves lots of "local install" and versioning issues; but the keyboard shortcuts aren't quite there yet, and debugging might be scary.

qaq 5y ago
It is bad for most projects
musingsole 5y ago
I don't have the same experience. I run a web service hosted entirely on lambda with some static pages in S3. Your lambda application should be runnable locally. Doing otherwise is an implementation choice. Some errors related to underlying OS considerations are harder to catch unless you spin up a Lambda container...but, that's just it. Spin it up locally and do your debugging. Not magical at all. Recursion in an Lambda application is MORE powerful than recursion locally. With lambda, you have as much horizontal scale as you can pay for. Spin off 10,000 threads if you want. You're upset you have to pay for it? You always pay for it with hardware and electrical bills and time if not directly to AWS. My application uses a recursive lambda strategy as its core design. What's magical is that all of your logs exist cleanly in Cloudwatch and retention policies are easy.
- __turbobrew__ 5y ago
  Being able to run the containers locally helps, but I have hit a myriad of issues which occur in the lambda runtime, but not when running the service locally. With EC2 or ECS backed by EC2 there is much less impedance mismatch between local dev environments and prod environments which results in less surprises.

by dash2 5y ago

qaq 5y ago

It is bad for most projects

musingsole 5y ago

I don't have the same experience. I run a web service hosted entirely on lambda with some static pages in S3. Your lambda application should be runnable locally. Doing otherwise is an implementation choice. Some errors related to underlying OS considerations are harder to catch unless you spin up a Lambda container...but, that's just it. Spin it up locally and do your debugging. Not magical at all. Recursion in an Lambda application is MORE powerful than recursion locally. With lambda, you have as much horizontal scale as you can pay for. Spin off 10,000 threads if you want. You're upset you have to pay for it? You always pay for it with hardware and electrical bills and time if not directly to AWS. My application uses a recursive lambda strategy as its core design. What's magical is that all of your logs exist cleanly in Cloudwatch and retention policies are easy.

__turbobrew__ 5y ago
Being able to run the containers locally helps, but I have hit a myriad of issues which occur in the lambda runtime, but not when running the service locally. With EC2 or ECS backed by EC2 there is much less impedance mismatch between local dev environments and prod environments which results in less surprises.