4 ms·

Noob here with some meta-questions about developer and operations complexity. From an outsider’s perspective, it looks like in a 2x2 matrix of developer simpli

Noob here with some meta-questions about developer and operations complexity. From an outsider’s perspective, it looks like in a 2x2 matrix of developer simplicity/complexity and operational simplicity/complexity, the current patterns all seem to be heavily biased for developer simplicity/operational complexity. 1. Is this assumption correct? 2. Does optimizing for another quadrant: developer complexity / operational simplicity make sense? My intuition is that complexity in code can be managed far better than complexity in operations. Developers have abstractions, reusable libraries, unit tests/integration tests, etc. There may also be weird efficiencies that arise from having developers deal with some of these problems right from the design stage. It seems kubernetes takes a problem and pushes it to fully to operations. Is there a solution that takes this problem and turns it into a developer problem?

Too 3y ago
The difficult part about Kubernetes for newcomers is that it tackles every problem at once. Large scale best-practices you would previously sweep under the rug are now things you can’t avoid addressing. Centralized logging, secret management, certificate rotation, rbac, liveness probes, rolling deployments, etc. A lot of people complaining about the complexity are doing all those things by hand instead - “just ssh into the server with a shared password, remove old logs and restart it lol”. It’s great if you actually need all of this and consider those practices essential complexity. If you don’t - it feels like someone is shoving accidental complexity down your throat. Turning it into a developer problem will not hide all these things or make them more manageable. It means you will reinvent k8s yourself, poorly.
diarrhea 3y ago
Infrastructure is, or at least should be, code as well. And as it is, you can write tests for it all the same! However, writing those tests is incredibly hard. It doesn’t matter if you approach it from a dev or ops angle. The system under test doesn’t only have side effects, it is side effects. You also cannot mock most things (in my opinion…), as that is either also very hard to instrument or straight up removes the test usefulness altogether. Imagine mocking the AWS management API for your integration tests. Not possible. So what Dev calls integration or e2e tests, ops calls the dev environment. Works, but differently to how devs would do it. I don’t see an alternative. Next, as much as knowledge siloes are being heralded as evil, they exist. Undoing siloes altogether isn’t possible. You’ll end up reerecting them elsewhere. Devs have their skill sets, and ops isn’t part of that. The opposite is also true. The intersection can be substantial, but never enough to have dev to it all alone. I don’t think that’s a bad thing either.

Too 3y ago

The difficult part about Kubernetes for newcomers is that it tackles every problem at once. Large scale best-practices you would previously sweep under the rug are now things you can’t avoid addressing. Centralized logging, secret management, certificate rotation, rbac, liveness probes, rolling deployments, etc. A lot of people complaining about the complexity are doing all those things by hand instead - “just ssh into the server with a shared password, remove old logs and restart it lol”. It’s great if you actually need all of this and consider those practices essential complexity. If you don’t - it feels like someone is shoving accidental complexity down your throat. Turning it into a developer problem will not hide all these things or make them more manageable. It means you will reinvent k8s yourself, poorly.

diarrhea 3y ago

Infrastructure is, or at least should be, code as well. And as it is, you can write tests for it all the same! However, writing those tests is incredibly hard. It doesn’t matter if you approach it from a dev or ops angle. The system under test doesn’t only have side effects, it is side effects. You also cannot mock most things (in my opinion…), as that is either also very hard to instrument or straight up removes the test usefulness altogether. Imagine mocking the AWS management API for your integration tests. Not possible. So what Dev calls integration or e2e tests, ops calls the dev environment. Works, but differently to how devs would do it. I don’t see an alternative. Next, as much as knowledge siloes are being heralded as evil, they exist. Undoing siloes altogether isn’t possible. You’ll end up reerecting them elsewhere. Devs have their skill sets, and ops isn’t part of that. The opposite is also true. The intersection can be substantial, but never enough to have dev to it all alone. I don’t think that’s a bad thing either.