L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2025 !
Choisir une nouvelle technologie de base de données sans serveur dans une agence (étude de cas)
L'adoption d'une nouvelle technologie est l'une des décisions les plus difficiles pour un technologue dans un rôle de leadership. Il s'agit souvent d'un domaine de risque important et inconfortable, que vous construisiez des logiciels pour une autre organisation ou au sein de la vôtre.
Au cours des douze dernières années en tant qu'ingénieur logiciel, je me suis retrouvé dans la position d'avoir à évaluer un nouvelle technologie à une fréquence croissante. Cela peut être le prochain framework frontend, un nouveau langage ou même des architectures entièrement nouvelles comme sans serveur.
La phase d'expérimentation est souvent amusante et excitante. C'est là que les ingénieurs logiciels sont le plus à l'aise, embrassant la nouveauté et l'euphorie des moments «aha» tout en développant de nouveaux concepts. En tant qu'ingénieurs, nous aimons penser et bricoler, mais avec suffisamment d'expérience, chaque ingénieur apprend que même la technologie la plus incroyable a ses imperfections. Vous ne les avez tout simplement pas encore trouvés.
Maintenant, en tant que co-fondateur d'une agence de création, mon équipe et moi sommes souvent dans une position unique pour utiliser les nouvelles technologies. Nous voyons de nombreux projets greenfield, qui deviennent l'occasion idéale pour introduire quelque chose de nouveau. Ces projets voient également un niveau d’isolement technique par rapport à l’organisation plus large et sont souvent moins chargés par les décisions antérieures.
Cela étant dit, un bon chef d’agence est chargé de prendre en charge la grande idée de quelqu'un d’autre et de la diffuser dans le monde. Nous devons le traiter avec encore plus de soin que nos propres projets. Chaque fois que je suis sur le point de faire le dernier appel à une nouvelle technologie, je médite souvent sur ce morceau de sagesse du co-fondateur de Stack Overflow Joel Spolski :
«Vous devez transpirer et saigner avec la chose pendant un an ou deux avant que vous ne sachiez vraiment que c'est assez bon ou que vous vous rendiez compte que peu importe vos efforts, vous ne pouvez pas … »
C'est la peur, c'est l'endroit où aucun responsable technique ne veut se retrouver Choisir une nouvelle technologie pour un projet réel est déjà assez difficile, mais en tant qu'agence, vous devez prendre ces décisions avec le projet de quelqu'un d'autre, le rêve de quelqu'un d'autre, l'argent de quelqu'un d'autre. Dans une agence, la dernière chose que vous voulez est de trouver l'une de ces imperfections près de la date limite d'un projet. Des délais et des budgets serrés font qu'il est presque impossible de changer de cap après le franchissement d'un certain seuil, donc découvrir qu'une technologie ne peut pas faire quelque chose de critique ou qu'elle n'est pas fiable trop tard dans un projet peut être catastrophique.
Tout au long de ma carrière en tant que logiciel ingénieur, j'ai travaillé dans des entreprises SaaS et des agences de création. Lorsqu'il s'agit d'adopter une nouvelle technologie pour un projet, ces deux environnements ont des critères très différents. Il y a chevauchement des critères, mais dans l'ensemble, l'environnement de l'agence doit fonctionner avec des budgets rigides et des contraintes de temps rigoureuses. Bien que nous souhaitons que les produits que nous fabriquons vieillissent bien au fil du temps, il est souvent plus difficile d'investir dans quelque chose de moins éprouvé ou d'adopter une technologie avec des courbes d'apprentissage plus prononcées et des aspérités.
Cela étant dit, les agences ont également des contraintes uniques qui une seule organisation peut ne pas en avoir. Nous devons privilégier l'efficacité et la stabilité. L'heure facturable est souvent la dernière unité de mesure lorsqu'un projet est terminé. J'ai travaillé dans des entreprises SaaS où passer un jour ou deux à la configuration ou à un pipeline de construction n'est pas un problème. Dans une agence, ce type de coût en temps met les relations à rude épreuve, car les équipes financières voient une réduction des marges bénéficiaires pour des résultats peu visibles. Nous devons également considérer la maintenance à long terme d'un projet, et inversement ce qui se passe si un projet doit être remis au client. Nous devons donc privilégier l’efficacité, la courbe d’apprentissage et la stabilité de la technologie que nous choisissons.
Lors de l’évaluation d’une nouvelle technologie, j’examine trois domaines primordiaux:
- La technologie
- L’expérience du développeur
- Le Entreprise
Chacun de ces domaines a un ensemble de critères que j'aime bien remplis avant de commencer vraiment à me plonger dans le code et à expérimenter. Dans cet article, nous examinerons ces critères et utiliserons l'exemple consistant à considérer une nouvelle base de données pour un projet et à l'examiner à un niveau élevé sous chaque lentille. Prendre une décision tangible comme celle-ci aidera à démontrer comment nous pouvons appliquer ce cadre dans le monde réel.
La technologie
La toute première chose à considérer lors de l'évaluation d'une nouvelle technologie est de savoir si cette solution peut résoudre les problèmes il prétend résoudre. Avant de se plonger dans la manière dont une technologie peut aider nos processus et nos opérations commerciales, il est important de déterminer d’abord qu’elle répond à nos exigences fonctionnelles. C'est aussi là que j'aime jeter un œil aux solutions existantes que nous utilisons et comment cette nouvelle se compare à elles.
Je me pose des questions comme:
- Est-ce que cela résout au minimum le problème mon
- En quoi cette solution est-elle meilleure?
- En quoi est-elle pire?
- Pour les domaines où elle est pire, que faudra-t-il pour surmonter ces lacunes?
- Quelle est la stabilité de la technologie?
Notre pourquoi?
À ce stade, je veux aussi examiner pourquoi nous cherchons une autre solution. Une réponse simple est que nous rencontrons un problème que les solutions existantes ne résolvent pas. Cependant, c'est souvent rarement le cas. Nous avons résolu de nombreux problèmes logiciels au fil des ans avec toute la technologie dont nous disposons aujourd'hui. Ce qui se passe généralement, c'est que nous nous tournons vers une nouvelle technologie qui rend quelque chose que nous faisons actuellement plus facile, plus stable, plus rapide ou moins cher.
Prenons l'exemple de React. Pourquoi avons-nous décidé d'adopter React alors que jQuery ou Vanilla JavaScript faisait le travail? Dans ce cas, l'utilisation du framework a mis en évidence le fait qu'il s'agissait d'un bien meilleur moyen de gérer les frontends avec état. Il est devenu plus rapide pour nous de créer des fonctionnalités telles que le filtrage et le tri en travaillant avec des structures de données au lieu de manipuler directement le DOM. C'était un gain de temps et une stabilité accrue de nos solutions. Typescript est un autre exemple où nous avons décidé de l'adopter car nous avons constaté des augmentations de la stabilité de notre code et de sa maintenabilité. Avec l'adoption de nouvelles technologies, il n'y a souvent pas de problème clair que nous cherchons à résoudre, mais plutôt simplement à rester à jour et à découvrir ensuite des solutions plus efficaces et stables que celles que nous utilisons actuellement.
Dans le cas d'une base de données, nous envisageaient spécifiquement de passer à une option sans serveur. Nous avons vu beaucoup de succès avec des applications et des déploiements sans serveur réduisant nos frais généraux en tant qu'organisation. Un domaine dans lequel nous avons estimé que cela manquait était notre couche de données. Nous avons vu des services comme Amazon Aurora, Fauna, Cosmos et Firebase qui appliquaient des principes sans serveur aux bases de données et nous voulions voir s'il était temps de faire le saut nous-mêmes. Dans ce cas, nous cherchions à réduire nos frais généraux opérationnels et à augmenter notre vitesse et notre efficacité de développement.
Il est important à ce niveau de comprendre pourquoi avant de vous lancer dans de nouvelles offres. Cela peut être dû au fait que vous résolvez un problème nouveau, mais beaucoup plus souvent vous cherchez à améliorer votre capacité à résoudre un type de problème que vous résolvez déjà. Dans ce cas, vous devez faire l'inventaire des lieux où vous êtes allé pour déterminer ce qui pourrait apporter une amélioration significative à votre flux de travail. En nous basant sur notre exemple de recherche de bases de données sans serveur, nous devrons examiner comment nous résolvons actuellement les problèmes et où ces solutions sont insuffisantes.
Où nous en sommes…
En tant qu'agence, nous avons déjà a utilisé un large éventail de bases de données, notamment MySQL, PostgreSQL, MongoDB, DynamoDB, BigQuery et Firebase Cloud Storage. La grande majorité de notre travail s'est cependant concentrée sur trois bases de données principales, PostgreSQL, MongoDB et Firebase Realtime Database. Chacun d'entre eux propose en fait des offres semi-sans serveur, mais certaines caractéristiques clés des offres plus récentes nous ont amenés à réévaluer nos hypothèses précédentes. Jetons un coup d'œil à notre expérience historique avec chacun de ces éléments en premier et pourquoi nous sommes laissés à envisager des alternatives en premier lieu.
Nous avons généralement choisi PostgreSQL pour des projets plus importants et à long terme, car il s'agit de la norme de référence éprouvée pour la bataille. presque tout. Il prend en charge les transactions classiques, les données normalisées et est conforme à ACID. Il existe une multitude d'outils et d'ORM disponibles dans presque toutes les langues et il peut même être utilisé comme base de données NoSQL ad hoc avec sa prise en charge de colonnes JSON. Il s'intègre bien avec de nombreux frameworks, bibliothèques et langages de programmation existants, ce qui en fait un véritable bourreau de travail partout. Il est également open-source et ne nous enferme donc pas dans un seul fournisseur. Comme on dit, personne n'a jamais été renvoyé pour avoir choisi Postgres.
Cela étant dit, nous nous sommes progressivement retrouvés à utiliser PostgreSQL de moins en moins au fur et à mesure que nous devenions une boutique orientée Node. Nous avons trouvé que l'ORM pour Node était terne et nécessitait plus de requêtes personnalisées (bien que cela soit devenu moins problématique maintenant) et NoSQL semblait être un ajustement plus naturel lorsque vous travaillez dans un environnement d'exécution javascript ou dactylographié. Cela étant dit, nous avions souvent des projets qui pouvaient être réalisés assez rapidement avec la modélisation relationnelle classique comme les workflows de commerce électronique. Cependant, gérer la configuration locale de la base de données, unifier le flux de test entre les équipes et gérer les migrations locales étaient des choses que nous n'aimions pas et que nous étions heureux d'abandonner alors que les bases de données NoSQL basées sur le cloud devenaient plus populaires.
MongoDB était de plus en plus notre base de données de choix car nous avons adopté Node comme back-end préféré. Travailler avec MongoDB Atlas a facilité la création rapide de bases de données de développement et de test que notre équipe pourrait utiliser. Pendant un certain temps, MongoDB n'était pas conforme à ACID, ne prenait pas en charge les transactions et décourageait trop d'opérations de type jointure interne.Par conséquent, pour les applications de commerce électronique, nous utilisions toujours Postgres le plus souvent. Cela étant dit, il existe une multitude de bibliothèques qui vont avec et le langage de requête de Mongo et le support JSON de première classe nous ont donné une vitesse et une efficacité que nous n'avions pas expérimentées avec les bases de données relationnelles. MongoDB a récemment ajouté la prise en charge des transactions ACID, mais pendant longtemps, c'était la principale raison pour laquelle nous avons opté pour Postgres à la place.
MongoDB nous a également introduit un nouveau niveau de flexibilité. Au milieu d'un projet d'agence, les exigences sont vouées à changer. Peu importe à quel point vous vous en défendez, il y a toujours une exigence de données de dernière minute. Avec les bases de données NoSQL, en général, la flexibilité de la structure des données a rendu ces types de changements moins sévères. Nous ne nous sommes pas retrouvés avec un dossier rempli de fichiers de migration pour gérer à nouveau les colonnes ajoutées, supprimées et ajoutées avant même qu'un projet ne voie le jour.
En tant que service, Mongo Atlas était également assez proche de ce que nous souhaitions dans une base de données service cloud. J'aime penser à Atlas comme une offre semi-sans serveur car vous avez encore des frais généraux opérationnels pour la gérer. Vous devez provisionner une base de données d'une certaine taille et sélectionner une quantité de mémoire à l'avance. Ces éléments ne seront pas automatiquement mis à l'échelle pour vous, vous devrez donc le surveiller lorsqu'il est temps de fournir plus d'espace ou de mémoire. Dans une base de données véritablement sans serveur, tout cela se produirait automatiquement et à la demande.
Nous avons également utilisé Firebase Realtime Database pour quelques projets. Il s'agissait en effet d'une offre sans serveur où la base de données évoluait à la demande, et avec une tarification à l'utilisation, cela avait du sens pour les applications où l'échelle n'était pas connue à l'avance et le budget limité. Nous l'avons utilisé à la place de MongoDB pour des projets de courte durée nécessitant des données simples. Une chose que nous n'avons pas appréciée à propos de Firebase était qu'il était plus éloigné du modèle relationnel typique construit autour de données normalisées auxquelles nous étions habitués. Garder les structures de données à plat signifiait que nous avions souvent plus de duplication, ce qui pouvait devenir un peu moche à mesure qu'un projet se développait. Vous finissez par devoir mettre à jour les mêmes données à plusieurs endroits ou essayer de réunir différentes références, ce qui entraîne plusieurs requêtes qui peuvent devenir difficiles à raisonner dans le code. Bien que nous aimions Firebase, nous ne sommes jamais vraiment tombés amoureux du langage de requête et avons parfois trouvé la documentation médiocre.
En général, MongoDB et Firebase avaient un objectif similaire sur les données dénormalisées, et sans accès à des transactions efficaces, nous souvent trouvé de nombreux flux de travail faciles à modéliser dans des bases de données relationnelles, ce qui a conduit à un code plus complexe au niveau de la couche application avec leurs homologues NoSQL. Si nous pouvions obtenir la flexibilité et la facilité de ces offres NoSQL avec la robustesse et la modélisation relationnelle d'une base de données SQL traditionnelle, nous aurions vraiment trouvé une bonne correspondance. Nous avons estimé que MongoDB avait la meilleure API et les meilleures capacités, mais Firebase avait le modèle véritablement sans serveur sur le plan opérationnel.
![Un diagramme de Venn montrant trois cercles de technologies A, B et C ayant un même point commun: une nouvelle solution idéale des fonctionnalités que vous aimez [19659043] Quand on regarde différentes technologies, l'ensemble des fonctionnalités de notre solution idéale va vivre quelque part où ces technologies se chevauchent. Cela nous donne tout ce que nous aimons, mais aussi des fonctionnalités supplémentaires qui étaient auparavant des compromis. (<a href=](https://i0.wp.com/cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/6e435c39-4b77-4ea2-8c49-8224aba96fd5/3-fauna-serverless-database-technology.png?ssl=1)
Grand aperçu )Notre idéal
À ce stade, nous pouvons commencer à examiner les nouvelles options que nous envisagerons. Nous avons clairement défini nos solutions précédentes et nous avons identifié les éléments qu'il est important que nous ayons au minimum dans notre nouvelle solution. Nous avons non seulement une base ou un ensemble minimum d’exigences, mais nous avons également un ensemble de problèmes que nous aimerions que la nouvelle solution atténue pour nous. Voici les exigences techniques que nous avons:
- Opérationnellement sans serveur avec une échelle à la demande
- Modélisation flexible (sans schéma)
- Pas de dépendance aux migrations ou aux ORM
- Transactions conformes ACID
- Prend en charge les relations et les données normalisées [19659016] Fonctionne avec les backends sans serveur et traditionnels
Alors maintenant que nous avons une liste de must-have, nous pouvons en fait évaluer certaines options. Il n'est peut-être pas important que la nouvelle solution cloue chaque cible ici. Il se peut simplement qu'il atteigne la bonne combinaison de fonctionnalités là où les solutions existantes ne se chevauchent pas. Par exemple, si vous vouliez une flexibilité sans schéma, vous deviez abandonner les transactions ACID. (Ce fut le cas pendant longtemps avec les bases de données.) Un exemple d'un autre domaine est que si vous voulez avoir une validation dactylographiée dans votre rendu de modèle, vous devez utiliser TSX et React. Si vous optez pour des options telles que Svelte ou Vue, vous pouvez avoir cela partiellement mais pas complètement à travers le rendu du modèle. Ainsi, une solution qui vous donne le faible encombrement et la vitesse de Svelte avec la vérification du type au niveau du modèle de React et TypeScript pourrait être suffisante pour être adoptée même s'il manquait une autre fonctionnalité. L'équilibre entre les désirs et les besoins va changer d'un projet à l'autre. C'est à vous de déterminer où va se trouver la valeur et de décider comment cocher les points les plus importants de votre analyse.
Nous pouvons maintenant jeter un œil à une solution et voir comment elle s'évalue par rapport à la solution souhaitée. Fauna est une solution de base de données sans serveur qui bénéficie d'une échelle à la demande avec une distribution mondiale. Il s'agit d'une base de données sans schéma, qui fournit des transactions conformes à ACID et prend en charge les requêtes relationnelles et les données normalisées en tant que fonctionnalité. Fauna peut être utilisé à la fois dans des applications sans serveur ainsi que dans des backends plus traditionnels et fournit des bibliothèques pour travailler avec les langages les plus courants. Fauna fournit en outre des flux de travail pour l'authentification ainsi qu'une multi-location simple et efficace. Ce sont deux caractéristiques supplémentaires solides à noter, car elles pourraient être les facteurs déterminants lorsque deux technologies sont nez à nez dans notre évaluation.
Maintenant, après avoir examiné toutes ces forces, nous devons évaluer les faiblesses. L'un d'eux est Fauna n'est pas open source. Cela signifie qu'il existe des risques de blocage des fournisseurs ou de changements commerciaux et tarifaires qui échappent à votre contrôle. L'open source peut être agréable car vous pouvez souvent proposer la technologie à un autre fournisseur si vous le souhaitez ou contribuer potentiellement au projet. Dans le monde des agences, le verrouillage des fournisseurs est quelque chose que nous devons surveiller de près, pas tant à cause du prix, mais la viabilité de l'entreprise sous-jacente est importante. Devoir changer de base de données sur un projet en cours de développement ou vieux de quelques années est à la fois désastreux pour une agence. Souvent, un client devra payer la facture pour cela, ce qui n'est pas une conversation agréable à avoir.
Une autre faiblesse qui nous préoccupait est l'accent mis sur JAMstack. Bien que nous aimions JAMstack, nous nous trouvons en train de créer plus souvent une grande variété d'applications Web traditionnelles. Nous voulons être sûrs que Fauna continue de prendre en charge ces cas d'utilisation. Nous avons eu une mauvaise expérience dans le passé avec un fournisseur d'hébergement qui était all-in sur JAMstack et nous avons fini par devoir migrer un assez grand nombre de sites à partir du service, nous voulons donc être sûrs que tous les cas d'utilisation continueront de se produire. support solide. À l'heure actuelle, cela semble être le cas, et les flux de travail sans serveur fournis par Fauna peuvent en fait compléter assez bien une application plus traditionnelle.
À ce stade, nous avons effectué nos recherches fonctionnelles et le seul moyen de savoir si cette solution est viable est de descendre et d'écrire du code. Dans un environnement d'agence, nous ne pouvons pas simplement prendre des semaines sur le calendrier pour que les gens évaluent plusieurs solutions. C'est la nature du travail en agence par rapport à un environnement SaaS. Dans ce dernier cas, vous pourriez construire quelques prototypes pour essayer de trouver la bonne solution. Dans une agence, vous aurez quelques jours pour expérimenter, ou peut-être l'occasion de faire un projet parallèle, mais dans l'ensemble, nous devons vraiment réduire cela à une ou deux technologies à ce stade, puis mettre les doigts sur le clavier.
L'expérience du développeur
Juger le côté expérience d'une nouvelle technologie est peut-être le plus difficile des trois domaines car il est par nature subjectif. Il aura également une variabilité d'une équipe à l'autre. Par exemple, si vous avez demandé à un programmeur Ruby, un programmeur Python et un programmeur Rust leurs opinions sur les différentes fonctionnalités du langage, vous obtiendrez tout un éventail de réponses. Donc, avant de commencer à juger une expérience, vous devez d'abord décider quelles caractéristiques sont les plus importantes pour votre équipe dans son ensemble.
Temps et configuration de l'installation
Les agences ont tendance à avoir peu de patience et de temps pour la configuration. Pour moi, j'aime les outils pointus, avec des conceptions ergonomiques, qui me permettent de travailler rapidement sur le problème de l'entreprise. Il y a quelques années, j'ai travaillé pour une entreprise SaaS qui avait une configuration locale complexe qui impliquait de nombreuses configurations et qui échouait souvent à des moments aléatoires dans le processus de configuration. Une fois que vous avez été installé, la sagesse conventionnelle était de ne rien toucher, et d’espérer que vous n’êtes pas resté assez longtemps dans l’entreprise pour devoir la configurer à nouveau sur une autre machine. J'ai rencontré des développeurs qui ont beaucoup aimé configurer chaque petit élément de leur configuration emacs et je n'ai rien pensé à perdre quelques heures dans un environnement local défectueux.
En général, j'ai trouvé que les ingénieurs d'agence ont un mépris pour ce genre de choses dans leur travail quotidien. À la maison, ils peuvent bricoler avec ces types d’outils, mais à une date limite, rien de tel que des outils qui fonctionnent. Dans les agences, nous préférerions généralement apprendre quelques nouvelles choses qui fonctionnent bien, de manière cohérente, plutôt que de pouvoir configurer chaque élément de technologie selon les goûts personnels de chaque individu.
Un des avantages de travailler avec une plate-forme cloud qui n'est pas open source est qu'elle possède entièrement l'installation et la configuration. Bien qu'un inconvénient soit le verrouillage des fournisseurs, l'avantage est que ces types d'outils font souvent ce pour quoi ils sont configurés. Il n'y a pas de bricolage avec les environnements, pas de configurations locales et pas de pipelines de déploiement. Nous avons également moins de décisions à prendre. C'est intrinsèquement l'attrait du serveur sans serveur. Le sans serveur en général repose davantage sur des services et des outils propriétaires. Nous échangeons la flexibilité de l'hébergement et du code source afin de gagner en stabilité et de nous concentrer sur les problèmes du domaine commercial que nous essayons de résoudre. Je noterai également que lorsque j'évalue une technologie et que j'ai le sentiment que la migration hors d'une plate-forme pourrait être nécessaire, c'est souvent un mauvais signe au départ.
Dans le cas des bases de données, l'ensemble- La configuration it-and-forget-it est idéale lorsque vous travaillez avec des clients où les besoins de la base de données peuvent être ambigus. Nous avons eu des clients qui ne savaient pas à quel point un programme ou une application serait populaire. Nous avons eu des clients pour lesquels nous n’avons pas été techniquement engagés à prendre en charge de cette manière, mais qui nous ont néanmoins appelés dans la panique quand ils avaient besoin de nous pour faire évoluer leur base de données ou leur application. Dans le passé, nous devions toujours prendre en compte des éléments tels que la redondance, la réplication des données et le partage à grande échelle lorsque nous élaborions nos SOW. Tenter de couvrir chaque scénario tout en étant également prêt à déplacer un livre complet d’activité au cas où une base de données n’aurait pas évolué est une situation impossible à préparer. En fin de compte, une base de données sans serveur facilite ces choses. Vous ne perdez jamais de données, vous n’avez pas à vous soucier de la réplication des données sur un réseau, ni de la mise à disposition d’une base de données et d’une machine plus volumineuses sur lesquelles les exécuter – tout fonctionne. Nous nous concentrons uniquement sur le problème commercial en question, l'architecture technique et l'échelle seront toujours gérées. Pour notre équipe de développement, c'est une énorme victoire; nous avons moins d'exercices d'incendie, de surveillance et de changement de contexte.
Apprentissage
Il existe une mesure classique de l'expérience utilisateur, qui, je pense, est applicable à l'expérience des développeurs, à savoir la capacité d'apprentissage. Lors de la conception d'une certaine expérience utilisateur, nous ne cherchons pas seulement si quelque chose est apparent ou facile au premier essai. La technologie a simplement plus de complexité que cela la plupart du temps. Ce qui est important, c'est la facilité avec laquelle un nouvel utilisateur peut apprendre et maîtriser le système. En ce qui concerne les outils techniques, en particulier les outils puissants, ce serait beaucoup demander qu'il n'y ait aucune courbe d'apprentissage. Habituellement, ce que nous recherchons, c'est qu'il y ait une excellente documentation pour les cas d'utilisation les plus courants et que ces connaissances puissent être facilement et rapidement développées dans un projet. Perdre un peu de temps pour apprendre sur le premier projet avec une technologie n'est pas un problème. Après cela, nous devrions voir l'efficacité s'améliorer avec chaque projet successif.
Ce que je recherche spécifiquement ici, c'est comment nous pouvons tirer parti des connaissances et des modèles que nous connaissons déjà pour aider à raccourcir la courbe d'apprentissage. Par exemple, avec les bases de données sans serveur, il n'y aura pratiquement aucune courbe d'apprentissage pour les installer dans le cloud et les déployer. Quand il s'agit d'utiliser la base de données, l'une des choses que j'aime, c'est quand nous pouvons encore tirer parti de toutes les années de maîtrise des bases de données relationnelles et appliquer ces apprentissages à notre nouvelle configuration. Dans ce cas, nous apprenons à utiliser un nouvel outil mais cela ne nous oblige pas à repenser notre modélisation de données à partir de zéro.
À titre d'exemple, lors de l'utilisation de Firebase, MongoDB et DynamoDB, nous avons constaté que cela encourageait les données dénormalisées plutôt que d'essayer de joindre différents documents. Cela a créé beaucoup de frictions cognitives lors de la modélisation de nos données, car nous devions penser en termes de modèles d'accès plutôt que d'entités commerciales. De l'autre côté de cette Faune nous a permis de tirer parti de nos années de connaissances relationnelles ainsi que de notre préférence pour les données normalisées lorsqu'il s'agissait de modéliser des données. La partie à laquelle nous avons dû nous habituer consistait à utiliser des index et un nouveau langage de requête pour rassembler ces éléments. En général, j'ai constaté que la préservation des concepts qui font partie de paradigmes de conception de logiciels plus larges facilite la tâche de l'équipe de développement en termes d'apprentissage et d'adoption.
Comment savons-nous qu'une équipe adopte et aime une nouvelle technologie. ? Je pense que le meilleur signe est lorsque nous nous demandons si cet outil s'intègre à ladite nouvelle technologie? Lorsqu'une nouvelle technologie atteint un niveau de désirabilité et de plaisir que l'équipe recherche des moyens de l'intégrer dans plus de projets, c'est un bon signe que vous avez un gagnant.
L'entreprise
Dans cette section, nous avons pour voir comment une nouvelle technologie répond aux besoins de notre entreprise. Celles-ci incluent des questions telles que:
- Dans quelle mesure peut-il être facilement tarifé et intégré dans nos plans de support?
- Pouvons-nous le transférer facilement vers les clients?
- Les clients peuvent-ils être intégrés à cet outil si nécessaire? le cas échéant, cet outil permet-il de gagner beaucoup de temps?
La montée en puissance du serveur sans serveur en tant que paradigme convient bien aux agences. Quand on parle de bases de données et de DevOps, le besoin de spécialistes dans ces domaines dans les agences est limité. Souvent, nous transférons un projet lorsque nous en avons terminé ou le soutenons dans une capacité limitée à long terme. Nous avons tendance à privilégier les ingénieurs full-stack car ces besoins dépassent largement ceux de DevOps. Si nous embauchions un ingénieur DevOps, il passerait probablement quelques heures à déployer un projet et beaucoup plus d'heures à attendre un incendie.
À cet égard, nous avons toujours des sous-traitants DevOps prêts, mais pas de personnel pour ces postes à temps plein. Cela signifie que nous ne pouvons pas compter sur un ingénieur DevOps pour être prêt à faire face à un problème inattendu. Pour nous, nous savons que nous pouvons obtenir de meilleurs tarifs d'hébergement en accédant directement à AWS, mais nous savons également qu'en utilisant Heroku, nous pouvons compter sur notre personnel existant pour résoudre la plupart des problèmes. Sauf si nous avons un client dont nous avons besoin pour prendre en charge à long terme des besoins spécifiques en backend, nous aimons utiliser par défaut les plates-formes gérées en tant que service.
Les bases de données ne font pas exception. Nous adorons nous appuyer sur des services comme Mongo Atlas ou Heroku Postgres pour rendre ce processus aussi simple que possible. Comme nous avons commencé à voir de plus en plus de notre pile se diriger vers des outils sans serveur comme Vercel, Netlify ou AWS Lambda, nos besoins en base de données ont dû évoluer avec cela. Les bases de données sans serveur comme Firebase, DynamoDB et Fauna sont excellentes car elles s'intègrent bien aux applications sans serveur, mais libèrent également complètement notre entreprise du provisionnement et de la mise à l'échelle. Ces solutions fonctionnent également bien pour les applications plus traditionnelles, dans lesquelles nous n’avons pas d’application sans serveur, mais nous pouvons toujours tirer parti de l’efficacité sans serveur au niveau de la base de données. En tant qu'entreprise, il est plus productif pour nous d'apprendre une base de données unique qui peut s'appliquer aux deux mondes plutôt qu'au changement de contexte. Ceci est similaire à notre décision d'adopter Node et javascript isomorphe (et dactylographié).
L'un des inconvénients que nous avons constatés avec le serveur sans serveur a été de proposer des prix pour les clients pour lesquels nous gérons ces services. Dans une architecture plus traditionnelle, les niveaux de taux forfaitaires permettent de les traduire très facilement en un taux pour les clients avec des circonstances prévisibles pour les augmentations et les dépassements. En ce qui concerne le sans serveur, cela peut être ambigu. Les gens de la finance n'aiment généralement pas entendre des choses comme nous facturons 1 / 10e de centime pour chaque lecture au-delà d'un million, et ainsi de suite. Cela est difficile à traduire en un chiffre concret, même pour les ingénieurs, car nous construisons souvent des applications dont nous ne sommes pas certains de l'utilisation. Nous devons souvent créer nous-mêmes des niveaux, mais les nombreuses variables qui entrent dans le calcul du coût d'un lambda peuvent être difficiles à comprendre. En fin de compte, pour un produit SaaS, ces modèles de tarification à l'utilisation sont excellents, mais pour les agences, les comptables aiment les chiffres plus concrets et prévisibles.
Quand il s'agissait de Fauna, c'était certainement plus ambigu à comprendre qu'une base de données MySQL standard qui avait un hébergement forfaitaire pour une quantité d'espace définie. L'avantage était que Fauna fournit une belle calculatrice que nous avons pu utiliser pour mettre en place nos propres systèmes de tarification.
Another difficult aspect of serverless can be that many of these providers do not allow for easy breakdown of each application being hosted. For instance, the Heroku platform makes this quite easy by creating new pipelines and teams. We can even enter a client’s credit card for them in case they don’t want to use our hosting plans. This can all be done within the same dashboard as well so we didn’t need to create multiple logins. When it came to other serverless tools this was much more difficult. In evaluating serverless databases Firebase supports splitting payments by project. In the case of Fauna or DynamoDB, this is not possible so we do have to do some work to monitor usage in their dashboard, and if the client wants to leave our service, we would have to transfer the database over to their own account.
Ultimately serverless tools provide great business opportunities in terms of cost savings, management, and process efficiency. However, often they do prove challenging for agencies when it comes to pricing and account management. This is one area where we have had to leverage cost calculators to create our own predictable pricing tiers or set clients up with their own accounts so they can make the payments directly.
Conclusion
It can be a difficult task to adopt a new technology as an agency. While we are in a unique position to work with new, greenfield projects that have opportunities for new technologies, we also have to consider the long-term investment of these. How will they perform? Will our people be productive and enjoy using them? Can we incorporate them into our business offering?
You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it’s important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses–the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.
After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity, however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.
When we first use a new technology on a project we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds mastery of the technology we begin using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past. In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don’t get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.
Further Reading
Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you’ll find levels of productivity you hadn’t realized before with existing databases.
(vf, il)Source link