samedi, 20 avril 2024

L’expérience des développeurs ne doit pas s’arrêter au front-end

Avec l’attrait croissant de l’infrastructure en tant que code, devops et plates-formes internes, les concepteurs back-end sont bien mieux équipés que jamais pour créer des applications et des services côté serveur extrêmement résistants, performants et évolutifs. Ils sont également en train de se noyer.

La complexité des applications modernes nécessite que les concepteurs back-end maîtrisent un éventail croissant d’outils, d’innovations et de stratégies, depuis les principes fondamentaux de Linux, les langages de script, la journalisation et le suivi. , à la mise en réseau basée sur le cloud, aux maillages de services, à l’observabilité, aux clusters Kubernetes et aux redoutables fichiers YAML.

Les concepteurs back-end pourraient bénéficier d’une pause ou, plus précisément, d’une bien meilleure expérience de conception. Heureusement, les fabricants d’outils se dépêchent de le fournir. De la réduction de la barre aux installations en tant que code, au lissage des workflows Kubernetes et des déploiements d’applications distribuées, en passant par la création d’espaces de travail de concepteurs dans le cloud selon les besoins, une nouvelle ère de projets promet de faciliter la vie des concepteurs qui travaillent côté serveur.

Les ingénieurs back-end ont aussi des sentiments

Dans le monde natif du cloud d’aujourd’hui, les concepteurs de toutes sortes graviteront naturellement vers des outils plus instinctifs et plus agréables à utiliser, même s’ils fonctionnent dans un domaine qui n’est généralement pas optimisé pour la simplicité et la facilité d’utilisation.

Alors que des entreprises comme Vercel et Netlify ont rencontré beaucoup de succès en se concentrant sur l’expérience du concepteur frontal et en éliminant le back-end, de nombreuses organisations voudront toujours un certain contrôle sur leurs installations de serveur. Les ingénieurs responsables de ce back-end pourraient également souhaiter une meilleure expérience.

« Il est naturel de voir des fournisseurs simplifier la tâche des concepteurs et c’est là que nous entrons dans les installations pour faire progresser les logiciels », RedMonk l’analyste James Governor a déclaré à InfoWorld. « En fin de compte, vous avez besoin de plates-formes pour vous permettre d’être plus efficace sans gérer manuellement les graphiques Helm, les opérateurs ou YAML. »

L’amélioration de l’expérience des développeurs back-end peut faire plus qu’améliorer le la vie des concepteurs back-end. Offrir des outils bien meilleurs et plus instinctifs peut permettre aux concepteurs back-end d’en faire plus, tout en éliminant les obstacles pour permettre à un plus grand nombre de développeurs de gérer leurs propres installations grâce à des abstractions réfléchies.

« Le contrôle des développeurs sur les installations n’est pas une proposition de tout ou rien », a écrit l’experte de Gartner Lydia Leong. « L’obligation peut être répartie tout au long du cycle de vie de l’application, de sorte que vous pouvez tirer parti du » vous le construisez, vous l’exécutez « sans toujours parachuter vos développeurs dans une nature sauvage et inconnue et leur souhaiter de la chance car ce n’est pas une ‘installations et problème du groupe d’opérations ».

En d’autres termes, « il est tout à fait acceptable de permettre à vos concepteurs d’accéder en libre-service aux environnements de développement et de test, et de créer des modèles d’infrastructure en tant que code pour production, sans les rendre entièrement responsables de la production », écrit Leong.

Pulumi : Apporter l’expérience des développeurs dans un pays oublié

Prenez Pulumi, qui vise à faire de la tâche de configuration de l’infrastructure quelque chose n’importe quel concepteur peut le faire en travaillant dans son langage d’émissions préféré, plutôt que quelque chose de propriétaire comme CloudFormation pour Amazon Web Solutions (AWS), Bicep pour Microsoft Azure ou YAML pour Kubernetes. Le moteur open source Pulumi configure ensuite les installations virtuelles et les points de terminaison pour que le code y soit déposé.

Pulumi est, essentiellement, un autre choix pour l’approvisionnement des installations en tant que code, mais garantit une courbe de connaissance moins profonde que des outils comme CloudFormation ou Terraform de HashiCorp.

Alors qu’il travaillait sur des outils de conception depuis plus d’une décennie chez Microsoft, le créateur et PDG de Pulumi, Joe Duffy, a été frappé par la réalisation que « personne n’avait réellement utilisé le niveau d’attention et d’amour pour la zone des installations ». car ils avaient besoin d’avancement frontal. « Le cloud était une réflexion après coup inintéressante et désordonnée », a-t-il déclaré à InfoWorld.

« La meilleure technologie que nous avions était Terraform, qui est une innovation propriétaire, alors que je souhaitais simplement un IDE et utiliser mon langage préféré , mais utilisez toujours le cloud au maximum », a déclaré Duffy.

L’expérience des développeurs est « la vie même » pour Pulumi, selon Duffy. « Nous voulons apporter une formidable expérience de développement dans un domaine qui n’en avait pas. C’est pourquoi nous utilisons des langages de fonctions de base », a-t-il déclaré. « Nous souhaitons que cette expérience soit satisfaisante et non fastidieuse. »

Pour les ingénieurs d’infrastructure, de plate-forme et de devops travaillant dans des environnements parsemés d’héritage, Pulumi permet la mise en place d’installations recyclables pour les développeurs, avec des politiques et dépistage en tant que code. Pulumi a récemment annoncé une édition Organisation Vital pour les entreprises clientes de ce type.

Pour les concepteurs travaillant dans des environnements plus nouveaux et natifs du cloud, Pulumi leur permet d’être véritablement full-stack, mais sans avoir à découvrir de nouveaux langages ou des capacités back-end spécifiques à un domaine.

« Je voulais trouver un service qui nous permette de concevoir des installations, non pas en écrivant du code de configuration et en exécutant un script, mais en tant que processus d’avancement logiciel, via le code et un flux de travail basé sur Git », a déclaré Andy Dang, ancien ingénieur AWS senior et cofondateur de la startup d’observabilité WhyLabs, à InfoWorld.

WhyLabs s’est tourné vers Pulumi après que Dang ait trouvé des choix d’infrastructure en tant que code existants comme CloudFormation et Terraform. complexe, notant que CloudFormation en particulier n’est « pas composé pour l’apport humain ».

Au contraire, Dang souhaitait que les équipes de développement et d’ingénierie allégées de WhyLabs soient en mesure de « réduire la quantité de connaissances spécifiques à l’infrastructure que le groupe nécessite, de sorte que t ils peuvent se concentrer au mieux sur leur élément particulier de la pile », a-t-il déclaré.

HashiCorp Waypoint : Construire un flux de travail de développeur cohérent

Une autre entreprise qui se lance dans la mêlée ici est HashiCorp, les créateurs de le populaire outil d’infrastructure en tant que code Terraform. Dans le but de faciliter le parcours des développeurs pour structurer et déployer leurs applications sur Kubernetes et Elastic Container Service (ECS) d’Amazon, HashiCorp a lancé Waypoint en 2020.

« Notre société pense que les développeurs veulent simplement déployer », Chang Li, directeur du marketing produit chez HashiCorp, a déclaré à InfoWorld.

Pour les aider à le faire, Waypoint propose une couche d’abstraction et une interface conviviales pour les développeurs et les opérateurs. Pour les concepteurs, cela suggère une exécution de base des procédures de construction et de publication, tandis que les opérateurs acquièrent une cohérence et une standardisation indispensables dans différents environnements, le tout en utilisant une seule commande : waypoint up.

« Notre public principal est les opérateurs », a déclaré Li. « À l’échelle de l’entreprise, les équipes opérationnelles se sentent obligées de standardiser un flux de travail à l’échelle de plusieurs plates-formes. Généralement, elles utilisent des outils CI/CD comme Jenkins ou Spinnaker et les trouvent trop lourds. »

Pour HashiCorp,  » Waypoint pourrait remplacer ces manuscrits ou ces flux de travail CI/CD personnalisés », a déclaré Li. « Ce devrait être une expérience simplifiée, sans interaction complexe avec l’infrastructure sous-jacente. »

