Reflexões sobre o desenvolvimento usando máquinas virtuais [fechado]

Vou trabalhar como líder de desenvolvimento para uma startup e sugeri que usássemos VMs para o desenvolvimento. Não estou falando de cada desenvolvedor ter um desktop com VMs para teste / desenvolvimento, quero dizer, ter um rack de servidor no qual todas as VMs são gerenciadas e fazer com que os desenvolvedores trabalhem a partir de um microPC localmente, ou mesmo remotamente, de um microPC (ChromeOS alguém?) computador.

Para mim, os benefícios são o fato de ser extremamente escalável, mais barato a longo prazo, mais fácil de gerenciar e utilizar o hardware em seu potencial máximo. Quanto aos contras, não consigo pensar em nenhum outro limitador de exibição em particular, além de precisarmos de alguém para configurar / manter essa configuração.

Eu esperava que alguns de vocês tivessem uma configuração semelhante em seu local de trabalho e pudessem ponderar suas opiniões. Obrigado.

O que você espera economizar, como uma fração do orçamento de desenvolvimento? Parece-me que você está preocupado com um epsilon. O custo das máquinas para desenvolvedores é inferior a 5% do custo total para manter um desenvolvedor na equipe. Portanto, a única questão importante é "isso poupará tempo aos desenvolvedores?" Poderia, se eles não precisassem gastar tempo instalando e atualizando o software de desenvolvimento. Ou pode custar tempo, se a rede ficar inativa, ou o servidor ficar inativo, ou, provavelmente, se a capacidade de resposta da rede estiver faltando um pouco. O desenvolvimento moderno depende da interação tecla a tecla com um IDE, ou pelo menos um editor muito inteligente. O atraso dessa interação em até algumas dezenas de milissegundos destrói a produtividade do desenvolvedor. Há também o custo para os desenvolvedores aprenderem essa nova maneira de trabalhar.

Essas não são objeções às VMs, mas objeções em potencial ao desenvolvimento remoto.

Acho que você está sendo tolo e insensato.

Primeiro de tudo, os custos da máquina são triviais em comparação com o custo de um desenvolvedor. Você deve trabalhar para maximizar a produtividade, não para minimizar o custo da máquina.

Segundo, a latência (não a largura de banda) é a chave para muitas tarefas de programação - especialmente a edição de texto. Para cada dólar / libra / euro que você economiza em máquinas para seus desenvolvedores, você gasta pelo menos dez em atualizações de rede para manter uma aparência de produtividade - e mesmo assim, eles provavelmente seriam mais produtivos se você economizasse fornecendo eles com Pentium III que você encontrou em uma lixeira em algum lugar.

Também acho que há um benefício substancial em fazer com que seus desenvolvedores usem um ambiente pelo menos razoavelmente próximo do esperado do usuário final de destino. Independentemente dos alvos oficiais de desempenho em uma especificação e tal, a maioria dos programadores baseia-se bastante em como o código "se sente" quando o testam. Quando eles estão usando um ambiente completamente diferente do usuário final, eles provavelmente perdem tempo com trivialidades enquanto ignoram completamente os principais problemas.

Por mais atraente que um ambiente homogêneo pareça do ponto de vista de suporte, você geralmente deve incentivar o máximo de variedade possível nas máquinas dos desenvolvedores. Os desenvolvedores raramente precisam de muito suporte de qualquer maneira, e saber imediatamente quando você tem código que falhará com um chip gráfico, CPU, adaptador de rede etc. mais do que paga o investimento mínimo.

Conclusão: se você está escrevendo um código que se destina (pelo menos principalmente) a ser usado em um ambiente de servidor virtualizado, você precisa fornecer isso aos seus desenvolvedores. Se você estiver fazendo isso de qualquer maneira para teste, também pode (mas não necessariamente) fazer sentido para o desenvolvimento. Da mesma forma, se você precisar (ou pelo menos tiver) de um servidor e rede severamente superespecificados, pode fazer sentido tirar vantagem disso usando o que você já tem disponível.

Sob circunstâncias mais típicas, no entanto, parece-me que é provável que isso introduza mais problemas do que resolve.

Essa foi uma das minhas idéias no passado: ter um servidor de alto desempenho com todo o software necessário e vários PCs de mesa de baixo desempenho que seriam usados ​​apenas para conectar-se ao servidor através da Área de Trabalho Remota.

Os benefícios seriam:

