Discussion :

[Nithril]

Bonjour,

Une station de travail performante est de mon point de vu indispensable au développeur pour un certain nombres de raison dont celle de l'efficacité.
Le cout de 5min de perdus sur une journée a cause d'un matériel peu performant c'est à la fin de l'année à minima 1000€ de perdu.

Une station de travail performante a un cout et force est de constater qu'un développeur code, build, test, discute, surf, boit du café. Le taux d'utilisation des ressources est bas et soumis à des pics de monté en charge (build, lancement de taches...) qu'il est important de traiter rapidement.

La question que je me pose pour rationaliser les ressources est la suivante : Est il viable (economiquement et ergonomiquement) de mettre en place un serveur puissant support de l'environnement de développements via un accès par remote desktop ? Cette question est restreinte au type de développements de type GUI ou Web n'ayant pas de contrainte graphique forte.


Les avantages

• Il permet de conserver son environnement de travail en cas de télétravail (si connexion internet suffisante)
• Maintenance plus aisée (sauvegarde, création d'user...)
• Il offre théoriquement des performances supérieures
• Rationnalise les ressources
• Scale in possible et qui impacte tous le monde (ajout de RAM, disques...)

Les inconvénients

• Retour aux années des terminaux
• Administration plus ardue notamment si les environnements des développeurs sont hétérogènes
• Une panne impacte tous les développeurs
• La réactivité/ergonomie est elle au rendez vous ?
• Gourmand en réseau ?

J'ai créé un fichier Excel pour simuler le cout des deux scénarii sur la base d'une équipe de 14 développeurs.

Les deux scenarii en concurrences sont les suivants :

1. Un serveur puissant (5000€) + N stations bureautique (350€)
2. N stations de travail (1100€)

Le premier scénario est a première vu (sur le cout matériel) plus économique.


Qu'en pensez vous ?

[Chatanga]

Il existe des restrictions sur le type de développement réalisable ou bien cette étude s'en veut indépendante ? Par exemple, si l'équipe de développement réalise une application graphique sollicitant le matériel graphique (SIG, jeu vidéo, etc.), je vois mal comment ça pourrait fonctionner. En fait, le simple fait d'avoir une instance d'EDI (du genre Eclipse plutôt que Emacs) ouverte "sur" chaque poste développeur risque d'être une épreuve pour le réseau.

[Nithril]

Il existe des restrictions sur le type de développement réalisable ou bien cette étude s'en veut indépendante ? Par exemple, si l'équipe de développement réalise une application graphique sollicitant le matériel graphique (SIG, jeu vidéo, etc.), je vois mal comment ça pourrait fonctionner. En fait, le simple fait d'avoir une instance d'EDI (du genre Eclipse plutôt que Emacs) ouverte "sur" chaque poste développeur risque d'être une épreuve pour le réseau.

Effectivement, elle est restreinte a des type de développements de type GUI ou Web n'ayant pas de contrainte graphique forte. Je modifie mon poste.

Les remotes intelligent desktops n'envoient il me semble que les événements d'affichage et non pas des images. Je rajoute la contrainte réseau

[chaplin]

Si l'environnement est virtualisé, avec une machine puissante, pour y avoir gouter, c'est impressionnant.

[gangsoleil]

Bonjour,

Si tu ne travailles pas dans un environnement defense, il faut aussi voir que les developpeurs ont besoin de pouvoir acceder au net, a leur mail, ... , et qu'il faut donc dimensionner le reseau et le(s) serveur(s) pour cela.

Par ailleurs, il est necessaire de prevoir un serveur de secours, ainsi que des back-ups reguliers (mais ce dernier point est vrai dans les deux cas).

Un dernier point : il n'est pas possible d'utiliser ce modele si les developpements sont trop bas niveau, car les (des)installations penalisent tout le monde, et la virtualisation fait naitre des problemes qui n'existent pas dans la realite.

[el_slapper]

L'avantage de la virtualisation, c'est aussi que ça permet d'avoir plusieurs développements paralèlles. Quand on créée des scripts dont l'execution est assez longue(quelles que soit la performance de la machine), c'est un confort immense, que j'ai fortement apprécié quand j'ai fait des scripts de tests automatisés d'interface.

Bon, mais en fait, dire ça, ça revient à faire +1 avec les autres; la vraie réponse est "ça dépend".

[Nithril]

Bonjour,

Si tu ne travailles pas dans un environnement defense, il faut aussi voir que les developpeurs ont besoin de pouvoir acceder au net, a leur mail, ... , et qu'il faut donc dimensionner le reseau et le(s) serveur(s) pour cela.

Par ailleurs, il est necessaire de prevoir un serveur de secours, ainsi que des back-ups reguliers (mais ce dernier point est vrai dans les deux cas).

Un dernier point : il n'est pas possible d'utiliser ce modele si les developpements sont trop bas niveau, car les (des)installations penalisent tout le monde, et la virtualisation fait naitre des problemes qui n'existent pas dans la realite.

L'idée est d'avoir un serveur puissant support des environnements de développement et pour chaque développeur un petit ordinateur pour se connecter en remote desktop au serveur, pour faire des taches de type bureautique et pour accéder au net.

Sur l'aspect réseau, je suis preneur d'avis technique. Je fais du remote desktop sur un serveur chez OVH sans trop de soucis et cela sans disposer d'une connexion internet surpuissante.

Le scénario 1 est sensible au panne matériel qui impacterait tous les développeurs. Soit effectivement un serveur de secours, soit des spares de rechange sur les éléments les plus sensibles.

[Nithril]

L'avantage de la virtualisation, c'est aussi que ça permet d'avoir plusieurs développements paralèlles. Quand on créée des scripts dont l'execution est assez longue(quelles que soit la performance de la machine), c'est un confort immense, que j'ai fortement apprécié quand j'ai fait des scripts de tests automatisés d'interface.

Bon, mais en fait, dire ça, ça revient à faire +1 avec les autres; la vraie réponse est "ça dépend".

J'ai négocié avec mon admin sys une mise à dispo d'une machine libre pour faire des tests. Je vais bien voir ce que cela donne

[iMeee]

Perso, je suis plus pour la solution du remote desktop.
Pour le développement web, GUI et console ça ne pose pas de soucis.
Le remote desktop (ainsi que la virtualisation du serveur en sus) permettent une meilleure utilisation des ressources (ça ne sert à rien d'avoir une bête de course pour chaque développeur), un télé-travail (éventuellement changer de poste dans la journée, sans terminer une session en cours).

Il y a peu j'ai essayé LTSP, une sorte de terminal serveur pour Linux. Je dois dire que j'ai été mis sur le cul, c'est réellement de la bombe.
En fait, les clients légers chargent une sorte de mini image par PXE (en réseau) et ensuite utilisent une sorte de bureau à distance (et c'est invisible). C'est bien plus fluide que Windows, les vidéos en HD passent sans soucis sur de vieilles machines, avec le son, etc ...

[LLB]

1. Un serveur puissant (5000€) + N stations bureautique (350€)
2. N stations de travail (1100€)

Le premier scénario est a première vu (sur le cout matériel) plus économique.

Le coût matériel n'est-il pas négligeable à côté des salaires ? Si une solution permet de gagner un peu de confort au développeur, ça compensera largement les quelques centaines d'euros d'écart. En fait, je pense que, même si la solution de travailler sur un serveur est retenue, il vaudrait mieux payer en plus des stations de travail correctes aux développeurs (pour ma part, je le prendrais mal si mon employeur me donnait une machine peu puissante), car ils auront toujours besoin de faire des choses en local.

Au niveau confort, je préfère de loin avoir ma station de travail où je suis maître de la machine. Chacun devrait pouvoir utiliser les logiciels adaptés, même si ce sont des IDE assez lourds (Visual Studio, Eclipse).

Il permet de conserver son environnement de travail en cas de télétravail

Même si chacun a sa station de travail, il peut être possible de s'y connecter à distance pour du télétravail.

[Nithril]

Le coût matériel n'est-il pas négligeable à côté des salaires ? Si une solution permet de gagner un peu de confort au développeur, ça compensera largement les quelques centaines d'euros d'écart. En fait, je pense que, même si la solution de travailler sur un serveur est retenue, il vaudrait mieux payer en plus des stations de travail correctes aux développeurs (pour ma part, je le prendrais mal si mon employeur me donnait une machine peu puissante), car ils auront toujours besoin de faire des choses en local.

Au niveau confort, je préfère de loin avoir ma station de travail où je suis maître de la machine. Chacun devrait pouvoir utiliser les logiciels adaptés, même si ce sont des IDE assez lourds (Visual Studio, Eclipse).

Même si chacun a sa station de travail, il peut être possible de s'y connecter à distance pour du télétravail.

L'objectif est que le travail sur le serveur soit transparent et qu'il n'apporte pas moins de confort qu'une station de travail. Je dirais même au contraire, qu'il apporte plus de confort.

Dans ce scénario, le développeur est maitre de sa machine, mais d'une machine de type desktop. Il peut installer/lancer les applications "bureautique" qu'il souhaite.

[Madmac]

Dans le domaine de la programmation, je ni crois tout simplement pas. Chaque programmeur a sa façon de procéder. Et cela implique souvent des logiciels secondaires qui sont important dans sa façon de programmer.

Par exemple, j'adore le système de fenêtre multiple sous Linux. Travailler avec une seule fenêtre me semble maintenant infernal. Le travail de programmeur peut-être passablement frustrant, alors j'accepterais mal de travailler dans une entreprise qui m'imposerait un environnement qui manquerait de flexibilité.

Quand on me parle des systèmes "dans les nuages", je ne peux m'empêcher de penser à la gaffe de IBM qui croyait qu'il n'y avait pas d'avenir dans les ordinateurs personnels.

[fregolo52]

Quand on me parle des systèmes "dans les nuages", je ne peux m'empêcher de penser à la gaffe de IBM qui croyait qu'il n'y avait pas d'avenir dans les ordinateurs personnels.

Humm, il ne faut pas confondre, le Cloud computing est plutôt fait pour des applis avec une config commune à tous les utilisateurs.

Remote Desktop est-elle la bonne solution ?
Comme le dit chaplin, il y a la virtualisation (Citrix & Co), c'est peut-etre moins gourmand en ressource réseau. Mais là, tu pleurs avec le prix des licences.

Nithril, dans ta configuration, tu as oublié le prix de la licence Terminal Server.

[ovh]

Le remote desktop ne me semble pas adapté pour développer :
- Pas d'interaction avec son poste, or selon les cas on peut devoir faire des tests système, ou utiliser le système de fichier à un emplacement commun qui pénaliserait donc les autres développeurs ou mettraient en péril la stabilité de la machine. De plus, le multi-écran est plus délicat à utiliser en remote desktop, or c'est une fonctionalité super pratique (typiquement la doc sur un écran, le code sur l'autre).
- Lourde charge réseau malgré tout, et surtout dépendance totale au réseau, la moindre coupure de 5 minutes et tout le monde est bloqué.

Je pense que les postes de travail d'aujourd'hui sont tous suffisamment puissants pour faire tourner les outils de dev modernes. Pour les applications de gestion, tu peux à la rigueur déporter la DB de dev sur un serveur, en créant une instance par développeur (pour éviter les conflits de données et de structures qui évoluent).

Sinon pour la nécessité d'avoir un environnement unique depuis différents endroits, tu peux toujours créer une image virtuelle comprenant tous les outils préconfigurés, que le développeur peut exécuter sur n'importe quel poste et retrouver instantanément tout son environnement. C'est ce que j'utilise personnellement pour bosser indifféremment sur mon poste fixe ou sur mon portable.

[Luc Hermitte]

Hum. J'ai déjà pratiqué la config très gros serveur sun/solaris en machine de dev (espaces persos, chaines de compils, etc). Nous connectés via PC/exceed.
J'étais le seul à être totalement immergé à distance (l'avantage d'être un vimmeur) et cela ne me posait aucun problème, bien au contraire.
Les machines de tests étaient d'autres serveurs, plus petits et dédiés à la finalité.
Et le multi-écran marchait très bien.

Franchement, je ne vois pas où est le problème pour développer.