Reflexiones sobre el desarrollo utilizando máquinas virtuales [cerrado]

Trabajaré como líder de desarrollo para una startup y he sugerido que usemos máquinas virtuales para el desarrollo. No estoy hablando de que cada desarrollador tenga un escritorio con máquinas virtuales para pruebas / desarrollo, me refiero a tener un rack de servidores donde se administran todas las máquinas virtuales y que los desarrolladores trabajen desde un microPC (¿ChromeOS cualquiera?) Localmente, o incluso remotamente desde su hogar computadora.

Para mí, los beneficios son el hecho de que es extremadamente escalable, más barato a largo plazo, más fácil de administrar y que utilizamos el hardware con su máximo potencial. En cuanto a los contras, no puedo pensar en ningún showtoppers en particular, aparte de que necesitaremos a alguien para configurar / mantener dicha configuración.

Esperaba que algunos de ustedes pudieran tener una configuración similar en su lugar de trabajo y poder opinar sobre sus opiniones. Gracias.

¿Qué espera ahorrar, como una fracción del presupuesto de desarrollo? Me parece que te preocupa un épsilon. El costo de las máquinas para desarrolladores es menos del 5% del costo total para mantener a un desarrollador en el personal. Por lo tanto, la única pregunta importante es "¿ahorrará tiempo a los desarrolladores?" Podría, si no tienen que pasar tiempo instalando y actualizando software de desarrollo. O podría costar tiempo, si la red se cae, o el servidor se cae, o, lo más probable, si la capacidad de respuesta en la red es lo más mínimo posible. El desarrollo moderno depende de la interacción de pulsación de tecla por pulsación de tecla con un IDE, o al menos un editor muy inteligente. Retrasar esa interacción incluso unas pocas decenas de milisegundos destruye la productividad del desarrollador. También existe el costo para que los desarrolladores aprendan esta nueva forma de trabajar.

Estas no son objeciones a las máquinas virtuales, sino posibles objeciones al desarrollo remoto.

Creo que estás siendo centavo y tonto.

En primer lugar, los costos de la máquina son triviales en comparación con el costo de un desarrollador. Debe trabajar para maximizar la productividad, no para minimizar el costo de la máquina.

En segundo lugar, la latencia (no el ancho de banda) es la clave para muchas tareas de programación, especialmente la edición de texto. Por cada dólar / libra / euro que ahorre en máquinas para sus desarrolladores, gastará al menos diez en actualizaciones de red para mantener incluso una apariencia de productividad, e incluso entonces, probablemente serían más productivos si economizara al suministrar con Pentium III que encontraste en un contenedor de basura en alguna parte.

También creo que hay un beneficio sustancial en hacer que sus desarrolladores usen un entorno al menos razonablemente cercano al esperado del usuario final objetivo. Independientemente de los objetivos de rendimiento oficiales en una especificación y tal, la mayoría de los programadores se basan bastante en cómo se "siente" el código cuando lo prueban. Cuando usan un entorno completamente diferente al del usuario final, es probable que pierdan tiempo en trivialidades mientras pasan por alto por completo los principales problemas.

Tan atractivo como suena un entorno homogéneo desde un punto de vista de soporte y tal, generalmente debe alentar la mayor variedad posible en las máquinas de los desarrolladores. Los desarrolladores rara vez necesitan mucho soporte de todos modos, y saber de inmediato cuándo tiene un código que fallará con un chip de gráficos, CPU, adaptador de red, etc., más que paga la inversión mínima.

En pocas palabras: si está escribiendo código que está destinado (al menos principalmente) para usarse en un entorno de servidor virtualizado, solo necesita proporcionarlo para sus desarrolladores. Si lo está haciendo de todos modos para probar, también puede (pero no necesariamente) tener sentido para el desarrollo. Del mismo modo, si de todos modos necesita (o al menos tiene) un servidor y una red excesivamente acelerados, podría tener sentido aprovecharlo utilizando lo que ya tiene disponible.

