3 ms·

I've worked in ops roles since about 2000 after a few years in backend corp IT stuff. I agree that what you've described was the original intent and goal of "d

I've worked in ops roles since about 2000 after a few years in backend corp IT stuff. I agree that what you've described was the original intent and goal of "devops" but in light of that failure, the "cross functional team" definition took over and then in light of that failure, the SRE was born and we're basically back where we started but now the ops people use git instead of rcs. In my experience and opinion, developers are really bad at ops and sysadmins/ops are really bad a development. Anyone that is truly good at both is a unicorn that is probably carrying their team.

di4na 4y ago
Why not sit down and figure out how we can train more unicorns instead. And maybe make the tooling helps at this
- pas 4y ago
  because it's not "profitable", it just doesn't make sense for 95+% of teams. most teams are not building the next facebook. most teams have at least some stability, most teams benefit from delegating specific tasks to specialists (eg at project kickoff they talk to the various leads they sketch out a design, agree, and get back to their respective terf, and when it comes time to deploy it they again talk to whoever and in a few iterations it gets deployed, it goes into testing and then into production, and that's it) sure, there's always bitching about how it's not agile, but ... like I said, they don't have next-facebook-like money. maybe Netflix is the best example for this. everyone was in awe of them for how they are going all in with Cassandra on AWS, microservices, flamegraphs, circuit breakers, 30% of the Internet traffic, and many groups/startups started copying them. but forgot a few tiny details like paying half a million dollars a year to new recruits and having a cashflow that can sustain all the aforementioned things. almost every group would benefit from a more holistic knowledge of whatever they are doing as a whole. but just as there seems to be a natural limit to how many peers one can comfortably have at the same time (eg Dunbar's number) it seems people naturally like to set up softer or harder boundaries for their IT knowledge. ¯\_(ツ)_/¯ ... and yes, tooling seems to be the place where this kind of complexity should live, but then maintaining that tool becomes the real challenge :)
  - di4na 4y ago
    I would argue that it is profitable, as it is far less expensive than the current shitshow. In particular for smaller companies. I have seen team of "unicorns" and you can do the equivalent of 100 devs organisation with a couple team. WhatsApp or Discord come to mind. Also that tooling could be opensourced and shared you know :D It does not have to be a price paid by everyone building their owns. But it would indeed have to handle the real problem. Not like the current tooling that our ops people force down everyone throat :cough: K8s :cough:
jve 4y ago
Hey, this comment inspired me to create a pool. I'd like to know what is the distribution of unicorns between HN crowd :) Pool: https://news.ycombinator.com/item?id=31891675 https://news.ycombinator.com/item?id=31891675

di4na 4y ago

Why not sit down and figure out how we can train more unicorns instead. And maybe make the tooling helps at this

pas 4y ago
because it's not "profitable", it just doesn't make sense for 95+% of teams. most teams are not building the next facebook. most teams have at least some stability, most teams benefit from delegating specific tasks to specialists (eg at project kickoff they talk to the various leads they sketch out a design, agree, and get back to their respective terf, and when it comes time to deploy it they again talk to whoever and in a few iterations it gets deployed, it goes into testing and then into production, and that's it) sure, there's always bitching about how it's not agile, but ... like I said, they don't have next-facebook-like money. maybe Netflix is the best example for this. everyone was in awe of them for how they are going all in with Cassandra on AWS, microservices, flamegraphs, circuit breakers, 30% of the Internet traffic, and many groups/startups started copying them. but forgot a few tiny details like paying half a million dollars a year to new recruits and having a cashflow that can sustain all the aforementioned things. almost every group would benefit from a more holistic knowledge of whatever they are doing as a whole. but just as there seems to be a natural limit to how many peers one can comfortably have at the same time (eg Dunbar's number) it seems people naturally like to set up softer or harder boundaries for their IT knowledge. ¯\_(ツ)_/¯ ... and yes, tooling seems to be the place where this kind of complexity should live, but then maintaining that tool becomes the real challenge :)
- di4na 4y ago
  I would argue that it is profitable, as it is far less expensive than the current shitshow. In particular for smaller companies. I have seen team of "unicorns" and you can do the equivalent of 100 devs organisation with a couple team. WhatsApp or Discord come to mind. Also that tooling could be opensourced and shared you know :D It does not have to be a price paid by everyone building their owns. But it would indeed have to handle the real problem. Not like the current tooling that our ops people force down everyone throat :cough: K8s :cough:

jve 4y ago

Hey, this comment inspired me to create a pool. I'd like to know what is the distribution of unicorns between HN crowd :) Pool: https://news.ycombinator.com/item?id=31891675 https://news.ycombinator.com/item?id=31891675