3 ms·

So instead of having a team of people own something (a product) you are splitting ownership up in so many ways, nobody really owns it, and now you have to make

So instead of having a team of people own something (a product) you are splitting ownership up in so many ways, nobody really owns it, and now you have to make everyone waste their time on KPI tracking because somehow that's better than someone just owning their small product as part of a larger business? This is pretty much a waterfall vs. iterations discussion where the reality is that the world doesn't stop moving while you're working. If a product team needs to deliver something (i.e. "allow users to select a delivery window for an order"), they might update their microsite with the components and API calls to do this, and then update their API microservice to exchange that information based on the customer's identity (so they can only update their own order delivery data). None of that knowledge is going to exist in a classic ops team, nor should it be if such a team were still relevant. At the same time, that team might need to take into account that there might be order peaks during the day and they have to collect and act on the right metrics to know how well their code works, how many resources they are consuming and what their scaling policy should be. None of that has anything to do with ops either. Then, at the end of the day, they'll use all of this information and domain specific knowledge to decide: - is the feature complete - can users make proper use of it - do we need to invest time and effort in code optimisations - do we need to extract this feature into a separate scalable entity to prevent disruptions to neighbouring features None of this is relevant or knowledge for ops either. Nobody will be able to manage a feature like that better than a product team with a few developers, a few features, a (shared) product owner, and perhaps a (shared) domain expert or tester. But the people who wrote the code own the implementation (but usually they don't own the business requirements). What ops (or devops enablers) would be doing in this case is: - make sure metrics aggregation is working as expected - make sure scaling is working as expected - make sure deployments and configuration updates are working - construct new deployment options if needed - construct new metric aggregation systems if needed - construct new scaling and traffic management systems if needed - notify the teams/owners if they are using deprecated resources or features for too long Perhaps a simple but too vague summary of the above would be: small feature-owning teams build and maintain their features, devops people enable many small teams to do their work by providing shared systems. A developer isn't just a 'writes some code, clocks out' type of value to a company. If it was that simple, robots could do it, and there would not be a shortage of skilled people. There are many more dimensions to work, and unless you work at a very large scale company, or a very restrictive company, it's highly unlikely that you'll be isolated from the world and just write a bit of anonymous source code with no idea of what happens before or after.

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 ;-)

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 ;-)