Sin embargo, en las circunstancias más típicas, me parece que es probable que esto introduzca más problemas de los que resuelve.

Esa fue una de mis ideas en el pasado: tener un servidor de alto rendimiento que tenga todo el software requerido, y un montón de PC de escritorio de bajo rendimiento que se utilizarían solo para conectarse al servidor a través de Escritorio remoto.

Los beneficios serían:

• El respaldo sólido. Es posible que algunos desarrolladores no quieran hacer una copia de seguridad de sus computadoras de escritorio con regularidad, por lo que una solución central sería más confiable,
• La posibilidad, para cada desarrollador, de trabajar desde cualquier lugar. Con esto también me refiero a trabajar desde cualquier PC en la empresa. Digamos por la mañana, el desarrollador quiere condiciones de trabajo silenciosas. Él va a su propia habitación y trabaja allí. Luego quiere hacer un par de programación o trabajar en un entorno más social. Simplemente apaga su PC de escritorio, va a otra habitación donde hay diez computadoras y se conecta desde allí. No "Debo volver a cargar todas mis aplicaciones".

Bueno, hay varios problemas serios con eso, haciéndome pensar que nunca usaré algo así en los próximos años.

• Especificidad de las soluciones remotas. ¿Qué hay de trabajar a distancia usando varias pantallas de computadora a la vez? Quiero decir, ¿es fácil? ¿Es obvio? ¿Los accesos directos que uso a diario están habilitados cuando trabajo a distancia? No estoy muy seguro. ¿Qué sucede si presiono Ctrl + Shift + Esc para ver la lista de programas actualmente en ejecución? Oh sí, no funciona, así que ahora debo recordar haberlo hecho de una manera diferente.

• Golpe de rendimiento. No estoy seguro de que no habrá disminución del rendimiento en absoluto. Y recuerde, un programador que usa una computadora lenta es un programador infeliz. Y la compañía que hace que sus programadores estén descontentos con las malas condiciones nunca producirá software de alta calidad.

• Mayor impacto de un desastre. ¿Alojará la solución en un servidor redundante? ¿Tiene red redundante en su empresa? Digamos que el enrutador se cae y no es redundante. Significa que todos los desarrolladores ahora no pueden trabajar. En absoluto. Porque no tienen software instalado localmente. Porque ni siquiera tienen código fuente: está en el servidor. Entonces todos se detienen y usted paga a todas esas personas por hora solo para esperar que el enrutador sea reemplazado.

• Costos de hardware. Si se trata de un único servidor, ¿cuánto costará? Si tiene, digamos, veinte desarrolladores, ¿serían suficientes 64 GB de RAM en el servidor? No tan seguro. ¿Sería suficiente una solución de cuatro núcleos con dos CPU? De nuevo, tengo algunas dudas. De lo contrario, ¿en qué piensas? ¿Algún tipo de nube? ¿O tiene una solución escalable que funciona en varios servidores? ¿Está listo para pagar el costo de Windows Server (si usa Windows) por máquina?

• Costo de electricidad. Si trabaja de forma completamente remota, significa que gasta casi la misma cantidad de energía del lado del servidor que si estuviera trabajando localmente, más la cantidad de energía desperdiciada por la máquina local y la red.

• Licencias No estoy seguro de si debo expresarlo como un beneficio o un problema, pero creo que el costo de las licencias de software en este caso será mucho mayor.

Y nuevamente, piense en todos los costos de administración, soporte, implementación, mantenimiento. Con una solución personalizada como esta, puede convertirse fácilmente en algo enorme, sin contar que cada vez que algo falla, verá a todos los desarrolladores NOP dando vueltas, esperando poder continuar su trabajo.

Utilizamos instancias de Amazon ec2 a pedido como máquinas de desarrollo. Esto no tiene nada que ver con el costo. Tenemos un "grupo de desarrolladores" trabajando en varios proyectos, y necesitamos la capacidad de movernos rápidamente entre proyectos.

