@chris-3335b7 That math is accurate. That “cold start” model and variable response latency is certainly a sore spot for serverless technologies like Pipedream, AWS Lambda, etc.
One option I like to suggest: if you expect your workflow to be called primarily during a certain time of the day (e.g. 9-5 in your timezone), you can schedule the warming workflow to run only during those hours.
We’re also tracking a feature here that would enable you to keep specific workflows warm / always-on if you’d like to follow.
Let me know if that helps or if you have any other questions.
Thanks Dylan. We’re currently using Autocode on client projects, but are considering Pipedream as an alternative - it looks very good.
Autocode doesn’t seem to have the cold start issue though - this is probably the one thing holding us back. We sometimes create user-facing endpoints for websites, and a 12 second wait would be a problem.
Will have a look at the workaround some more - thanks for the input.
Great, I really appreciate the feedback. Are you on a specific plan on Autocode? I know for their Teams plan they used to warm all endpoints automatically, but I’m curious if they’ve expanded that support.
Either way, this is definitely on our minds. I shared this feedback today with the team during our weekly meeting.
Thanks for coming back to me. We’re on their gold plan.
To be fair, based on the figures we discussed above, at $0.0002 per invocation we’re looking at c. $1.70 per month per warm endpoint. So to all practical purposes it’s not a cost issue. It’s more a case of having to remember to do it each time, and trying to convince a dev team to move away from the current way of working (“Wait! You have to do what?!”). But that’s a me problem.
Fwiw, Pipedream looks to give us a really strong combination of speed of development and flexibility. We’re a Shopify agency and I see it as an excellent way of rapidly developing apps to extend the platform’s capability. We’re using Autocode to do this on a couple of client projects right now, but I think PD wins out on performance (once warm, we’ve found it faster in like-for-like tests) and flexibility (we can do stuff in PD that we can’t on AC, such as switching between GraphQl / REST at our whim).