I’ve always “automated stuff away” and worried about making sure whatever I developed had a sane, reproducible way of a) being tested and b) being deployable at scale, so I’ve watched DevOps/SRE unfold as I hopped between both sides of the fence (I’m a Solution Architect at Microsoft now, and spent a few decades in telcos doing the above).
I’m going to be (intentionally) critical here, but please understand that these are examples taken from a biased sample (I work in Portugal with very traditional enterprise customers and early stage startups, either of which usually lack-or don’t care about-senior talent - juniors of all stripes tend to be over-enthusiastic about jargon and bleeding edge, and the blast radius is huge on both kinds of companies).
The way I see it (in both enterprise and the local startups I deal with) is that DevOps has created as much confusion and undue ceremony as Agile in many places, all of which share a common trait—developers there do not understand (or want to deal) with software architecture and just want to hit their sprint targets without reasoning about the architectural impact of implementation details.
Enterprise devs will usually not have any real control about architecture, internal endpoints or even dev environments (all the Ops is taken away from them) and startup devs are usually rushing things, setting up faster infra to fix code problems and building up technical debt _in architecture terms_ (the Ops stuff is usually haphazard and too bleeding edge).
There are some positive exceptions, though. I’m currently helping a customer do Kubernetes from a _governance_ perspective (i.e., figuring out all the steps from dev to prod including environments, namespaces, network policy groups, etc.), and even though this is being done alongside already existing deployments, _taking the time to plan and work things out inside your org_ makes a lot of difference.
We’re not calling it DevOps, SRE, or Agile. It’s not a buzzword-laden, Valley-anointed process. It’s just (senior) engineers (Devs and Ops) talking and systematically going through what will work and won’t...
I’m going to be (intentionally) critical here, but please understand that these are examples taken from a biased sample (I work in Portugal with very traditional enterprise customers and early stage startups, either of which usually lack-or don’t care about-senior talent - juniors of all stripes tend to be over-enthusiastic about jargon and bleeding edge, and the blast radius is huge on both kinds of companies).
The way I see it (in both enterprise and the local startups I deal with) is that DevOps has created as much confusion and undue ceremony as Agile in many places, all of which share a common trait—developers there do not understand (or want to deal) with software architecture and just want to hit their sprint targets without reasoning about the architectural impact of implementation details.
Enterprise devs will usually not have any real control about architecture, internal endpoints or even dev environments (all the Ops is taken away from them) and startup devs are usually rushing things, setting up faster infra to fix code problems and building up technical debt _in architecture terms_ (the Ops stuff is usually haphazard and too bleeding edge).
There are some positive exceptions, though. I’m currently helping a customer do Kubernetes from a _governance_ perspective (i.e., figuring out all the steps from dev to prod including environments, namespaces, network policy groups, etc.), and even though this is being done alongside already existing deployments, _taking the time to plan and work things out inside your org_ makes a lot of difference.
We’re not calling it DevOps, SRE, or Agile. It’s not a buzzword-laden, Valley-anointed process. It’s just (senior) engineers (Devs and Ops) talking and systematically going through what will work and won’t...