Entornos de desarrollo virtualizados en redes empresariales

Estamos intentando implementar un entorno de desarrollo utilizando la virtualización para un pequeño equipo de 4 desarrolladores dentro de una organización empresarial. Esto nos permitiría establecer entornos de desarrollo, prueba y preparación por separado, además de permitir el acceso a nuevos sistemas operativos que son requisitos para los sistemas o herramientas que estamos evaluando. Cambiamos el propósito de una máquina de clase de estación de trabajo existente, agregamos 24 GB de RAM y RAID-10, y lo estábamos haciendo bien hasta que intentamos agregar la máquina al dominio.

Ahora estamos comenzando la guerra que todos los desarrolladores empresariales desde el principio de los tiempos han tenido que luchar: la lucha por el control local de un entorno de desarrollo y pruebas. La red y los administradores de TI han planteado inquietudes que van desde "El servidor ESX es el estándar de la empresa" hasta que "los servidores no están permitidos en las VLAN del cliente" a "[rellenar el espacio en blanco] no es un conjunto de habilidades que actualmente posee el local u organización empresarial de TI ".

Podríamos justificar el hardware de clase de producción y el soporte de TI formal si tuviéramos que hacerlo, pero llevaría tiempo e implicaría mucho dolor de cabeza. Incluso entonces, podría llevar meses asignar formalmente los recursos de TI al tratar esto como un sistema de producción, e incluso si lo hiciéramos, probablemente perderíamos el control local que necesitamos.

Me imagino que muchos de ustedes han tenido dificultades similares por el control de los desarrolladores de entornos que no son de producción, y la virtualización en particular, por lo que mis preguntas son las siguientes:

