4 ms·
> Use managed, serverless (defined as ‘usage-based pricing with little to no capacity planning required’) primitives wherever possible, even at the cost of func
by EdwardDiego 3y ago
> Use managed, serverless (defined as ‘usage-based pricing with little to no capacity planning required’) primitives wherever possible, even at the cost of functionality.
Erk. I get where they're coming from, but it feels like they're choosing lower AWS costs, but in doing so, incurring higher dev costs.
But maybe, that's a trade-off that makes sense for them. Would like to have more background on this balancing act - e.g., what "functionality" means to them.
The other concern I'd have is the risk of unanticipated spend, serverless techs can scale up really well, and your costs can also scale up hand-in-hand.
I guess it depends on how bursty their product is.
- throwup238 3y agoMy money is on them getting neither lower AWS costs nor lower dev costs. They're just paying out both ends because "cloud" is a thought-terminating cliché at this point.
- EdwardDiego 3y agoYeah, that's where my "Erk" came from. But I don't know what their product looks like under the hood so can't really comment further, just that "even at the cost of functionality" got my antennae tingling. Ditto the bit where "As a last resort, we write our own code". That feels like a lot of pain and YAML trying to cobble together other people's expensive code.
- Kinrany 3y ago"AWS is expensive" is a thought-terminating cliche as well.
- throwup238 3y agoAMZN ain't making its profit selling books and toothbrushes. It's all the yummy egress and all the other markups you're paying for.
- cowthulhu 3y agoWho are all these people egressing gb/mo/customer? Does everyone except me work at Netflix?
- xyzzy_plugh 3y agoI agree it's a weird thing to obsess over. I have never seen egress mentioned, let alone approach the leaderboard in terms of costs.
- rendaw 3y agoI'm not sure I believe it, but they could reasonably make profit on economies of scale that individual organizations wouldn't get managing their own hardware - merged hardware utilization, sharing engineering efforts, standard hardware procurement, etc.
- sethammons 3y agoI feel you are reading it backwards. They are increasing infra costs and decreasing eng development cost - they promote using dynamodb over making your own key value store. And if that doesn't work for some reason, then use open source, maybe foundationdb or redis. And if that can't work, then build it. Building it will take longer and system stability will almost always be worse comparatively.
- xyzzy_plugh 3y agoWhen I hear "dynamodb or maybe foundationdb or redis" that sounds like three very different projects.
- sethammons 3y agofor sure. They are all key value stores, but they are all better tailored for different purposes. The idea is to accept the limits of the building blocks you are choosing and figure out how to support your product that way. The alternative is to build the custom datastore solution which _will_ be harder than the org expects. Everyone wants a magic datastore that does everything and usually when an org tries to build their own, it fails to scale out for a multitude or reasons. I have definitely seen it work and work well -- but it always took way more effort than planned. If it is not a core competency, it is probably not worth the investment to build your own.