The same reason cloud is all the rage. It has its uses, hype is behind it and the marketing ignores its caveats.
The main issue I have with it is simple: in my experience you cannot really debug some classes of issues ("we had intermittent issues calling endpoint A from function B") and they kinda push on you a certain type of organization model so if it doesn't reflect your organization model (for example, you have centralized infra teams) prepare to be screwed.
At an higher level, it massively encourages atomization of systems, which makes them essentially spaghetti with a network you cannot debug as the sauce. Good luck, hope your company pays for honeycomb.
Because there's a lot more people working on software then people who actually understand computer systems so they have to latch on to some vendor narrative to actually be able to deliver any discernible value they could possibly derive from their parsing of blogs and pattern matching discourse that got them their overpaid job.
I love it. This could be specific to the work I'm doing though. I'm doing workflows. For each workflow I have a lambda endpoint for the REST call and then run a container that does all of it, we use a little SQS, Lambda, and Dynamo here and there, but it's just a process that runs for a while and dies.
If I was doing this on a server I would have to use some kind of distributed task runner, scale-up servers etc.. With Faregate I don't even see the servers come up and down, it's just a magic box of runtimes.
This right here is the epitome of the cloud risk: the tarpits are hidden and keep moving.
People swear by some golden happy path they found. They claim that means cloud is an amazing new frontier of platform engineering. Then they warn of the hidden tarpit they found and never seem to connect the dots.
Step Functions are AWS' answer to the question "how can we easily execute lambdas from AWS triggers as part of a Saga?"
Sagas are hard, and developers already use AWS stuff like S3 and SNS to run lambdas as part of transactions. Providing a high-level Saga service sounds like a solution to everyone's problem, but getting it right seems to be a problem too hard for AWS.
But you do not need a Step Functions to run Lambdas, specially if you don't have to run them as part of distributed transactions.
In a week, from start to production, I migrated an AWS RDS database to Cloudflare D1 behind an OpenAPI REST interface over HTTPS using itty-router-openapi [1]. This will save me at least $250 pa, plus I no longer need worry about certificates and other server admin, which really adds up.
During the process I never saw an IP address or had to deal with networking, except when connecting to RDS. The attack surface I need to look at is minimal. The only blocker was a wasted day when itty-router pushed an backwards-incompatible change, but otherwise it was very smooth.
I can now implement a new service in about half an hour and have it tested and in production within a few hours.
I always hear people talk about "it's scalable" in terms of scaling UP. To me, the value is in scaling DOWN. If you have a function that doesn't run continuously, there's value in executing it as a Lambda instead of keeping a server or Docker container up 24/7 to do the work. Same with other serverless technologies. If there is a period of time where there is complete inactivity, being able to scale to 0 is a cost benefit.
So much this. To me, something like AWS Lambdas is the best tool in the toolbox if you already run stuff in AWS and you want to offload any event handler or background task to a dedicated service. More often than not your use case will fit easily in the lambda's free tier, and you don't have to waste any time monitoring a service that rarely runs.
16 comments
[ 2.8 ms ] story [ 37.3 ms ] threadThe main issue I have with it is simple: in my experience you cannot really debug some classes of issues ("we had intermittent issues calling endpoint A from function B") and they kinda push on you a certain type of organization model so if it doesn't reflect your organization model (for example, you have centralized infra teams) prepare to be screwed.
At an higher level, it massively encourages atomization of systems, which makes them essentially spaghetti with a network you cannot debug as the sauce. Good luck, hope your company pays for honeycomb.
If I was doing this on a server I would have to use some kind of distributed task runner, scale-up servers etc.. With Faregate I don't even see the servers come up and down, it's just a magic box of runtimes.
DO NOT USE AWS STEP, it's hot garbage.
This right here is the epitome of the cloud risk: the tarpits are hidden and keep moving.
People swear by some golden happy path they found. They claim that means cloud is an amazing new frontier of platform engineering. Then they warn of the hidden tarpit they found and never seem to connect the dots.
Step Functions are AWS' answer to the question "how can we easily execute lambdas from AWS triggers as part of a Saga?"
Sagas are hard, and developers already use AWS stuff like S3 and SNS to run lambdas as part of transactions. Providing a high-level Saga service sounds like a solution to everyone's problem, but getting it right seems to be a problem too hard for AWS.
But you do not need a Step Functions to run Lambdas, specially if you don't have to run them as part of distributed transactions.
During the process I never saw an IP address or had to deal with networking, except when connecting to RDS. The attack surface I need to look at is minimal. The only blocker was a wasted day when itty-router pushed an backwards-incompatible change, but otherwise it was very smooth.
I can now implement a new service in about half an hour and have it tested and in production within a few hours.
This really feels like progress.
[1] https://github.com/cloudflare/itty-router-openapi
Repeat after me. There. Is. No. Silver. Bullet.
If you don't need to scale then great but why are you building it instead of buying it or using qi or whatever.
So much this. To me, something like AWS Lambdas is the best tool in the toolbox if you already run stuff in AWS and you want to offload any event handler or background task to a dedicated service. More often than not your use case will fit easily in the lambda's free tier, and you don't have to waste any time monitoring a service that rarely runs.