3 ms·

>Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same

>Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same operational solutions, just with better tools as the passage of time allowed better tools to exist. DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure). Maybe when it became a job title (later) then it just became a rebranding of the ops team.

dijit 2y ago
DevOps has that meaning to you, maybe. I would implore some reading into the origin. Cliff notes version, things that happened around the same time: * Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team * 10+ deploys a day from Flickr; where the authors are in a single unified team of sysadmins and developers. Like Agile, people always claim you're "doing it wrong", which I find ironic given that the portmanteau was created to bring Agile to systems administration itself. However, devops was confused right out of the gate. Your definition is the 10+ deploys a day talk. I actually wrote a blog post about this: https://blog.dijit.sh/devops-confusion-and-frustration/ https://blog.dijit.sh/devops-confusion-and-frustration/
- benfortuna 2y ago
  You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
  - funnybeam 2y ago
    > So devs decided they could do it themselves (with better tools). And failed. Other people’s jobs always look easy from the outside
    - benfortuna 2y ago
      Actually devs focusing on Ops lead to development of the automation we use today for most Ops activities, so I would say that is a success.
      - pjmlp 2y ago
        We already had such automation tools under system administration umbrella. What do we think we were using Perl for?
        teqsun 2y ago
        > "What do we think we were using Perl for?" Job Security (joking)
        benfortuna 2y ago
        Scripting is not in the same league as Puppet, Chef, Ansible, etc. Automation at scale required the development of tools like these.
        pjmlp 2y ago
        Most of those predate DevOps phenomenon, and have roots in systems administration.
        drewcoo 2y ago
        Not scale in terms of your company scaling. Only scale in terms of number of companies using the same off the shelf tooling. The difference with those tools is that they were off the rack and not bespoke. There were plenty of bespoke systems before, used in fewer places because bespoke systems are expensive.
  - dijit 2y ago
    That tends to happen when your IT team is a cost center, they had no resources on standby. Now you pay AWS anywhere from 5-11x more for an instance, but you still have an ops team managing it (by some name). If you had given even 20% of that investment to the sysadmins you would have had an equivalent system. AWS just weaponised this short-sighted thinking that was killing ops teams.
    - benfortuna 2y ago
      But if AWS originates from the ops teams of Amazon, then perhaps they were just doing Ops better than everyone else. They chose not to be just a cost centre, and find ways to become better.
      - dijit 2y ago
        That’s certainly an opinion. From what I recall it was AWS developers trying to solve object storage, and EC2 came later. Not about ops.
  - sgarland 2y ago
    Perhaps they would’ve spent more effort making software not suck if they still had that constraint. Instead, now we get the modern dumpster fire because more resources are an HPA call away.
amonith 2y ago
> DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure) Not happening in any of the companies I worked for as a contractor or subcontractor. In those companies at best dev teams have nowadays some additional capability to deploy to dev/test instantly (so they do their own CI/CD pipelines and manage dev infra via Terraform or whatever) but production is always handled by a "DevOps" team which does not touch the application code at all. This is especially visible in companies that outsource their development to software houses / individual contractors (B2B stuff, most of the folks I interact with).
- formerly_proven 2y ago
  These setups are frankly asinine. Often come with another contractor and an entirely separate org to handle service/support. And then management wonders why relatively simple applications take forever to ship, changes take even longer and operating costs are astronomic ("back in the day four guys could do this" - they still can, you just don't let them).

dijit 2y ago

DevOps has that meaning to you, maybe. I would implore some reading into the origin. Cliff notes version, things that happened around the same time: * Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team * 10+ deploys a day from Flickr; where the authors are in a single unified team of sysadmins and developers. Like Agile, people always claim you're "doing it wrong", which I find ironic given that the portmanteau was created to bring Agile to systems administration itself. However, devops was confused right out of the gate. Your definition is the 10+ deploys a day talk. I actually wrote a blog post about this: https://blog.dijit.sh/devops-confusion-and-frustration/ https://blog.dijit.sh/devops-confusion-and-frustration/

benfortuna 2y ago
You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
- funnybeam 2y ago
  > So devs decided they could do it themselves (with better tools). And failed. Other people’s jobs always look easy from the outside
  - benfortuna 2y ago
    Actually devs focusing on Ops lead to development of the automation we use today for most Ops activities, so I would say that is a success.
    - pjmlp 2y ago
      We already had such automation tools under system administration umbrella. What do we think we were using Perl for?
      - teqsun 2y ago
        > "What do we think we were using Perl for?" Job Security (joking)
      - benfortuna 2y ago
        Scripting is not in the same league as Puppet, Chef, Ansible, etc. Automation at scale required the development of tools like these.
        pjmlp 2y ago
        Most of those predate DevOps phenomenon, and have roots in systems administration.
        drewcoo 2y ago
        Not scale in terms of your company scaling. Only scale in terms of number of companies using the same off the shelf tooling. The difference with those tools is that they were off the rack and not bespoke. There were plenty of bespoke systems before, used in fewer places because bespoke systems are expensive.
- dijit 2y ago
  That tends to happen when your IT team is a cost center, they had no resources on standby. Now you pay AWS anywhere from 5-11x more for an instance, but you still have an ops team managing it (by some name). If you had given even 20% of that investment to the sysadmins you would have had an equivalent system. AWS just weaponised this short-sighted thinking that was killing ops teams.
  - benfortuna 2y ago
    But if AWS originates from the ops teams of Amazon, then perhaps they were just doing Ops better than everyone else. They chose not to be just a cost centre, and find ways to become better.
    - dijit 2y ago
      That’s certainly an opinion. From what I recall it was AWS developers trying to solve object storage, and EC2 came later. Not about ops.
- sgarland 2y ago
  Perhaps they would’ve spent more effort making software not suck if they still had that constraint. Instead, now we get the modern dumpster fire because more resources are an HPA call away.

amonith 2y ago

> DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure) Not happening in any of the companies I worked for as a contractor or subcontractor. In those companies at best dev teams have nowadays some additional capability to deploy to dev/test instantly (so they do their own CI/CD pipelines and manage dev infra via Terraform or whatever) but production is always handled by a "DevOps" team which does not touch the application code at all. This is especially visible in companies that outsource their development to software houses / individual contractors (B2B stuff, most of the folks I interact with).

formerly_proven 2y ago
These setups are frankly asinine. Often come with another contractor and an entirely separate org to handle service/support. And then management wonders why relatively simple applications take forever to ship, changes take even longer and operating costs are astronomic ("back in the day four guys could do this" - they still can, you just don't let them).