C’est exactement cette même aggravation avec les outils CI/CD existants qui a en fait poussé le créateur de Docker, Solomon Hykes, à essayer de faire CI/CD plus convivial pour les développeurs avec sa tâche open source, Dagger.

Render : un mélange Goldilocks de choix d’hébergement

Établi par l’ancien responsable du danger chez Stripe, Anurag Goel, Render vise à offrir aux développeurs un mélange Goldilocks de choix d’hébergement qui se situent entre des plates-formes extrêmement opiniâtres comme Heroku et la complexité illimitée d’AWS.

Après avoir quitté Stripe, Goel s’amusait avec l’apprentissage automatique pendant son temps libre. Tout en apprenant à développer des conceptions d’apprentissage automatique, il a vu des scientifiques de l’information investir des jours pour préparer leurs environnements de bloc-notes Jupyter. Au lieu de cela, Goel voulait « un provisionnement en un clic dans le cloud » et une expérience qui reflétait celle de l’intégration des paiements à l’aide de l’API Stripe.

« Je n’arrêtais pas d’être attiré par l’infrastructure et les performances des développeurs », a-t-il déclaré à InfoWorld. « À la base, Render automatise les devops. »

En pratique, les concepteurs peuvent lier leur référentiel GitHub ou GitLab à Render, qui commence alors à recommander des commandes pour créer et démarrer votre application. Render est un service propriétaire et fonctionne sur AWS et Google Cloud en attendant, avec une assistance bare metal à venir rapidement.

« Les gens viennent nous voir parce qu’ils pensent que Kubernetes est trop complexe, mais les fonctions qu’ils ont besoin sont sur Render en raison du fait que nous avons développé sur Kubernetes d’une manière qui expose exactement ce qu’ils désirent », a déclaré Goel.

Où Render diffère des autres backend-as-a-service ( BaaS) alternatives d’hébergement est qu’il n’apporte pas de point de vue sur la façon de créer et d’exécuter vos applications, qu’il s’agisse d’un site Web fixe, d’une tâche Cron ou de quoi que ce soit dans un conteneur Docker. « Nous ne poussons pas une idéologie particulière sur la façon de construire des applications », a déclaré Goel.

Render n’est pas non plus le seul à adopter une méthode BaaS centrée sur le développeur. Le travail open source Appwrite travaille sur une plate-forme auto-hébergée permettant aux développeurs d’exécuter facilement des applications Web, mobiles et Flutter via un ensemble d’API sélectionnées.

Encore : Apporter la méthode back-end Spotify au masses

Encore est un autre travail open source plus récent visant à améliorer l’expérience des concepteurs pour les tâches d’ingénierie back-end. Intégré à Go, Encore est un framework back-end qui résume les tâches de configuration manuelles pour les environnements cloud.

Encore a l’intention d’aider les développeurs à rester dans un état de circulation en automatisant les actions de configuration manuelle pour le provisionnement de l’infrastructure cloud, en créant un passe-partout code, instrumenter l’application et produire la documentation. Les développeurs peuvent ensuite publier sur AWS, Azure ou Google Cloud.

Le projet a été créé en 2021 par les anciens ingénieurs de Spotify André Eriksson, Marcus Kohlberg et Horia Jurcu, en plus de l’ancien ingénieur de Monzo Dominic Black et l’ancien ingénieur Google Stefan Ekerfelt. Les fondateurs déclarent que Repetition était fondée sur leurs aggravations partagées en composant une infrastructure back-end distribuée complexe et la répétition constante de tâches back-end spécifiques.

Repetition s’efforce de « conserver les excellentes parties du cloud et de changer ce qui les concepteurs traitent, leur permettant de développer des produits et de ne pas s’enliser dans les marécages de YAML et de tuyaux », a déclaré Eriksson à InfoWorld.

La start-up a levé un tour de table de 3 millions de dollars mené par Crane Endeavour Partners et a rendu son moteur de développement back-end open source généralement disponible en avril 2022.

Gitpod : environnements de développement à la demande

Ensuite, il y a Gitpod, un projet open source aux prises avec le très problème spécifique de fournir aux concepteurs leur environnement de développement local bien usé, mais tous prêts à entrer dans le cloud en quelques secondes.

