Priceline CTO Marty Brodbeck sur l’amélioration de l’expérience des développeurs

Il y a trois ans, l’agence de voyages en ligne Priceline a commencé son voyage vers le cloud dans le but de créer une infrastructure technologique plus flexible et agile, explique le CTO Marty Brodbeck.

Cet effort comprenait la modernisation des applications en suivant la méthodologie à 12 facteurs, « les déplaçant dans des conteneurs Docker, puis en rationalisant ce processus en les exécutant dans Kubernetes sur Google GKE Edge ».

Dans le même temps, l’organisation mettait en place une infrastructure de données en temps réel pour fournir un aperçu des performances de l’entreprise et identifier les tendances futures.

Julia King, rédactrice en chef du CIO, s’est entretenue avec Brodbeck lors du récent sommet du CIO sur l’avenir du cloud pour discuter des défis et des succès de la mise à l’échelle du déploiement du cloud, de son objectif de faciliter le travail des développeurs et des leçons apprises en cours de route.

Ce qui suit sont des extraits édités de cette conversation. Pour plus d’informations sur Brodbeck, regardez l’intégralité de l’interview intégrée ci-dessous.

En adoptant une approche axée sur le développeur :

Nous considérons le processus de développement logiciel comme l’un des processus métier les plus critiques au sein de l’entreprise. Ainsi, plus nous pourrons leur faciliter la vie et augmenter leur vélocité, plus ils contribueront aux objectifs généraux de l’entreprise. Et comme nous effectuons beaucoup de tests A/B en tant qu’entreprise, la fréquence à laquelle nous pouvons mettre des fonctionnalités sur notre plateforme et les tester est une priorité essentielle pour nous.

L’un des défis que nous avons rencontrés jusqu’à présent dans notre transformation cloud est que nombre de ces technologies sont si nouvelles qu’elles n’offrent pas nécessairement l’expérience de développement la plus robuste.

[Another challenge] Une grande partie du développement cloud que nous avons réalisé est constitué de 12 facteurs et de Kubernetes. Pourtant, bon nombre des pipelines CI/CD existants qui existent actuellement ne sont pas nécessairement Kubernetes ou natifs à 12 facteurs pour commencer.

La culture de l’entreprise est fortement collaborative. [W]Nous aimons tester, itérer et déployer relativement rapidement. Et c’est exactement de la même manière que nous testons l’outillage. Nous aimons proposer un ensemble de cas d’utilisation, les tester rapidement, déterminer s’ils répondent à nos besoins, puis trouver un moyen d’évoluer.

Nous le faisons dans toute l’organisation. Si un ingénieur a une très bonne idée, nous voulons être en mesure d’avancer rapidement sur cette idée, de la tester, de la rendre plus robuste, puis si cela fonctionne vraiment, de l’étendre à l’ensemble de l’organisation.

Sur l’examen de la nouvelle technologie cloud :

La façon dont nous envisageons toute nouvelle technologie est, d’abord et avant tout, quel genre d’efficience et d’efficacité opérationnelles allons-nous retirer de ces technologies ? Quels coûts pouvons-nous retirer de la manière actuelle dont nous gérons notre infrastructure et le développement de logiciels ?

[Then] nous regardons [the] valeur ou revenus supplémentaires [a new technology] va rouler sur notre plateforme. Cette capacité nous aidera-t-elle à permettre de meilleures expériences client, ce qui va générer davantage de revenus et de croissance de notre plate-forme et une meilleure expérience pour nos clients ?

Le troisième concerne simplement l’efficacité opérationnelle ou des mesures plus qualitatives autour d’une meilleure expérience de travail pour nos collègues et employés.

Chaque fois que nous évaluons un type de technologie, une analyse de rentabilisation est construite autour de l’un de ces trois compartiments, ou parfois les trois ensemble, avec un retour sur investissement clair sur cet investissement et quand nous pensons que nous allons rentabiliser ces analyses de rentabilisation. pour la compagnie.

[As an example], l’analyse de rentabilisation du cloud que nous avons élaborée avec Google reposait avant tout sur la réduction des coûts de notre infrastructure. Nous avons donc élaboré une analyse de rentabilisation sur 3 ans qui prévoit la suppression de tous nos centres de données d’ici 2023.

La deuxième analyse de rentabilisation claire concernait l’efficacité de notre pipeline CI/CD : combien de nouvelles fonctionnalités nettes pourrions-nous tirer d’un investissement dans les outils CI/CD pour l’entreprise ? Quel degré d’automatisation pourrions-nous intégrer à notre pipeline CI/CD pour rendre nos développeurs plus efficaces ?

Sur les leçons apprises en cours de route :

Je pense que la plus grande leçon pour nous a été de s’assurer que vous disposiez d’un très bon support opérationnel et d’une stabilité pour faire fonctionner ces plates-formes dans le cloud.

Et cela [involves] quelques éléments clés :

La première consiste à disposer d’une plate-forme d’observabilité très robuste qui surveille vos applications cloud et vous permet de rechercher les bogues et les défauts.

Deuxièmement, vous avez mis en place de très bons contrôles de gestion des coûts et vous pouvez obtenir des informations granulaires sur la façon dont votre organisation utilise le cloud, avec de très bonnes politiques de gouvernance.

Troisièmement, disposer d’une organisation d’ingénierie de fiabilité de site très robuste capable de gérer les déploiements et la gestion de votre environnement et de votre échelle Kubernetes.

J’aimerais savoir tout ce que je sais maintenant, à l’époque où nous avons commencé cela. Mais la beauté est que nous avons échoué rapidement dans ces domaines et avons pu pivoter très rapidement et mettre en place de très bonnes capacités qui nous ont permis d’étendre notre déploiement cloud en temps opportun.