He says he's using Lamda, perhaps he should rethink that decision if his overhead is really that high.
He says he's using Lamda, perhaps he should rethink that decision if his overhead is really that high.
Ping is running in 7 regions, has an Elasticsearch cluster for logging, another for the check data itself, thousands of checks running each minute and thousands of alerts running each minute. RDS for the primary store, SES for emails, EC2 for hosting the app itself. Add on extra services such as Baremetrics and these things add up quickly. Run 7 EC2 nodes and you're already well over $250, not to mention the loads in each region are different.
Lambda's pricing is indeed not competitive with VMs right now, but that will go down with FaaS becoming wildly available from other providers. The more important thing to me is that it's close to zero maintenance, no bastions, no AMIs, no provisioning, no third-party monitoring, etc.
If you've ever worked with Elasticsearch you'd also know that it requires a pretty substantial set of resources to function well. I'm happy to over-provision for the beginning if it means providing a better experience. Nothing would be worse than under-provisioning IMO.
Would you recomend starting something with a free tier and phasing it out if it's not working over charging up front from the beginning?
I can see pros/cons to both sides.
From successful bootstrappers in B2B, nearly 100% of the advice that I've gotten is to start without free and add it later as a lead-gen mechanism if it fits your business. Early on customer acquisition is a slog and generally relies on 1:1 conversations often with a pre-existing relationship (in-network). Hopefully feedback from these people help you get close enough to product market fit that outsiders will consider using the product. From there it's a marketing and lead nurturing game where freemium may make sense.
Advice for B2C would be quite different.
Typically base costs are higher when you design for scale vs when you don't. And marginal costs are lower when you design for scale vs when you don't.
And yes, that's obviously a concern, but you can design for profit first and refine for scale. It wouldn't be very difficult to put some of those things in a VM to start and then move them to lambda once breaking even is no longer an issue.