En general, la VM ahorra tiempo de configuración inicial. Pero a largo plazo, pierde tiempo debido a la pérdida de productividad. El costo no es un eje, porque el costo del desarrollador es mucho más que el costo de la máquina.

Los costos de productividad incluyen: tiempo necesario para iniciar una imagen de VM (varios minutos), poca capacidad de respuesta y limitaciones de recursos / memoria. Estos no son mucho inicialmente, pero con el tiempo se vuelven molestos.

En uno de nuestros proyectos, reestructuramos el código para simplificar la configuración inicial para "descargar código y ejecutar maven". Con este cambio, fue sencillo para un nuevo desarrollador comenzar a trabajar en el proyecto, y ahora nadie usa la imagen de VM de Amazon. Estamos buscando emular esto también en otros proyectos, pero llevará tiempo. Hasta entonces, tenemos nuestras imágenes ec2.

Ten mucho cuidado aquí. Recientemente fui implementado en un cliente donde todos en el departamento de TI tenían su VM esencialmente por la misma razón: para permitirles tener PC de gama baja en el escritorio y luego conectarse de manera remota a la VM y hacer su trabajo normal.

La experiencia allí no fue bonita. Al menos una vez por semana corríamos extremadamente lento por varias razones. En general, podríamos saber cuándo alguien en el equipo estaba ejecutando un conjunto de paquetes SSIS de procesador intensivo. Eventualmente nos trasladaron a algunos de nosotros a diferentes servidores, lo que ayudó a algunos, pero el rendimiento nunca fue el correcto.

Creo que si va a hacerlo, haga su diligencia debida en la potencia del servidor, sus necesidades de procesamiento, cuántas máquinas va a servir, etc. Podría ahorrarle algo de dinero, pero si no se implementa correctamente, puede causar MUCHO de dolores de cabeza

Tenga en cuenta: esto NO es una llama de la arquitectura VM, solo una advertencia para las personas que lo están investigando, asegúrese de tener a sus patos en fila antes de la implementación.

El desarrollo en máquinas virtuales puede funcionar bastante bien, pero solo si se hace correctamente:

• El hecho de que el uso de máquinas virtuales le permita tener una sola computadora para todo su equipo en lugar de una por desarrollador no significa que sea una buena idea
• Reiniciar no debería requerir abrir un ticket de soporte con un tiempo de respuesta de 24 horas
• Las máquinas virtuales de desarrollo no deben estar en un centro de datos a 5000 millas de distancia de los desarrolladores.
• Si bien los desarrolladores pueden administrar las máquinas virtuales y, por lo tanto, no son compatibles, eso no significa que no puedan acceder a servicios de red como el control de código fuente.
• La conexión de escritorio remoto debe ser estándar, no un applet personalizado de "alta seguridad" que convierta cualquier comilla escrita en diéresis.
• Obtener una nueva VM o reconstruir una existente debería llevar minutos, no semanas

He visto todos estos problemas, y no disfruto particularmente trabajar con ellos. Sin embargo, también tengo una configuración de VM en casa que uso por elección. Eso se ejecuta más rápido de lo que lo haría una instalación local y permite cosas como entornos separados para diferentes proyectos y reconstrucciones rápidas cuando un entorno se vuelve inestable.

Trabajo con máquinas virtuales, pero no lo recomiendo para su proyecto principal.

La razón por la que uso máquinas virtuales para el desarrollo es porque tengo que admitir proyectos heredados (por ejemplo, VB6, .NET 1.1, etc.) y no quiero ensuciar mi máquina principal al tener que instalar VS2003 / 2005 / vb6 / etc. ... Funciona bien, pero hay problemas intermitentes aquí y allá.

Además, la interacción es más lenta, las máquinas virtuales tardan un tiempo en iniciarse / apagarse, no tienen efectos de interfaz de usuario nativos (como Aero en Win7), etc.

