Certaines boîtes ont une activité qui ne convient pas à ce type de service et qui rend ces externalisations à la fois plus coûteuses en temps, en ressources humaines (mais ventilé sur les utilisateurs, alors ça compte moins qu'un poste d'admin aux yeux du patron) et en ressources matérielles (consommation et machines).
Il va falloir le démontrer tout ça... De mon expérience (je ne travaille qu'on premise) :
en temps : l'an dernier on s'est acheté des serveurs F5 entre notre décision de passer par eux et leur mise en prod il s'est passé 9 mois, prendre du LB AWS aurait pris probablement moins de 2 mois (je compte l'accord d'achat, les tests sur un environnement de qualification, les benchmark puis le passage en prod)
en ressources humaines : on a 2 personnes à temps pleins pour gérer des machines, on a une intervention régulière du fabriquant des serveurs/routeurs/onduleurs (au moins une intervention sur site tous les 3 mois) pour nos F5 on a eu 2 interventions d'une semaine d'un formateur/intégrateur (toujours sur site). L'arrivé de nouveaux nous a demandé de revoir le montage électrique complet de notre salle serveur et à couler une dalle de béton car le poids des nouvelles baies est trop grand pour les espèce que faux sols (comme des faux plafonds mais au sol) que l'on avait).
en ressources matérielles nos machines sont dimensionnées pour les pique de charge que l'on a certaines semaines entre 19 et 21h le reste du temps on a beaucoup moins de charge (les pique doivent faire une fois 10 par rapport à la moyenne). On a pas de solution à l'heure actuelle pour démarrer dynamiquement des machines et les intégrer à notre cluster en fonction de la charge ou de l'heure, ça pourrait être une idée mais c'est plutôt complexe à mettre en place et ça aurait ses limites (nos machines de bases de données n'ont pas à être dynamiques, on va de toute manière garder 2 machines par fonction pour éviter qu'un serveur qui tombe impact le service).
On est mono site, tu peux quasiment tout doubler si tu veux faire du multi site (pour faire survivre ton service à des problèmes plus conséquent). Avec tout ça il y a aussi le roulement standard, comme vérifier régulièrement que nos 2 lignes internet fonctionne bien et qu'on bascule bien en cas de perte de l'une des 2.
On fait ça parce qu'on veut vraiment pas que nos données soient gérées ailleurs que chez nous, mais on est conscient que ça représente au contraire un coût considérable. L'utilisation d'un PAAS permettrait de réduire tout ça, mais on resterait sur des machines sur dimensionnée.
Qu'il y ai des cas où ce soit mieux d'être on premise, je n'en doute pas. Mais dans le cas générale tu gagne beaucoup à passer sur un cloud (à qualité de service identique évidement).
[^] # Re: Minimalisme
Posté par barmic 🦦 . En réponse au journal Tout cela me fatigue.... Évalué à 3.
Il va falloir le démontrer tout ça... De mon expérience (je ne travaille qu'on premise) :
On est mono site, tu peux quasiment tout doubler si tu veux faire du multi site (pour faire survivre ton service à des problèmes plus conséquent). Avec tout ça il y a aussi le roulement standard, comme vérifier régulièrement que nos 2 lignes internet fonctionne bien et qu'on bascule bien en cas de perte de l'une des 2.
On fait ça parce qu'on veut vraiment pas que nos données soient gérées ailleurs que chez nous, mais on est conscient que ça représente au contraire un coût considérable. L'utilisation d'un PAAS permettrait de réduire tout ça, mais on resterait sur des machines sur dimensionnée.
Qu'il y ai des cas où ce soit mieux d'être on premise, je n'en doute pas. Mais dans le cas générale tu gagne beaucoup à passer sur un cloud (à qualité de service identique évidement).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll