Qu’est-ce qui vous convient ? / Blogs / Perdu

Cela ne fait que 25 ans environ que Jeff Bezos vendait des livres dans son garage pour une petite entreprise connue sous le nom d’Amazon.com. Au cours des deux prochaines décennies, Amazon et d’autres détaillants ont connu de nombreux changements dans leurs activités, et le plus récent est un passage à une architecture davantage basée sur les microservices.

Architecture monolithe

Le mot monolithe est souvent attribué à quelque chose de grand et de glacial, et ce n’est pas nécessairement loin de l’aspect de la conception de logiciels. Cette architecture est un grand réseau informatique singulier composé d’un code unique qui englobe tous les besoins de l’entreprise.

Comme Amazon, de nombreux détaillants ont commencé et continuent d’utiliser une approche monolithique, où l’application entière a été conçue comme une seule unité. Cela a été un succès car cela a donné aux entreprises de nombreuses capacités et une excellente rampe de lancement pour passer au numérique, ce qu’elles n’avaient jamais fait auparavant.

Changer une architecture monolithique nécessite de mettre à jour l’ensemble de la pile, ce qui fait croire à beaucoup que les monolithes sont restrictifs et prennent du temps. D’un autre côté, les monolithes peuvent être pratiques au début de la vie d’un projet pour faciliter la gestion du code, les frais généraux et le déploiement de tout à la fois.

Avantages et inconvénients de l’architecture monolithique

Il existe de nombreux avantages et inconvénients lorsque l’on travaille dans une architecture monolithique. Les avantages sont :

• Déploiement plus facile – il y a un déploiement majeur avec tout couplé ensemble
• Développement plus facile – avec un code long, il est plus facile de développer
• Meilleures performances – avec un code centralisé, une API peut faire ce que plusieurs API font dans un microservice
• Tests simplifiés – les tests peuvent être effectués plus rapidement
• Débogage plus facile – les problèmes sont plus faciles à trouver car tout est dans un seul code

Cependant, il y a aussi des inconvénients à ce style. Les inconvénients sont :

• Vitesse de développement plus lente – ces applications sont plus longues et plus complexes
• Évolutivité – selon la façon dont il est construit, la mise à l’échelle ne peut pas être effectuée sur des composants individuels
• Fiabilité – si une erreur se produit, elle peut affecter la disponibilité de l’ensemble de l’application
• Obstacle à l’adoption de la technologie – toute modification du framework ou du langage affecte l’ensemble de l’application, augmentant ainsi les coûts et allongeant le temps passé sur le code
• Manque de flexibilité – limité par les technologies qui existent déjà à l’intérieur du monolithe
• Déploiement – bien qu’il soit facile de faire un déploiement majeur, l’inconvénient est que pour faire un simple changement, tout doit être redéployé

Architecture de microservices

Une analogie souvent utilisée pour les microservices est d’avoir un gros rocher (monolithe) et de le décomposer en petits cailloux ou morceaux (microservices – ou applications atomiques discrètes).

Les développeurs peuvent créer leurs propres fonctionnalités, fonctions et capacités indépendamment les unes des autres et les déployer dans un environnement – souvent le cloud – afin qu’elles puissent être mises à disposition dès qu’elles sont prêtes. Ces équipes de développement sont petites, donc souvent plus agiles et agiles.

Avantages et inconvénients de l’architecture des microservices

Tout comme l’architecture monolithique, les microservices présentent de nombreux avantages et inconvénients. D’abord les avantages :

• Agilité/évolutivité flexible – la vitesse, la flexibilité et l’agilité augmentent car il y a des équipes plus petites qui n’ont pas à tout tester manuellement
• Développement continu – les utilisateurs actuels ne sont pas affectés lorsqu’une nouvelle API est déployée
• Hautement maintenable et testable – quelques milliers de lignes de code facilitent l’expérimentation et la restauration si quelque chose ne fonctionne pas, ce qui accélère la mise sur le marché
• Déployable indépendamment – les microservices sont des unités individuelles qui sont toutes destinées à un déploiement rapide
• Flexibilité technologique – les utilisateurs peuvent sélectionner les outils qu’ils désirent
• Haute fiabilité – des modifications spécifiques peuvent être apportées sans que l’ensemble du système ne s’effondre

