La vérité sur la "modernisation des applications"

Vous envisagez actuellement de remanier, de replatformer ou de réarchitecturer une application ? Félicitations, car cela signifie très probablement que vous avez choisi de vous engager sur la voie de la modernisation des applications après avoir découvert les quatre avantages clés que le cloud peut offrir.

Découvrir les avantages de la modernisation des applications dans le nuage

Spécifiquement liés à la modernisation des applications, ces avantages sont les suivants :

1. Modernisation des technologies de l'information : en réduisant la dette technique liée au matériel et aux logiciels obsolètes et en améliorant l'infrastructure sous-jacente, notamment en améliorant la sécurité, les opérations, la fiabilité, l'évolutivité, etc.
2. Réduction des coûts : en réduisant les dépenses en matériel et en logiciels coûteux et en améliorant l'utilisation des ressources, notamment en réduisant le coût total de possession ou en passant du CAPEX à l'OPEX.
3. Agilité de l'entreprise : en étant capable de réagir plus rapidement aux changements du marché et en améliorant la capacité à déployer de nouvelles initiatives de modernisation des applications afin de tirer le meilleur parti des nouvelles opportunités.
4. L'innovation : en tirant une nouvelle valeur de la technologie et en développant et en lançant des produits et des services modernes.

Cependant, malgré tous ces avantages, le chemin vers la modernisation des applications n'est pas toujours facile. Il peut souvent se diviser en plusieurs directions différentes et de nombreuses organisations ne savent pas laquelle prendre. Mais n'ayez crainte, laissez-nous vous guider et révéler la vérité sur deux chemins que les organisations croisent fréquemment et ne savent pas lequel prendre : Kubernetes bricolé et géré ou le PaaS tout-en-un.

Les piliers fondamentaux de l'évolution des applications modernes

Avant de nous plonger dans le meilleur choix pour la modernisation des applications aujourd'hui, nous devons examiner où tout a commencé. Que vous décidiez de développer votre propre plateforme ou de vous appuyer sur un PaaS, tous deux s'appuient sur les cinq mêmes principes fondamentaux des pratiques d'ingénierie moderne qui ouvrent la voie à la modernisation des applications.

Ces principes forment un ensemble cohérent de bonnes pratiques à suivre :

1. Technologies à code source ouvert : Si vous n'êtes toujours pas convaincu par l'adoption des logiciels libres, consultez cet article de nos amis de Strapi.
2. Applications conteneurisées : Prêt à dire adieu à votre environnement de développement qui reflète votre production depuis... 2016 ? C'est le moment !
3. Les microservices sont prêts : Mais n'oubliez pas que les empiler encore et encore vous ramènera à un monolithe - alors n'oubliez pas de les ranger.
4. Git-driven : Il n'y a vraiment pas d'autre façon de coder, il faut utiliser Git.
5. Sans serveur d'abord : exécutez simplement votre code et payez à l'utilisation. Et croisez les doigts pour qu'il n'y ait pas de bogues dans votre code.

Maintenant que les bases sont posées, il est temps de se pencher sur ce que signifie réellement la conduite d'un projet de modernisation d'application, avec ses différentes étapes et ses différents défis. Permettez-nous de lever le voile sur toute confusion autour de la modernisation des applications avant de nous plonger dans les deux voies que nous avons évoquées plus haut.

Tracer la voie de la modernisation des applications

En faisant la lumière sur la méthodologie qui sous-tend la modernisation des applications, nous espérons que vous serez en mesure d'identifier les étapes qui présentent un risque potentiel pour votre équipe ou votre projet. Cela vous permettra d'évaluer laquelle des deux voies (DIY ou PaaS) est la plus appropriée pour vous, en connaissance de cause :

