IT is cyclical.
Or of course world war 3 happens and the latest, greatest thing going in IT is “I mean I’m still alive, whatever that’s worth.” And making anything usable from whatever is found. Even a blinking LED becomes either neat or a way for a roving warboy to find/kill you.
killin' me smalls.
Only somebody who does not work at FAANG uses FAANGMULA, so why not just go with MULA.
Instead of renting a VM or running docker containers you rent a small physical server for each service.
That said, Lambda has been out for a while and seems to have avoided taking over the world. Generic vCPU-hours are so cheap now though that it isn't compelling from a a cost perspective (serverless will either cost you more at the high end of the scale, or else save you a few bucks a month on your idle instances at the low end). Also, the developer experience isn't as good yet IMO. Thinks like LocalStack help, but it's still not natural-feeling to deploy a big application this way. (scale-to-zero it's great for small side projects though -- I have a few apps in Cloud Run that cost me like a nickel a month, a few dollars if I have a good month in terms of traffic).
I do not know if this is solvable: a permanent service with light autoscaling handles even inconsistent load so well and reduces operational complexity so much that I don't know if serverless will be anything more than toys. It is no coincidence that AWS Lambda's first language was a frontend language* (Node.js). Those use cases have low to moderate scale (because after that you split frontend and backend).
^Amazon Prime Video post: https://www.primevideotech.com/video-streaming/scaling-up-th.... *First mention of AWS Lambda languages in AWS Compute Blog only mentioned nodejs: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
The biggest problem is that the computing model, or the architecture that is commonly required for this sort of apps (event-driven and asynchronous) is hard to develop, manage and reason about (especially with the async-lambda integrations that by default retry their work if they fail). This means that you need to think about them and architect them in a way that makes them idempotent.
If you configure everything properly, event-driven, AWS Lambda-based apps can be extremely useful. I just don't believe that the complexity required to add them to your application is worth the complexity that needs to be added to your app to make it all work.
What I wanted to say is that Lambda functions have their use-cases, and that if used reasonably, they can heavily simplify the application that they are used within.
Our product (https://stacktape.com, disclosure: Im a founder), makes it easy to deploy both container-based (ECS Fargate and ECS EC2) apps, and lambda functions, with almost no changes in the configuration). This allows our users to always choose the right technology/computing model for the use-case they are working on.
"All of this has happened before, and it will all happen again." ;-)
What about 'AI Tendrils' <-- tiny AI workers on little devices that feed the Mother AI - like an agent would monitor, but you tell it what info or behaviours are allowed and have that securly streamed back to the AI/model/LLM? (I dont know where the data would go) but then when you run your query/prompt youre running it against a much closer-to-processing-power than if you had to go query each device on a request?
--
I thought this output from GPT was interesting for thinking of the above:
https://i.imgur.com/WsxwuJh.png
and a BOM
https://i.imgur.com/5g1mXfp.png
https://i.imgur.com/MdbQKx1.png
https://i.imgur.com/Bi0PRTQ.png
--
Actually, I asked gpt to recommend additional columns, here is the result
User what columns would you suggest to add ChatGPT
Here are some additional columns that you may consider adding to the HN table:
* Display type: OLED, LCD, AMOLED, etc.
* Display resolution: the number of pixels on the screen.
* Water resistance: the level of protection against water damage.
* Heart rate monitor: whether the wearable device has a built-in heart rate monitor.
* Sleep tracking: whether the wearable device can track your sleep patterns.
* Music playback: whether the wearable device can play music and if it has built-in storage.
* NFC: whether the wearable device supports near-field communication for contactless payments.
* Voice assistant: whether the wearable device has a built-in voice assistant like Siri, Google Assistant, or Alexa.
* Other sensors: such as an accelerometer, gyroscope, barometer, altimeter, or compass.
Keep in mind that the more columns you add, the wider the table becomes, which may make it more difficult to view or analyze. So, you may want to choose the most important columns for your specific use case and audience.