Environnements de développement virtualisés dans les réseaux d'entreprise

Nous tentons de mettre en œuvre un environnement de développement utilisant la virtualisation pour une petite équipe de 4 développeurs au sein d'une organisation d'entreprise. Cela nous permettrait de mettre en place des environnements de développement, de test et de mise en scène séparés - ainsi que de permettre l'accès à de nouveaux systèmes d'exploitation qui sont des exigences pour les systèmes ou les outils que nous évaluons. Nous avons redéfini une machine existante de classe station de travail, ajouté 24 Go de RAM et RAID-10, et nous nous en sortions bien jusqu'à ce que nous tentions de faire ajouter la machine au domaine.

Maintenant, nous commençons la guerre que tous les développeurs d'entreprise ont dû combattre depuis la nuit des temps - la lutte pour le contrôle local d'un environnement de développement et de test. Le réseau et les administrateurs informatiques ont soulevé des préoccupations allant de "ESX Server est la norme d'entreprise" à "les serveurs ne sont pas autorisés sur les VLAN clients" à "[remplir-le-blanc] n'est pas un ensemble de compétences actuellement détenu dans le local ou organisation informatique d'entreprise ".

Nous pourrions justifier le matériel de production et le support informatique formel si nous le devions, mais cela prendrait du temps et impliquerait beaucoup de maux de tête. Même alors, cela pourrait prendre des mois pour obtenir officiellement des ressources informatiques attribuées en traitant cela comme un système de production - et même si nous le faisions, nous perdrions probablement le contrôle local dont nous avons besoin.

J'imagine que beaucoup d'entre vous ont eu des luttes similaires pour le contrôle des environnements de non-production par les développeurs - et la virtualisation en particulier - donc mes questions sont les suivantes:

1. Quelles stratégies et quels arguments vous ont aidé à conquérir les gens de l'infrastructure (informatique et réseau) pour permettre à ces types de silos d'exister dans les entreprises qui ont des politiques de réseau et de sécurité standard en place qui empêcheraient généralement (et naturellement) ce type de non ( infrastructure gérée de manière centralisée?
2. Avez-vous trouvé que c'était une question de justification technique - ou plus d'une lutte politique pour le contrôle et la propriété?
3. Si vous vous êtes retrouvé avec un environnement de développement géré par l'informatique, quel obstacle a-t-il constitué pour le développement et les tests quotidiens?
4. Quelqu'un at-il fini par déplacer son environnement de développement vers un VLAN déconnecté ou un réseau entièrement séparé pour éviter ces difficultés d'accès au réseau?

En outre, ce n'est pas une guerre sainte Hyper-V contre ESX (nous serions d'accord avec les deux - mais Hyper-V a été sélectionné car il est "gratuit" avec MSDN à ces fins [oui, VMWare a aussi des outils gratuits - mais le les bons outils de gestion ne le sont généralement pas], et seraient plus faciles à gérer par les développeurs locaux dans une "boutique Microsoft") - donc les arguments pour ou contre l'un ou l'autre sortent du cadre de cette question.

C'est aussi moins une virtualisation que du matériel physique - je suppose que la même question pourrait être posée sans le composant de virtualisation à l'équation.

Supposez également que l'équipe de développement a déjà pris des assurances pour gérer la gestion des correctifs et l'antivirus, ou s'intégrer aux systèmes d'entreprise existants si elle le prend en charge. Ce scénario, avec différentes questions, est également publié sur SF pour, espérons-le, susciter le point de vue opposé.

Vous êtes sorti de la réserve et essayez de le justifier.

Il ne s'agit pas de virtualisation; C'est une question de contrôle et de responsabilité. Le service informatique est responsable de la sécurité et de la fiabilité des systèmes de l'entreprise. Pour s'assurer qu'ils fonctionnent, l'informatique les garde sous leur propre contrôle. Vous avez construit un système qui n'est pas sous le contrôle de l'informatique et cela devient maintenant un problème.

