<story><title>DevOps uses a capability model, not a maturity model</title><url>https://octopus.com/blog/devops-uses-capability-not-maturity</url></story><parent_chain><item><author>samsquire</author><text>What upsets me about devops work is that everything I do at a client is a lineage of architecture and design that needs to be maintained going forward and it only exists at that client.&lt;p&gt;The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave.&lt;p&gt;I just think of the thousands of CI&amp;#x2F;CD systems, build systems, attempts at parallelising builds, impressive optimisations, tooling, automation that have been written for each company over-and-over-again, and there&amp;#x27;s no cross polenation except when they are open sourced.&lt;p&gt;I suppose Kubernetes is part of the answer here, a distribution of practices that survives organisations and spreads between organisations and client-specific lineages of software evolution.&lt;p&gt;I want to work on interesting capabilities such as diagrammatic observability and live visualizations of systems.&lt;p&gt;I really need to make a idle cloud environment simulation game where you invest time in servers, capabilities to handle load and problems that occur randomly or on a schedule.</text></item></parent_chain><comment><author>totetsu</author><text>What upsets me about DevOps, is I know ops pretty well, but am not on par with dev, and every job that just needs someone to ops work now wants to quiz me about O(n) before they&amp;#x27;ll interview. Then I look around at the people who are good at the Dev part and the don&amp;#x27;t know their way around an os or cloud infra.</text></comment>
<story><title>DevOps uses a capability model, not a maturity model</title><url>https://octopus.com/blog/devops-uses-capability-not-maturity</url></story><parent_chain><item><author>samsquire</author><text>What upsets me about devops work is that everything I do at a client is a lineage of architecture and design that needs to be maintained going forward and it only exists at that client.&lt;p&gt;The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave.&lt;p&gt;I just think of the thousands of CI&amp;#x2F;CD systems, build systems, attempts at parallelising builds, impressive optimisations, tooling, automation that have been written for each company over-and-over-again, and there&amp;#x27;s no cross polenation except when they are open sourced.&lt;p&gt;I suppose Kubernetes is part of the answer here, a distribution of practices that survives organisations and spreads between organisations and client-specific lineages of software evolution.&lt;p&gt;I want to work on interesting capabilities such as diagrammatic observability and live visualizations of systems.&lt;p&gt;I really need to make a idle cloud environment simulation game where you invest time in servers, capabilities to handle load and problems that occur randomly or on a schedule.</text></item></parent_chain><comment><author>zug_zug</author><text>This isn&amp;#x27;t unique to devops, this is a general software thing. But there is an answer, which is the standard technology stack:&lt;p&gt;- AWS
- Postgres
- Linux
- Docker
- Jenkins or similar
- Slack
- Pagerduty
- Jira - Packer - Terraform - etc&lt;p&gt;If you stay on the path there will be dozens of tools, plugins, and paths to do  outstanding things with minimal work. Parallelising builds for example is built in to jenkins (if you define the workflow), which will autoscale workers in a setup that takes &amp;lt; 1 hr to setup in aws.&lt;p&gt;If you&amp;#x27;re writing code to solve a problem that a standard tool exists for, you&amp;#x27;re the problem.</text></comment>