Alors que l’industrie s’est en fait principalement déplacée vers des pipelines de production et de publication d’installations automatisées, le cofondateur Johannes Landgraf pensait qu’il était « un peu fou » que les concepteurs continuent de « dupliquer des environnements de concepteur qui reposent sur des ordinateurs privés et subissent une dérive de configuration ».

Gitpod commence par un fichier YAML qui explique à quoi doit ressembler l’environnement de développement , de l’IDE à la base de données, total avec les compilateurs, les serveurs de langage et le système d’exploitation. « Tout ce qui se trouve sur votre système informatique local, nous le portons sur le cloud avec la même expérience à laquelle les concepteurs sont habitués », a déclaré Landgraf.

Gitpod s’intègre à GitHub, GitLab et Bitbucket et préconstruit tous vos projets chaque fois que le code est poussé vers votre référentiel, comme un serveur de combinaison continue. Lorsque les développeurs lancent un environnement, tout est actuellement initialisé et prêt à s’exécuter. Ils n’ont pas besoin d’attendre que les dépendances se chargent et que les scripts soient construits.

L’expérience des concepteurs fait « partie de notre ADN de base », a déclaré Landgraf. « Notre objectif est de supprimer autant de frictions que possible pour que les développeurs fassent ce pour quoi ils sont payés et ce qu’ils aiment, c’est-à-dire être innovant, composer du code et développer de la valeur, sans altérer les choses qui les ralentissent. »

Le travail open source a actuellement connu une bonne traction, GitHub faisant bientôt de même en introduisant son propre environnement de développement basé sur le cloud appelé Codespaces en 2021.

Tous les ingénieurs GitHub opèrent désormais dans Codespaces, où « les environnements avancés sont provisionnés à la demande pour la tâche à accomplir » et les concepteurs peuvent « développer des Codespaces fiables et préconfigurés, préparés et préparés pour l’avancement de GitHub.com en 10 secondes », selon le directeur principal de l’ingénierie de GitHub, Cory Wilkerson.

Comment AWS, Azure et Google Cloud simplifient les constructions d’infrastructures

Les trois grandes sociétés de cloud ont toujours tendance à fournir des outils primitifs plutôt que des outils opiniâtres. Cependant, en 2015, AWS a été transféré pour permettre aux entreprises de configurer leur propre ensemble de modèles de conception d’environnement reproductibles avec l’introduction d’AWS Proton. Cet outil en libre-service permet aux développeurs de déployer sur une infrastructure prête pour la production qui a déjà été créée et autorisée par un devops professionnel ou un groupe de plate-forme.

Proton diffère des options back-end entièrement gérées comme AWS App Runner ou AWS Amplify, qui prennent les choses encore plus en action en gérant l’ensemble des pipelines de configuration, de mise en réseau, d’équilibrage de charge et de publication pour les applications Web, mobiles ou conteneurisées à exécuter dans le cloud.

Google et Microsoft fournir des services back-end avisés comparables, tels que Google Firebase et Azure App Service, mais pas la capacité de produire des modèles de conception d’environnement spécifiques à l’entreprise fournis par Proton.

Permettre un véritable développement en libre-service

Même si les concepteurs acquièrent de plus en plus d’excellentes alternatives pour faire abstraction de toutes leurs tâches de développement back-end, il y aura toujours une forte demande d’outils permettant aux entreprises de fournir et de gérer leur propre infrastructure et ly brochure pour que les concepteurs l’utilisent.

« Ces outils n’en sont qu’à leurs débuts, mais je constate une adoption rapide car ils résolvent 2 problèmes courants dont nous entendons beaucoup parler : l’informatique d’entreprise qui souhaite verrouiller les environnements, et empêcher les concepteurs d’introduire des éléments non réglementés dans l’organisation », a déclaré l’ancien analyste de Gartner Fintan Ryan à InfoWorld.

Si ces outils peuvent également faire abstraction du travail inclus dans de nombreuses tâches d’ingénierie et de développement back-end, alors ils le feront prennent leur place non seulement dans le cercle des gagnants de cette classification émergente, mais également dans le cœur et l’esprit des constructeurs d’applications et de services back-end.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici