Comme nous l’avons vu il y a quelques semaines, la livraison d’applications est devenue un des moteurs de votre business, surtout si elle est bien exploitée. Même si le DevOps tend à améliorer le développement, il n’est malheureusement pas la solution miracle dans un environnement de production adéquat.

Le DevOps : demandeur de ressources

Le DevOps est la collaboration entre le développement et les opérations avec un but commun : développer et updater des applications plus rapidement et plus efficacement. Grâce à ses spécificités empreintes de l’activité réelle, le DevOps est aujourd’hui reconnu comme l’une des méthodes les plus performantes des SI.

Néanmoins son impact dépend entièrement de l’espace de stockage, et donc de développement, dont disposent les développeurs. Ces derniers sont souvent tributaires de copies complètes de leur environnement de production. L’écriture de nouvelles lignes de code, leurs tests, les corrections et les améliorations ne peuvent être réalisées dans l’environnement de production, afin d’éviter des risques qui pourraient être importants pour le business.

En interne, les développeurs peuvent s’entendre dire « Vous allez devoir attendre 45 jours pour commencer votre développement car nous ne pouvons pas libérer du temps machine sur nos opérations actuelles. » Si les développeurs se retrouvent à court de temps machine et d’espace de stockage, ils pourront être tentés de passer par un Cloud public. Cette solution n’en est pas une en soi, puisque l’application n’aura pas été testée dans un environnement réel de production et la confidentialité de certains développements pourrait être engagée.

Avec un tel constat, il est facile de comprendre pourquoi les développeurs peuvent être frustrés, entre la pression de la livraison et les limites de leur propre infrastructure.

 

Le PRA et ses ressources inutilisées

Pendant ce temps-là, le PRA (Plan de Reprise d’Activité) fonctionne tranquillement de son côté. Il s’agit d’une infrastructure totalement séparée de celle de l’entreprise, véritable copie complète de l’environnement de production et de la totalité de ses données, applications, stockage et même de puissance machine. Hormis 2 ou 3 tests annuels, il reste inactif, prêt à être utilisé en cas de problème.

Réfléchissez-y un instant.

Une copie complète de votre environnement, une infrastructure identique mais séparée, toutes les données de l’entreprise, et assez de stockage et de puissance machine pour relancer toutes les opérations au cas où le serveur principal crasherait.

Vous pourriez presque entendre toute votre team DevOps réclamer à l’unisson « Laissez-nous l’utiliser !»

Et pourquoi pas ? Toutes vos données y sont déjà. Et votre équipe de développement pourrait y réaliser des tests de charge de performance dans une copie conforme de votre environnement de production.

Et si jamais un test de reprise d’activité était prévu ou si un désastre venait à arriver, pas de problème non plus. Mettez votre programme DevOps en stand-by et le PRA reprendra sa fonctionnalité première. Une fois la situation terminée, les ressources pourront être retransférées à la team DevOps qui pourra reprendre là son travail où elle l’avait laissé.

En réalité, vous l’aurez compris, DevOps et PRA peuvent parfaitement cohabiter et même plus. En autorisant votre team DevOps à utiliser les ressources du PRA, vous augmenterez radicalement la vitesse de production de vos applications – et de leurs upgrades – et vous améliorerez le développement et les processus de test. De plus, cette solution supprime le besoin de budget additionnel pour des ressources de calcul supplémentaires, puisque le budget est déjà en place pour financer votre PRA.

FavoriteLoadingAjouter à mes favoris

Une réponse

  1. Arlette QUILLERE

    Cela suppose qu’au niveau réseau vous soyez au niveau 3 car au niveau 2 ça ne marchera pas . Par ailleurs , si vous répliquez les données sur votre PRA , il n’est pas question qu’elles puissent être modifiées par des tests donc l’utilisation du PRA par les développeurs, bien que très tentante, me semble limitée à des cas spécifiques .

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.