Comment gérer efficacement de nombreuses applications – Le démarrage interne
En faisant partie d’une équipe d’innovation, vous aurez tendance à entendre beaucoup de choses comme: «Construisons un prototype pour tester l’idée.», Et «Il est temps de mettre à niveau ce produit vers la version 2.0».
Si vous êtes le seul à gérer l’infrastructure cloud, vous serez probablement confronté à des défis et à une augmentation des frais généraux de tous les produits nouveaux et mis à niveau s’ajoutant à votre infrastructure. L’architecture sera bientôt inefficace pour gérer la charge accrue et les composants d’infrastructure.
Dans la plupart des cas, votre équipe d’innovation serait plutôt maigre et devrait se multiplier en termes de taille d’équipe et de nombre d’applications – en raison de la demande croissante en innovation numérique. Il est peu probable que la structure et les processus de votre équipe actuelle suivent une croissance rapide.
Les défis liés à l’architecture et aux processus structurés sont entrelacés et se rejoignent dans un package. Un processus structuré devrait être en place pour gérer une architecture complexe. Je partagerai sur la base de mon expérience, comment vous pouvez gérer ces défis pour évoluer à grande vitesse.
Pensez aux «super applications» comme WeChat et Grab. Pour la plate-forme Grab, ils ont des mini-applications, c’est-à-dire GrabFood, GrabDelivery, etc. Ce sont des exemples réussis de sociétés innovantes regroupant un grand nombre d’applications indépendantes sur une seule plate-forme. Du point de vue de la base de code, il est logique que chacune des mini-applications ait sa base de code, comme avec la plate-forme. Nous voulons réaliser quelque chose de similaire pour héberger nos applications – sauf que ce sera sur un site Web au lieu d’une application mobile, une plateforme d’innovation.
Pour concevoir une plateforme d’innovation évolutive sur le Web, vous pouvez vous tourner vers des fournisseurs de services cloud performants, à savoir AWS, GCP, Azure pour vous inspirer. En naviguant sur AWS, vous vous rendrez compte que les 212 services sont probablement des applications indépendantes et distinctes. Cependant, l’expérience de la navigation sur AWS donnait l’impression qu’il s’agissait d’une seule application.
En commençant par le point de vue de l’architecture, vous pouvez envisager d’adopter l’API et l’architecture de microservices (MSA), inspirées du mandat de l’API Amazon – qui ont permis à AWS d’évoluer très rapidement. Pour les meilleures pratiques de conception, vous pouvez vous référer au diagramme ci-dessous de MuleSoft dans la conception d’API et de microservices.
Le principal avantage de cette architecture est que les API deviennent des blocs de construction réutilisables «Lego» à partager entre nos applications, ce qui vous permet 1) d’innover à la vitesse sans reconstruire des composants similaires, et 2) de mélanger et associer des services et des capacités pour stimuler l’innovation.
Une mise en garde: passer à MSA impliquerait également que votre équipe devrait être restructurée pour s’adapter à l’architecture technique ou vice-versa. Cela est dû à la loi de Conway.
Les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations
Sur le frontend des applications, pour gérer la transition transparente entre les applications, vous pouvez consulter le cadre OAuth2. Les flux d’autorisation OAuth2, associés à la gestion des sessions, permettent aux applications indépendantes de circuler sur la plate-forme de manière transparente et sécurisée. Vous pouvez trouver un exemple du flux implicite ci-dessous pour une seule application.
Une fois que vous avez déterminé la transition des applications sur la plate-forme, l’étape suivante consiste à examiner la gestion du code source (SCM) et DevOps. Notez que ce sont des composants essentiels à prendre en compte dans la conception de votre architecture. Cependant, je n’entrerai pas dans trop de détails car c’est un sujet assez important. je recommanderais lire plus sur Azure DevOps et réfléchissez à la façon d’intégrer cela dans votre architecture – cela peut vous faire économiser une tonne d’efforts pour votre configuration DevOps.
Enfin, vous devrez également vous assurer qu’il existe une conception d’interface utilisateur cohérente sur tous les frontaux de vos applications si vous souhaitez les héberger sur la même plateforme similaire à AWS. Pour le backend de l’application, cependant, des modifications devraient être apportées si vous passez à l’API et à MSA.
Il est primordial que les normes de processus et de conception soient établies et appliquées pour une mise en œuvre réussie. Je vais aborder certaines des normes de conception et de gouvernance des processus dans les sections suivantes.
Cette section couvre les composants à centraliser et fait partie de Gouvernance de l’architecture d’entreprise (EA). Dans la mesure du possible, nous souhaitons laisser aux développeurs et architectes la flexibilité de décider du type de langages de programmation à utiliser, des passerelles API et également de l’infrastructure; cela adhère au principe de conception des microservices polyglottes – qui offre de nombreux avantages.
D’un autre côté, il y a des éléments cruciaux à normaliser. Les composants incluent IAM, les outils et référentiels DevOps et les bibliothèques. En gérant ces composants de manière centralisée, il vous permet de gérer les aspects utilisateur, stratégie, processus et actifs de votre architecture; cela est essentiel à mesure que la taille de votre équipe augmente, vous aurez besoin d’un contrôle plus précis sur l’accès des utilisateurs à travers les applications.
Il existe de nombreuses applications open-source que vous pouvez intégrer (à condition que votre organisation le permette) pour IAM central, DevOps, la journalisation et les référentiels. Vous pouvez vérifier Cape de protection Car je suis, Jenkins et Gitlab pour DevOps, Lien pour les référentiels d’images, WAPITI pour la gestion des logs, CapRover pour PaaS, et beaucoup plus; ils sont également disponibles pour les déploiements sur site.
Les applications susmentionnées vous offrent une vue centralisée du centre de commandement des opérations de votre équipe; ils gèrent le contrôle d’accès, le déploiement, la journalisation et le dépannage, la gestion de la configuration et l’hébergement de vos applications.
Avec une visibilité et un contrôle accrus sur vos applications, il réduit les frais généraux d’exploitation et de gestion pendant que vous faites évoluer votre équipe et votre infrastructure – ce qui contribue à son tour à une agilité accrue.
Une fois que vous avez configuré votre architecture et vos composants principaux, la prochaine étape consiste à établir un ensemble de normes et de processus opérationnels pour votre équipe. Les procédures couvrent les normes de documentation, les revues de code et les directives, la gestion des versions des applications, etc. – qui sont des composants de bonnes pratiques DevOps.
Une remarque: de nos jours, DevOps et Agile sont couramment discutés ensemble et c’est difficile de parler de l’un sans parler de l’autre. Ses important de noter la différence. Une chose est sûre, c’est que les deux contribuent à l’expédition rapide des logiciels.
Une architecture DevOps robuste garantit la gouvernance au sein de votre équipe, par exemple les revues de code et les cas de test devraient passer avant de procéder au déploiement, etc. Associé à l’automatisation, vous pourrez atteindre la vitesse et la gouvernance. Il existe différentes façons de concevoir et de mettre en œuvre une bonne architecture DevOps; cela dépend principalement des besoins et des objectifs de votre équipe. Vous pouvez trouver une architecture DevOps de référence (flux de déploiement) ci-dessous.
Une analogie: vous pouvez considérer le pipeline DevOps comme une ligne d’usine qui produit de nombreux produits et mises à jour rapidement tout en garantissant que chacun d’eux répond aux normes de qualité prédéfinies.
S’il vous arrive de travailler dans un environnement où la sécurité et la conformité sont primordiales, vous souhaiterez peut-être aligner vos processus sur les principes de sécurité fondamentaux sur les conseils d’un auditeur technologique. Dans un tel environnement, vous voudrez peut-être DevSecOps qui intègre la sécurité dans l’ensemble du processus.
Avec une bonne implémentation DevOps en place pour régir et automatiser vos processus, vous pourrez évoluer et expédier vos produits rapidement tout en garantissant et en respectant les normes de qualité. Les nouveaux développeurs pourraient également intégrer l’équipe et devenir productifs à un rythme plus rapide, car la plupart des processus sont automatisés et guidés. En conséquence, votre équipe pourra continuer à innover à grande vitesse tout en grandissant.