21–30 of 115 posts
In my experience, a big fancy post in smart words is never actually a practical implement to change the current practices of a company.
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. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisatio…
Surely Github workflows https://github.com/actions/starter-workflows or Gitlab templates is the culmination of your devops work? Not Kubernetes (?) unless I missed something. The rewarding thing for me is applying this and other sensible defaults like observing iteration speed and driving delivery..
In real world, permutation and combination are endless. Every org has peculiar problem either created by the engineers themselves or are result of certain business decisions.
I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out…
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
What is devops here again? Is it the The Phoenix Project one on one extreme or system admin for the cloud on the other extreme?
For many organizations, a rebranding of systems engineer.
What is devops here again? Is it the The Phoenix Project one on one extreme or system admin for the cloud on the other extreme?
Once the research picked up, they started building out a broader picture of what a DevOps organization did and whether those things made them more successful (better at delivering software, more reliable, more profitable, etc).
The Phoenix Project / The Unicorn Project explain the concept by telling a story - they kind of tell the same story, but from different perspectives. There's also Investments Unlimited which takes an even broader view by adding governance, risk, and compliance (but in a way that aligns to DevOps).
In 2023, DevOps is best described by the DORA research (The State of DevOps Report) as it covers technical, cultural, and product concerns that all amplify each other.
What is devops here again? Is it the The Phoenix Project one on one extreme or system admin for the cloud on the other extreme?
I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out…
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out…
Almost as though there should be a “Capability Maturity Model.” Man, I wish someone had come up with that 40 years ago.
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. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisatio…
For me what upsets me about devops work, is that for many organizations it is a synonym for systems engineer, lots of Ops and very little Dev.
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. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisatio…
This isn't unique to devops, this is a general software thing. But there is an answer, which is the standard technology stack: - AWS - Postgres - Linux - Docker - Jenkins or similar - Slack - Pagerduty - Jira - Packer - Terraform - etc 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 de…