• Étape 1 : Évaluer ce que vous avez. Cela peut sembler évident, mais nous ne comptons plus le nombre de fois où des équipes ont découvert au tout dernier moment une petite fonction ou un petit composant dont leurs applications ont besoin pour fonctionner et qu'elles avaient omis de prendre en compte.
• Étape 2 : Obtenir un parrainage. Lorsqu'un projet est mené par une personne qui n'a pas de transparence efficace avec son équipe, les choses ne se passent généralement pas très bien.
• Étape 3 : Valider automatiquement. Pas de silos organisationnels ou d'intermédiaires entre le développement et les opérations. Adoptez DevOps.
• Étape 4 : Concevoir en tant que norme. Et vous pourriez, à un moment donné, envisager une reconstruction plutôt qu'une migration.
• Étape 5 : Suivre l'efficacité. Nous ne parlons pas ici de surveillance des opérations, mais de mesures de santé que vous pouvez vérifier chaque semaine lors de vos réunions de travail.
• Étape 6 : Changez et formez. Même si vous êtes un bricoleur et un grand autodidacte en matière de déploiement d'entreprise, il est fortement recommandé d'adopter la méthodologie de réussite client de l'éditeur.

Vous avez tout compris ? C'est parfait ! Vous avez tout ce qu'il faut pour prendre la bonne décision. Il est temps de se plonger dans nos deux voies - DIY ou PaaS - en commençant par la première.

Bricolage et gestion de Kubernetes

Vous êtes prêt à concevoir, construire et exécuter votre propre implémentation ? C'est incroyable, vous êtes très probablement un bricoleur ! Et comme toutes les vidéos de bricolage sur YouTube, cela commence par la mise en place de votre propre atelier ou, comme nous l'appelons dans l'écosystème du cloud, de la zone d'atterrissage. Vous pouvez également la considérer comme la base de votre projet et, par conséquent, comme un coût inévitable.

La zone d'atterrissage est constituée de différents piliers et modules qui évoluent avec le temps. Et bien qu'elle puisse varier selon que l'application est destinée à des initiatives PoC ou à des charges de travail d'entreprise globales, il existe quelques éléments clés qui sont nécessaires pour un environnement de production. Il s'agit des éléments suivants

1. IAM et gouvernance
2. Mise en réseau
3. Sécurité
4. Observabilité
5. Services partagés
6. Facturation
7. Automatisation

Cela semble beaucoup, n'est-ce pas ? En réalité, une agence spécialisée est en mesure de livrer une configuration standard et prête à la production en 25 jours ouvrables environ. C'est sans compter le temps supplémentaire pour la formation et la documentation que l'on peut s'attendre à trouver dans n'importe quel projet.

Supposons maintenant que votre objectif soit de déployer Kubernetes, même s'il repose sur des services gérés tels que Google Kubernetes Engine ou Azure Kubernetes Service. Malheureusement, certaines fonctionnalités ne fonctionnent pas par magie. Par exemple, l'Autopilot ou l'Auto-scaling fonctionnent très bien... une fois que vous avez la bonne configuration, c'est-à-dire.

Pour déployer une application basée sur Kubernetes, la zone d'atterrissage initiale que nous avons mentionnée précédemment doit avoir quelques modules adaptés, notamment le réseau, la sécurité, l'observabilité, les services partagés et l'automatisation. Ainsi qu'un nouveau module clé créé : l'architecture Kubernetes.

D'accord, mais qu'est-ce que cela signifie exactement ? Eh bien, vous devrez prendre en compte des éléments tels que la stratégie d'isolation, la haute disponibilité, les paramètres des pools de nœuds, les paramètres des étiquettes, les classifications des charges de travail, les paramètres LimitRange et quotas, la configuration du chiffrement etcd, les politiques de sécurité du pod et le contexte de sécurité, et la liste continue.

Une liste qui nécessitera environ 15 jours de travail supplémentaires, soit un total de 40 jours de travail pour la mise en place d'une zone d'atterrissage si l'on ajoute les 25 jours précédents. Un investissement initial minimum qui devrait toujours être pris en compte avant de s'embarquer dans une stratégie de bricolage - surtout à long terme. Et n'oubliez pas que c'est du bricolage, ce qui signifie qu'à chaque fois qu'un nouveau cas d'utilisation émerge, vous devrez le refaire vous-même et maintenir ce que vous avez déjà créé dans un avenir prévisible.

