En infogérance, beaucoup d’entreprises solutionnent des problèmes de programmation informatique de leurs applications internet ou non en augmentant les ressources de leurs serveurs d’hébergement. C’est une solution économique intéressante quand on met en balance les coûts de développement et les coûts d’hébergement, mais ça ne dure jamais très longtemps car quand un système est mal monté il faut toujours plus de ressources au fil du temps.
L’infogérance par le code et pour le code
Un serveur se pense en conjonction des développements informatique. Si une application consomme beaucoup de ressources serveur/machine c’est que probablement elle contient des éléments qui sont ressource-ophage et qu’elle a mal été conçue.
Au lieu de pratiquer l’inflation des ressources machine il faudrait plutôt très probablement se pencher sur le code des applications pour trouver ce qui consomme et pourquoi. Parfois le problème se règle très simplement avec un système de cache. Parfois c’est un peu plus compliqué il faut revoir le code, remettre sur la table les requêtes à la base de données, changer le CMS, développer ou re-développer ses propres fonctionnalités pour qu’elles s’intègrent correctement dans l’application. Revoir intégralement l’application c’est toujours mieux.
Un « serveur qui rame »
Souvent un « serveur qui rame », qui sature et qui est à bout de ressources, c’est une succession de patchs, de pansements, liés à des interventions successives de prestataires ou d’employés indélicats. Là c’est compliqué, il est très probable que vous deviez tout recommencer et refondre votre système. Mais si vous refondez votre système alors il faudra prendre un développeur consciencieux pour que ça soit un nouveau système pérenne et durable
Ça n’est pas forcément une mauvaise nouvelle, sauf pour votre budget j’en conviens, mais ça sera l’occasion de remettre des points sur la table et de disposer d’un système plus intéressant pour votre activité.
Sauvegardes, sauvegarder et préserver !
Les sauvegardes font aussi parties d’une bonne coopération entre le développement et l’infogérant du serveur. S’il n’y a pas de réflexion sur la préservation des données au niveau des applications elles-même alors il y aura forcément inflation de la quantité de sauvegardes.
Des exemples :
- Souhaitons nous sauvegarder en cas d’erreur de l’application et disposer d’un « retour en arrière » technique permanent parce que si l’application plante elle va rendre les données erronées ? .. Bon ben là tout est dans la description ; c’est l’application qui pose problème.
- Souhaitons nous sauvegarder au cas où le serveurs crash ? Un serveur qui crash ne doit pas être un problème, il doit y avoir un ou des serveurs redondants qui peuvent prendre le relai. Si les coûts d’une infrastructure en grappe sont hors de votre budget (ce qui est peu probable si l’application fait partie de votre business), il faut dé-corréler données et application, mettre vos données dans un espace garantie par un prestataire (Cloud) et appuyer pour que le développeur se prépare à une réinstallation rapide de votre application.
Les sauvegardes c’est incontournable. Il est possible d’avoir une solution qui répond à tous les cas ; on sauvegarde tout et tout le temps. Je pense que ça n’est pas la bonne solution, il vaut mieux une subtile coopération entre le développeur de l’application et l’infogérant de l’hébergement. C’est plus économique et moins risqué en terme de perte de données.
Un système idéal est pour moi un fonctionnement en grappe :
- 2 serveurs minimum en front de HTTP
- une base de données moderne de type MongoDB en grappe aussi contenant aussi les fichiers statistiques
- une sauvegarde unique de seulement la base de données
- 1H chaude
- 24H chaude
- 3 jours froide
- 1 mois froide et archivée
purgée à 3 mois
Mais évidement chaque fonctionnement a ses prérogatives, ses spécialités, ses risques et ses objectifs ; il faut étudier le système et l’activité pour proposer la bonne solution de sauvegarde.
Au service de votre infogérance
Machine dédiée, Cloud, Serveur virtuel, Conteneur d’application, je suis en mesure d’opérer sur tous les systèmes et vous garantir les meilleurs choix.
Enfin vous l’aurez compris, l’infogérance fait partie de la programmation informatique, elles vont de pair et l’une ne fonctionne pas sans l’autre.
RGPD/GDPR sont en partie du ressort des infogérants, je maîtrise le sujet.
Dans mon expérience j’ai généré plusieurs millions de pages vues mensuelles et n’ai jamais dépassé un petit serveur de 1x2GHz pour moins de 8Go de RAM ; tout est question d’optimisation du code.
À la recherche d’une prestation sans recrutement vous pouvez opter pour mon entreprise d’infogérance.