Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are attempting to implement a development environment using virtualization for a small team of 4 developers within an enterprise organization. This would allow us to set up separate development, testing, and staging environments - as well as allowing access to new operating systems that are requirements for systems or tools we are evaluating. We re-purposed an existing workstation-class machine, threw in 24GB RAM and RAID-10, and were doing fine until we attempted to get the machine added to the domain.

Now we are beginning the war that all enterprise developers since the beginning of time have had to fight - the fight for local control of a development and testing environment. The network and IT admins' have raised concerns ranging from "ESX Server is the enterprise standard" to "servers are not allowed on client VLANs" to "[fill-in-the-blank] is not a skill set currently possessed in the local or enterprise IT organization".

We could justify production-class hardware and formal IT support if we had to, but it would take time and involve a whole lot of headache. Even then it might take months to formally get IT resources assigned by treating this as a production system - and even if we did, we would likely lose the local control we need.

I imagine that many of you have had similar struggles over developer control of non-production environments - and virtualization in particular - so my questions are as follows:

  1. What strategies and arguments have helped you win over the infrastructure (IT & Network) folks to allow these types of silos to exist within enterprises which have standard network and security policies in place that would generally (and understandably) preclude this type of non-(centrally)-managed infrastructure?
  2. Have you found this to be a matter of technical justification - or more of a political struggle for control and ownership?
  3. If you ended up with a IT-managed development environment, how much of a roadblock has it been for day-to-day development and testing?
  4. Has anyone ended up moving their development environment to a disconnected VLAN or entirely separate network to avoid these network access struggles?

Also, this is not a Hyper-V vs. ESX holy war (we would be fine with either - but Hyper-V was selected since it is "free" with MSDN for these purposes [yes, VMWare has free tools too - but the good management tools generally aren't], and would be easier to manage by the local developers in a "Microsoft Shop") - so arguments for or against either are outside the scope of this question.

This is also less of a virtualization vs. physical hardware - I suppose the same question could be asked without the virtualization component to the equation.

Also assume that the dev team has already made assurances to either manage patch management and antivirus, or integrate with the existing enterprise systems if they will support it. This scenario, with different questions, is also posted on SF to hopefully elicit the opposing viewpoint.

share|improve this question
    
Why are you attempting to virtualize the developer machines? What problem are you trying to solve? Your developers, network and IT admins are going to ask you this anyway, so you might as well spill the beans here. –  Robert Harvey Sep 28 '11 at 2:22
    
    
2  
OK, to be clear: We want the ability to have separate on-demand development, testing, and production environments; automated unit testing/CI; access to OS and/or tools that we don't currently have running in our production environment but are requirements for systems or tools we are evaluating; Honestly, I thought that the benefits of developers having staged environments for testing and deployment as well as the use of virtualization in general were accepted and established. Granted, local admin control isn't required for all of those, but it is of some. –  ScottBai Sep 28 '11 at 2:44
1  
You make a valid point regarding stating my case (benefits) - however that was actually part of the question. The current dev environment consists of the developer workstations coupled with deployment to a production server to which the devs have limited rights (think file copy + individual SQL database DBO). Obviously this is not optimal (I'm new there, but everyone already knew this is a big problem). That is otherwise a good question as the virtualization part really is not really a significant differentiating factor than if we had existing physical machines playing this role. –  ScottBai Sep 28 '11 at 2:53
show 5 more comments

migrated from stackoverflow.com Sep 28 '11 at 2:15

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 2 down vote accepted

You've gone "off the reservation", and are trying to justify it.

This isn't about virtualization; It's about control and responsibility. The IT department has responsibility for the safety and reliability of the company's systems. To make sure they work, IT keeps them under their own control. You've built a system not under the control of IT, and it's now becoming a problem.

The usual reasons programmers want their own systems, in my experience, is:

  • IT is not responsive. It takes weeks to get a new environment, but you need one now.
  • You need control; They won't give it to you. You need to be able to set permissions, install components, etc. IT won't let you.

Ultimately, when you go to production, you will want an IT-managed system that's completely locked down. But while you're developing, you need flexibility. Some suggestions:

  • Make Friends. get to know some people in IT; Talk to them face to face. Explain your situation and ask them what can be done. You may be able to get admin rights to a dev server simply by asking.
  • Run Local. If you can run portions of the application on your local machines, you may not need a server, or you can get away with a locked-down DB instance.
  • Get a Sponsor. Nothing gets IT moving like a VP coming in and saying, "Why are you blocking my project?" Use your project sponsor's clout.
  • To the Cloud! If your project budget will cover it, just host on EC2 -- you bypass your entire IT department. The risks are getting hacked, and getting fired for letting company information outside the firewall.
  • Run the Long Game. Put in the requests for properly authorized and administered servers early. When you get complaints about your homebrew, say that you're still waiting on the official servers.
  • Preallocate. Request servers that you think you might need in the future. Then re-purpose them when you have actual needs.
share|improve this answer
    
Very valid points. +1 for the sponsor tip, it works like a charm most of the times! –  reno812 Sep 28 '11 at 15:24
    
This is a great answer - not the one I necessarily wanted to hear, but I think you hit the nail on the head. I now realize that this is a matter of the devs having a legitimate need for a development environment - but having a perception that IT is not responsive and thus not trying to work WITH them to meet our needs. As much as I like playing with hardware, I'd much rather be provided an IT-managed environment with a dev environment (full rights), test environment (deployment-only rights), staging (no rights), and production (no rights) and not have to manage all that infrastructure. –  ScottBai Sep 28 '11 at 17:21
add comment

The IT department actually have a point.

They probably manage thousands of applications on hundreds of systems. The only way they can do this effectively is to have a few selected standard software stacks running on even fewer standard hardware configurations.

If you follow this route you will encounter more and more problems as you get closer to production -- in the worst case scenario you will need to re-factor the whole application to run in a standard production environment days before you go live.

Better to work with the IT group and ask them to configure some standard test environments for you, its what they are paid to do. -- Ironically they will probably set up virtual machine for each environment.

Programers should program, let the IT infrastructure guys provide the infrastructure and the network guys configure the networks -- its how corporations work!

Also if your application is so non standard that IT will not consider building a test environment -- you will have zero chance of getting it in production. Talk to you enterprise architects find out what environments are standard and try to use them. If you really cannot implement your application using the standard software/hardware you need to make a formal request for enterprise architecture to approve your infrastructure as an exceptional case.

share|improve this answer
add comment

You will have to make your case with management that:

  1. Having the virtualized environment fulfills one or more of the company's specifically stated requirements (such as the flexibility of supporting multiple platforms), and

  2. You can implement it in a more timely manner, with less cost than IT can, and

  3. Having local control will lower costs and reduce time-to-market delays, and

  4. You can satisfy IT's security and maintenance concerns, and

  5. Programmer productivity will not be affected.

The last one is a big if.   I have discussed this issue with a number of people that specialize in this kind of virtualization. They tell me that, by the time you throw enough hardware at this to make it as responsive as a local PC, there won't be any hardware cost savings.

So your demonstrated cost savings will have to come in the form of flexibility in configuration, and the ability to change those configurations at a moment's notice.

share|improve this answer
    
Thank you for your interest and answer - but I'm not sure you understand the Q or our intention. You're making an argument against virtualization - but that's not the question. Also a good answer if the Q was how to justify to the people paying the bills why this is a good idea - but my question is neither; it is how to get inter-organizational departments who neither pay your bills nor specifically care about your department's productivity level to play nice by allowing an exception to the normal course of business. Or are you saying that it's just a matter of justifying it and all is well? –  ScottBai Sep 28 '11 at 3:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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