Lorsqu'il s'agit de DIY et de Managed Kubernetes, il est important de considérer l'objectif de ce que vous essayez de construire. Tous les développeurs n'assument pas leur rôle de concepteur de plateformes personnalisées et même de grandes entreprises ont échoué dans ce domaine. Mais c'est précisément pour cela que les solutions PaaS (Platform-as-a-Service) ont été créées.

PaaS tout-en-un

À ce stade de l'article, vous vous êtes probablement dit "oui, ils ont raison pour le bricolage mais..." ou "hmm mais si..." et nous espérons que c'est exactement ce que vous avez fait ! Cela signifie que, comme la majorité des gens, vous voulez voir la carte complète avant d'emprunter une nouvelle voie pour votre prochain projet. S'assurer qu'un PaaS est suffisamment flexible pour répondre aux besoins de votre projet et de votre développement et obtenir des réponses à des questions telles que :

• Puis-je passer d'AWS à GCP ?
• Puis-je héberger mon application en France et non en Allemagne?
• Puis-je migrer d'ElasticSearch à OpenSearch?
• Puis-je développer en Node au lieu de PHP?
• Puis-je construire un middleware indépendant pour moderniser mes applications ?
• Puis-je créer une nouvelle application à architecture de microservices?
• ...et sans doute bien d'autres encore.

Nous comprenons, les gens ont besoin d'être rassurés sur le fait qu'une nouvelle voie va mener à un meilleur endroit. Et dans de nombreux cas, nous pouvons tous éprouver des difficultés à nous défaire de certaines responsabilités dans le cadre de nos projets. Mais si vous parvenez à dépasser ces préoccupations, vous pourrez alors vous accueillir dans le monde du PaaS et emprunter une voie plus facile pour le développement.

Le concept de PaaS est assez séduisant : vous vous concentrez sur la livraison du code, tandis que le fournisseur gère tout le reste. Cela semble bien, n'est-ce pas ? Il n'est pas nécessaire de construire une zone d'atterrissage ou quoi que ce soit d'autre. Et tout fonctionne de manière déclarative, il suffit de dire au fournisseur ce que vous voulez (généralement dans un fichier de configuration YAML), de redéployer, et c'est généralement à vous. Tout en ayant la liberté de faire un peu de personnalisation ou d'utiliser des outils externes pour renforcer votre application là où vous le souhaitez ou en avez besoin.

Le PaaS est vraiment un moyen infaillible de normaliser votre infrastructure, mais ce n'est pas un secret que la normalisation peut avoir un coût. Un coût plus élevé qui, pour nous, se traduit par des avantages plus importants.

Lorsque vous parcourez le marché à la recherche du meilleur PaaS, vous devez prêter attention à des attributs tels que : la dépendance de la plateforme aux fournisseurs IaaS sous-jacents et la localisation disponible, la politique de l'outil "apportez votre propre outil" (comme un CDN), et l'ensemble des runtimes pris en charge qu'ils offrent. Vous devriez également jeter un coup d'œil à l'historique du fournisseur de la plateforme, car il peut en dire long sur la philosophie et l'objectif de la solution qu'il propose. Il y a une grande différence entre un ingénieur qui a construit un produit pour résoudre ses anciens problèmes et un entrepreneur qui a voulu profiter d'une opportunité de marché. Mais il existe de nombreux fournisseurs de PaaS qui peuvent vous offrir tout cela.

La meilleure approche de la modernisation des applications

Imaginez : vous avez décidé qu'il était temps de moderniser votre application, vous avez déjà adopté les meilleures pratiques dont nous avons parlé précédemment et vous avez conçu une méthodologie pour y parvenir. Cela signifie qu'il ne reste plus qu'une seule question en suspens : dois-je opter pour une solution solo ou PaaS ?

C'est à vous seul de décider, mais si vous voulez notre avis sur la question, le PaaS pourrait bien être la solution. Testez si nous vous avons guidé sur la bonne voie vers le PaaS avec notre essai gratuit dès aujourd'hui !

Regarder cette vidéo