• O backup sólido. Alguns desenvolvedores podem não querer fazer backup de seus computadores desktop regularmente, portanto, uma solução central seria mais confiável,
• A possibilidade, para todo desenvolvedor, de trabalhar de qualquer lugar. Por isso, quero dizer também trabalhar em qualquer PC da empresa. Digamos que de manhã, o desenvolvedor queira condições de trabalho silenciosas. Ele vai para o seu próprio quarto e trabalha lá. Então ele quer fazer uma programação em pares ou trabalhar em um ambiente mais social. Ele simplesmente desliga o PC de mesa, vai para outra sala onde há dez computadores e se conecta a partir daí. Não "Preciso recarregar todos os meus aplicativos novamente".

Bem, existem vários problemas sérios com isso, fazendo-me pensar que nunca usarei algo assim nos próximos anos.

• Especificidade de soluções remotas. Que tal trabalhar à distância usando várias telas de computador ao mesmo tempo? Quero dizer, é fácil? Isso é óbvio? Os atalhos que uso diariamente estão ativados ao trabalhar à distância? Eu não tenho tanta certeza. E se eu pressionar Ctrl + Shift + Esc para ver a lista de programas em execução no momento? Ah, sim, não funciona, então agora devo me lembrar de fazê-lo de uma maneira diferente.

• Desempenho atingido. Não tenho certeza de que não haverá redução no desempenho. E lembre-se, um programador que usa um computador lento é um programador infeliz. E a empresa que deixa seus programadores descontentes com condições ruins nunca produzirá software de alta qualidade.

• Maior impacto de um desastre. Você hospedará a solução em um servidor redundante? Você tem rede redundante em sua empresa? Digamos que o roteador desligue e não seja redundante. Isso significa que todos os desenvolvedores agora não podem trabalhar. Em absoluto. Porque eles não têm software instalado localmente. Porque eles nem têm código-fonte: está no servidor. Então todo mundo para e você está pagando todas essas pessoas por hora apenas para esperar a substituição do roteador.

• Custos de hardware. Se for um único servidor, quanto custará? Se você tiver, digamos, vinte desenvolvedores, 64 GB de RAM no servidor seriam suficientes? Não tão certo. A solução quad-core com duas CPUs seria suficiente? Mais uma vez, tenho algumas dúvidas. Caso contrário, o que você pensa? Algum tipo de nuvem? Ou você tem uma solução escalável que funciona em vários servidores? Você está pronto para pagar o custo do Windows Server (se você usa o Windows) por máquina?

• Custo de eletricidade. Se você trabalha remotamente, significa que você gasta quase a mesma quantidade de energia do lado do servidor como se estivesse trabalhando localmente, mais a quantidade de energia desperdiçada pela máquina local e pela rede.

• Licenças. Não tenho certeza se devo colocá-lo como um benefício ou um problema, mas sinto que o custo do licenciamento de software nesse caso será muito maior.

E, novamente, pense em todos os custos de gerenciamento, suporte, implantação, manutenção. Com uma solução personalizada como essa, ela pode facilmente se tornar enorme, sem contar que toda vez que algo falhar, você verá todos os desenvolvedores por aí, esperando para poder continuar seu trabalho.

Usamos instâncias do Amazon EC2 sob demanda como máquinas de desenvolvimento. Isso não tem nada a ver com custo. Temos um "pool de desenvolvedores" trabalhando em vários projetos e precisamos da capacidade de avançar rapidamente entre os projetos.

Em geral, a VM economiza tempo de configuração inicial. Mas a longo prazo, perde tempo devido à perda de produtividade. O custo não é um eixo, porque o custo do desenvolvedor é muito maior que o custo da máquina.

Os custos de produtividade incluem - tempo gasto para iniciar uma imagem de VM (vários minutos), capacidade de resposta ruim e restrições de recursos / memória. Inicialmente, essas não são muitas, mas com o tempo elas se tornam irritantes.

Em um de nossos projetos, refatoramos o código para simplificar a configuração inicial para "baixar código e executar o maven". Com essa mudança, era simples para um novo desenvolvedor começar a trabalhar no projeto - e agora ninguém usa a imagem da VM da amazon. Também queremos imitar isso em outros projetos, mas isso levará tempo. Até lá, temos nossas imagens ec2.

Tenha muito cuidado aqui. Recentemente, fui implantado em um cliente em que todos os funcionários do departamento de TI tinham sua VM essencialmente pelo mesmo motivo - para permitir que eles tivessem PCs mais baixos na mesa e depois se conectarem remotamente à VM e fizessem seu trabalho normal.