Cependant, les microservices présentent certains inconvénients. Ils sont:

• Étalement du développement – plus de services dans plus d’endroits le rendent plus complexe et nécessite un niveau plus élevé de maturité numérique
• Coûts d’infrastructure exponentiels – moins rentables car chaque pièce coûte de l’argent
• Plus de frais généraux organisationnels – plus de communication et de collaboration nécessaires par projet
• Défis de débogage – les défis se situent désormais à l’extérieur de l’environnement dans la production d’exécution, la gestion du cloud, la mise à l’échelle automatique, les compétences de l’équipe
• Pas de normalisation – pas de plate-forme commune signifie des langues et des pratiques différentes
• Pas de propriété claire – plus de services signifie plus d’équipes, ce qui brouille les lignes de communication claires

Microservices contre commerce sans tête

Souvent, les organisations qui adoptent une approche de microservices pensent qu’elles opèrent dans l’espace du commerce sans tête, mais ce n’est pas nécessairement vrai. Le commerce sans tête est une version des microservices en ce sens qu’il est basé sur une API, mais il dissocie également la logique métier et les aspects transactionnels et de données du commerce du niveau de présentation.

Ce que fait le commerce sans tête, c’est donner aux marques l’agilité nécessaire pour fournir du contenu tel que des produits, des données et des commandes à n’importe quel point de contact tout en étant capable de l’afficher comme elles le souhaitent. Les microservices permettent d’isoler les services back-end individuels les uns des autres, de les déployer à la carte, de les mettre à l’échelle indépendamment et de les développer de manière autonome.

Alors, qu’est-ce qui convient à votre organisation ?

Choisir ce qui convient à votre organisation

Lors du choix de l’approche à utiliser pour le commerce dans votre organisation, il y a quelques éléments à prendre en compte.

1. Vous devez connaître honnêtement votre maturité numérique. Ces décisions tombent souvent entre les mains des responsables informatiques, et ils doivent être honnêtes quant à l’état de leurs capacités. Si vous n’êtes pas tout à fait au point avec votre maturité numérique, envisagez de suivre une formation et un mentorat pour déterminer quand vous serez prêt, car le passage aux microservices d’un monolithique implique une transition vers une technologie différente. C’est une façon différente de penser et de définir les responsabilités.
2. Vous devez comprendre le modèle de fonctionnement et les coûts. Il ne suffit pas de simplement s’asseoir à une réunion du conseil d’administration et de dire : « Je peux déployer du code cinq fois par jour ». Il est essentiel de comprendre ce qu’il faut pour fonctionner avec des microservices.
3. Il doit y avoir l’adhésion de la direction à l’approche que vous choisissez. Ils doivent comprendre que les microservices sont une réinvention du fonctionnement de votre organisation informatique et de la culture au sein de l’équipe.
4. L’organisation doit être culturellement alignée sur le paradigme. Il doit y avoir un engagement envers une nouvelle façon de penser, de propriété et de responsabilité collective pour l’API.
5. Il est essentiel de comprendre à quoi ressemble la maintenance et l’innovation dans le cadre de cette nouvelle approche. Les partenaires doivent tenir compte du personnel qui a mis en œuvre ce type d’approche et s’appuyer sur lui pour tout planifier, des tremplins à un plan quinquennal.
6. Faire des recherches est important, mais rappelez-vous que les démos des fournisseurs et les rapports des analystes ne racontent qu’une partie de l’histoire. Ils n’opèrent pas activement au sein du système et ne gèrent pas leurs propres produits et sites Web.

Conclusion

Il est probable que de nombreux fournisseurs passeront à une approche de microservices dans les années à venir et que certains monolithes pourraient être perturbés sur le marché, mais cela ne devrait pas décourager l’utilisation d’une approche monolithique. Tout le monde ne va pas changer du jour au lendemain ou même faire le changement du tout. Il est crucial de décider quelle approche profitera au marché et à l’organisation dans laquelle vous vous trouvez.

Si vous cherchez à passer à une architecture de microservices, Perficient peut vous aider à créer et à déployer des microservices natifs du cloud pour créer une plate-forme robuste et évolutive qui favorise un déploiement facile des fonctionnalités pour améliorer l’expérience client.

Contactez-nous pour commencer dès aujourd’hui.