6 ms·

>However, if you can reduce the risk with zero cost, you should do that. Zero cost is rarely, rarely true with regards to operations. If you use non-standard p

>However, if you can reduce the risk with zero cost, you should do that. Zero cost is rarely, rarely true with regards to operations. If you use non-standard ports, you'll have to document that somewhere, or else it becomes tribal knowledge. If you don't document it, and someone leaves, how do you know how to access your servers? At the very moment you don't know how to SSH in, you've just paid the price. It's no longer zero cost. If you do document it, you must now take the time to manage the permissions to that document, figure out who needs to know, and then change access as people come and go. All of that requires time, which also has a cost. Plus all of this also has training costs when you onboard new people. Zero cost is a real thing with computer science but not operations.

derefr 6y ago
Zero net cost is certainly almost never a thing; but zero incremental cost is often a thing. To further your alternate-port example: let's say you have some instances running on Google Cloud. GCP already has a big CLI codebase that they get everybody to use, which has a command `gcloud compute ssh` for connecting to instances, which already has tons of magic built into it. It would therefore be pretty easy for GCP to add additional magic — e.g. randomizing the SSH ports of newly-deployed instances, and then publishing those ports as project secrets in a way that the gcloud CLI tool can discover and use in the `gcloud compute ssh` subcommand. The incremental cost of an approach like this is effectively zero: the DevOps folks didn’t have to build anything new to get this advantage, because they already built all the infrastructure required (i.e. spent the labor-cost you’d be spending) in the process of getting some other, earlier advantages. In a sense, setting up a platform or infrastructure that's more complex/flexible than what you require at the time, is the opposite of "technical debt." Rather than saving labor now but needing to be paid down with later labor, it requires more labor now, but potentially saves labor later. It’s a bit like paying a retainer fee: you get less than you pay for (or nothing) up front; but in return, you get things "for free" later on. "Tech equity" might be a good term for this — it's what you get when you invest labor into your tech stack.
- vsareto 6y ago
  I don't disagree, but this kind of goal post moving is how zero cost will turn into a buzzword down the line because it'll really mean zero incremental costs when referring to operations. Plus, zero incremental costs may only apply if you match the situation being presented. If not, you may have real costs associated with implementing obscurity. This evaluation of whether you will get zero incremental costs or not is a cost in itself. It's just a misappropriation of the term from zero cost abstractions and it bugs me, especially since it's being ported from compiler theory/engineering to operations, two things which rarely have anything to do with one-another. They'd be way better off coming up with "cost-effective obscurity" ideas, instead of calling this zero cost.

derefr 6y ago

Zero net cost is certainly almost never a thing; but zero incremental cost is often a thing. To further your alternate-port example: let's say you have some instances running on Google Cloud. GCP already has a big CLI codebase that they get everybody to use, which has a command `gcloud compute ssh` for connecting to instances, which already has tons of magic built into it. It would therefore be pretty easy for GCP to add additional magic — e.g. randomizing the SSH ports of newly-deployed instances, and then publishing those ports as project secrets in a way that the gcloud CLI tool can discover and use in the `gcloud compute ssh` subcommand. The incremental cost of an approach like this is effectively zero: the DevOps folks didn’t have to build anything new to get this advantage, because they already built all the infrastructure required (i.e. spent the labor-cost you’d be spending) in the process of getting some other, earlier advantages. In a sense, setting up a platform or infrastructure that's more complex/flexible than what you require at the time, is the opposite of "technical debt." Rather than saving labor now but needing to be paid down with later labor, it requires more labor now, but potentially saves labor later. It’s a bit like paying a retainer fee: you get less than you pay for (or nothing) up front; but in return, you get things "for free" later on. "Tech equity" might be a good term for this — it's what you get when you invest labor into your tech stack.

vsareto 6y ago
I don't disagree, but this kind of goal post moving is how zero cost will turn into a buzzword down the line because it'll really mean zero incremental costs when referring to operations. Plus, zero incremental costs may only apply if you match the situation being presented. If not, you may have real costs associated with implementing obscurity. This evaluation of whether you will get zero incremental costs or not is a cost in itself. It's just a misappropriation of the term from zero cost abstractions and it bugs me, especially since it's being ported from compiler theory/engineering to operations, two things which rarely have anything to do with one-another. They'd be way better off coming up with "cost-effective obscurity" ideas, instead of calling this zero cost.