Trois modèles à éviter lors de la sélection de plates-formes natives Cloud

Les motifs résonnent avec moi. En tant que développeur et concepteur d'un logiciel, il semble naturel de voir le fil conducteur tissé partout.

Exploiter ce fil dans d'autres domaines s'il est précieux ou l'ajouter à ma liste «Refactor un jour» s'il est nocif toujours semblé être une prochaine étape logique. Récemment, j'ai commencé à voir un modèle dans les conversations avec certains de mes clients et en interne avec plusieurs de mes collègues talentueux.

Cloud Native Application Platforms

Les conversations ont été largement sur la façon dont une organisation devrait aller sur l'adoption de nouvelles plateformes pour aider à répondre aux objectifs organisationnels. Les objectifs variaient mais consistaient souvent à augmenter la vitesse de développement (accélérer la mise sur le marché), simplifier les opérations (réduction des coûts), moderniser les applications (abandon hérité) et bien d'autres choses encore

. (ceci englobe un ensemble de technologies en évolution rapide, y compris la plate-forme en tant que service et le conteneur en tant que service). En tant que technologues, la discussion sur l'adoption passe inévitablement rapidement au processus de sélection de la plate-forme.

Définir les exigences de l'analyse quantitative, déterminer l'adéquation qualitative d'un ensemble d'outils et établir le bon ensemble de critères de sélection. Bien que les aspects quantitatifs et qualitatifs soient critiques, et que l'évaluation doive suivre un processus bien établi pour éviter de réinventer la roue d'analyse, il y a plus à adopter que de sélection d'outils et de plate-forme.

le modèle d'évaluation stricte des étapes d'adoption en fonction des caractéristiques techniques des plateformes. Nous devons élargir notre approche pour considérer plusieurs autres aspects.

Premièrement, nos équipes sont-elles prêtes à adopter des cadres d'application modernes? Possèdent-ils les compétences et l'encadrement nécessaires pour effectuer cette transition?

Deuxièmement, s'il était logique que les processus de développement et de déploiement actuels restent sans modification, cette réflexion nécessite une analyse sérieuse. Nous devrions nous attendre à un changement important dans la manière dont notre équipe de développement et d'exploitation interagira avec la nouvelle plate-forme ainsi que les rôles qu'ils rempliront. Et finalement, c'est un peu différent des autres mais c'est un modèle malheureux, l'approche de construire-votre-propre aux plates-formes d'application ne devrait jamais faire partie de notre processus de sélection.

Discutons-en un peu plus loin. évaluation des cadres d'application modernes

Dans certains cas, les projets peuvent vouloir présenter les applications existantes à la nouvelle plate-forme avec le moins de refactorisation possible. Cela accélère les efforts de migration et de modernisation mais laisse rarement l'application en mesure de tirer pleinement parti des capacités de la plate-forme et ne parvient souvent pas à fournir la valeur attendue.

La plate-forme porte généralement la responsabilité des architectes. application. Pour vraiment tirer profit de la plateforme, il faut repenser le cadre et l'architecture de l'application.

Adopter les concepts d'application à 12 facteurs, explorer les langages émergents (Ruby, Python, Go, Scala, etc.), évaluer d'autres cadres pour fournir des services mise en cache, notifications, proxy, maillage de service) à l'application et la révision des modèles d'applications natives du cloud (découverte de service, disjoncteur, configuration distribuée) sont autant d'aspects critiques de l'exploitation des plates-formes natives cloud.

améliorer vos pipelines de construction et de déploiement existants. Pas seulement les outils que vous utilisez, mais les zones de gaspillage dans vos processus existants.

Comment pouvez-vous saisir cette opportunité pour optimiser votre processus de développement de l'idée à la production? Quelles étapes ne seront plus nécessaires, de faible valeur, ou peuvent être facilement automatisées pour accélérer votre livraison? Et votre organisation est prête à s'adapter à ces changements pour faciliter l'adoption de la plateforme.

La façon d'appliquer les principes de Continuous Delivery, Lean et Agile devrait faire partie de votre processus d'évaluation et être essentielle au succès de l'adoption. N'oubliez pas que le rôle existant changera également, ne vous attendez pas à ce que certaines activités persistent dans votre processus de livraison actuel et dans votre plate-forme d'applications natives cloud. Les rôles doivent changer pour adopter un nouveau modèle.

Tenter de construire votre propre plate-forme d'application

Plusieurs des plates-formes dont j'ai discuté: Pivotal Cloud Foundry et RedHat OpenShift, souvent comparées aux Kubernetes de Google Le moteur ou récemment AWS EKS disposent tous d'un projet open source en amont qui constitue la base de ces solutions fournisseurs. Dans certains cas, des guides bien intentionnés mais inexpérimentés suggéreront «d'économiser de l'argent» et d'aller avec le projet open source en amont pour construire leur propre plateforme d'application.

Je ne saurais trop insister sur l'approche désastreuse adoptée. À de très rares exceptions près, vous ne trouverez pas de différenciateur compétitif ou d'économies de coûts à long terme dans les activités de construction de plate-forme.

Dans ce cas, vous êtes en concurrence avec Pivotal, Google et Redhat du monde. Vous finirez frustrés d'essayer de garder la plate-forme à jour et de réaliser que vous recréerez ce qui existe déjà la majorité du temps.

Il y a beaucoup à dire sur le sujet de la sélection et de l'adoption de plateformes. Pour l'instant je veux simplement souligner qu'une approche mesurée de la sélection de plate-forme est importante et chez Perficient nous avons un processus complet de sélection de plate-forme d'applications natives dans le cloud.

Inclut un critère d'évaluation construit et personnalisable modèles, un ensemble de listes de contrôle de préparation, et plus encore. Mais l'analyse de votre environnement culturel est tout aussi importante.

Vos développeurs et vos opérateurs doivent être ciblés tôt dans le processus de prise de décision. La décision sur la façon dont vous allez construire et automatiser vos processus de déploiement à l'avenir est essentielle et ne devrait pas être laissée après coup dans votre analyse. Evitez ces mauvaises configurations et expérimentez le succès rencontré lors de l'adoption réussie d'une plate-forme native de cloud.