Show IH: Flex.io - Serverless Functions for the Rest of Us
Hi folks -- are there any Python or JavaScript-saavy devs here willing to take a five-minute crack at our onboarding? In beta and just updated our app and docs and are looking for constructive criticism. :)
We provide a service for stitching together functions with out-of-the-box helper tasks that take the pain out of OAuth, notifications, scheduling, local storage, library dependencies, function chaining and other 'glue' code.
While "serverless" has typically meant a scale-first microservice, we're trying to target a class of utility where rolling a server would be overkill but rolling a lambda and combining with other required pieces in the AWS ecosystem (gateway, dynamo, s3, ses, etc) would be overly complex.
So, basic examples might include light data integration between sftp and dropbox, weekly analytics report applying pandas to a google sheet, creating "server-side" web components for static sites, etc.
Any feedback would be really appreciated! Thanks a ton!
So I looked at the site, I'm not too sure I understand the use cases. I'm a developer, I've deployed to both lambda and regular VPS before, why would I use your service ?
Hi. Thanks for asking!
Flex.io is a higher-level abstraction that appeals more to developers who don't want (or are unable) to get their hands dirty with the breadth of AWS beyond Lambda, but whose applications would still be a good fit for serverless. And, like any serverless ROI, we're also assuming that provisioning and maintaining a server wouldn't make sense for the class of application.
Flex.io is particularly useful when trying to abstract or extend web services. Take Google Sheets. On one hand you might want an internal management report that takes data and formats it with pandas each week. On another hand you might want to use Google Sheets as a simple back-end for a lightweight app. Either way, to read and write to Google Sheets file system, handle the OAuth refresh token, and deliver via email notifications or API endpoint wouldn't be trivial (or possible simply with Lambda alone). But, it's all pre-packaged in Flex.io so you just have to add your function(s).
...
Let me know if that's helpful; happy to engage in more discussion as its super useful for us to help frame the product. :)
Also, was there anything in particular in the use cases that were confusing or was it more that you didn't see why you'd choose Flex.io over Lamda or rolling your own?
Thanks for explaining, I guess I found it confusing because I'm not familiar with the particular pain points mentioned on the landing page.
but hey, I guess you're solving somebody's issues. congrats on your launch !
heh; thnx!
Looks sweet. How do I get on your Hacker plan?
We're in beta right now, so its all hacker plan at the moment. :) Would love to have you try it and let me know what you think. Thanks!
(Maybe I missed the “it’s all hacker plan atm”)
But dude, you should advertise that on your landing pages and get people hooked on it while it is free.
Good feedback. It is there ("Tiers that scale with you. Free during our beta period."), but probably not super obvious. :( In general, the pricing is just best guess flag in the ground, but subject to change as we get more users and see the typical usage pattern.
Right now we see a people do a bunch of executions during testing/prototyping a pipe, but then ratcheting down to once-a-day/once-a-week type usage thereafter, once a pipe is "live".
That seems like a sensible usage pattern due to people doing rapid development before launch.
My best advice here for retention is to start identifying key metrics for people are successful and those who churn, and then start engaging with those people who start to meet those churn numbers. For example, maybe people that create 3 or more pipes have a lifetime value of $XX and are 90% more likely to upgrade at the end of their trial, while those that create 3 or less are more likely to not give you money at the end of their trial. Then create a engagement sequence for those people and learn from them how you could do better.
Agreed. So, think this is reasonable approach, but we'll see.
Totally agree. A lot of manual blocking and tackling at present to get this, but ultimately do want to turn it into something more pattern-driven.
Thnx!
This comment was deleted 2 years ago
This comment was deleted 7 years ago
This is what we're seeing too -- of course if you tried to go straight serverless akin to lambda you'd be dead. But once you need more than a solitary function via endpoint, you can start getting into technical weeds quickly. That investment would certainly make sense for for a scale-first function for a material app, but probably not for a lot of lesser needs.
We're definitely lacking on this front -- just released a bunch of tutorials and docs this week, so now trying to bring that forward to the home page. I like this idea of the 'old way' and 'new way' contrast; thanks for that. I'll think about how we might be able to present it succinctly... cheers!
This comment was deleted 2 years ago
Thanks so much; love to have you! :) All free at this point; we're just looking for feedback and constructive criticism. Lemme know if you have any questions. Thnx!