L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
[Webinar Recording] Création et déploiement d'applications sur OpenShift sur AWS
Récemment, Gary Chen, directeur de la recherche d'IDC, et Victor Wolters, stratège d'entreprise de Perficient, ont présenté un webinaire sur la modernisation des applications, les conteneurs et la valeur de Red Hat OpenShift sur AWS.
Ils disent que peu importe où vous vous trouvez. votre transformation numérique, il n'est jamais trop tard pour penser à la modernisation des applications. Que vous cherchiez à moderniser une application existante ou à créer une nouvelle application pour prendre en charge vos charges de travail, les conteneurs et OpenShift sur AWS offrent une myriade de solutions aux défis de votre entreprise.
Regardez l'enregistrement pour entendre Gary et Victor discuter: [19659004] Adoption des conteneurs par les entreprises
Transcription du webinaire
Je suis Rick Klein, je suis avec Perficient et je suis directeur de l'Alliance . Je suis votre modérateur pour aujourd'hui et je suis très heureux de vous accueillir pour créer et déployer des applications sur OpenShift avec AWS. C'est un sujet très intéressant et qui retient beaucoup l'attention de l'industrie: moderniser les applications, les conteneuriser et les mettre sur une plate-forme comme AWS, avec OpenShift. C'est une discussion très opportune alors que nous progressons dans la modernisation des applications et le transfert des éléments vers le cloud.
Je m'appelle Gary Chen. Je suis directeur de recherche chez IDC et je couvre le calcul défini par logiciel, qui comprend la virtualisation, les conteneurs et les plates-formes d'infrastructure cloud. Je suis ici pour vous parler des conteneurs. Nous allons commencer par passer en revue l'adoption par les entreprises et les tendances issues des recherches d'IDC sur l'adoption des conteneurs. Et ensuite, nous allons parler spécifiquement d'une étude que nous avons réalisée sur OpenShift sur AWS où nous avons parlé à un certain nombre de clients et construit un modèle pour quantifier les avantages de l'utilisation d'OpenShift sur AWS.
Dans l'ensemble, il s'agit d'un conteneur d'entreprise la croissance à partir d'un niveau élevé – c'est un très bon moyen d'avoir une image de ce qui se passe dans l'industrie. Cela examine tous les calculs d'entreprise installés dans le monde aujourd'hui. Vous pouvez voir que la plupart sont des VM, dans la couleur bleuâtre foncé. Et le métal nu est dans le rouge; évidemment, cette tendance a été à la baisse à mesure que les choses se virtualisent de plus en plus. La zone supérieure que vous voyez en gris clair est celle des conteneurs.
Les conteneurs peuvent fonctionner sur du métal nu ou des VM. Cette vue n'est pas affichée ici, mais il s'agit du navire principal de cette application. Nous avons commencé assez modestement et aujourd'hui, nous représentons probablement environ 5% du calcul total de l'entreprise en conteneurs. Il en reste encore un quart dans l'année, et COVID a certainement gommé un peu les choses. Mais je pense que nous arriverons probablement à environ 5%. Si vous regardez 2023, ce sera plus de 20%. C’est vraiment une très bonne croissance. Mais ce sera une longue transition pour la plupart des gens.
Quand vous regardez le taux de croissance composé sur cinq ans, en moyenne, les instances de conteneurs doublent d'année en année. Cette technologie et de nombreux cas d’utilisation suscitent énormément d’enthousiasme.
Nous examinons quels sont les principaux moteurs pour les entreprises de déployer des conteneurs. Nous voyons quelques domaines différents. Les charges de travail modernes et les applications modernes, en particulier l'IA et le ML, ont récemment augmenté. Cela est dû à la nature dynamique et évolutive de ces charges de travail. Nous voyons également cet avantage et l'IoT commence à augmenter. Les conteneurs sont agréables et légers, et l'infrastructure est distribuée et automatisée, ce qui s'intègre parfaitement à l'IoT.
Certaines des autres choses que je pense plus communément appelées avantages des conteneurs sont la livraison de logiciels plus rapide. Cela vient avec une productivité plus élevée des développeurs, où ils peuvent passer moins de temps à jouer avec l'infrastructure et le code d'expédition et plus de temps à coder. Du côté des opérations, il s’agit d’augmenter l’efficacité opérationnelle, d’automatiser davantage, de flux de travail et d’appliquer davantage.
L’autre partie concerne la modernisation et la migration des applications existantes. S'il serait bien que toutes les entreprises puissent tout développer avec la technologie moderne, ce n'est vraiment pas la réalité. Ils utilisent de nombreuses applications existantes et commencent à les moderniser pour leur transformation numérique. Une grande partie de cela migre vers le cloud. Bien que les conteneurs soient une excellente technologie, et ils sont très standardisés avec les images de conteneurs et Kubernetes, ils peuvent vraiment aider à la migration. Les conteneurs ne sont pas une solution à tous les problèmes de migration vers le cloud, mais c'est un excellent outil qui peut vraiment vous aider.
En haut, vous voyez une amélioration de la sécurité. Je pense que beaucoup de gens ne le devinent pas tout de suite. Dans nos conversations avec les clients, nous expliquons comment les conteneurs peuvent également contribuer à la sécurité de différentes manières. Il existe un registre de conteneurs ou un catalogue. Toutes vos images sont centralisées et c'est un excellent moyen de savoir ce qui est déployé et quelle est la version de tout. Vous permettant d'obtenir une meilleure évaluation de vos actifs.
Deux conteneurs sont généralement utilisés avec des machines virtuelles ou des conteneurs ou des machines virtuelles. C’est une autre couche d’isolement. Si quelqu'un voulait sortir d'un conteneur et compromettre un hôte, il devrait sortir du conteneur, puis sortir de la machine virtuelle. Il s’agit de deux niveaux de sécurité et peut être très efficace.
L’autre aspect est de savoir comment les gens commencent à migrer vers des infrastructures plus modernes et des méthodologies modernes. Les gens rapportent que le passage aux microservices est meilleur pour la sécurité. Parce que lorsque vous aviez un monolithe, vous n'aviez vraiment qu'une seule posture de sécurité. Vous aviez cette grande chose contre laquelle vous deviez vous défendre, et c'était les microservices, ça le brise. Vous pouvez maintenant vous concentrer sur les parties sur lesquelles vous devez vraiment vous concentrer et sur les domaines sur lesquels vous pouvez peut-être moins vous concentrer. Vous pouvez avoir des postures de sécurité plus granulaires par rapport à un monolithe.
Avec CI / CD, qui n’est pas nécessairement une technologie de conteneur, mais qui est souvent liée aux systèmes de conteneur. Cela permet aux utilisateurs de mettre à jour et de corriger plus rapidement. S'ils doivent réagir à un incident, une faille ou une mise à jour, ils peuvent le faire beaucoup plus rapidement.
L'autre partie avec les conteneurs est cette idée d'infrastructure immuable. Hors du registre de conteneurs, si vous avez besoin de mettre à jour quelque chose ou de déployer une nouvelle version, vous supprimez l'ancienne version pour déployer la nouvelle. Au lieu d'entrer dans un élément existant et de modifier la configuration, cela résout de nombreux problèmes historiques liés à la configuration. C'est la dérive de configuration. Les conteneurs peuvent beaucoup aider dans ces différents aspects. Celles-ci sont parmi les plus courantes que les clients nous disent utiliser pour améliorer la sécurité.
Quels sont les principaux défis auxquels les gens sont confrontés en matière de conteneurs? Il est intéressant de noter que la sécurité est l’avantage le plus courant, mais aussi le principal défi des conteneurs, et c’est parce qu’il s’agit d’une nouvelle technologie. Il y a un manque d’expérience, un manque de connaissances et un manque de pratiques. Les gens ne savent pas ce qu’ils doivent faire. Ils savent que c’est quelque chose de nouveau. Ils doivent le sécuriser, mais ils ne sont pas vraiment sûrs de la meilleure façon de procéder; les systèmes de conteneurs peuvent être très volumineux. Lorsque vous envisagez de sécuriser tout le pipeline à partir du point, une image de conteneur est d'abord créée jusqu'à l'exécution. C’est beaucoup de domaines à couvrir, et c’est un défi.
La deuxième partie a été la gestion des données. Nous voyons l'émergence de ces nouvelles applications – l'IA et le ML sont très populaires. Ces choses génèrent des données. Nous voyons de plus en plus d'applications avec état exécutées sur des conteneurs. Vous devez protéger et gérer ces données du point de vue des conteneurs.
Le prochain défi est la plomberie universelle entre les centres de données et les nuages. La plupart des utilisateurs ont des conteneurs exécutés dans des centres de données, et ils fonctionnent également dans des clouds publics. Ils ont besoin d'un plan de contrôle unifié, d'une gestion unifiée et d'une visibilité sur tout cela sans créer de silos séparés.
Cette diapositive examine les instances de conteneurs – où vivent-elles? On-prem est orange, le gris est divisé entre le cloud privé et la virtualisation de serveurs ou bare metal plus traditionnelle. Le bleu est le cloud public. Ce que nous voyons ici, c'est que les conteneurs sont vraiment une technologie hybride. Ils ont commencé dans le cloud public car il était lié au développement natif du cloud. Comme il est devenu de plus en plus courant, nous l'avons vu commencer à se développer sur site. Désormais, c'est dans tous ces environnements pour un modèle véritablement hybride avec une affinité particulière pour le cloud public. Le cloud public a un pourcentage de conteneurs plus élevé que tout autre type d'infrastructure, comme lorsque vous regardez les VM. Il y a certainement une affinité avec le développement cloud natif et les applications modernes. Le cloud public est un facteur majeur lorsque vous examinez les déploiements de conteneurs aujourd'hui.
Nous examinons maintenant les charges de travail en cours de conteneurisation. Il y a beaucoup d'enthousiasme autour de ces nouveaux microservices et applications cloud natives, mais dans l'entreprise, la réalité est qu'il existe des applications existantes avec lesquelles ils doivent faire face. Nous voyons beaucoup de conteneurisation des applications existantes. Il y a un mix assez uniforme, très légèrement orienté vers les applications existantes. Mais les gens tirent encore beaucoup d'avantages de la conteneurisation. Ces applications héritées peuvent conduire à une meilleure utilisation et à une densité plus élevée pour un flux de travail plus moderne. Il est plus facile de distribuer des progiciels et de les tester, même toutes les nouvelles applications. Ils ne sont pas tous nécessairement natifs du cloud. Il y a aujourd'hui beaucoup de frais généraux importants pour mettre en œuvre des microservices et un manque de compétences pour les personnes qui savent comment les créer. Cela va prendre beaucoup de temps pour que les gens puissent s'y intégrer.
Lorsque vous envisagez de prendre une application existante et de la conteneuriser, voici le processus. Il y a une gamme parce que vous avez des applications simples et des applications plus complexes.
Lorsque nous avons demandé aux clients de les classer selon le niveau d'effort et les modifications nécessaires pour conteneuriser l'application, environ un quart d'entre elles nécessitent des modifications importantes. Trente-sept pour cent étaient de la modération et 40% étaient peu ou pas de modifications du modèle. Cela se traduit par un temps de migration, car 27% des applications qui sont des applications plus complexes prennent généralement trois mois ou plus, 12% d'entre elles dépassant six mois pour certaines des applications les plus simples et les plus modérées. Les gens peuvent les faire en une semaine, donc environ 22% d'entre eux le font en moins d'une semaine. Alors que la grande majorité, environ 45% environ, entrent dans cette catégorie de quelques mois. Mais cela dépend beaucoup de la charge de travail.
Les gens s’améliorent également. Vous pouvez basculer pour identifier ce que sont les applications, les candidats conteneurisés et quels sont les processus.
Une grande partie de la conteneurisation consiste à placer initialement l'application dans le conteneur. Il existe des projets beaucoup plus longs autour de la refactorisation de ces applications. À l'heure actuelle, près de la moitié de toutes les applications sont conteneurisées. Souvent, la refactorisation se déroule sur une longue période – cela peut prendre des années. Ce nombre a en fait diminué depuis les débuts des conteneurs. Les utilisateurs sont plus réalistes quant à ce qui peut être remanié et à quel niveau. Avec les nouvelles technologies, je pense que les gens sont souvent très optimistes à ce sujet, et ils sont donc définitivement devenus plus réalistes.
Une grande partie du processus cible les parties de l'application que vous voulez vraiment moderniser. Avec les applications monolithiques, les gens conserveront un noyau monolithique statique, dont le taux de changement est très lent. Il n'y a pas beaucoup de développement en cours. Ils découperont les parties qui changent le plus rapidement et doivent être remplies, de A à B, où B est modernisé, et il y a beaucoup de développement à action rapide en cours. Ils les refactoriseront et vous vous retrouverez avec une application Frankenstein avec des pièces héritées et des pièces plus modernes. Ceci est souvent associé à une migration vers le cloud public.
Nous entrons maintenant dans l'étude de la valeur commerciale d'IDC, où nous avons interrogé des clients qui utilisent OpenShift sur AWS. Nous quantifions les avantages qu'ils ont obtenus dans une variété de domaines différents, des développeurs à l'infrastructure. Le document complet sera disponible après l’événement – il contient beaucoup plus d’informations et une analyse approfondie des chiffres.
En termes de bénéfices annuels moyens et moyens pour les organisations, il s’élève à près de 11 millions de dollars. Nous les avons vu se répartir dans quatre seaux de base. Le domaine le plus important concerne les avantages de la productivité des entreprises. Il s'agit de revenus plus élevés provenant de logiciels plus fonctionnels et d'applications plus rapides, et de services en cours de déploiement, ainsi que d'une productivité plus élevée des employés pour les personnes qui les utilisent.
La deuxième partie est la productivité du personnel informatique. Il s'agit d'opérations et de gestion plus efficaces à partir de la plate-forme Kubernetes et du cloud public. Il est plus automatisé défini par logiciel et piloté par API. Cela leur facilite la vie. Ensuite, le troisième avantage concerne l'atténuation des risques moyens. Moins de temps d'arrêt et plus de productivité des utilisateurs grâce à une infrastructure plus résiliente et une infrastructure plus évolutive. Ainsi, l'application est disponible quelle que soit la charge.
La dernière zone, qui semble très petite ici, n'est pas une question d'éternuement. Il s’agit en fait de la réduction des coûts de l’infrastructure informatique et du coût de la plate-forme elle-même.
En examinant un peu plus en détail certaines de ces mesures, nous avons examiné l’effet sur le développement d’applications et le temps nécessaire pour déployer de nouveaux calculs et de nouveaux stockages. Il y a une réduction du temps absolu, ainsi qu'une réduction du temps du personnel requis. Cela se fait dans le cloud. Avec les conteneurs, c'est d'une manière moderne, pilotée par API, souvent avec une infrastructure sous forme de code. L'ensemble des processus automatisés prend moins de temps et d'implication du personnel informatique pour répondre à ces demandes. Les développeurs obtiennent les ressources dont ils ont besoin plus rapidement afin de pouvoir travailler au codage. Cela concerne les deux types de provisionnement: l'infrastructure cloud sous-jacente, qui sera le stockage et les machines virtuelles, ainsi que le côté utilisateur pour obtenir un conteneur ou y amener des clients.
Nous avons constaté une productivité des développeurs presque 24% supérieure avec OpenShift sur AWS. Les développeurs peuvent se concentrer davantage sur le code et laisser l'infrastructure être moins un obstacle. Ils ont des cycles de développement plus rapides grâce aux conteneurs et à Kubernetes et aux outils modernes dans un flux de travail moderne.
L'autre partie est qu'ils peuvent accéder Services AWS de l'environnement OpenShift. En tant que développeur, vous pouvez accéder à de nombreux services qui peuvent vous aider à développer des applications plus rapidement, comme une base de données gérée. Vous pouvez également accéder aux GPU ou à l'IA en tant que service et à la blockchain en tant que service. Vous obtenez une grande partie de cette arborescence de composants qui peut vous aider à créer une application plus rapidement que si vous deviez créer vous-même tous ces éléments.
Cette diapositive examine la réduction des coûts des applications. Lorsque nous examinons le coût de la plate-forme, à savoir le matériel et les logiciels, nous avons constaté qu'il avait été réduit et que les économies pouvaient ensuite être réinvesties dans le personnel des développeurs. Dans l'ensemble, ils sont en mesure de transférer 10% du budget global de la plate-forme vers le personnel des développeurs. Cela augmente encore plus la vitesse du logiciel. Vous avez plus de personnes que vous êtes en mesure d'embaucher et de leur fournir un environnement plus productif, ce qui accélère le développement de logiciels.
Cela prend en compte les coûts d'infrastructure informatique sur cinq ans, et nous avons constaté que le coût en moyenne sur le coût de l’infrastructure et de la plate-forme elle-même. Le temps nécessaire au personnel informatique pour le gérer et le coût des temps d'arrêt, des produits et de la perte de productivité des utilisateurs qui en découlent.
En résumé, nous avons constaté un retour sur investissement sur cinq ans de 661%, cinq mois de retour sur investissement. Parmi les autres indicateurs intéressants que nous avons trouvés, nous avons constaté que les utilisateurs pouvaient doubler le nombre de nouvelles applications par an qu’ils pouvaient déployer. L'entreprise est capable d'innover, d'accéder à de nouveaux marchés et de s'étendre dans de nouvelles zones géographiques.
En fin de compte, cela se traduit par des revenus commerciaux plus élevés pour l'organisation. Nous avons constaté que le chiffre d'affaires moyen par organisation représentait près de 44 millions de dollars de plus en passant à OpenShift sur AWS.
Quelques minutes seulement sur Perficient. Évidemment, nous travaillons directement avec IDC avec AWS et Red Hat pour vous fournir ces informations. Perficient est en fait une société cotée en bourse – nous avons réalisé un chiffre d'affaires d'environ 570 millions de dollars l'année dernière et espérons obtenir plus de 600 millions de dollars cette année. Nous avons 25 emplacements dans le monde, dont 22 en Amérique du Nord. Nous avons été fondés en 1997, sommes devenus publics en 1998. Nous avons un peu plus de 4 500 employés. Nous sommes dans la plupart des grandes villes dans lesquelles vous pourriez résider, avec des gens en Chine, en Inde, en Colombie et à Londres.
Nous sommes une entreprise de livraison mondiale. La plupart de nos emplacements sont en Amérique du Nord, mais nous voyons les choses un peu différemment. Nous voulons nous assurer que nous vous proposons les bonnes compétences aux bons endroits, mais aussi au bon coût. Nous avons donc une organisation de livraison mondiale – nous avons des gens qui sont en mer, près des côtes et à terre. Nous gérons tous nos engagements clients ici en Amérique du Nord, mais nous avons des sites à travers le monde.
Nous entretenons une relation de longue date avec Red Hat et nous travaillons avec AWS depuis un certain temps également. Nous avons plus de 15 ans d'expérience combinée avec les deux partenaires. Nous avons déjà plusieurs déploiements en place, avec plus de 100 déploiements OpenShift et AWS. Nous avons beaucoup d'expérience dans ce domaine et pouvons le faire fonctionner pour vous et vos applications. Nous étions le partenaire Rising Star de l'année 2018 pour Red Hat juste avant leur acquisition. Nous possédons une expertise en solutions sur différentes plates-formes cloud, services multi-cloud, modernisation d'applications, migration, microservices et conteneurs.
Les conteneurs sont vraiment en train de devenir la norme de facto pour le déploiement et l'exécution d'applications sur tous les différents modèles informatiques existants. Il est important de noter que cela fait partie de la création d’une entreprise plus agile et plus adaptable. Compte tenu de ce qui se passe dans le monde aujourd'hui, l'agilité et l'adaptation sont des éléments très importants pour la réussite d'une entreprise.
À ce stade, j'aimerais vous présenter Victor Wolters, notre principal stratège d'entreprise.
Merci beaucoup beaucoup, Rick. Merci également, Gary, d’avoir partagé cette information – elle s’accordera très bien avec ce dont nous parlons ici aujourd’hui. Nous voulions partager avec vous une étude de cas d'un client chez qui nous travaillons sur des conteneurs. Vous verrez en passant en revue quelques leçons apprises et le contexte de l'engagement réel que beaucoup de faits du monde réel sont ressortis de cette étude de cas qui soutiennent ce que Gary a partagé.
Cette entreprise en particulier avec laquelle nous travaillons est dans le secteur de la logistique d'expédition. Ils sont de nature mondiale et disposent d'installations partout dans le monde.
Ils nous ont posé des questions et des préoccupations très spécifiques, principalement centrées sur une grande application héritée monolithique qui existe depuis de nombreuses années. Il contient de nombreuses applications qui sont essentielles à la mission et qui restent longtemps. Il avait atteint un point où ils avaient des défis, et avec cela, leur entreprise se développait et se développait à un rythme rapide. Ils trouvaient de plus en plus difficile de répondre à la demande et de répondre à ce que l'unité commerciale demandait en termes de changements et de modifications. Les défis pour eux étaient centrés sur une variété de domaines différents en ce qui concerne cette application héritée.
L'un des plus grands défis était le coût de maintenance de cette application particulière. La dette technique associée à cette seule application était assez importante, et il devenait difficile de justifier de continuer à dépenser de l'argent dessus.
Un autre défi important était le manque de capacité à déployer de nouveaux changements et à apporter des améliorations à l'application pour conserver à la demande des entreprises. Ils pouvaient à peine obtenir une mise à niveau par an, et lorsque les mises à niveau étaient déployées, ils devaient faire davantage de mises à niveau. C'est un problème courant que nous voyons avec ces applications qui existent depuis un certain temps.
Ils sont donc arrivés à Perficient parce que nous avons travaillé avec eux sur d'autres projets. Ils nous ont présenté leur défi et ce qu'ils pensaient devoir faire. Nous avons trouvé une solution qui répondait à leurs principales exigences. Le plus important était la possibilité d'apporter des changements et de déployer ces changements sur cette application en temps opportun.
Ils essayaient, au mieux, d'arriver à un an, étant donné l'architecture actuelle, la conception et tout ce qui existait. D'un point de vue commercial, ils ne pouvaient tout simplement plus vivre avec. Comme mentionné précédemment, la réduction des coûts était un gros problème.
Au fur et à mesure que nous en parlions davantage et que nous discutions de ce qu'ils devaient faire, nous avons réalisé qu'ils avaient besoin d'automatisation. Ils avaient fait des poches d'automatisation dans différents domaines et différentes parties de leur équipe informatique à travers le monde, mais ils n'avaient pas centralisé ou perfectionné des outils ou des normes particuliers sur la façon d'automatiser, le degré d'automatisation ou où ils allaient faire. il. L'équipe qui a pris en charge cette application particulière faisait tout manuellement, ce qui augmentait le coût et ralentissait. Il y avait un besoin d'augmenter un peu l'automatisation, combiné à l'idée qu'il fallait beaucoup de temps pour faire avancer les choses, obtenir des modifications et les mettre en œuvre. Cela rejoint directement ce que Gary a dit sur sa diapositive sur les principaux pilotes – ils devaient moderniser l'application, augmenter la productivité des développeurs ou augmenter le nombre de nouvelles versions afin de proposer de nouvelles fonctionnalités et fonctions à leurs clients qui l'exigeaient. Ce sont des choses courantes que nous constatons chez les clients lorsque nous parlons d’applications existantes et de modernisation d’applications existantes.
Nous avons commencé à parler de la manière exacte dont ils voulaient y parvenir et de la manière dont ils voulaient le faire. Et cela nous a amenés à passer à des recommandations.
Dans les recommandations qui ont été formulées, l'une des recommandations que nous avons faites tout de suite était un passage à l'infrastructure cloud. Cette organisation a un état d'esprit où elle évitait le cloud et n'utilisait pas le cloud de manière significative. C'est une façon habituelle de passer au cloud pour les grandes organisations qui en font un peu ici, un peu là. Nous avons recommandé qu'ils devaient moderniser l'application et qu'ils devraient le faire sur une plateforme de conteneurs. Il y avait une grande variété de raisons pour lesquelles nous estimions qu'ils devraient faire cela et pourquoi ils devraient passer à une plate-forme de conteneurs. Heureusement, ils pensaient déjà aux conteneurs, mais ils pensaient à une plate-forme de conteneur différente de celle de Red Hat OpenShift.
Nous prenons en charge les deux plates-formes, nous connaissions donc les avantages et les inconvénients des deux. Nous avons eu une conversation avec eux et ils ont finalement opté pour Red Hat OpenShift. Il y avait quelques éléments qui se démarquaient sur cette plate-forme et qui ont fait la différence – l'un était l'automatisation et la capacité de mettre en œuvre l'automatisation depuis le tout début du processus jusqu'à bien plus loin dans le processus de déploiement global. La plate-forme Red Hat allait être un bien meilleur support et correspondre à certaines de leurs autres technologies, et en termes de ce dont leurs équipes étaient au courant.
Il n'est pas rare qu'une partie de l'organisation ne sache pas quelle autre partie de l'organisation fait déjà. Nous avons entamé des conversations autour de cette plate-forme de conteneurs, et nous avons examiné certains des autres groupes avec lesquels nous avons travaillé et souligné qu'ils avaient déjà implémenté Red Hat OpenShift et avaient deux clusters opérationnels qui pourraient être exploités pour cet engagement. Nous sommes allés de l'avant avec notre modernisation, et nous allions d'abord faire une replatforming. Cela va dans le sens de la diapositive de Gary où il en a parlé non seulement pour les nouvelles applications, mais pour les applications existantes.
Nous avons commencé par la refactorisation et nous l'avons ensuite déplacée vers la plate-forme de conteneur. C’était une décision difficile car c’est une application si volumineuse. Il y avait des inquiétudes et des questions sur la possibilité de replatformer sans avoir à retravailler considérablement le code pour le faire fonctionner. Nous avons fait des pilotes et des vérifications de test pour valider quelques morceaux de code. Grâce à ces projets pilotes, nous avons pu déterminer que nous replatformerions puis refactoriser l'application pour qu'elle devienne une structure plus moderne avec des API, des microservices et des choses de cette nature. Comme vous pouvez le voir, beaucoup de décisions se résumaient à des recommandations différentes de celles où nous étions, mais aucune d'entre elles n'a changé la donne.
Nous avons commencé à analyser – nous avons un processus de livraison lorsque nous faisons du développement agile et travail de livraison où nous itérons et revérifions et nous assurons que nous progressons. Mais nous examinons également les leçons tirées des derniers sprints que nous avons effectués. En examinant cela pour ce client particulier, les leçons se sont divisées en deux catégories naturelles de leçons commerciales apprises et de leçons technologiques apprises.
Beaucoup de ces leçons sont spécifiques aux conteneurs par rapport à certains d'entre eux qui sont plus larges que cela. Vous commencerez à comprendre un peu ce que c'est si vous n'êtes pas dans le monde des conteneurs ou si vous travaillez dans un conteneur, certaines choses à rechercher.
Certaines des leçons commerciales que nous avons apprises étaient très importantes. : comptez le coût, vérifiez l'avantage. De toute évidence, ils avaient déjà compté le coût de l'ancienne application actuelle et ils savaient ce qu'il leur en coûtait pour maintenir cela et continuer à fournir. Cela pourrait être une grande mise en garde pour eux en termes de perte d'activité et de ne pas pouvoir fournir cette capacité supplémentaire. Mais l'un des problèmes – une des choses auxquelles je n'avais vraiment pas beaucoup réfléchi – est que l'approche que nous adoptons avec une plate-forme de conteneurs commence à porter ses fruits est la notion de délais de livraison. Combien de temps faut-il pour sortir quelque chose et le déployer en production, de manière sûre et cohérente, et entièrement testé, validé et conforme à toutes les réglementations. Ils ont vraiment commencé à en voir les avantages dès le premier sprint, alors que nous avons commencé à avancer et à replatformer le code dans la plate-forme de conteneurs et avons vraiment commencé à voir les avantages de ce que les conteneurs peuvent apporter.
Il y a un bonne occasion de commencer à réduire les coûts. Gary a montré que vous récupérez 10% de votre temps de développement en passant à ce type de plate-forme, et c'est essentiellement là que nous avons commencé à voir que 10% commencent à se produire. Nous ne passons pas beaucoup de temps à faire des allers-retours avec l'entreprise. Lorsque nous avons repensé les exigences ou les choses de cette nature, cela a été très rapide et l’avantage est que nous avons établi un lien plus étroit avec l’entreprise. Les gens d'affaires et les informaticiens parlent fréquemment, et ils ont des conversations significatives, surtout quand il s'agit de tests d'acceptation et des phases finales de tests qui ont fait une grande différence là-bas.
Il est devenu très évident que vous évaluer ces processus, en termes de collaboration avec les gens d'affaires, ils commencent à passer en revue et à analyser leur entreprise et à identifier de nouvelles fonctionnalités sur une base plus large. Lorsque les unités commerciales prennent des décisions concernant de nouveaux services ou produits qu'elles souhaitent proposer.
L'une des choses qui se passait était que ces entreprises travaillaient souvent de manière indépendante, et il n'y avait pas une inclusion complète de l'informatique, des finances et tout le monde, et les premières étapes de l'examen des choses. Ce processus a commencé à susciter un engagement et une implication plus directs, et ils ont immédiatement commencé à partager de nouvelles idées sur ce qu'ils devaient faire. La collaboration a vraiment commencé à entrer en jeu et a commencé à faire une énorme différence dans la façon dont ils commençaient à avancer. L'attitude à l'égard de l'informatique a commencé à changer. Ils ont également commencé à se rendre compte que l'informatique pouvait vraiment les aider, et mieux définir leur avenir et où ils vont aller avec cette seule application. Cela a vraiment fait une différence en termes de pouvoir définir cela pour la façon dont ils ont commencé à créer ces nouveaux services et ces nouvelles applications à l'avenir.
Dans le même ordre d'idées, il y avait des parties prenantes qui n'avaient pas été consultées sur certaines de ces activités. . Nous avons commencé à parler à ces autres groupes et à interagir avec d'autres groupes, et nous avons commencé à recevoir un nouvel ensemble de contributions et à ressentir beaucoup plus de soutien. Comme il s'agit d'une organisation qui a un groupe informatique typique divisé par fonction, certains groupes se trouvaient dans des pays et des fuseaux horaires différents. Il y a toutes sortes de défis dans ces domaines, mais alors que nous commençons à inclure plus de personnes dans les stand-ups quotidiens ainsi que dans d'autres ateliers de conception et des choses de cette nature. L'effort de collaboration a commencé à se gélifier, ce qui a finalement porté ses fruits à la fin lorsque nous sommes passés à la refactorisation et à passer à une structure plus moderne dans le code de l'application lui-même.
Et finalement, nous avons commencé à travailler avec les gens d'affaires pour vérifier ce qu'ils voyaient de nos clients et ce qu'ils entendaient dire par rapport à ce qu'ils voulaient faire et ce dont ils avaient besoin de cette application, car certaines parties de cette application étaient destinées aux clients, mais la plupart étaient internes. Beaucoup de gens ne pensaient pas que le client externe avait une grande voix à ce sujet. Plus on en parlait, plus ils commençaient à se rendre compte qu'ils avaient une voix là-dedans. Cela nous amène aux leçons sur les technologies.
Une chose qui est devenue très claire est de réfléchir avant de sauter. Le but de cette leçon était qu'ils avaient quelques groupes différents au sein du groupe de développement d'applications lui-même, ainsi que des groupes de soutien, des groupes d'infrastructure et d'autres comme les tests et l'assurance qualité. Ils avaient tous des opinions divergentes sur les outils à utiliser et sur la manière dont vous devriez effectuer le processus. Vous devez parcourir des choses de cette nature pour que cette application soit replatformée et modernisée. Il y avait une tendance à dire que puisque ce groupe a dit que nous devrions utiliser cet outil, alors nous devrions utiliser cet outil. Ce qui se passerait? Quels sont les effets d'entraînement? Tous ceux d’entre nous qui ont été dans le monde de la technologie et de l’information pendant un certain temps savent qu’il n’existe pas de plate-forme ou d’outil unique pour résoudre tous les problèmes. Vous avez toujours cette multiplicité de choses avec lesquelles vous travaillez, mais vous devez y penser avant de prendre cette décision et d'y penser. Cela ne signifie pas que vous ne devriez pas essayer de nouveaux outils, mais vous devez déterminer s’ils sont utiles dans votre portefeuille particulier et avec quoi vous travaillez. You should limit it to things that you clearly see some benefit that’s going to come about before you jump into it.
The second thing here is really thinking about how you go about doing this replatforming and modernization. Is the use of container technology really as much as a technology platform?
As much as it has anything else, that brings together all of these different components and a whole new way of putting together applications and deploying, testing, and maintaining applications. It calls for a whole new way of thinking about these applications and beginning to think about these applications as platforms, as solutions, not just as applications. What I mean by that is that the code you’re going to deploy on this container and the pods, and all the configuration within your service mesh, and all the different parts of this platform, are going to allow you to put that together with some other components around it. It’s really forming a business solution platform that could actually be leveraged to delivery multiple applications, as we’ve thought of applications in time past. As you’re beginning to make this move to the container, and you begin to modernize an application to move it to a container platform, you’re creating a new one.
Be sure you’re thinking about the architecture that codes the APIs and microservices as a business solution platform that could actually service a variety of different needs within the company. Think about creating a business solution platform that fits underneath a digital business platform where you’re delivering the actual services and products to your customers. If you think about it, this fits into the whole main stream of what we’ve seen in trends over the past years. We moved from centralized mainframe computing to many computers to microcomputers, and nanocomputing and then moving to the cloud. There’s a mega shift in trends. It’s along the same lines as this shift of how we do code and how we create new business solutions. The container platform is a significant part that helps you find that path and a way to move forward, and then to continue to leverage what you develop over and over again.
The third point is solutions. You really need to think about what you’re doing in terms of moving things over and how, when you’re moving to a modernization phase, if it’s an existing app and you’re modernizing it. Be sure and think about how you could modernize it, break it apart, separate it, and put it into APIs and microservices in a way that those APIs and microservices can be reused in a different way. The container platform allows you – a platform like OpenShift – tremendous flexibility to be able to do that with the use of your containers and segue many things within the platform.
Then, it’s about the access to data and the ability to quickly build out MVPs to test out a new service and product offering. If you do the coding right, in terms of modernizing or even new code, you will find a lot of reusable components that will make a big difference. The container platform allows you to put it back together with automation in a way that you couldn’t today with the applications you have available.
Finally, think loose, fully integrated processes. We know there’s not a standard we should seek to live up to. But we’ve seen hard code connections, where we had hardcoded IDs and passwords for one piece of the solution to talk to another piece of the solution. We want to get away from that kind of stuff and use the container platform and the power of service mesh as a way to begin to integrate processes that may run across multiple solutions and applications that you deliver. Be sure that you’re tying together your automation correctly, and that your automation scripts and your pipelines are designed and built in such a way that can easily be modified to bring in additional capabilities and deliver additional capabilities for your business. It will really pay off as you move forward.
One of the challenges that we run into with almost every client that we work with, is the ability to automate this full process – the governance process – from end to end.
We’re taking it to the next level. When we’re moving collateral to a container platform, it’s a great opportunity to start thinking about patterns. When you think about patterns, you’re thinking about them in terms of your architecture and your network. You’re thinking about patterns of flow – communication flow, traffic routing – and what you’re doing to actually modernize an app or move it forward. Again, the container platform allows you to establish a pattern in terms of how you do that. You can actually leverage that pattern through your CI/CD pipelines to go to the next application or next solution and deploy quickly. You’ll recognize it right away – that’s a pattern. You’re speeding up the process and getting a jump ahead and making something happen. As you think about patterns, think about automation – that’s one of the reasons for patterns. When those patterns are automated, you’re able to easily grab them and bring them over.
Automation is one of the big selling points for going to a container platform. Don’t forget: it’s portability, the ability to deploy it in the public cloud, on-prem, private cloud, or a hybrid option. There’s flexibility with the container platform. The container deploy supports your solution. And deploying your solution into that requires that you have a certain level of automation to make it go as smoothly as possible to be able to redeploy the application quickly, simply, and easily and spread it out across multiple different applications. Then, you’ll know a bit about the old and the new – there are some things we’ve always done that we need to continue to do, but do you need to do them the way you’ve always done them? Is there an opportunity to think about it in a different way?
The container platform can bring that to the table for you, and we’ve seen that with this client. We’ve been able to automate tremendous amounts of compliancy, testing, and risk mitigation. They didn’t have it automated before and it was taking a lot of time to get deployments into production. Because those things weren’t automated, we were able to automate quite a bit of that and still meet the same requirements that were there before.
For us, the application modernization that Perficient follow is very similar to this. The only thing I wish to point out is that there’s a patter there. There is a methodology that we follow for these modernization journeys. You won’t always have exactly these steps, but you’ll go through this, and it’s an iterative, repeatable process. You’re going to cycle through multiple times to actually get to the modernized application and get it ready for deployment.
But you need to think about a few key concepts that I’ve mentioned previously. You need to think about collaboration – what you do and who you collaborate with. Is there a variety? You need to think about your research tools and how you do that. How do you want to modernize? Do you need a greenfield to do your research? When you get into the construction phase, don’t be afraid if you need to change the process. If it’s greenfield and you’re trying to develop an MVP, don’t be afraid to fail and fail quickly. Deploy, test, fail – use the repeat process here to continue to modernize and get your application moving forward.
Questions
- What industries or industry segments have been getting the best traction from migrating to containerization in the cloud and comparing that to other models in similar industry segments?
Containers are going to be a pretty horizontal technology. The market for virtualization is for anyone who wants to develop faster apps and software development. Right now, the two leading industries are IT computer and the software industries. If you’re in the business of making software or providing some kind of Internet service, like a Google. But we’ve really seen financial services be the lead. There are needs for new technologies like AI simulation as well as user-facing banking apps. Then manufacturing, healthcare, retail, and telecom for network functions, 5G, edge, and IoT. Those are the most common ones.
- Are you seeing an acceleration in modernization projects? If so, what types are you seeing? How does the customer decide what applications to modernize?
We’re definitely seeing an acceleration in modernization. It’s a big initiative and a lot of companies amid the current economic and global environment have accelerated with the pandemic. One example is the working from home scenario; the other one is transacting business differently. In retail, they’ve had to shift to curbside pickup quickly and many businesses have moved transactions online. It’s at an unprecedented scale and demand.
At Perficient, we’ve seen an acceleration of requests for application modernization, and we have a group almost exclusively focused on that and we have a methodology for approaching it. You saw the overall high-level process for deciding which applications to modernize, and it can be tricky in many cases. It’s difficult to apply it across a wide range of industries and application types, but I would say that what we’re seeing a lot of clients lean toward is to modernize some of their more difficult and larger applications, only because there’s so much business logic and mission criticality to the company that’s worth it to them to start to modernize and try to get that application to a better state that allows for faster response and adaptation. It’s an application that represents a pretty significant revenue flow within a company. I think the other kinds of applications we’re seeing with modernization fall to the other end of the spectrum. They’re wanting to get into the container platform – they want to understand it, the infrastructure, and the people, so they take a low-risk application and begin to move forward. It’s two opposite ends of the spectrum that we’re seeing people select the applications for.
Thank you. We’re at the top of the hour.
Source link