Lo que va a ahorrar en términos de dinero que desperdiciará y más por la molestia que está a punto de imponer a su equipo. Además, como alguien mencionó aquí, no hay soporte para pantallas múltiples. Necesito al menos 3 pantallas para ser lo más productivo posible.

La regla # 1 de desarrollo es mantener contentos a sus desarrolladores. Encontrará que es casi imposible hacerlo con máquinas virtuales remotas. La compatibilidad con monitores múltiples es irregular, el retraso de la red y los problemas son problemáticos, y los ahorros de costos son generalmente mínimos.

Trabaje en máquinas virtuales, claro, pero también permita máquinas virtuales locales y haga que la computadora física sea una bestia ridículamente rápida también.

Teletrabajo al 100%, y entre mi ISP personal y la VPN, a pesar de la alta confiabilidad, tienen suficientes errores que me volverían loco si no pudiera trabajar en modo fuera de línea.

En general, simplemente giro una variedad de imágenes de VirtualBox y trabajo a partir de ellas. Copiar unos cientos de MB por cable no requiere mucho tiempo si necesita uno nuevo localmente.

Mi equipo implementó con éxito una configuración de "servidor lento de PC / VM rápida". Para un equipo de 20 desarrolladores, teníamos un servidor de 8 procesadores y 256 GB de RAM conectado a través de fibra a una SAN muy rápida. Era costoso, pero más barato que darle a cada desarrollador una estación de trabajo con un rendimiento similar. Para un equipo pequeño (4 desarrolladores), no estoy seguro de que las economías de escala entren en acción y realmente le ahorren algo.

Vale la pena mirar las máquinas virtuales para el desarrollo, pero el costo financiero es la razón incorrecta .

Esto se cubrió brevemente en la entrega experta .NET de Marc Holmes con NAnt & CruiseControl.net ; en resumen, el argumento para desarrollar en una VM es que desalienta cualquier aspecto del trabajo de depender de la configuración particular del desarrollador. Destruye tu VM al comienzo de cada proyecto y, a menos que realmente necesites una herramienta en particular, no sigue dando vueltas. Esto minimiza la probabilidad de que los cambios que realice se rompan en la máquina de nadie más que la suya. Los desarrolladores pueden llorar por que les quiten sus juguetes, pero en última instancia, confiar en las herramientas es una debilidad y cualquier cosa que no se pueda hacer intuitivamente en un ambiente limpio es un olor.

Tenga en cuenta que no necesariamente creo en los argumentos presentados anteriormente. Entiendo y hasta cierto punto me alineo con ellos, pero los estoy haciendo por razones de argumentos, para generar discusión.

Posibles inconvenientes

• Si el host de VM se cae ... está todo manguera. Si alguna vez has tenido un equipo de 20 personas, grita "¡GAH! al unísono ... no es divertido.
• Si está permitiendo instantáneas ... esas consumen recursos rápidamente. 20 personas * 10-20 instantáneas cada una de ellas ocupa mucho espacio en el disco duro (o al menos lo suficiente como para comenzar a causar problemas).
• Si encuentra problemas con el uso de recursos en el host, nuevamente, todos experimentan el dolor.

IME, es una buena solución y funciona, pero necesita un hardware decente en el host y cuando suceden cosas malas, le suceden a todos.

Esto falla uno de los criterios más importantes de la prueba de Joel.

Me aseguro de que todos mis desarrolladores tengan al menos una computadora portátil o de escritorio i3 o mejor con tanta RAM como sea posible.

8GB es por lo que me esfuerzo.

Los hace más productivos, y en realidad pueden ejecutar Virtual Box en sus máquinas locales para desarrollo y pruebas, en lugar de servidores costosos de mantener. Pueden tomar instantáneas de su Virtual Box para instalar cosas locas y probar diferentes navegadores e instaladores y todo y en segundos volver a una buena configuración conocida sin necesidad de contactar a los servicios de "TI".

