Comment by cloverich
4 years ago
> So we never made it self service.
I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?
4 years ago
> So we never made it self service.
I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?
Yes we advertised it as a feature to all new signups, with a link to request limits. It's not equivalent to a button, the dirty secret is that when people requested it, I planned to put a notification in my calendar to go look at their usage the last day of the month and adjust their bill accordingly. :)
We were concerned about spending time on marginal features that didn't actually matter much to people, so we "launched" it without building it to see if anyone cared.
I'm not one of your customers but when I have looked at pay-as-you-go services or autoscaling services before I basically don't even consider any that don't allow me to cap the costs per month or similar.
So you could perhaps also consider that if it is only marketed when you sign up and not a clearly defined feature some people (like me) will just never sign up at all.
Personally, I don't think that capping costs explicitly is a good idea, because it doesn't carry enough information about what to do when you hit that cap.
Not even considering something like AWS with a bazillion types of services, say you have a cloud hosting service that runs nothing but auto-scaling clusters of servers billed by the hour. So I set a cap on costs but not cap on scaling up and turn it loose. It gets a hug of death from something, scales to the sky, does serve all of that traffic fine, but burns through my monthly cost cap in an hour. Oops, now it's down entirely for the next 3 weeks or whatever. Does anybody in the world who's willing to pay for hosting something actually want that? I have to doubt it.
On the other hand, capping the scaling size by number of hosts sounds pretty reasonable. Set a cap at say 2x your normal peak traffic. You get a hug from something, it hits the cap. Most of your extra traffic gets errors or really slow responses, but your service stays up, even when the traffic dies down. Your monthly costs are a bit higher than usual, but manageable. That sounds like a much better result to me.
That doesn't even get into stuff like, oh hey we dropped your DB server because you hit your cost cap early and it costs money to keep it running and to create a new backup too, hope you don't miss that data too much!
That's actually why we made a big deal out of it in our launch post. We thought maybe it would attract underserved customers. I am surprised that it had no effect.
My guess is that people who are interested in controlling costs are also not getting enough value from auto scaling services. So we're already not attracting those folks, and offering a cost control feature isn't enough to get us over the hump.
1 reply →
I’m also not interested in this feature, but do want to say that’s a lovely example of implementing the bare minimum to gauge the value of a feature.
That was a great MVP plan for that feature! Figuring out what not to build is a great way to save development time.