5 ms·

> What ops (or devops enablers) would be doing in this case is: > small feature-owning teams build and maintain their features, devops people enable many small

by trog 4y ago

> What ops (or devops enablers) would be doing in this case is: > small feature-owning teams build and maintain their features, devops people enable many small teams to do their work by providing shared systems. So I don't think I get your point. The stuff you've listed here just looks like stuff straight old Ops would do, set the parameters for Dev, and then things would just roll on. Saying "ops (or devops enablers)" like that is confusing me because the whole point of the original article (I thought) was to note that DevOps has basically become Ops, so what have we actually achieved? i.e., that as soon as you distinguish between "devs" and "devops" people, you've basically already drawn a line between traditional dev and ops roles.

oneplane 4y ago
You are indeed not getting the point. Ops people do not 'set the parameters'. DevOps doesn't become ops, and devs don't become ops either. The only ops left is perhaps contract management that really doesn't have anything to do with the developers. DevOps can mean the practise of intersecting tasks that classically would be categorised as either development or operations, but it can also mean the people with enough skills to understand the needs of the developed features as well as the requirements of a useful infrastructure. Take a very dated example: - Operations might request new server hardware purchase orders - Then they rack it, install an OS - Someone else, say, application management, installs Jenkins on it - Someone else yet again configures Jenkins so Developers can use it - A developer now logs in to Jenkins, and clicks build on their product or entire project - Operations gets a fax from Jenkins about a new build being ready to be installed - Operations sends the build to a different application management person - Different application management installs the new build - Developer can finally see the end result If at any step something goes wrong dependency-wise, the person involved is not allowed or not able to do anything about it because it is outside of their scope. This is classic operations. On top of that, all those layers are annoying and inefficient. Instead of all that we have new tools, and new grouping of activities which run in parallel: DevOps-enabling person: - Notices a shared CI system would benefit everyone (developers, customers, finance) - Proposes such a system and perhaps presents a demonstration - Configures a virtual or container system from any XaaS provider to provide this CI system to anyone who wants it - Adds integration with SCM - Tries out a few builds to test SCM lifecycle Developer: - Writes code, commits to SCM - SCM fires a CI pipeline - Developer can see the end result - Makes additional modifications, immediately sees the result again because nobody else is required to perform those tasks - Maybe additional CI options are needed, create commit with CI changes and update CI to have those extra options available - Instant results yet again Classical operations only existed because there were no tools and no shared responsibilities. The world has changed and now shared responsibilities and tools to act on those exist. Net result: a whole lot less people waiting on each other because they all operate in their own fiefdom. Operations is dead, unless you are still playing datacenter at the office. The closest remaining thing is the service desk and perhaps desktop management for end-users that are locked into some Citrix hell. But we were talking about DevOps which is the intersection of Development tasks and Operational tasks, not end-users and office equipment ;-)

by trog 4y ago

oneplane 4y ago

You are indeed not getting the point. Ops people do not 'set the parameters'. DevOps doesn't become ops, and devs don't become ops either. The only ops left is perhaps contract management that really doesn't have anything to do with the developers. DevOps can mean the practise of intersecting tasks that classically would be categorised as either development or operations, but it can also mean the people with enough skills to understand the needs of the developed features as well as the requirements of a useful infrastructure. Take a very dated example: - Operations might request new server hardware purchase orders - Then they rack it, install an OS - Someone else, say, application management, installs Jenkins on it - Someone else yet again configures Jenkins so Developers can use it - A developer now logs in to Jenkins, and clicks build on their product or entire project - Operations gets a fax from Jenkins about a new build being ready to be installed - Operations sends the build to a different application management person - Different application management installs the new build - Developer can finally see the end result If at any step something goes wrong dependency-wise, the person involved is not allowed or not able to do anything about it because it is outside of their scope. This is classic operations. On top of that, all those layers are annoying and inefficient. Instead of all that we have new tools, and new grouping of activities which run in parallel: DevOps-enabling person: - Notices a shared CI system would benefit everyone (developers, customers, finance) - Proposes such a system and perhaps presents a demonstration - Configures a virtual or container system from any XaaS provider to provide this CI system to anyone who wants it - Adds integration with SCM - Tries out a few builds to test SCM lifecycle Developer: - Writes code, commits to SCM - SCM fires a CI pipeline - Developer can see the end result - Makes additional modifications, immediately sees the result again because nobody else is required to perform those tasks - Maybe additional CI options are needed, create commit with CI changes and update CI to have those extra options available - Instant results yet again Classical operations only existed because there were no tools and no shared responsibilities. The world has changed and now shared responsibilities and tools to act on those exist. Net result: a whole lot less people waiting on each other because they all operate in their own fiefdom. Operations is dead, unless you are still playing datacenter at the office. The closest remaining thing is the service desk and perhaps desktop management for end-users that are locked into some Citrix hell. But we were talking about DevOps which is the intersection of Development tasks and Operational tasks, not end-users and office equipment ;-)