Comment concevoir une architecture applicative moderne
Développer des applications pour absorber des milliers de services distribués en simultané requiert une nouvelle forme d’architecture. Notre expert Kurt Marko passe en revue les différentes étapes pour y arriver.
Les applications Cloud sont considérées comme un service où la facilité de déploiement et de modification sont inhérentes, tout comme le dimensionnement et la mesure. A tel point que derrière le mode de conception de l’application, l’architecture moderne doit aussi évoluée.
Les services Cloud, eux-mêmes bâtis sur une infrastructure massivement distribuée, sont conçus pour être résilients, mais aussi pour passer d’une plateforme à l’autre et se redimensionner, sans qu’il n’y ait d’impact sur les utilisateurs. La couche d’accès et de contrôle étant assurée par les APIs, les utilisateurs sont isolés de la couche sous-jacente. Ceux-ci n’ont probablement aucune idée, ni ne se préoccupent, de l’infrastructure sur laquelle ces services s’exécutent. Cette approche représente l’un des nombreux avantages des services Cloud par rapport aux logiciels s’appuyant sur des architectures traditionnelles, plus monolithiques.
Pourtant, ces mêmes caractéristiques pourraient, et même devraient, être appliquées aux applications développées à partir d’un ou plusieurs Cloud. Un design granulaire, fondé sur les microservices, fournit un environnement virtuel pour toutes architectures d’entreprise répondant aux critères actuels : à savoir répondre aux exigences du numérique, servir des millions de clients mobiles ainsi que supporter les très tendances applications de l’Internet des objets.
L’entreprise numérique connectée
La raison pour laquelle les architectures doivent changer est la suivante : la convergence de la connectivité haut-débit et des dizaines d’années d’avancée de la Loi de Moore. Cela a par exemple contribué à l’émergence de smartphones bon marché qui ont saturé le marché et la création de services Cloud par les fournisseurs de services. Ensemble, ces technologies ont accéléré la mutation des entreprises et des métiers. Que vous l’appeliez la New Economics of Connections chez Gartner ou l’Unbounded Enterprise chez AT&T Bell Labs, cela a un sens commun : les entreprises, et par conséquent leurs applications et leurs systèmes, vont de plus en plus interagir avec les individus, les terminaux, les objets virtuels sous la forme de processus automatisés, par exemple. Cette explosion d’interactions est ce que Gartner appelle le Digital Mesh.
L’impact sur l’architecture logicielle est comparable à ce que Facebook, Google, ou AWS ont pu créer ; moins à des systèmes centraux et monolithiques. Il s’agit d’être capable d’absorber un nombre grandissant de workloads et ce, de manière imprévue. Et les effets vont dépasser l’architecture IT pour s’immiscer dans les méthodes des entreprises : IT bimodale, DevOps, développement agile, des concepts censés accélérer l’innovation numérique.
Composé avec le « connecté »
Au final, l’architecture moderne d’entreprise sera calée sur le Cloud. Que les applications s’exécutent sur des services publics comme AWS ou Azure, sur une infrastructure privée bâtie sur Azure Stack, OpenStack ou vCloud, ou encore sur les 2 (dans un modèle hybride), l’architecture doit prendre en compte la disponibilité de services partagés et mesurés pouvant être instanciés, modifiés, dimensionnés et interconnectés. Alors que les entreprises développent des services numériques qui ressemblent à ceux de Facebook et Uber, l’architecture applicative doit ressembler à des services natifs pour le Cloud et pas à des systèmes monolithiques enfermés dans une grande boîte.
Mais de quoi se compose une architecture moderne :
- Dissocier l’interface client et les services métier. Les applications vont se plier au modèle mobile et s’exécuter aussi dans le navigateur. La partie cliente est réservée à l’interface utilisateur et les traitements métier sont gérés par les services en back-end.
- Etre distribué par défaut. En back-end, les applications doivent pouvoir supporter plusieurs instances, fournir la résilience et des capacités de dimensionnement, mais sans se couper de possibilités de mises à jour qu’impliquent des processus agiles et continus
- S’appuyer sur des microservices. Des services en back-end doivent être conçus pour des fonctions spécifiques. Ils pourront aussi être partagés par les utilisateurs et reliés entre eux pour des applications spécifiques. Imaginez les microservices comme des briques utilisées pour bâtir arbitrairement des fonctions complexes. Ces services peuvent s’exécuter dans leur propre VM ou dans un conteneur, partageant une instance d’OS. Ils seront enfin quantifiables par défaut pour supporter des capacités de facturation à la demande, le suivi des performances et le dimensionnement automatique.
- Communication asynchrone. Les services échangent des informations via des bus de messages, des connexions non persistantes aux sockets et du partage de fichiers.
- Un portefeuille dense de services. Les services devront exposer des métadonnées pour favoriser leur gestion, leur consommation et leur orchestration dans un vaste portefeuille de services. Et ce, afin d’inclure des back-ends mobiles et IoT, du stockage de données et de l’analytique, du messaging, du monitoring et de la sécurité.
- Une bibliothèque de templates et de design patterns. Ce portefeuille constitue aussi une base de templates qui assemblent des services pour répondre à certains scénarri de développement, comme le propose Azure. La bibliothèque comprend également des modèles de données standard utilisés pour sélectionner des services de données appropriés (NoSQL, SQL, Big Data) et la transformation des données.
- APIs. Les APIs forment la première, sinon l’unique, interface.
- Infrastructure automatisée. Les services peuvent être instanciés à partir de templates pour déployer, dimensionner, déplacer et décommissionner des instances Cloud. La mesure de ces services est exploitée pour alerter sur l’usage des ressources, de l’activité et des erreurs.
- Sécurité granulaire. Les accès aux services sont contrôlés au rôle, les politiques étant définies dans les templates. L’identité et les rôles des utilisateurs sont gérés de façon centrale et éventuellement fédérés par des systèmes externes.
A mettre sur sa To-Do List
Il est probable qu’une architecture d’entreprise puisse faire la différence entre les projets de transformation numérique qui échouent et ceux qui réussissent. Ce qui signifie ainsi que les CIO et les responsables IT doivent développer cela en étroite collaboration avec l’IT, les développeurs et les métiers. Pour les métiers et l’exploitation, cela nécessite la mise en place d’équipes pluridisciplinaires, comme le très tendance DevOps.
La modernisation de l’architecture d’entreprise est en fait une illustration de l’évolution de l’IT vers de nouvelles pratiques, comme l’agilité. Avec pour objectif : répondre positivement au dynamisme du numérique. En tant que tel, il est fort probable que cela s’accompagne de changements structurels et culturels dans l’entreprise.
Traduit et adapté par la rédaction
