5 ms·

This is based on the premise that DevOps is a team of people, it's own silo. And that is not what DevOps is about IMHO...

querulous 11y ago
yeah, if your company has a devops team you are really just doing traditional ops / devs, but with a split ops team
e12e 11y ago
I was surprised to see that most of the comments here seem to take DevOps to mean simply Ops. The whole point, the only point, of devops is to not have "write feature, throw it to ops"-processes. I think the latest generation of PaaS can been seen two ways: on one hand, it's like having a great ops-teamt that will handle everything you throw at them (and have set up clear borders for what is "their" responsibility), the other is to say that it's great for devops: with the low level of management needed for cloud infrastructure (compared with setting up your own hardware, choosing and tuning a network storage solution, manage fail-over for databases, making sure to patch ssh/TLS/libc/libz/libtiff/libpng...) means that we get better DevOps: you might prototype in a local docker, but as part of the commit cycle, every dev will run tests, and push out to production, with rolling updates. I don't know when "DevOps" became so watered down -- I guess it's the same old story as with Lean/Agile: the real win is in changing the business process, and has nothing to do with tooling and consultants: changing processes is actually hard, so no-one does it. But when you've paid out the nose for "educating" your "team" to do agile/devops, you start to claim that your waterfall was built by Toyata. Because you paid for the privilege.
- illumin8 11y ago
  To me, containers seem to be a perfect way to have a reasonable contract between Dev and Ops. The Ops team just has to maintain a secure, stable, and performant infrastructure that can run containers, and Devs can put whatever they want in the container, and not have to worry about anything below it.
  - e12e 11y ago
    Sure, but now dev has the responsibility for upgrading all those libraries again. Just because your container worked fine 5 years ago, doesn't mean it's a good idea to run the same container in production today. Maybe it parses png images, or handles ssl termination. Or you could say that ops now has the responsibility to scan all containers for old binary code/bad behaviour, and throw the container back over the fence if they find an issue. I do agree that containers are a good start on having such a "contract" -- I'm not sure it's enough.
illumin8 11y ago
DevOps is the anti-silo... It's funny and a bit ironic that traditional corporations have heard some vague information about DevOps and immediately decided that they should create a DevOps silo/team, while apparently missing the fact that the entire DevOps philosophy is about breaking down silos and having everyone build Ops into their codebase...

querulous 11y ago

yeah, if your company has a devops team you are really just doing traditional ops / devs, but with a split ops team

e12e 11y ago

I was surprised to see that most of the comments here seem to take DevOps to mean simply Ops. The whole point, the only point, of devops is to not have "write feature, throw it to ops"-processes. I think the latest generation of PaaS can been seen two ways: on one hand, it's like having a great ops-teamt that will handle everything you throw at them (and have set up clear borders for what is "their" responsibility), the other is to say that it's great for devops: with the low level of management needed for cloud infrastructure (compared with setting up your own hardware, choosing and tuning a network storage solution, manage fail-over for databases, making sure to patch ssh/TLS/libc/libz/libtiff/libpng...) means that we get better DevOps: you might prototype in a local docker, but as part of the commit cycle, every dev will run tests, and push out to production, with rolling updates. I don't know when "DevOps" became so watered down -- I guess it's the same old story as with Lean/Agile: the real win is in changing the business process, and has nothing to do with tooling and consultants: changing processes is actually hard, so no-one does it. But when you've paid out the nose for "educating" your "team" to do agile/devops, you start to claim that your waterfall was built by Toyata. Because you paid for the privilege.

illumin8 11y ago
To me, containers seem to be a perfect way to have a reasonable contract between Dev and Ops. The Ops team just has to maintain a secure, stable, and performant infrastructure that can run containers, and Devs can put whatever they want in the container, and not have to worry about anything below it.
- e12e 11y ago
  Sure, but now dev has the responsibility for upgrading all those libraries again. Just because your container worked fine 5 years ago, doesn't mean it's a good idea to run the same container in production today. Maybe it parses png images, or handles ssl termination. Or you could say that ops now has the responsibility to scan all containers for old binary code/bad behaviour, and throw the container back over the fence if they find an issue. I do agree that containers are a good start on having such a "contract" -- I'm not sure it's enough.

illumin8 11y ago

DevOps is the anti-silo... It's funny and a bit ironic that traditional corporations have heard some vague information about DevOps and immediately decided that they should create a DevOps silo/team, while apparently missing the fact that the entire DevOps philosophy is about breaking down silos and having everyone build Ops into their codebase...