undefined | Better HN

0 pointsthrowaway8943454y ago0 comments

With an Ops team, developers aren’t expected to operate their code. That’s the ops team’s problem. And the ops team is measured on uptime, which is a function of the code itself, which they can’t actually change—devs own that. What the ops team can do is to slow down the rate of deployments (another input to downtime/uptime). Rather than many small deployments, they’ll have larger deployments once or twice a quarter (at best).

So a desire to ship features regularly and preserve agility and quality is the “trendy” that the GP is talking about.

0 comments

2 comments · 1 top-level

thinkharderdev4y ago· 1 in thread

Regardless of how often you ship, things still break sometimes though right? And you still need to find out why when they do. Often the issue is some interaction between application and infrastructure which requires knowledge of both to understand. Long before k8s was a thing and I worked in an environment like you describe above I still knew how the infrastructure worked even if I personally wasn't allowed to touch it.

throwaway894345OP4y ago

> Regardless of how often you ship, things still break sometimes though right? And you still need to find out why when they do.

The point is that under the traditional model, ops is responsible for the debugging, and they are typically already familiar with the infrastructure. Of course, things in organizations are rarely neatly isolated like this, so certainly developers would help with the debugging in many other, and having infra expertise will help.

j / k navigate · click thread line to collapse