Le processus de construction d'un logiciel commence généralement par un ensemble d'exigences. En tant qu'ingénieurs, nous sommes formés pour trouver le moyen le plus efficace de répondre à ces exigences. Ensuite, nous déterminons comment ajuster et dimensionner le logiciel en fonction de l'utilisation et des besoins de fiabilité des utilisateurs.

Ce processus est cyclique, voire sisyphéen. Au fur et à mesure que le logiciel est utilisé et que l'entreprise se développe, le produit doit être amélioré pour répondre à de nouveaux besoins ou exigences. Les ingénieurs doivent donc "remanier" le code, puis le tester et le déployer à nouveau.

Le refactoring, dans le contexte de la construction de logiciels, se réfère au processus consistant à apporter des changements mineurs et sûrs au code afin d'améliorer ses performances, sa maintenabilité ou d'autres aspects sans altérer son comportement général. Cela revient à polir et à optimiser la base de code existante. L'équipe d'ingénieurs de Prime Video, par exemple, a dû relever le défi de remanier son architecture sans serveur pour utiliser des services conteneurisés à longue durée d'exécution, ce qui a nécessité de modifier la façon dont le logiciel était structuré et géré.

Martin Fowler, le célèbre développeur de Logiciel, , l'a très bien dit, "[L'essence du refactoring] est d'appliquer une série de petites transformations préservant le comportement, chacune d'entre elles étant "trop petite pour valoir la peine d'être faite". Cependant, l'effet cumulé de toutes ces transformations est très important. En procédant par petites étapes, vous réduisez le risque d'introduire des erreurs. Vous évitez également de casser le système pendant que vous procédez à la restructuration, ce qui vous permet de remanier progressivement un système sur une longue période de temps".

J'ai récemment entendu des histoires passionnantes sur les changements qui se préparent dans la manière dont le logiciel est construit et géré et qui pourraient briser ce cycle. Certaines organisations transforment des services distribués en nuage en applications monolithiques, voire passent du nuage à un environnement de centre de données. De nombreuses organisations engagées dans le processus de transformation numérique s'intéressent à la transition cyclique après avoir rompu avec l'architecture monolithique, même si certains obstacles subsistent.

Grâce à une technique appelée "infrastructure as code", dans laquelle les ingénieurs gèrent et fournissent l'infrastructure informatique par le biais du code et de l'automatisation plutôt que par des processus manuels, ce voyage de refonte de la couche d'infrastructure est une tâche descriptive possible. Mais il est important de noter que ce processus de remaniement demande encore beaucoup de temps et d'efforts pour concevoir, mettre en œuvre, tester et déployer les changements en toute sécurité, de manière à ce qu'ils ne causent aucun problème au système.

Dans le cas de l'équipe d'ingénieurs de Prime Video, leur objectif était de continuer à fournir un excellent contenu vidéo et un comportement d'application aux utilisateurs tout en apportant des changements significatifs à la façon dont l'infrastructure était mise en place. Ils ont porté ou "recompilé" manuellement l'infrastructure en modifiant la façon dont elle était définie dans le code, en passant de l'utilisation de fonctions Lambda de courte durée à l'utilisation de services Elastic Container Service (ECS) de plus longue durée.

Considérations relatives aux changements d'architecture

Le passage à une architecture différente, comme l'a fait l'équipe de Prime Video, s'accompagne d'un certain nombre d'éléments à prendre en compte :

• Productivité
  • Les différentes interfaces de calcul requièrent différents niveaux d'effort et de maintenance. Par exemple, les configurations sans serveur nécessitent moins de maintenance, alors que les serveurs à longue durée de vie requièrent plus d'attention.
  • Certaines architectures nécessitent plus de code pour démarrer, ce qui peut affecter la rapidité avec laquelle les équipes d'ingénieurs sont en mesure de rendre le logiciel opérationnel.
  • La simplification d'un système complexe de petits services (un spaghetti de microservices) peut faciliter le travail sans trop dépendre de l'informatique en nuage. 