A experiência não foi bonita. Pelo menos uma vez por semana, estávamos correndo muito devagar por vários motivos. Geralmente, podíamos saber quando alguém da equipe estava executando um conjunto de pacotes SSIS com uso intensivo de processador. Eles acabaram transferindo alguns de nós para servidores diferentes, o que ajudou alguns, mas o desempenho nunca foi bom.

Eu acho que se você for fazer isso - faça sua devida diligência na energia do servidor, suas necessidades de processamento, quantas máquinas você servirá, etc. Isso poderia economizar algum dinheiro, mas se não for implementado corretamente, pode causar MUITOS de dores de cabeça.

Observe: isso NÃO é uma chama da arquitetura da VM - apenas um aviso para as pessoas que estão olhando para ela - verifique se você tem seus patos seguidos antes da implementação.

O desenvolvimento em máquinas virtuais pode funcionar muito bem, mas apenas se bem:

• Só porque o uso de VMs permite que você tenha um único computador para toda a equipe, em vez de um por desenvolvedor, não significa que é uma boa ideia
• A reinicialização não deve exigir a abertura de um tíquete de suporte com um tempo de resposta de 24 horas
• As VMs de desenvolvimento não devem estar em um datacenter a 5.000 milhas de distância dos desenvolvedores.
• Embora as VMs possam ser gerenciadas por desenvolvedores e, portanto, sem suporte, isso não significa que elas não possam acessar serviços de rede, como controle de origem.
• A conexão da área de trabalho remota deve ser padrão, não um applet personalizado de "alta segurança" que converte as aspas digitadas em trema.
• Obter uma nova VM ou reconstruir uma existente deve levar minutos, não semanas

Eu já vi todos esses problemas e não gosto muito de trabalhar com eles. No entanto, também tenho uma configuração de VM em casa que uso por opção. Isso é executado mais rapidamente do que uma instalação local faria e permite coisas como ambientes separados para diferentes projetos e recriações rápidas quando um ambiente se torna instável.

Trabalho com VMs, mas não o recomendo para o seu projeto principal.

O motivo de eu usar VMs para desenvolvimento é porque tenho que dar suporte a projetos legados (por exemplo, VB6, .NET 1.1, etc ...) e não quero sujar minha máquina principal, tendo que instalar o VS2003 / 2005 / vb6 / etc ... Funciona bem, mas há problemas intermitentes aqui e ali.

Além disso, a interação é mais lenta, as VMs demoram um pouco para iniciar / desligar, não têm efeitos de interface do usuário nativos (como o Aero no Win7), etc.

Tudo o que você vai economizar em termos de dinheiro, você desperdiçará e muito mais com o aborrecimento que está prestes a impor à sua equipe. Além disso, como alguém mencionado aqui, não há suporte para várias telas. Preciso de pelo menos três telas para ser o mais produtivo possível.

A regra número 1 do desenvolvimento é manter seus desenvolvedores felizes. Você achará isso quase impossível de fazer com VMs remotas. O suporte a vários monitores é irregular, o atraso e os blips da rede são problemáticos e a economia de custos é geralmente mínima.

Trabalhe em VMs, claro, mas permita também VMs locais e faça do computador físico um animal ridiculamente rápido também.

Eu telecomuto 100% e entre o meu ISP pessoal e a VPN - apesar da alta confiabilidade - eles têm blips suficientes que me deixariam maluco se eu não pudesse trabalhar no modo offline.

Geralmente, apenas giro uma variedade de imagens do VirtualBox e trabalho com elas. A cópia de algumas centenas de MBs por cabo não exige muito tempo, se você precisar de um novo localmente também.

Minha equipe implementou com êxito uma configuração de "servidor lento para PC / VM rápida". Para uma equipe de 20 desenvolvedores, tínhamos um servidor de 8 processadores e 256 GB de RAM conectado via fibra a uma SAN muito rápida. Era caro, mas mais barato do que fornecer a cada desenvolvedor uma estação de trabalho com desempenho semelhante. Para uma equipe pequena (4 desenvolvedores), não tenho certeza de que as economias de escala aumentariam e realmente salvariam qualquer coisa.

Vale a pena examinar as VMs para desenvolvimento, mas o custo financeiro é o motivo errado .