Los desarrolladores necesitan las máquinas más rápidas de la empresa, con la mayor cantidad de RAM y permisos de root en sus máquinas locales. Fin de la historia.

He trabajado en máquinas virtuales antes para el desarrollo, tanto las máquinas virtuales locales (que se ejecutan en la PC local) como las remotas. Los locales eran mucho más agradables para trabajar que los remotos.

Las máquinas virtuales remotas, a las que nos conectamos mediante RDP, tenían un pequeño retraso entre cada pulsación de tecla y acción. Es posible desarrollarse bajo tales condiciones por un corto tiempo, pero día a día se volvió muy frustrante.

Felizmente desarrollé bajo una VM local en VMWare porque necesitaba ejecutar Flash Builder en una máquina Linux, y estuve bastante contento con él siempre que tuviera suficiente memoria, era bastante utilizable.

Hacemos eso para nuestras máquinas remotas y funciona bastante bien. La mayoría de las veces no se trabaja desde casa (normalmente solo para una reparación de emergencia aquí y allá), por lo que solo usamos netbooks de gama baja, conectados de forma remota a nuestras máquinas de escritorio rápidas en la oficina. Definitivamente son aún más lentos (probablemente limitados por la red más que nada), pero de vez en cuando trabajan para tareas cortas. Sin embargo, esto realmente no sería aceptable para un caballo de trabajo a tiempo completo, ya que VM con frecuencia puede causar un retraso que incluso con el mejor hardware, en mi humilde opinión, es un poco molesto.

En mi último trabajo, hicimos exactamente eso:

Utilizamos un Windows Terminal Server, donde cada desarrollador tenía una cuenta. Los desarrolladores todavía tenían PC normales (porque ya estaban allí), pero las PC solo ejecutaban el cliente RDP.

Hicimos el desarrollo de Java, por lo que el software utilizado fue el compilador de Java + IDE (principalmente Eclipse), más el navegador web, las herramientas de consulta de DB, el cliente de control de versiones y, en ocasiones, el software de oficina (OpenOffice.org en nuestro caso).

No encontramos ningún problema real, y el rendimiento fue bastante decente.

El único problema real es que realmente debe tener cuidado de no interrumpir a otros en algunas situaciones, porque está compartiendo un sistema. Cuando las operaciones de TI necesitaban hacer copias de archivos grandes o ejecutar copias de seguridad en el servidor, el rendimiento se degradaba para todos. Cuando identificamos y resolvimos esto (copiando con baja prioridad, o durante la noche), todo funcionó bien.

Por lo tanto, la advertencia es: evaluar el rendimiento lo antes posible y planificar su hardware y su uso en consecuencia.

TL; DR: Lo he hecho en múltiples trabajos y ahora lo prefiero.

El costo es la razón equivocada para enfocarse. Aquí hay algunos mejores.

Razones

• Consistencia de la plataforma en los diferentes entornos (desarrollo, prueba y producción).
  • Por qué: elimina completamente un vector de defectos, defectos de las diferencias de plataforma en diferentes entornos.
• Permite que los cambios en el sistema, como las actualizaciones, ocurran primero en vms de desarrollo, se verifiquen, se pongan a prueba, se verifiquen y entren en producción; todo mucho más fácil con vms de desarrollo (y prueba).
  • Por qué: control. Puedo hacer instantáneas, revertir, identificar los deltas, hacer el cambio en un servidor y propagar un éxito simplemente duplicando el vm, etc.
• A veces, los sistemas con los que se desarrolla solo están disponibles en una red segura. Alternativamente, el servidor en el que se ejecutará su software solo puede tener acceso limitado o diferentes características de red.
  • Por qué: la máquina virtual de desarrollo puede estar en la VLAN que tiene acceso al sistema o servicio bloqueado. Alternativamente, si el servidor de desarrollo tiene el mismo acceso limitado que el servidor de prueba y producción, nunca se trata de codificar accidentalmente un requisito en una característica de red o acceso que no estará disponible.

