Indeed, it does seem rather ridiculous at face value. On the other hand, I have coworkers that run CPU-IPC bound workloads inside x86-64 docker containers on M1 macs (incurring the overhead of both machine code emulation and OS virtualization). I have other coworkers sweating for hours whether to use 32-bit or 64-bit integers for APIs designed for microcontrollers running at 300Mhz. I have even more coworkers writing stuff in rust because it's "memory safe" and "so fast", but they have no idea that they're doing thousands of unnecessary heap memory allocations per second when I naively start asking questions in a code review.
Even really smart, capable people in general have really poorly calibrated intuition when it comes to the intrinsic overhead of software. It's a testament to the raw computational power of modern hardware I guess. In the case of AWS, it's never been easier to accidentally a million dollars a month.
> AWS Step Functions charges users per state transition
Apparently they didn’t know about the EXPRESS execution model, or the much improved Map state. The story seems to be one of failing to do the math and design for constraints rather than an indictment of serverless.
I have to agree with others - it is amazing this article saw the light of day.
Over 15 years ago now, I was an intern at Toyota. We were working with an in-house python based framework for doing cool/terrible drive-by-wire things with test cars.
I had a project to work around a bottleneck of the framework. It could only process about 70 CAN frames per second before running out of CPU. The vehicle's CAN bus had several thousand per second, though. At the time I was able to fix the problem by adding filtering to the CAN adapter's kernel module.
A couple years later, I worked on replacing the python based framework with C++. I discovered the underlying root cause of the bottleneck. Someone (cough my manager) had figured out a very "pythonic" way to extract bit-packed fields from the 64-bit CAN frame payloads. They converted every 8-byte payload buffer into a canonical binary representation, i.e. ascii strings of 1's and 0's. They then used string slicing syntax to extract fields. Finally, they casted the resulting substrings back to integers. Awesome!
I've since used python many times to process CAN frames in realtime, scaling up to thousands of frames per second without the CPU breaking a sweat. One trick is to use integer bit shifts and masks rather than string printing, slicing and parsing...
Horribly inefficient code is a wonderful thing at a small scale. The faster you solve your problem, the sooner you can solve the next problem.
I once threw together a mylar balloon helium blimp in the shape of a Dragon space capsule. My goal was to fly it over the cafeteria crowd at SpaceX during the C2 launch. For control, I used the PCB of a travel wifi router. I soldered three small DC motors to its LED outputs. The embedded software consisted of something like:
nc -l -u -p 10000 | bash
I then connected my laptop to the access point and ran a python script that would send UDP packets containing shell commands to toggle the LED GPIO pins based on arrow keypresses.
The crowd really enjoyed the novelty. After the excitement was over, I flew it around some more in the cafeteria. Elon Musk walked up to it floating in the air, paused for a few seconds, then looked around the room trying to find the operator. I was just like any other employee hanging out at a table casually typing on my laptop, though.
Good times. On my last day there I still had a helium tank under my desk. So, I filled up a life-sized Elmo balloon (a left over prototype), then let it float up into the rafters of the office. It was presumably up there for a month or two.
> For control, I used the PCB of a travel wifi router. I soldered three small DC motors to its LED outputs. The embedded software consisted of something like:
> nc -l -u -p 10000 | bash
That's a neat idea. Did you have to flash it with a custom firmware or do they typically come with netcat etc installed?
You would probably do a little bit of research after seeing the performance of your code. It's one thing to code the prototype sloppily, it's another to push it to prod.
Lots of opportunities short of rearchitecting: use batching; use multi threading in lambdas; use S3 range requests; use the EXPRESS execution model; etc, etc
Even really smart, capable people in general have really poorly calibrated intuition when it comes to the intrinsic overhead of software. It's a testament to the raw computational power of modern hardware I guess. In the case of AWS, it's never been easier to accidentally a million dollars a month.