Isso foi abordado brevemente no Expert .NET Delivery de Marc Holmes usando o NAnt & CruiseControl.net - em suma, o argumento para o desenvolvimento em uma VM é que desencoraja qualquer aspecto do trabalho de se tornar dependente da configuração específica do desenvolvedor. Você monitora sua VM no início de cada projeto e, a menos que você realmente precise de uma ferramenta específica, ela não fica por aí. Isso minimiza a probabilidade de que as alterações feitas sejam interrompidas na máquina de qualquer pessoa, exceto a sua. Os desenvolvedores podem chorar por ter seus brinquedos levados - mas, em última análise, confiar em ferramentas é uma fraqueza e tudo o que você não pode fazer intuitivamente em um ambiente limpo é um cheiro.

Note que eu não acredito necessariamente nos argumentos apresentados acima. Eu entendo e até certo ponto me alinhar com eles, mas estou fazendo-os por causa de argumentos, para gerar discussão.

Desvantagens potenciais

• Se o host da VM ficar inoperante ... você estará todo hospedado. Se você já teve uma equipe de 20 pessoas gritando "GAH! NÃO RESPONDEM !?" em uníssono ... não é divertido.
• Se você está permitindo fotos instantâneas ... elas consomem recursos rapidamente. 20 pessoas * 10 a 20 instantâneos, cada um deles ocupa muito espaço no disco rígido (ou pelo menos o suficiente para começar a causar problemas).
• Se você encontrar problemas com o uso de recursos no host, novamente, todos experimentarão a dor.

IME, é uma boa solução e funciona, mas você precisa de um hardware decente no host e quando coisas ruins acontecem, elas acontecem a todos.

Isso falha em um dos critérios mais importantes do teste de Joel.

Certifico-me de que todos os meus desenvolvedores tenham pelo menos um laptop ou desktop i3 ou melhor com tanta memória RAM quanto possível.

8 GB é o que eu me esforço.

Isso os torna mais produtivos e eles podem realmente executar o Virtual Box em suas máquinas locais para desenvolvimento e teste, em vez de manter servidores caros. Eles podem capturar instantaneamente sua Virtual Box, instalar coisas malucas e testar diferentes navegadores e instaladores e tudo mais e em segundos voltar a uma configuração boa conhecida sem a necessidade de entrar em contato com os serviços de "TI".

Os desenvolvedores precisam das máquinas mais rápidas da empresa, com mais permissões de RAM e root em suas máquinas locais. Fim da história.

Eu trabalhei em VMs antes para desenvolvimento, tanto VMs locais (em execução no PC local) quanto remotas. Os locais eram muito mais agradáveis ​​de se trabalhar do que os remotos.

As VMs remotas, às quais estávamos conectando pelo RDP, apresentavam um pequeno atraso entre cada pressionamento de tecla e ação. É possível desenvolver sob tais condições por um curto período de tempo, mas dia após dia se tornou muito frustrante.

Felizmente, desenvolvi-me em uma VM local no VMWare porque precisava executar o Flash Builder em uma máquina Linux e fiquei muito feliz com isso desde que tivesse memória suficiente - era bastante utilizável.

Fazemos isso para nossas máquinas remotas e funciona bastante bem. Raramente trabalhamos em casa (normalmente apenas para uma correção de emergência aqui e ali); portanto, usamos apenas netbooks de baixo custo, remotados em nossas rápidas máquinas de escritório no escritório. Eles definitivamente ainda são mais lentos (provavelmente limitados pela rede mais do que qualquer coisa), mas trabalham para tarefas curtas de vez em quando. Isso realmente não seria aceitável para um cavalo de trabalho em tempo integral, no entanto, uma vez que a VM pode frequentemente causar um pouco de atraso que mesmo com o melhor hardware, IMHO, é um pouco perturbador.

No meu último trabalho, fizemos exatamente isso:

Usamos um Windows Terminal Server, onde cada desenvolvedor tinha uma conta. Os desenvolvedores ainda tinham PCs regulares (porque eles já estavam lá), mas os PCs executavam apenas o cliente RDP.

Fizemos o desenvolvimento do Java, portanto, o software usado no local onde compilador Java + IDE (principalmente Eclipse), além de navegador da Web, ferramentas de consulta de banco de dados, cliente de controle de versão e ocasionalmente office sw (OpenOffice.org no nosso caso).

Não encontramos nenhum problema real e o desempenho foi bastante decente.

O único problema real era que você realmente precisa tomar cuidado para não atrapalhar os outros em algumas situações, porque está compartilhando um sistema. Quando as operações de TI precisavam fazer cópias grandes de arquivos ou executar backups no servidor, o desempenho diminuía para todos. Quando identificamos e resolvemos isso (copiando com baixa prioridade ou durante a noite), tudo teve um bom desempenho.

