4 ms·

Forgetting to kill your cloud instances and getting charged isn't a dark pattern, no more than forgetting to fill your gas tank isn't an automotive manufacturin

Forgetting to kill your cloud instances and getting charged isn't a dark pattern, no more than forgetting to fill your gas tank isn't an automotive manufacturing dark pattern, or leaving your water running in the basement sink and forgetting all winter and then having a fight with your husband just before Christmas because the water bill is $1000 and you're the only one that uses the basement utility sink but only in the summer because it is too cold in the winter...

scrose 5y ago
Forgetting to shut down an instance in the cloud is the least worrying problem. In AWS, everything has a price. And some things don’t have a price until they’re the only thing left(ie. Elastic IPs that only charge once they are not assigned to an instance). For someone new to AWS and testing things out, a closer analogy would be like moving into a new house and trying to find out which pipes are leaking
phist_mcgee 5y ago
I would say it's dark because the platform does not usually place any emphsasis in letting you know it's still there or not. There are no built in safety rails (like a check fuel light) that can help. These platforms are designed to be obtuse.
- danpalmer 5y ago
  I'd challenge these being "obtuse", I think it's more likely that they are designing for a different type of customer. As an engineer working on a production system, everything in code, etc, I don't really want an alert saying "Are you sure you still want to be running your database?". This isn't really a feature that most production systems need. What I'd like to see is features for experimental work – being able to mark an AWS account, or org, or maybe individual services/resources, as "experimental" and have it auto shut off after some reasonable amount of time, with clear warnings during use (as much as possible) that this is an unsupported experimental service. Hell, if the time limit/capacity limit was low enough, I feel like these could be a permanent free plan with cloud providers. The question is: are these customers worth designing features for? I could see why they might not be, although I think it would be beneficial to the industry.
  - SavantIdiot 5y ago
    That's a good point(s). I don't need lots of obvious messages about what my system is doing if I already understand it. However, I'd like to see a "verbose" or "-vvvv" or "DEBUG=9" for any service. I think I might be speaking from bias because I only use about 8~10 AWS services, but perhaps if I jumped into their ML stuff I wouldn't know wtf is going on. So maybe a beginner-billing mode switch would be helpful. While most new programmers don't like to RTFM (at all!) and expect a quick search of stackoverflow to solve everything, I think the number of complaints of stealth billing are SO high on HN that it appears systemic. That's not good.

scrose 5y ago

Forgetting to shut down an instance in the cloud is the least worrying problem. In AWS, everything has a price. And some things don’t have a price until they’re the only thing left(ie. Elastic IPs that only charge once they are not assigned to an instance). For someone new to AWS and testing things out, a closer analogy would be like moving into a new house and trying to find out which pipes are leaking

phist_mcgee 5y ago

I would say it's dark because the platform does not usually place any emphsasis in letting you know it's still there or not. There are no built in safety rails (like a check fuel light) that can help. These platforms are designed to be obtuse.

danpalmer 5y ago
I'd challenge these being "obtuse", I think it's more likely that they are designing for a different type of customer. As an engineer working on a production system, everything in code, etc, I don't really want an alert saying "Are you sure you still want to be running your database?". This isn't really a feature that most production systems need. What I'd like to see is features for experimental work – being able to mark an AWS account, or org, or maybe individual services/resources, as "experimental" and have it auto shut off after some reasonable amount of time, with clear warnings during use (as much as possible) that this is an unsupported experimental service. Hell, if the time limit/capacity limit was low enough, I feel like these could be a permanent free plan with cloud providers. The question is: are these customers worth designing features for? I could see why they might not be, although I think it would be beneficial to the industry.
- SavantIdiot 5y ago
  That's a good point(s). I don't need lots of obvious messages about what my system is doing if I already understand it. However, I'd like to see a "verbose" or "-vvvv" or "DEBUG=9" for any service. I think I might be speaking from bias because I only use about 8~10 AWS services, but perhaps if I jumped into their ML stuff I wouldn't know wtf is going on. So maybe a beginner-billing mode switch would be helpful. While most new programmers don't like to RTFM (at all!) and expect a quick search of stackoverflow to solve everything, I think the number of complaints of stealth billing are SO high on HN that it appears systemic. That's not good.