patternModerate
Pros/cons of discontinuing a DevOps workflow?
Viewed 0 times
workflowdiscontinuingprosdevopscons
Problem
I'm trying to evaluate whether or not it is a good idea to move away from a devops-style workflow to the traditional dev-then-ops (not sure what you call that).
We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-software) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been pretty successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as DevOps, but without question we are living the DevOps life, with each developer intimately familiar with both the code and the system it runs on.
One of the questions we will face shortly is what "efficiencies" are shared between us and the IT department for our parent company. Our project owner usually prefers outsourcing over in-house learning, so in our case these efficiencies probably means getting as much IT work "off our plate" as possible. Currently, I would say our team has a 70/30% split between experience in coding vs infrastructure. The IT department is solidly in the IT realm, with no visible crossover into software development.
Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of operations work that we shed. I'm skeptical about this though. Our product is still pre-beta (despite already being a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.
Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is tho
We are a small 5 person department tucked away within a 4000 employee traditional media (eg non-software) company. Two years ago we began building software to allow our department to significantly scale up our production. We've been pretty successful and the greater company is beginning to take notice. To date, we have been solely responsible for the design, development and deployment of what has become a ~10 service AWS microservice platform. Our team doesn't identify as DevOps, but without question we are living the DevOps life, with each developer intimately familiar with both the code and the system it runs on.
One of the questions we will face shortly is what "efficiencies" are shared between us and the IT department for our parent company. Our project owner usually prefers outsourcing over in-house learning, so in our case these efficiencies probably means getting as much IT work "off our plate" as possible. Currently, I would say our team has a 70/30% split between experience in coding vs infrastructure. The IT department is solidly in the IT realm, with no visible crossover into software development.
Our project owner (a non-technical individual) is hoping that by handing off as much work as possible to the IT team we will see a ~1:1 boost in productivity for each hour of operations work that we shed. I'm skeptical about this though. Our product is still pre-beta (despite already being a significant business asset) and in our limited experience with the IT department there are usually significant delays for things as simple as filesystem permission changes.
Right now, my ideal solution would be for the IT department to "adopt" us and allow us to continue deploying our own work, while ensuring that we meet the standards & requirements of the IT office. I'm not sure how realistic that is tho
Solution
It's not a good idea.
In my experience you'll gain the disadvantages of both while any projected advantages will somehow fail to materialize.
Itemized:
IT will comply with their own standard. The new task (for them) will follow the same 'sluggish' template all their work now has. Be prepared they will find it challenging - so even less speed than standard simple actions.
IT will lean on you guys for every single anomaly. You will put in effort to get one guy up to speed - and the next thing you now you'll be repeating yourself because the following task/problem/day there will be a new guy, again.
Again template behaviour will be that short manuals will fail to catch every anomaly, and thorough texts will not be read for being too long. So any investment here will be a loss, likewise the enormous effort needed to implement improvements to get your tools to 'shrink-wrapped'quality.
Last but not least any problems will reflect on you guys. Tar, tarbrush principle.
If the above sounds cynical, well, I'm afraid I've been there. Repeatedly.
What to do instead?
Go shopping in the IT department, find yourself a useful candidate, and keep this guy 'on loan' to relieve you workload.
In my experience you'll gain the disadvantages of both while any projected advantages will somehow fail to materialize.
Itemized:
- You will lose speed.
IT will comply with their own standard. The new task (for them) will follow the same 'sluggish' template all their work now has. Be prepared they will find it challenging - so even less speed than standard simple actions.
- You will fail to offload.
IT will lean on you guys for every single anomaly. You will put in effort to get one guy up to speed - and the next thing you now you'll be repeating yourself because the following task/problem/day there will be a new guy, again.
- Documentation will be required, but it will not help.
Again template behaviour will be that short manuals will fail to catch every anomaly, and thorough texts will not be read for being too long. So any investment here will be a loss, likewise the enormous effort needed to implement improvements to get your tools to 'shrink-wrapped'quality.
Last but not least any problems will reflect on you guys. Tar, tarbrush principle.
If the above sounds cynical, well, I'm afraid I've been there. Repeatedly.
What to do instead?
Go shopping in the IT department, find yourself a useful candidate, and keep this guy 'on loan' to relieve you workload.
Context
StackExchange DevOps Q#1141, answer score: 10
Revisions (0)
No revisions yet.