Portanto, a ressalva é: avalie o desempenho o mais rápido possível e planeje seu hardware e seu uso de acordo.

TL; DR: Eu fiz isso em vários trabalhos e agora prefiro.

O custo é o motivo errado para focar. Aqui estão alguns melhores.

Razões

• Consistência da plataforma nos diferentes ambientes (desenvolvimento, teste e produção).
  • Motivo: elimina completamente um vetor de defeito, defeitos de diferenças de plataforma em diferentes ambientes.
• Permite que alterações do sistema, como atualizações, ocorram primeiro nos vms de desenvolvimento, sejam verificadas, acumulem para testar, verifiquem e entrem em produção; tudo muito mais fácil com o desenvolvimento (e teste) vms.
  • Por que: Controle. Posso capturar instantâneos, reverter, identificar os deltas, fazer as alterações em um servidor e propagar um sucesso simplesmente duplicando a VM, etc.
• Às vezes, os sistemas contra os quais você desenvolve estão disponíveis apenas em uma rede segura. Como alternativa, o servidor em que o software será executado pode ter apenas acesso limitado ou características de rede diferentes.
  • Por que: A VM de desenvolvimento pode estar na VLAN que tem acesso ao sistema ou serviço bloqueado. Como alternativa, se o servidor de desenvolvimento tiver o mesmo acesso limitado que o servidor de teste e produção, nunca haverá a questão de codificar acidentalmente um requisito em uma característica de rede ou acesso que não estará disponível.

Desafios

O desafio número um é o desenvolvimento remoto, especialmente se você precisar passar por um gateway ou servidor de salto. Isso dificulta, especialmente se os desenvolvedores não são bem-arredondados (eles têm algum conhecimento de engenharia de sistema, conhecimento de rede, etc.).

Existem muitas variações de desenvolvimento remoto, mas elas geralmente se resumem a duas diferenças principais.

• Execute suas ferramentas de desenvolvimento no ambiente remoto e use protocolos como clientes RDP, clientes X11 remotos etc.
• Execute suas ferramentas de desenvolvimento localmente e use protocolos para sincronizar ou executar de forma transparente no servidor remoto, geralmente usando ssh como a camada de transporte.

Ferramentas

Existem ferramentas que ajudarão no desenvolvimento remoto e existem IDEs que o facilitam. Você precisará investigar até que ponto ele é capaz de desenvolvimento remoto; muitos não ficam sem rodar no mesmo servidor em que o código está sendo desenvolvido. No entanto, existem outras ferramentas.

• Shell Seguro: As configurações de desenvolvimento remoto mais bem-sucedidas usam ssh em maior grau, usando logins sem senha (usando autenticação de chave), multi-saltos transparentes (resolve o problema do servidor de salto) e outras opções de configuração para melhorar o tempo de resposta. Nota: Eu sempre tive problemas ao usar implementações não-OpenSSH do SSH.
• GNU Screen / TMUX: Multiplexadores de terminal. A tela é o avô deles e ainda está forte, mas acho que a maioria das pessoas começou a mudar (ou até começar) no TMUX.
• Vim / Emacs : A velha guarda, mas ambos funcionam muito bem para o desenvolvimento remoto de maneiras diferentes. É o Vim, então tudo o que precisa é de um shell, enquanto o Emacs pode ser executado localmente e usar o TRAMP para desenvolvimento remoto.

Em uma abordagem um pouco diferente - você forneceu aos seus gerentes / contadores uma planilha destacando o custo do uso dessas máquinas lentas? Saliente para eles que uma solução de VM (a menos que seja feita da maneira correta e que não seja fácil) pode simplesmente colocar os desenvolvedores e, portanto, a empresa no mesmo barco.

Isso dependerá da quantidade de energia administrativa que você possui sobre a instalação do VMware. Se você colocar um subconjunto de baixa prioridade, terá máquinas lentas, dependendo da atividade de outros subconjuntos.

O hardware é barato, os programadores são caros.

Por que você deseja que seus programadores fiquem frustrados, dando a eles máquinas de desenvolvimento lento? O custo da atualização do hardware diminui em comparação com os benefícios de desempenho que eles obterão.

Peça máquinas melhores. No mínimo, peça 4 GB de RAM. A adição de outro tablet de 2GB será recuperada em menos de uma semana.

A falta de suporte para tela dupla sempre foi a causa da morte. Não consigo imaginar um trabalho de desenvolvimento significativo em uma única tela.

