BLOG

Pourquoi les réseaux sont importants pour l’architecture des applications

Miniature de Lori MacVittie
Lori MacVittie
Publié le 08 mai 2017
2965-Group

J’ai beaucoup écrit sur le sujet de la relation parfois tumultueuse entre les architectures d’applications et le réseau. Pour la plupart, ils se sont concentrés sur la manière dont les changements dans l’architecture des applications impactent le réseau et les services d’application utilisés pour fournir vitesse, évolutivité et sécurité . Aujourd’hui, nous allons cependant inverser cette relation et voir comment le réseau a un impact assez significatif sur les applications et, par conséquent, sur l’innovation.

Cela m'a été rappelé par un article récent sur la haute évolutivité, dans lequel son auteur illustre pourquoi le réseau est important et comment l'évolution s'est produite - jusqu'à aujourd'hui avec le sans serveur et pourquoi il est possible d'envisager un monde dans lequel Internet est effectivement l'ordinateur. C'est long, mais c'est une bonne lecture, et je vous encourage à prendre le temps de le lire. Je vais résumer ici, mais il y a beaucoup de choses que je n'aborde pas et que vous trouverez intéressantes dans l'article source.

À l’époque de l’accès à Internet par ligne commutée, les sites Web étaient principalement constitués de texte avec peut-être une ou deux images (de faible qualité). Si vous vouliez quelque chose d'interactif, vous lanciez Gopher ou Telnet et utilisiez un terminal textuel. Il n’y avait tout simplement aucun moyen pour le dernier kilomètre via l’accès commuté de prévoir quelque chose de plus complexe.

À mesure que la vitesse de connexion par ligne commutée a augmenté, pour finalement être remplacée par les premières offres « haut débit », les applications ont commencé à afficher davantage d’images et à se diviser en plusieurs pages. Parce que le réseau était suffisamment rapide pour transmettre ces informations sans que le consommateur ne s’ennuie et ne se précipite pour jouer à Diablo. Ce modèle s’est poursuivi jusqu’à ce que l’échelle devienne un problème. Ce n’était plus la vitesse qui freinait les sites, mais l’échelle. L’équilibrage de charge est soudainement devenu une mine d’or.

Les vitesses du réseau ont continué d’augmenter, et pas seulement sur le dernier kilomètre, mais également à l’intérieur du centre de données et le long de la dorsale Internet. Le Web 2.0 a introduit la notion d’applications Web dans le monde, nous offrant des sites Web réactifs et interactifs qui tiraient parti de la capacité du réseau à garantir l’échelle et la vitesse des données échangées.

Les architectures d’application ont changé en raison des avancées du réseau. Sans vitesse et échelle, le monde du Web 2.0 n’aurait jamais vu le jour, car il n’aurait tout simplement pas satisfait le besoin de vitesse inné de chaque consommateur. Mais ces applications reposaient toujours sur un modèle traditionnel à trois niveaux, comprenant une couche de présentation, une couche logique et une couche de données. Ils ont simplement été diffusés sur Internet.

Peu de temps après, les SOA (Service Oriented Architectures pour les jeunes – au fait, sortez de ma pelouse) étaient à la mode. En utilisant une combinaison de normes (SOAP, XML) et en s’appuyant sur des concepts orientés services existants, les « services Web » ont pris le relais. Les services Web et SOA ont introduit le concept de décomposition des applications en services individuels. Si cela vous semble familier, c’est normal, car aujourd’hui nous appelons ce concept « microservices ».

Le problème pour les services Web était que XML était un format volumineux et que son analyse sur le client (ou le serveur) prenait du temps. Étant donné que XML était au cœur de SOA, cela signifiait que chaque service consommait X temps pour échanger sur le réseau et traiter. Comme le temps disponible pour traiter une demande d’un consommateur est limité, cela limite nécessairement le nombre de services dans lesquels une application peut être raisonnablement décomposée.  Deux ou trois services étaient le maximum que l’on pouvait espérer obtenir.

Aujourd’hui, les réseaux sont plus rapides et plus épais de bout en bout. Les réseaux de centres de données (et de cloud) sont mesurés en gigabits par seconde, et non en mégabits par seconde, et même les connexions à haut débit feraient honte aux premières vitesses des réseaux d'entreprise. Cela signifie des transferts plus rapides sur le réseau. Combinées à des augmentations incroyables de la vitesse de calcul et d’E/S (parce que la loi de Moore est exacte), les applications ont pu se décomposer en dizaines, voire en centaines de services qui peuvent être appelés et exécutés dans les paramètres de réponse attendus. Nous appelons cela des microservices.

Ces changements dans le réseau ont permis des architectures d’application et des API modernes. Il encourage l’échange d’informations en temps réel d’une manière qui n’aurait jamais été possible au début du siècle. De la même manière que la technologie est désormais considérée comme un élément clé de la stratégie d’entreprise plutôt que d’assumer son rôle traditionnel de soutien, le réseau est de plus en plus un élément clé des applications. Alors que nous observons l’arrivée de la prochaine vague d’architectures (sans serveur), nous constatons que sans un réseau hautement réactif et intégré et un niveau de service d’application offrant une réponse quasi instantanée aux événements d’échelle et de sécurité, de tels modèles informatiques sont inaccessibles.

Il s’agit désormais moins de la vitesse du réseau (nous atteignons les limites de la vitesse de la lumière) que de la vitesse du réseau à répondre à des événements tels que l’augmentation ou la diminution de la capacité, l’arrêt d’une attaque en cours ou le contournement des problèmes dans l’infrastructure du réseau ou de l’application. La prochaine génération de réseaux est définie, pilotée et activée par logiciel. Il migre également vers un modèle d’évolutivité qui adopte une approche juste à temps nécessitant des vitesses de réaction quasi instantanées de la part des services fournissant l’accès, l’évolutivité et la sécurité aux services hébergés dans ces conteneurs.

Le « réseau », comme nous avons tendance à l’appeler, est composé de services résidant dans une variété de logiciels et de matériels . La capacité du « réseau » à réagir et à fournir des services dans un modèle juste-à-temps déterminera, en partie, le succès de ces modèles d’architecture d’application émergents. 

« Le réseau » n’a jamais été aussi important qu’aujourd’hui.