Réarchitecturer pour une innovation continue

De nombreuses entreprises construisent leurs propres services logiciels en utilisant des architectures monolithiques.

Cette stratégie présente des avantages : la conception et le déploiement de systèmes monolithiques sont généralement simples au départ. À mesure que les applications deviennent de plus en plus sophistiquées, il peut devenir difficile de maintenir la productivité des développeurs et la vitesse de déploiement, ce qui se traduit par des systèmes coûteux, chronophages et dangereux à déployer. Ce document montre comment réorganiser vos applications selon un paradigme cloud natif qui vous permet d'accélérer la livraison de nouvelles fonctionnalités même lorsque vos équipes s'élargissent, tout en augmentant la qualité des logiciels et en atteignant des niveaux de fiabilité et de disponibilité plus élevés.

À mesure que les services et les équipes qui en sont responsables se développent, ils ont tendance à devenir plus difficiles à adapter et à gérer, ainsi qu'à devenir plus complexes. Il devient plus difficile d'effectuer des tests et des déploiements, d'ajouter de nouvelles fonctionnalités et de maintenir la stabilité et la disponibilité.

Selon une étude menée par l'équipe Google DORA, il est possible pour les entreprises de toutes tailles et de toutes disciplines d'atteindre des niveaux élevés de débit de distribution de logiciels, de stabilité et de disponibilité des services. Les équipes les plus performantes peuvent déployer plusieurs fois par jour, apporter des modifications à la production en moins d'une journée, restaurer le service en moins d'une heure et atteindre des taux d'échec des modifications compris entre 0 et 15 %.

De plus, les meilleurs interprètes sont capables d’améliorer la productivité des développeurs, mesurée par le nombre de déploiements par développeur et par jour, même lorsqu’ils agrandissent leurs équipes.

Qu'est-ce qu'une architecture cloud native ?

La création, le test et le déploiement d'applications monolithiques doivent être effectués comme une seule entité. Souvent, le système d'exploitation, le middleware et la pile de langages d'une application sont modifiés ou configurés individuellement. Les scripts et les procédures de développement, de test et de déploiement d'applications sont souvent propres à chaque application. Cette méthode est simple et efficace pour les applications greenfield, mais à mesure que ces systèmes se développent, il devient plus difficile de les modifier, de les tester, de les déployer et de les exécuter.

De plus, à mesure que les systèmes se développent, le nombre et la complexité des équipes chargées de développer, de tester, de déployer et d’exploiter le service augmentent également. Il est courant, mais erroné, de diviser les équipes par fonction, ce qui entraîne des transferts entre équipes qui augmentent les délais et la taille des lots et entraînent des reprises considérables. Une étude menée par DORA indique que les équipes les plus performantes sont deux fois plus susceptibles de créer et de déployer des logiciels qu’une équipe unique et interfonctionnelle.

Parmi les symptômes de cette maladie, on trouve :

• Processus de construction longs et fréquemment interrompus
• Cycles d'intégration et de test peu fréquents
• Des efforts accrus sont nécessaires pour soutenir les processus de construction et de test
• Diminution de la productivité des développeurs
• Processus de déploiement pénibles qui doivent être exécutés en dehors des heures ouvrables, nécessitant des temps d'arrêt programmés
• Des efforts considérables dans la gestion de la configuration des environnements de test et de production

Transition vers le cloud natif

De nombreuses entreprises ont mis en œuvre une méthodologie « lift-and-shift » pour migrer leurs services vers le cloud.

Dans cette méthode, aucune petite modification du système n’est nécessaire et le cloud est essentiellement traité comme un centre de données conventionnel, bien qu’il offre des API, des services et des outils d’administration bien supérieurs à ceux des centres de données conventionnels.

Cependant, le lift-and-shift à lui seul n’offre aucun des avantages du modèle cloud natif décrit ci-dessus.

En raison du coût et de la difficulté de la transition de leurs applications vers une architecture cloud native, qui implique de repenser tout, de la conception des applications aux opérations de production et à l'ensemble du cycle de vie de la distribution des logiciels, de nombreuses entreprises s'arrêtent à la phase de « lift-and-shift ». Cette appréhension est justifiée : plusieurs grandes entreprises ont des initiatives de re-plateformisation « big bang » sur plusieurs années qui n'ont pas abouti.

La réponse est d'adopter une approche progressive, itérative et évolutive pour réarchitecturer vos systèmes en cloud natif, permettant aux équipes d'apprendre à fonctionner avec succès dans ce nouveau paradigme tout en continuant à produire de nouvelles fonctionnalités : il s'agit d'une stratégie de « déplacement et d'amélioration ».

L'application du figuier étrangleur est un motif important dans l'architecture évolutive. Au lieu de reconstruire les systèmes à partir de zéro, développez de nouvelles fonctionnalités de manière contemporaine et cloud native, mais faites-les communiquer avec l'ancien programme monolithique pour les fonctionnalités existantes. Déplacez progressivement les fonctionnalités actuelles au fil du temps, comme l'exige l'intégrité conceptuelle des nouveaux services.

Téléchargez le livre blanc de Google Cloud pour en savoir plus sur la réarchitecture pour une innovation continue uniquement sur Whitepapers Online.