9

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 though. Plus it is nearly the opposite approach our project owner is advocating since it would add additional operations work in the short term.

In our situation, what are the likely pros/cons of staying with DevOps approach vs handing off IT?

Improve this question
1
  • I think you already have a correct vision of the consequences, that's highly personal and company related. What's sure is that workload doesn't transfer as 1:1, for each hour of ops transferred, you'll likely have part of it to assist the ops team in debug and handling delays... (this is not really an answer, so just leaving it as a comment)
    – Tensibai
    Commented May 11, 2017 at 8:41

4 Answers 4

Reset to default
10

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:

  1. 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.
  2. 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.
  3. 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.

Improve this answer
6

You can find many of the answers in the result of DevOps survey which you should ask the product owner to read. This is a document written specifically for business people with little technical knowledge talking in the terms he should understand.

At average you will need 1 extra developer for every 4 people to keep same level of feature development (38% vs 49% time spent on new work). Your mean time to recover from failure will drop up to 25 times. Your work will be 20% less enjoyable and you will be 40% as likely to recommend your work to a friend. Just those three facts should be enough.

Improve this answer
4

What you will lose by fitting into the IT organization is the "Dev" part of your little DevOps team. When teams become segmented into artificial roles of NetOps, SysOps and Dev, you introduce the following problems:

  1. Un-needed red tape and isolation - To do anything the developers will have to submit a ticket to IT and wait for them to implement it. They will no longer be able to implement and interact with it themselves - up to and including their Dev and QA instances which will limit what infrastructure they can code out. They are stuck at the VM barrier instead of being able to code on the full stack. If what they submit to IT looks like DevOps code, they will be ill-equipped to handle it and might revert back to manual deployments.
  2. Neglect - Alternatively, they may just deploy it as is and then neglect the beast because they don't know how to interact with it - and they aren't developers, so code is not their problem.
  3. Outages - One of the oft overlooked benefits of DevOps is it's programmatic nature. Sure, it might take longer to deploy that server by treating it as code, but this automates out human mistakes. The way it went into dev is they way it will go into QA/Test is the way it will go into prod, thereby reducing outages. When developers lose access to the network equipment they need to deploy their service or the compute infrastructure not only does it take longer, but it introduces more fallible humans which will cause more outages.
  4. Documentation - In some senses, DevOps code is self docuementing. You know how the server was built and deployed because the code tells you. In 5 years, when it is time for an upgrade to CentOS 8 or whatever, no one will know how to deploy your application anymore - including at the network, storage, monitoring and backup layers.

In short, you should suggest that your project owner take the time to read The Mythical Man-Month to disabuse him or her of the notion that you will see a 1:1 relationship in productivity and The Phoenix Project which is a good novelized (and entertaining) illustration of what is gained and lost by using DevOps in non-technical language for non-technical people. If the project owner has any sort of commute an Audible audiobook of The Phoenix Project is available.

Improve this answer
3

I would suggest that you adopt some of the IT team, and give them thorough training in the new system.

Once they understand the system fully then it makes sense to offload it to them.

Otherwise, you will become a Support Center for IT - and spend a lot of time firefighting as they learn the intricacies of the new system.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.