• Fiabilité
  • La simplification d'un microservice spaghetti peut faciliter les tests et l'observation, ce qui améliore la fiabilité du logiciel.
• Sécurité de l'informatique en nuage
  • Lorsque vous modifiez l'architecture, il se peut que vous deviez adapter la manière dont le système se défend contre les attaques, car la surface d'attaque change.
  • Les rôles et les autorisations (rôles IAM) et les configurations de réseau peuvent également nécessiter une mise à jour, et parfois même le code au niveau de l'application peut être affecté.
• Coût
  • Chaque service en nuage a sa propre structure tarifaire, qui doit être prise en compte lors des modifications architecturales.

En tant que concepteur de logiciels, j'ai découvert au fil des ans diverses bonnes pratiques en matière de réorganisation des systèmes, et j'ai même dirigé moi-même certains de ces efforts. Cependant, j'ai souvent trouvé que cette tâche était répétitive, qu'elle nécessitait une documentation importante et qu'elle était dispersée dans un trop grand nombre de cadres et de paradigmes de programmation. Mes principales préoccupations étaient que de tels changements prennent du temps et qu'il y a toujours un risque de rupture. Je me suis donc souvent demandé si c'était la bonne façon d'allouer les ressources d'ingénierie.

La modification des architectures est un processus complexe qui implique une collaboration et une communication entre les équipes chargées des applications et de l'infrastructure, même pour des changements simples. Il n'existait pas de solution permettant de consolider ces exigences en matière d'application et d'infrastructure... jusqu'à aujourd'hui.

Entrez dans le nuage de l'aile*

Fondée en avril 2022 par Elad Ben Israel, créateur d'AWS CDK, et Shai Ber, ancien VP R&D chez EquityBee*, avec des racines profondes dans la mise à l'échelle de l'infrastructure cloud et la création d'outils de développement largement utilisés, Wing* est un nouveau cadre de programmation conçu pour le cloud.

Les avantages de l'Aile, à mon avis, sont les suivants :

• Productivité accrue: Unifie le code de l'application et de l'infrastructure, l'infrastructure est générée par un compilateur et moins de code doit être maintenu par les développeurs.
• Sécurité dans le nuage: Le compilateur peut réduire la surface d'attaque et générer les autorisations IAM les moins privilégiées et les topologies de réseau par code d'application.
• Réduction des coûts: Un ingénieur peut observer les charges de travail dans le nuage et recomposer l'architecture d'une ressource informatique à une autre en fonction des métriques de la charge de travail observée.
• Itération de développement plus rapide: Wing peut simuler un environnement en nuage localement et permettre une boucle de rétroaction plus rapide.
• Portabilité dans le nuage: Conserve le code de l'application et l'infrastructure peut être recompilée vers une nouvelle cible en nuage.
• Portabilité des services: Le code de l'application est conservé et l'infrastructure peut être recompilée pour une nouvelle cible de service (exemple : file d'attente en mémoire, file d'attente Kafka, AWS SQS).
• Programmes distribués: Réduit la barrière de l'utilisation de l'infrastructure distribuée en nuage en déduisant les exigences de la logique de l'application.

Depuis sa création, Wing a rassemblé une équipe de plus de 10 ingénieurs aux États-Unis, en Israël et en Europe et a planté les graines, je crois, pour créer une open source significative dans l'espace de l'infrastructure en nuage.

Chez Battery, je m'enthousiasme lorsque des fondateurs et des entrepreneurs abordent des problèmes complexes en s'appuyant sur des principes de base et en faisant preuve de simplicité et de clarté. Elad, Shai et le reste de l'équipe Wing apportent une richesse de connaissances issues de leur passage chez Amazon, Microsoft et Equitybee* et, je crois, comprennent comment apporter de la clarté aux problèmes les plus complexes de l'ingénierie du cloud. J'ai hâte de voir comment ils continueront à innover.