Ambientes de desenvolvimento virtualizado em redes corporativas

Estamos tentando implementar um ambiente de desenvolvimento usando virtualização para uma pequena equipe de 4 desenvolvedores dentro de uma organização corporativa. Isso nos permitirá configurar ambientes separados de desenvolvimento, teste e preparação - além de permitir o acesso a novos sistemas operacionais que são requisitos para sistemas ou ferramentas que estamos avaliando. Repropomos uma máquina de classe de estação de trabalho existente, instalamos 24 GB de RAM e RAID-10 e estávamos indo bem até tentarmos adicionar a máquina ao domínio.

Agora, estamos iniciando a guerra que todos os desenvolvedores empresariais, desde o início dos tempos, tiveram que enfrentar - a luta pelo controle local de um ambiente de desenvolvimento e teste. A rede e os administradores de TI levantaram preocupações que variam de "ESX Server é o padrão da empresa" a "servidores não permitidos em VLANs de clientes" a "[preencher o espaço em branco] não é um conjunto de habilidades atualmente possuído no local ou organização de TI corporativa ".

Poderíamos justificar o hardware da classe de produção e o suporte formal de TI, se necessário, mas isso levaria tempo e envolveria muita dor de cabeça. Mesmo assim, pode levar meses para obter formalmente os recursos de TI designados, tratando-os como um sistema de produção - e mesmo se o fizéssemos, provavelmente perderíamos o controle local de que precisamos.

Eu imagino que muitos de vocês tiveram lutas semelhantes pelo controle do desenvolvedor de ambientes que não são de produção - e virtualização em particular -, então minhas perguntas são as seguintes:

1. Quais estratégias e argumentos ajudaram você a conquistar o pessoal da infraestrutura (TI e rede) para permitir que esses tipos de silos existam nas empresas que possuem políticas padrão de rede e segurança que geralmente (e compreensivelmente) impedem esse tipo de não ( infra-estrutura gerenciada centralmente)?
2. Você achou que isso é uma questão de justificativa técnica - ou mais uma luta política por controle e propriedade?
3. Se você acabou com um ambiente de desenvolvimento gerenciado por TI, qual foi o obstáculo para o desenvolvimento e testes diários?
4. Alguém acabou movendo seu ambiente de desenvolvimento para uma VLAN desconectada ou para uma rede totalmente separada para evitar essas dificuldades de acesso à rede?

Além disso, essa não é uma guerra santa entre o Hyper-V e o ESX (estaríamos bem com qualquer um - mas o Hyper-V foi selecionado porque é "gratuito" com o MSDN para esses fins [sim, o VMWare também possui ferramentas gratuitas - mas o boas ferramentas de gerenciamento geralmente não são] e seria mais fácil de gerenciar pelos desenvolvedores locais em uma "Microsoft Shop"). Portanto, argumentos a favor ou contra qualquer um estão fora do escopo desta questão.

Isso também é menos virtualização vs. hardware físico - suponho que a mesma pergunta possa ser feita sem o componente de virtualização da equação.

Suponha também que a equipe de desenvolvedores já tenha garantido o gerenciamento do gerenciamento de patches e antivírus ou a integração com os sistemas corporativos existentes, caso o suporte. Esse cenário, com perguntas diferentes, também é publicado no SF para, esperançosamente, obter o ponto de vista oposto.

Você saiu da reserva e está tentando justificá-la.

Não se trata de virtualização; É sobre controle e responsabilidade. O departamento de TI é responsável pela segurança e confiabilidade dos sistemas da empresa. Para garantir que eles funcionem, a TI os mantém sob seu próprio controle. Você criou um sistema que não está sob o controle da TI e agora está se tornando um problema.

Os motivos habituais pelos quais os programadores desejam seus próprios sistemas, na minha experiência, são:

• A TI não responde. Demora semanas para obter um novo ambiente, mas você precisa de um agora.
• Você precisa de controle; Eles não vão dar a você. Você precisa definir permissões, instalar componentes etc. A TI não permitirá.

Por fim, quando você for à produção, desejará um sistema gerenciado por TI completamente bloqueado. Mas enquanto você está desenvolvendo, você precisa de flexibilidade. Algumas sugestões:

• Fazer amigos. conhecer algumas pessoas em TI; Fale com eles cara a cara. Explique sua situação e pergunte a eles o que pode ser feito. Você pode obter direitos de administrador em um servidor dev simplesmente perguntando.
• Execute Local. Se você pode executar partes do aplicativo em suas máquinas locais, pode não precisar de um servidor ou pode se safar de uma instância de banco de dados bloqueada.
• Obter um patrocinador. Nada faz com que a TI se mova como um vice-presidente entrando e dizendo: "Por que você está bloqueando meu projeto?" Use a influência do seu patrocinador do projeto.
• Para a nuvem! Se o orçamento do seu projeto cobrir, basta hospedar no EC2 - você ignora todo o departamento de TI. Os riscos estão sendo invadidos e demitidos por deixar as informações da empresa fora do firewall.
• Execute o jogo longo. Coloque as solicitações de servidores administrados e autorizados corretamente com antecedência. Quando receber reclamações sobre o seu homebrew, diga que ainda está esperando nos servidores oficiais.
• Pré-alocar. Solicite servidores que você acha que pode precisar no futuro. Em seguida, redirecione-os quando você tiver necessidades reais.

Por mais que eu seja amador em situações como essas, parece que é necessário um argumento apropriado e bem construído para justificar aos chefes de departamento a necessidade de despesa extra (e expansão) dos recursos de TI. Você provavelmente quer um bom orador capaz de intermediar as questões e relacionar o valor potencial da proposta àqueles que acabam pagando por ela.

O problema é realmente aquele que merece consideração real: um grupo deseja o ambiente Dev, mas isso pressiona o outro grupo que se sente responsável, de fato, é responsável pela segurança do sistema como um todo, sendo as redes especialmente algo que a TI representa justificadamente. precioso sobre.

Parece-me que a capacidade de terceirizar certos recursos para um projeto potencialmente lucrativo ou mesmo apenas um ambiente gratuito para desenvolvedores foi substituída por uma racionalização de mercado da virtualização como uma medida de corte de custos e controle de recursos.

Agora, não me interpretem mal, não sou contra a virtualização, longe disso. Mas me ocorre que muitas vezes existem resons muito bons e explicáveis ​​para permitir que um grupo de desenvolvimento tenha direito a um reino separado que seria mais produtivo em um ambiente e potencialmente mais seguro do que simplesmente virtualizar tudo.

Certamente, uma empresa pode economizar dinheiro usando a nuvem para tarefas regulares entre departamentos entre escritórios, é muito útil lá. (é uma forma de virtualização, mas diferente, eu sei)

Mas suponha que um desenvolvedor gere um erro não identificável que não pode ser depurado porque há uma dúvida sobre se o aplicativo / programa foi interrompido devido a uma implementação de virtualização (ou seja, que não ocorreria em um computador independente) e, em seguida, ele torna-se contraproducente perder tempo tentando rastrear o bug que não está realmente na programação, mas na implementação da VM.

Espero estar sendo claro. Não tenho a resposta para o seu caso específico, mas acho que essas são considerações úteis em termos de problema, e eu recomendo fortemente que essas questões sejam discutidas de maneira aberta e completa com os dois departamentos envolvidos e, talvez, um representante da gestão empresarial que acabaria por defender a compra. Daí a minha sugestão de um bom orador ou intermediário!

Presumivelmente, se exigir mais funcionários, isso pode ser uma coisa positiva (há muitas pessoas desempregadas por aí), mas pode haver inteligência de TI suficiente na seção de desenvolvedores para adicionar uma função como administrador de servidor para seu próprio grupo?

Sei que é realmente muito importante, por isso não desejo ser irreverente, mas há momentos em que acho que a consolidação e a adição de papéis aos trabalhadores existentes impõem muita carga no seu tempo pessoal, o que eles tendem a se ressentir , especialmente quando poderiam fazer parte de algo radicalmente novo e bem-sucedido em engenharia de software.

Não invejo o seu problema, mas invejo o local de trabalho que está totalmente envolvido em trazer novos designs, novos softwares e novas idéias. Sinceramente, desejo a você boa sorte e espero que minhas contribuições sejam de alguma ajuda.

Mihaly

O departamento de TI realmente tem razão.

Eles provavelmente gerenciam milhares de aplicativos em centenas de sistemas. A única maneira de fazer isso com eficiência é ter algumas pilhas de software padrão selecionadas em execução em ainda menos configurações de hardware padrão.

Se você seguir esta rota, encontrará mais e mais problemas à medida que se aproxima da produção - no pior dos casos, precisará fatorar novamente o aplicativo inteiro para executar em um ambiente de produção padrão dias antes de entrar em operação.

Melhor trabalhar com o grupo de TI e pedir que eles configurem alguns ambientes de teste padrão para você, é para isso que eles são pagos. - Ironicamente, eles provavelmente configurarão uma máquina virtual para cada ambiente.

Os programadores devem programar, deixar que a equipe de infraestrutura de TI forneça a infraestrutura e a equipe de rede configure as redes - é assim que as empresas trabalham!

Além disso, se seu aplicativo não for tão padrão que a TI não considere criar um ambiente de teste - você terá zero chance de obtê-lo em produção. Fale com você, arquitetos corporativos, descubra quais ambientes são padrão e tente usá-los. Se você realmente não puder implementar seu aplicativo usando o software / hardware padrão, precisará fazer uma solicitação formal de arquitetura corporativa para aprovar sua infraestrutura como um caso excepcional.

Você terá que argumentar com a gerência que:

1. Ter o ambiente virtualizado atende a um ou mais dos requisitos especificamente declarados da empresa (como a flexibilidade de oferecer suporte a várias plataformas) e

2. Você pode implementá-lo em tempo hábil, com menos custo do que a TI e

3. Ter controle local reduzirá os custos e reduzirá os atrasos no mercado e

4. Você pode satisfazer as preocupações de segurança e manutenção de TI e

5. A produtividade do programador não será afetada.

O último é um grande se.   Eu discuti esse problema com várias pessoas especializadas nesse tipo de virtualização. Eles me dizem que, quando você lançar hardware suficiente para torná-lo tão responsivo quanto um PC local, não haverá economia de custos de hardware.

Portanto, sua economia de custo demonstrada terá que vir na forma de flexibilidade na configuração e na capacidade de alterar essas configurações a qualquer momento.