Déplacement des monolithes avec des microservices
Il existe une croyance fantaisiste selon laquelle vous pouvez prendre un monolithe, le mettre dans un récipient, et voilà ! Les avantages de l'architecture moderne en termes d'échelle et de vitesse.
En fait, une enquête KubeKon 2018 suggère que c'est exactement ce qui se passe pour environ 55 % des répondants qui ont indiqué qu'ils utilisent les conteneurs « comme remplacement de VM pour les applications existantes ». D’autres enquêtes montrent qu’un nombre important d’applications Java de classe entreprise s’exécutent dans des conteneurs. Une enquête Diamanti de 2018 a montré que si la majorité (54 %) utilisait des conteneurs pour les applications cloud natives, près d'un tiers (31 %) les utilisaient pour moderniser les applications héritées.
Les raisons invoquées sont généralement opérationnelles ; les conteneurs sont perçus comme plus simples à gérer, malgré l’explosion des pièces mobiles à gérer. Les frais de performance et de licence sont également souvent des facteurs déterminants dans la décision d’utiliser des conteneurs.
Mais cette démarche n’est pas aussi simple que de regrouper une application héritée et de la déposer dans un conteneur.
La réalité est que les monolithes (applications client-serveur et Web traditionnelles) présentent certaines caractéristiques qui rendent difficile leur transfert dans un conteneur et la récolte des avantages opérationnels. Les conteneurs et les microservices ne sont pas mutuellement exclusifs, mais tous deux s'appuient sur les principes « construits pour échouer » sur lesquels repose la disponibilité des applications modernes. Ce principe, si vous ne le connaissez pas, est que si un conteneur tombe en panne, vous en démarrez simplement un autre pour prendre sa place. Tous les conteneurs sont destinés au bétail et l'un est aussi bon que l'autre.
Dans les architectures d’applications sans état délibérément modernes , c’est vrai. Dans les architectures d’applications avec état traditionnelles, ce n’est pas tellement le cas.
Vous voyez, le client-serveur et son successeur, l’application Web à trois niveaux, sont généralement avec état. Ils conservent certaines informations sur l’interaction entre un client et l’application au cours d’une session. Cette session peut être conservée en mémoire sur l'application ou le serveur Web, ou dans une base de données distincte. Quel que soit l'endroit où ces données sont stockées, c'est elles qui rendent l'application dynamique. Ces données sont pertinentes et importantes pour le fonctionnement de l'application. Elles contiennent votre panier d'achat, la dernière page que vous avez visitée et d'autres informations spécifiques à l'application.
Vous pouvez imaginer que si le serveur Web/d’application sur lequel ces informations sont stockées disparaît soudainement, cela interrompt négativement l’expérience client. Mon panier est parti. Je dois retourner là où j'étais. Je dois tout recommencer, en gros.
Ce comportement est diamétralement opposé aux principes architecturaux modernes qui éliminent le fonctionnement avec état d’une application. C'est la nature sans état des applications et services modernes qui permet de remplacer de manière transparente une instance par une autre lorsque quelque chose ne va pas. C'est la base sur laquelle fonctionne « construit pour échouer ». Si vous réintroduisez l’État dans cette équation, soudainement tout s’effondre.
Même si l'application continue de fonctionner, l'utilisateur reste dans l'incertitude. Leur flux est perturbé, leurs transactions transportées dans les profondeurs, pour ne plus jamais être revues.
Ce problème est celui qui a donné naissance à la nécessité pour les services d’application de respecter l’état. Une fois qu'un client se connectait à une application/un serveur Web particulier, il devait se connecter à cette même application/à ce même serveur Web pendant toute la durée de la session. La persistance des cookies et d’autres mécanismes ont été développés pour garantir que les requêtes soient acheminées vers le même serveur à chaque fois. Pour préserver l'État.
La réalité est qu'à moins que vous ne soyez une start-up entièrement nouvelle, vous avez déjà des applications traditionnelles et modernes en cours d'exécution. Bien que les recherches sur le sujet varient, la répartition « 63 % d'applications héritées / 37 % de nouvelles applications » reste largement constante au fil du temps. Ce qui signifie que vous devez prendre en charge à la fois les architectures héritées et modernes.
Le simple déplacement du monolithe dans un conteneur ne servira à rien si vous n’avez pas abordé la distinction entre avec et sans état.
ÉTAGÈRE ARCHITECTURALE
La meilleure façon - ou du moins la plus simple - de gérer la migration des monolithes vers un environnement conteneurisé est de vous assurer que vous pouvez toujours respecter l'état même dans l'anarchie sans état d'un cluster de conteneurs. Cela nécessite une certaine intelligence à la limite du cluster, à l'entrée où N-S rencontre E-O.
Une approche à deux niveaux prend en charge les approches opérationnelles traditionnelles et modernes ainsi que la migration d’applications traditionnelles avec état vers un environnement conteneurisé. En tirant parti des services F5 Container Ingress (CIS), NetOps peut continuer à répondre aux besoins des applications avec état qui migrent vers des environnements conteneurisés. La connectivité garantit que les méthodes traditionnelles d’équilibrage de charge utilisant la persistance peuvent continuer à fonctionner et à diriger les demandes vers le bon conteneur ou directement vers un environnement traditionnel.
Pendant ce temps, BIG-IP peut diriger simultanément les demandes d'applications et d'API modernes vers un contrôleur d'entrée à l'intérieur du cluster de conteneurs pour une distribution sur autant de conteneurs sans état que nécessaire.
Les transitions prennent du temps
La réalité est que la plupart des organisations prennent en charge jusqu’à cinq architectures d’applications distinctes : des monolithes aux applications mobiles en passant par les microservices. La prise en charge simultanée d’un nombre égal mais distinct de modèles de réseau et opérationnels risque de submerger les opérations et d’annuler les avantages du passage à des architectures et environnements modernes. Une approche stratégique à deux niveaux permet aux organisations de tirer parti des avantages opérationnels et commerciaux des deux modèles tout en effectuant la transition vers un environnement majoritairement conteneurisé.
OPTION RÉFACTEUR
L’une des choses que vous pouvez faire pour faciliter cette transition est de refactoriser les applications héritées pour tirer parti des sessions partagées. Ces sessions se déroulent dans un emplacement distinct du serveur Web/d'application - généralement une sorte de base de données - et sont accessibles par n'importe quel serveur Web/d'application avec l'ID de session approprié. Vous devrez toujours garder une trace de l'identifiant de session, mais cela peut généralement être accompli via un cookie qui persiste quel que soit l'état du serveur Web/d'application. Si les applications héritées n'utilisent pas déjà un modèle de session partagé, le refactoring pour le faire est un processus assez simple par rapport au replatforming de l'ensemble de l'application.
Étant donné que de telles transitions prennent du temps (après tout, nous fonctionnons encore presque tous dans un modèle multicloud aujourd'hui), il est important de trouver et de tirer parti des options architecturales qui maximisent les avantages sans compromettre les besoins fondamentaux des clients, comme la disponibilité et la sécurité. L’utilisation d’une approche architecturale à deux niveaux offre les deux avantages sans restreindre les efforts de conteneurisation.