1. ¿Qué estrategias y argumentos lo han ayudado a ganarse a la gente de infraestructura (TI y red) para permitir que exista este tipo de silos dentro de las empresas que tienen políticas estándar de red y seguridad que generalmente (y comprensiblemente) excluirían este tipo de no ( infraestructura gestionada centralmente?
2. ¿Ha encontrado que esto es una cuestión de justificación técnica, o más de una lucha política por el control y la propiedad?
3. Si terminó con un entorno de desarrollo administrado por TI, ¿cuánto ha sido un obstáculo para el desarrollo y las pruebas del día a día?
4. ¿Alguien ha terminado moviendo su entorno de desarrollo a una VLAN desconectada o una red completamente separada para evitar estas dificultades de acceso a la red?

Además, esta no es una guerra santa de Hyper-V vs. ESX (estaríamos bien con cualquiera de ellos, pero Hyper-V fue seleccionado ya que es "gratuito" con MSDN para estos fines [sí, VMWare también tiene herramientas gratuitas, pero el las buenas herramientas de administración generalmente no lo son], y sería más fácil de administrar por los desarrolladores locales en una "Tienda de Microsoft"), por lo que los argumentos a favor o en contra de ambos están fuera del alcance de esta pregunta.

Esto también es menos virtualización que hardware físico. Supongo que se podría hacer la misma pregunta sin el componente de virtualización de la ecuación.

Suponga también que el equipo de desarrollo ya ha hecho garantías para administrar la administración de parches y el antivirus, o integrarse con los sistemas empresariales existentes si lo admiten. Este escenario, con diferentes preguntas, también se publica en SF para obtener el punto de vista opuesto.

Has salido de la reserva y estás tratando de justificarla.

Esto no se trata de virtualización; Se trata de control y responsabilidad. El departamento de TI tiene la responsabilidad de la seguridad y confiabilidad de los sistemas de la compañía. Para asegurarse de que funcionen, TI los mantiene bajo su propio control. Has creado un sistema que no está bajo el control de TI, y ahora se está convirtiendo en un problema.

Las razones habituales por las que los programadores quieren sus propios sistemas, en mi experiencia, son:

• TI no responde. Se necesitan semanas para obtener un nuevo entorno, pero ahora necesita uno.
• Necesitas control; No te lo darán. Debe poder establecer permisos, instalar componentes, etc. TI no lo permitirá.

Finalmente, cuando vaya a producción, querrá un sistema administrado por TI que esté completamente bloqueado. Pero mientras se desarrolla, necesita flexibilidad. Algunas sugerencias:

• Hacer amigos. conocer a algunas personas en TI; Habla con ellos cara a cara. Explique su situación y pregúnteles qué se puede hacer. Es posible que pueda obtener derechos de administrador para un servidor de desarrollo simplemente preguntando.
• Ejecutar local. Si puede ejecutar partes de la aplicación en sus máquinas locales, es posible que no necesite un servidor o puede salirse con una instancia de DB bloqueada.
• Consigue un patrocinador. Nada hace que TI se mueva como un vicepresidente entrando y diciendo: "¿Por qué estás bloqueando mi proyecto?" Use la influencia de su patrocinador de proyecto.
• A la nube! Si el presupuesto de su proyecto lo cubrirá, solo aloje en EC2: omita todo su departamento de TI. Los riesgos están siendo pirateados y despedidos por permitir que la información de la empresa salga del firewall.
• Ejecuta el juego largo. Realice las solicitudes de servidores debidamente autorizados y administrados con anticipación. Cuando reciba quejas sobre su cerveza casera, diga que todavía está esperando en los servidores oficiales.
• Preasignar Solicite servidores que cree que podría necesitar en el futuro. Luego vuelva a utilizarlos cuando tenga necesidades reales.

Por mucho que sea un aficionado en situaciones como estas, parece que se requiere un argumento apropiado y bien construido para justificar ante los jefes de departamento la necesidad del gasto adicional (y la extensión) de los recursos de TI. Probablemente desee un buen orador que sea capaz de intermediar los problemas y relacionar el valor potencial de la propuesta con aquellos que terminan pagando por ella.

El problema es en realidad uno que merece una consideración real: un grupo quiere el entorno de desarrollo, pero eso ejerce cierta presión sobre el otro grupo que se siente responsable, de hecho es responsable de la seguridad del sistema en general, especialmente las redes son algo que los departamentos de TI justificablemente precioso sobre

Me sorprende que la capacidad de desplazar ciertos recursos fuera del sitio para un proyecto prospectivamente lucrativo o incluso un entorno libre para desarrolladores haya sido reemplazada por una racionalización del mercado para la virtualización como una medida de reducción de costos y control de recursos.

Ahora no me malinterpreten, no estoy en contra de la virtualización, ni mucho menos. Pero se me ocurre que a menudo hay resones muy buenos y explicables para permitir que un grupo de desarrollo tenga derecho a un reino separado que sería un entorno más productivo y potencialmente más seguro que simplemente virtualizar todo.

Seguro que una empresa puede ahorrar dinero al usar la nube para cosas departamentales regulares entre oficinas, es muy útil allí. (es una forma de virtualización, pero diferente, lo sé)

Pero supongamos que un desarrollador genera un error no identificable que no se puede depurar porque hay una pregunta sobre si la aplicación / programa se ha roto debido a una implementación de virtualización (es decir, que no ocurriría en una computadora independiente). se vuelve contraproducente para perder tiempo tratando de rastrear el error que no está realmente en la programación, sino en la implementación de VM.

Espero estar siendo claro. No tengo la respuesta para su caso específico, pero creo que estas son consideraciones útiles en términos del problema, y ​​recomendaría encarecidamente que estos temas se discutan abierta y completamente con los dos departamentos involucrados, y tal vez un representante del gestión empresarial que finalmente tendría que defender las compras. ¡De ahí mi sugerencia de un buen orador o intermediario!

Presumiblemente si requiere más empleados, entonces eso podría ser algo positivo (hay muchas personas desempleadas por ahí) pero podría haber suficiente inteligencia de TI en la sección de desarrolladores para agregar un rol como administrador del servidor para su propio grupo.

Sé que en realidad es bastante importante, por lo que no deseo ser impertinente, pero hay momentos en los que creo que la consolidación y la incorporación de roles a los trabajadores existentes conlleva demasiada carga en su tiempo personal, que tienden a terminar resentidos. , especialmente cuando podrían ser parte de algo radicalmente nuevo y exitoso en ingeniería de software.

No envidio su problema, sin embargo, sí envidio el lugar de trabajo que está totalmente comprometido con la creación de nuevos diseños, nuevo software y nuevas ideas. Sinceramente le deseo la mejor de las suertes y espero que mis contribuciones sean de alguna ayuda.

Mihaly

El departamento de TI realmente tiene un punto.

Probablemente gestionan miles de aplicaciones en cientos de sistemas. La única forma en que pueden hacer esto de manera efectiva es tener unas pocas pilas de software estándar seleccionadas ejecutándose en incluso menos configuraciones de hardware estándar.

Si sigue esta ruta, encontrará más y más problemas a medida que se acerque a la producción: en el peor de los casos, deberá volver a factorizar toda la aplicación para que se ejecute en un entorno de producción estándar días antes de que entre en funcionamiento.

Es mejor trabajar con el grupo de TI y pedirles que configuren algunos entornos de prueba estándar para usted, es lo que se les paga por hacer. - Irónicamente, probablemente configurarán una máquina virtual para cada entorno.

Los programadores deben programar, dejar que los chicos de la infraestructura de TI proporcionen la infraestructura y los chicos de la red configuren las redes: ¡así es como funcionan las corporaciones!

Además, si su aplicación no es tan estándar que TI no considerará crear un entorno de prueba, tendrá cero posibilidades de ponerla en producción. Hable con sus arquitectos empresariales, descubra qué entornos son estándar e intente usarlos. Si realmente no puede implementar su aplicación utilizando el software / hardware estándar, debe realizar una solicitud formal para que la arquitectura empresarial apruebe su infraestructura como un caso excepcional.

Tendrá que presentar su caso ante la gerencia que:

1. Tener el entorno virtualizado cumple uno o más de los requisitos establecidos específicamente por la compañía (como la flexibilidad de soportar múltiples plataformas), y

2. Puede implementarlo de manera más oportuna, con un costo menor que el de TI, y

3. Tener control local reducirá los costos y reducirá los retrasos en el tiempo de comercialización, y

4. Puede satisfacer las preocupaciones de seguridad y mantenimiento de TI, y

5. La productividad del programador no se verá afectada.

El último es un gran si.   He discutido este problema con varias personas que se especializan en este tipo de virtualización. Me dicen que, cuando arroje suficiente hardware para que sea tan sensible como una PC local, no habrá ningún ahorro en los costos de hardware.

Por lo tanto, sus ahorros de costos demostrados tendrán que venir en forma de flexibilidad en la configuración y la capacidad de cambiar esas configuraciones en cualquier momento.