Agora, eles são ótimos para testar / implantar / mexer, então não acho que devam cair da pilha também.

Se você tiver um mainframe com 50 discos SSD no RAID10 e usar apenas 3-4 máquinas nesse mainframe, ele poderá funcionar.

Caso contrário, eles estão atrasados, realmente atrasados ​​(embora, em alguns casos raros, o instantâneo possa compensar isso).

Eu tenho uma máquina de desktop decente no escritório à qual posso me conectar do meu laptop por VPN usando o compartilhamento de tela.

Ele funciona para incidentes de suporte fora de horas e ocasionalmente trabalho remoto forçado. Certamente é melhor do que manter um ambiente totalmente configurado em uma segunda máquina ou desenvolver coisas que precisam de baixa latência para o datacenter em uma WAN.

No entanto, é frustrante trabalhar dessa maneira por longos períodos. Ocasionalmente, fui trabalhar para a segunda metade do dia, uma vez que tudo o que me mantinha em casa foi tirado do caminho.

Latência e imóveis de tela são os dois assassinos para mim.

Eu não acho que você queira usar uma solução de VM remota. A conexão de rede será o gargalo e, mesmo em uma conexão rápida, pode ser suficiente para causar frustração. Estamos nos afastando dessa técnica para o uso de ambientes de desenvolvimento local.

Desenvolvemos no iMacs, o que é muito bom, mas nossos aplicativos da Web estão sendo executados em um ambiente Linux na Produção. O problema é que, eventualmente, podemos encontrar um problema que só acontece no Linux e pode ser difícil de solucionar. É aí que entra o poder das máquinas virtuais. No entanto, eu nem gosto da idéia de usar uma VM 100% do tempo.

Recentemente, aprendi sobre o Vagrant (http://vagrantup.com/docs/getting-started/why.html) e o Chef por tornar o trabalho com o VirtualBox super fácil. O Vagrant oferece a capacidade de iniciar facilmente uma VM quando você precisar e derrubar uma VM quando não for necessário. Para que eu pudesse fazer todo o meu desenvolvimento usando meu Mac. Então, quando estiver pronto para testar meu código, eu posso iniciar uma VM para testá-lo e mantê-lo apenas enquanto eu precisar. O Vagrant também permite compartilhar facilmente VMs com seus colegas de trabalho, para que todos possam ter certeza de que estão trabalhando no mesmo ambiente.

Eu recomendaria verificar o Vagrant para que você tenha pelo menos conhecimento das opções disponíveis quando se trata de desenvolver e trabalhar com VMs.

Eu tenho trabalhado em um projeto legado referente a 5 máquinas, cada uma delas tendo um papel em um pipeline de computação (a máquina 1 envia solicitação para a máquina 2, e por sua vez envia a solicitação para a máquina 3, etc.). A implantação da configuração na máquina virtual nos poupou MUITO tempo: 1. O sistema não podia ser comprado porque os desenvolvedores eram preguiçosos / não tinham tempo para incorporar os testes no design. 2. Muitas configurações foram implantadas e eu precisava gastar tempo organizando-as em grupos.

Agora eu uso porque trabalho em muitos projetos ao mesmo tempo. O principal problema que tenho agora é: 1. As VMs estão consumindo muito tempo para manter. 2. As VMs estão consumindo enormes quantidades de memória para executar

Isso torna as VMs difíceis de usar quando você tenta usá-las para ter ordem. Mantenha uma máquina principal com seu e-mail e texto, desenvolva em VMs dedicadas. Mantém sua vida arrumada e limpa a um custo.

Conforme declarado por outros, realmente depende do problema que você está tentando resolver com os desktops da VM e, em seguida, avalia os benefícios de resolver esse problema contra as desvantagens que o ambiente da VM terá.

Estamos caminhando para um ambiente híbrido, onde todos os nossos desenvolvedores onshore terão máquinas físicas tradicionais, mas os desenvolvedores externos (trabalhando com uma pequena empresa de terceirização no momento) usarão desktops virtuais. Os problemas que estamos tentando resolver com os desktops remotos estão relacionados à segurança e ao desempenho. O ambiente virtual obviamente nos proporcionará maior controle do ponto de vista da segurança e, para o desempenho, transferiremos apenas "pixels alterados" em vez do código fonte completo e teremos que implementar servidores proxy e tal.

Ainda não tenho certeza se este é o caminho certo a seguir, mas é para onde estamos indo.