D'après mon expérience, les programmeurs veulent généralement que leurs propres systèmes soient:

• IL n'est pas réactif. Il faut des semaines pour obtenir un nouvel environnement, mais vous en avez besoin maintenant.
• Vous avez besoin de contrôle; Ils ne vous le donneront pas. Vous devez être en mesure de définir des autorisations, d'installer des composants, etc. Le service informatique ne vous le permet pas.

En fin de compte, lorsque vous passerez en production, vous voudrez un système géré par les TI qui soit complètement verrouillé. Mais pendant que vous développez, vous avez besoin de flexibilité. Quelques suggestions:

• Se faire des amis. faire connaissance avec des informaticiens; Parlez-leur face à face. Expliquez votre situation et demandez-leur ce qui peut être fait. Vous pouvez peut-être obtenir des droits d'administrateur sur un serveur de développement simplement en le demandant.
• Exécutez local. Si vous pouvez exécuter des parties de l'application sur vos machines locales, vous n'avez peut-être pas besoin d'un serveur ou vous pouvez vous en sortir avec une instance de base de données verrouillée.
• Obtenez un sponsor. Rien ne fait bouger l'informatique comme un vice-président entrant et disant: "Pourquoi bloquez-vous mon projet?" Utilisez l'influence de votre parrain de projet.
• Vers le cloud! Si le budget de votre projet le couvrira, hébergez simplement sur EC2 - vous contournez tout votre service informatique. Les risques sont piratés et licenciés pour avoir laissé des informations sur l'entreprise en dehors du pare-feu.
• Exécutez le Long Game. Envoyez rapidement les demandes de serveurs correctement autorisés et administrés. Lorsque vous recevez des plaintes concernant votre homebrew, dites que vous attendez toujours sur les serveurs officiels.
• Préallouer. Demandez des serveurs dont vous pensez avoir besoin à l'avenir. Puis redéfinissez-les lorsque vous avez des besoins réels.

Autant je suis amateur dans des situations comme celles-ci, il semble qu'un argument approprié et bien construit soit nécessaire pour justifier auprès des chefs de service la nécessité des dépenses (et de l'étendue) supplémentaires des ressources informatiques. Vous voulez probablement un bon orateur capable d'intervenir sur les problèmes et de relier la valeur potentielle de la proposition à ceux qui finissent par la payer.

Le problème est en fait un problème qui mérite une réelle considération: un groupe veut l'environnement de développement, mais cela met une certaine pression sur l'autre groupe qui se sent responsable, en effet est responsable de la sécurité du système global, le réseautage étant particulièrement quelque chose que les services informatiques sont à juste titre précieux sur.

Il me semble que la possibilité de délocaliser certaines ressources pour un projet potentiellement lucratif ou même simplement un environnement gratuit pour les développeurs a maintenant été remplacée par une rationalisation du marché de la virtualisation en tant que mesure de réduction des coûts et de contrôle des ressources.

Maintenant, ne vous méprenez pas, je ne suis pas contre la virtualisation, loin de là. Mais il me vient à l'esprit qu'il existe souvent de très bonnes et explicables raisons pour permettre à un groupe de développement d'avoir droit à un domaine distinct qui serait plus productif dans un environnement et potentiellement plus sûr que de simplement tout virtualiser.