Desafíos

El desafío número uno es el desarrollo remoto, especialmente si tiene que pasar por una puerta de enlace o un servidor de salto. Lo hace difícil, especialmente si los desarrolladores no están bien formados (tienen algunos conocimientos de ingeniería de sistemas, conocimientos de redes, etc.).

Existen muchas variaciones de desarrollo remoto, pero generalmente se reducen a 2 diferencias principales.

• Ejecute sus herramientas de desarrollo en el entorno remoto y use protocolos como clientes RDP, clientes X11 remotos, etc.
• Ejecute sus herramientas de desarrollo localmente y use protocolos para sincronizar o ejecutar de forma transparente en el servidor remoto, a menudo usando ssh como capa de transporte.

Herramientas

Existen herramientas que ayudarán con el desarrollo remoto, y hay IDE que lo facilitan. Tendrá que investigar hasta qué punto es capaz de desarrollo remoto, muchos no están sin ejecutar en el mismo servidor en el que se está desarrollando el código. Sin embargo, hay otras herramientas.

• Secure Shell: las configuraciones de desarrollo remoto más exitosas usan ssh en mayor medida, usando inicios de sesión sin contraseña (usando autenticación de clave), multihops transparentes (resuelve el problema del servidor de salto) y otras opciones de configuración para mejorar el tiempo de respuesta. Nota: Siempre he tenido problemas al usar implementaciones de SSH que no son OpenSSH.
• GNU Screen / TMUX: multiplexores terminales. Screen es el abuelo de ellos y todavía se está fortaleciendo, pero creo que la mayoría de la gente ha comenzado a cambiar (o incluso a comenzar) en TMUX.
• Vim / Emacs : la vieja guardia, pero ambas funcionan muy bien para el desarrollo remoto de diferentes maneras. Es Vim, por lo que todo lo que necesita es un shell, mientras que Emacs puede ejecutarse localmente y usar TRAMP para el desarrollo remoto.

En una táctica ligeramente diferente: ¿ha entregado a sus gerentes / contadores una hoja de cálculo que destaque el costo del uso de estas máquinas lentas? Indíqueles que una solución de VM (a menos que se haga correctamente, y eso no es fácil) podría simplemente poner a los desarrolladores y, por lo tanto, a la compañía en el mismo barco.

Esto dependerá de la cantidad de poder administrativo que tenga sobre la instalación de VMware, si se le coloca en un subgrupo de baja prioridad, entonces tendrá máquinas lentas dependiendo de la actividad de otros subgrupos.

El hardware es barato, los programadores son caros.

¿Por qué querrías frustrar a tus programadores dándoles máquinas de desarrollo lento? El costo de actualizar el hardware no es nada comparado con el beneficio de rendimiento que obtendrán.

Pide mejores máquinas. Por lo menos pide 4 gb de ram. Agregar otra tableta de 2 gb se recuperará en menos de una semana.

La falta de soporte de doble pantalla siempre ha sido el factor decisivo. Simplemente no puedo imaginar hacer un trabajo de desarrollo significativo en una sola pantalla.

Ahora, hacen rock para pruebas / despliegue / violín, por lo que tampoco creo que deberían caerse de la pila.

Si tiene un mainframe con 50 discos SSD en RAID10, y solo usa 3-4 máquinas en ese mainframe, entonces podría funcionar.

De lo contrario, son lentos, muy lentos (aunque en algunos casos raros las instantáneas pueden compensar eso).

Tengo una máquina de escritorio decente en la oficina a la que puedo conectarme desde mi computadora portátil a través de VPN mediante el uso compartido de pantalla.

Funciona para incidentes de soporte fuera de horario y el trabajo remoto forzado ocasional. Sin duda, es mejor que mantener un entorno totalmente configurado en una segunda máquina, o para desarrollar cosas que necesitan baja latencia en el centro de datos a través de una WAN.