Bien sûr, une entreprise peut économiser de l'argent en utilisant le cloud pour des tâches de bureau inter-bureaux régulières, c'est très utile là-bas. (c'est une forme de virtualisation, mais différente, je sais)

Mais supposons qu'un développeur soulève une erreur non identifiable qui ne peut pas être déboguée car il y a une question de savoir si l'application / le programme s'est cassé en raison d'une implémentation de la virtualisation (c'est-à-dire qu'il ne se produirait pas sur un ordinateur autonome), puis il devient contre-productif pour perdre du temps à essayer de retrouver le bogue qui n'est pas réellement dans la programmation, mais dans l'implémentation de la machine virtuelle.

J'espère que je suis clair. Je n'ai pas de réponse pour votre cas spécifique, mais je pense que ce sont des considérations, espérons-le, utiles en termes de problème, et je recommanderais fortement que ces questions soient discutées ouvertement et pleinement avec les deux ministères concernés, et peut-être un représentant de la la direction de l'entreprise qui devra finalement faire valoir les achats. D'où ma suggestion d'un bon orateur ou intermédiaire!

Vraisemblablement, si cela nécessite plus d'employés, cela pourrait être une chose positive (il y a beaucoup de chômeurs), mais il pourrait y avoir suffisamment d'intelligence informatique dans la section développeur pour ajouter un rôle d'administrateur de serveur pour leur propre groupe?

Je sais que c'est en fait assez important, donc je ne veux pas être désinvolte, mais il y a des moments où je pense que la consolidation et l'ajout de rôles aux travailleurs existants imposent beaucoup trop de temps personnel, ce qu'ils ont tendance à ressentir avec ressentiment , surtout quand ils pourraient faire partie de quelque chose de radicalement nouveau et de génie logiciel réussi.

Je n'envie pas votre problème, mais j'envie le milieu de travail qui est pleinement engagé dans la création de nouveaux designs, de nouveaux logiciels et de nouvelles idées. Je vous souhaite sincèrement bonne chance et j'espère que mes contributions vous seront utiles.

Mihaly

Le service informatique a en fait un point.

Ils gèrent probablement des milliers d'applications sur des centaines de systèmes. La seule façon de le faire efficacement est de disposer de quelques piles logicielles standard sélectionnées fonctionnant sur encore moins de configurations matérielles standard.

Si vous suivez cette voie, vous rencontrerez de plus en plus de problèmes au fur et à mesure que vous vous rapprocherez de la production - dans le pire des cas, vous devrez reformuler toute l'application pour qu'elle s'exécute dans un environnement de production standard quelques jours avant la mise en service.

Mieux vaut travailler avec le groupe informatique et leur demander de configurer des environnements de test standard pour vous, c'est pour cela qu'ils sont payés. - Ironiquement, ils vont probablement configurer une machine virtuelle pour chaque environnement.

Les programmeurs doivent programmer, laisser les gars de l'infrastructure informatique fournir l'infrastructure et les gars du réseau configurer les réseaux - c'est comment les entreprises fonctionnent!

De plus, si votre application n'est pas si standard que l'informatique n'envisagera pas de créer un environnement de test - vous n'aurez aucune chance de la mettre en production. Discutez avec vos architectes d'entreprise pour savoir quels environnements sont standard et essayez de les utiliser. Si vous ne pouvez vraiment pas implémenter votre application à l'aide du logiciel / matériel standard, vous devez faire une demande formelle d'architecture d'entreprise pour approuver votre infrastructure comme un cas exceptionnel.

Vous devrez faire valoir votre argument auprès de la direction qui:

1. Le fait que l'environnement virtualisé réponde à une ou plusieurs des exigences spécifiques de l'entreprise (telles que la flexibilité de prendre en charge plusieurs plates-formes), et

2. Vous pouvez l'implémenter plus rapidement, à moindre coût que l'informatique, et

3. Le contrôle local réduira les coûts et réduira les délais de commercialisation, et

4. Vous pouvez répondre aux préoccupations de sécurité et de maintenance des TI, et

5. La productivité du programmeur ne sera pas affectée.

Le dernier est un gros si.   J'ai discuté de ce problème avec un certain nombre de personnes spécialisées dans ce type de virtualisation. Ils me disent qu'au moment où vous lancez suffisamment de matériel pour le rendre aussi réactif qu'un PC local, il n'y aura pas d'économies de matériel.

Ainsi, vos économies de coûts démontrées devront prendre la forme d'une flexibilité de configuration et de la possibilité de modifier ces configurations à tout moment.