Sin embargo, es frustrante trabajar así durante largos períodos. En ocasiones, he conducido al trabajo durante la segunda mitad del día una vez que lo que sea que me mantuvo en casa se quitó del camino.

La latencia y el estado de la pantalla son los dos asesinos para mí.

No creo que quieras ir con una solución remota de VM. La conexión de red será el cuello de botella e incluso en una conexión rápida, puede ser suficiente para causar frustración. Nos estamos alejando de esta técnica para usar entornos de desarrollo local.

Desarrollamos en iMacs, lo cual es realmente agradable, pero nuestras aplicaciones web se ejecutan en un entorno Linux en Producción. El problema con esto es que eventualmente, podemos encontrar un problema que solo ocurre en Linux y podría ser difícil de solucionar. Ahí es donde entra el poder de las máquinas virtuales. Sin embargo, ni siquiera me gusta la idea de usar una VM el 100% del tiempo.

Recientemente me enteré de Vagrant (http://vagrantup.com/docs/getting-started/why.html) y Chef por hacer que trabajar con VirtualBox sea muy fácil. Vagrant le brinda la capacidad de iniciar fácilmente una VM cuando la necesita, y derribar una VM cuando no la necesita. Entonces podría hacer todo mi desarrollo usando mi Mac. Luego, cuando estoy listo para probar mi código, puedo iniciar una VM para probarlo, y solo mantenerlo todo el tiempo que lo necesite. Vagrant también le brinda la capacidad de compartir máquinas virtuales fácilmente con sus compañeros de trabajo para que todos puedan estar seguros de que están trabajando en el mismo entorno.

Recomendaría revisar Vagrant para que al menos conozca las opciones disponibles cuando se trata de desarrollar y trabajar con máquinas virtuales.

He estado trabajando en un proyecto heredado relacionado con 5 máquinas, cada una tiene un papel en una tubería de cómputo (la máquina 1 envía la solicitud a la máquina 2, que a su vez enviará la solicitud a la máquina 3, etc.). Sin embargo, la implementación de la configuración en la máquina virtual nos ahorró ENORME tiempo: 1. El sistema no se podía depurar ya que los desarrolladores eran perezosos / no tenían tiempo para incorporar las pruebas en el diseño. 2. Se implementaron demasiadas configuraciones y necesitaba perder tiempo organizándolas en grupos.

Ahora lo uso porque trabajo en demasiados proyectos a la vez. El principal problema que tengo ahora es: 1. Las máquinas virtuales consumen demasiado tiempo para mantener. 2. Las máquinas virtuales consumen enormes cantidades de memoria para ejecutarse

Esto hace que las máquinas virtuales sean difíciles de usar cuando intentas usarlas para tener orden. Mantenga una máquina principal con su correo electrónico y texto, desarrolle en máquinas virtuales desdiacalizadas. Mantiene su vida ordenada y limpia a un costo.

Como han dicho otros, realmente depende del problema que intente resolver con los escritorios de VM y luego sopesar los beneficios de resolver ese problema contra las desventajas en las que incurrirá el entorno de VM.

Estamos avanzando hacia un entorno híbrido donde todos nuestros desarrolladores en tierra tendrán máquinas físicas tradicionales, pero los desarrolladores en alta mar (que trabajan con una pequeña empresa de outsourcing en este momento) usarán escritorios virtuales. Los problemas que intentamos resolver con los escritorios remotos están relacionados con la seguridad y el rendimiento. El entorno virtual obviamente nos proporcionará un mayor control desde una perspectiva de seguridad y, para el rendimiento, solo transferiremos "píxeles modificados" en lugar de código fuente completo y tendremos que implementar servidores proxy y demás.

Todavía no estoy seguro de si este es el camino correcto, pero es hacia dónde nos dirigimos.