Entretien avec le directeur technique d'Amazon : histoires, analyses et secrets en provenance de l'interne
TechFlow SélectionTechFlow Sélection
Entretien avec le directeur technique d'Amazon : histoires, analyses et secrets en provenance de l'interne
Si vous souhaitez devenir une entreprise en pleine croissance, vous ne pouvez pas agir comme une entreprise traditionnelle.
Dédié à des analyses Web3 approfondiesTraduction : TechFlow
Note : Cet article fait partie du dossier « Notes chinoises sur les cours de création d'entreprise YC » de TechFlow (mis à jour quotidiennement ; cet article est le dernier de la série). Il a pour objectif de recueillir et compiler les versions chinoises des cours YC. Le vingt-cinquième épisode présente le cours en ligne de Werner Vogels, directeur technique d'Amazon, intitulé « Expériences et perspectives sur la technologie et les startups ».
Avant Amazon
Avant de rejoindre Amazon, j’étais chercheur scientifique et ai travaillé pendant dix ans à l’université Cornell sur des systèmes distribués à grande échelle. Je n’étais pas un informaticien typique. J’ai vraiment décidé de retourner aux études à l’âge de 28 ans. Avant cela, je travaillais dans un hôpital en tant que radiothérapeute, prodiguant des traitements par rayonnement aux patients atteints de cancer au sein de l’Institut néerlandais du cancer. Un jour, j’ai réalisé que je ne pouvais plus supporter de voir les gens mourir autour de moi, alors j’ai décidé de faire quelque chose de complètement différent. L’informatique semblait être un bon choix.
Nous étions alors au milieu des années 80, et l’informatique n’était pas aussi répandue qu’aujourd’hui. Mais il s’est avéré que j’avais un certain talent, même si je ne le savais pas encore. J’ai donc commencé à approfondir ce domaine, car c’était vraiment ce qui m’intéressait. J’ai obtenu mon doctorat, travaillé quelques années dans un institut de recherche au Portugal, puis été invité à rejoindre l’université Cornell.
Durant mon séjour à Cornell, outre mes recherches, je conseillais régulièrement de grandes entreprises comme HP, ainsi que d’autres entreprises dont je ne me souviens plus clairement, tout en participant à diverses conférences. À un moment donné, Amazon m’a invité à présenter certains travaux sur lesquels je menais des recherches. Au départ, j’étais surpris et perplexe : Vraiment ? Dois-je vraiment le faire ?
À cette époque, quel était le défi posé par la navigation web et les bases de données ? Pourtant, dès que j’ai commencé à y travailler, j’ai compris qu’il s’agissait en réalité d’un défi technologique énorme. Amazon n’était pas seulement un détaillant, c’était une entreprise technologique opérant à une échelle que je n’avais jamais vue auparavant, bien supérieure à celle de toutes les autres entreprises pour lesquelles j’avais déjà consulté. Du point de vue de la recherche sur les systèmes distribués, les défis auxquels ils étaient confrontés étaient impressionnants.
Lorsqu’Amazon m’a proposé un poste, j’ai accepté sans hésiter.
Échelle opérationnelle et leadership technologique chez Amazon
Je pense que la plupart des chercheurs en systèmes distribués ont compris depuis longtemps à quelle échelle doivent fonctionner ces grandes entreprises — et pas seulement elles. Qu’il s’agisse d’entreprises Internet ou numériques, pour réussir, elles doivent opérer à très grande échelle.
En repensant à 2004, quand j’ai rejoint Amazon, beaucoup pourraient penser qu’à l’époque, opérer à l’échelle d’Amazon était relativement facile. Mais cela ne signifie pas que vous pouvez vous appuyer sur un poste ou une infrastructure essentielle. Beaucoup de travail a donc été accompli dans les technologies cloud et autres domaines afin de tirer pleinement parti des avantages offerts.
En 2004, Amazon avait déjà atteint une certaine échelle uniquement par la pratique, sans manuel ni guide expliquant comment construire une organisation ou une entreprise évolutives. Ainsi, selon moi, Amazon était en avance technologique, devançant de 5 à 10 ans en matière d’application, de développement technologique et d’échelle opérationnelle. Cela est particulièrement crucial pour les entreprises qui cherchent à croître rapidement.
Si vous voulez devenir une entreprise en croissance rapide, vous ne pouvez pas agir comme une entreprise traditionnelle. Ces dernières se heurtent souvent au dilemme de l’innovateur : une fois qu’une chose réussit, elles ralentissent considérablement.
Construire une entreprise capable de croître rapidement de manière continue est une tout autre affaire. Vous devez soigneusement évaluer votre activité. Par exemple, créer de la dette technique ou tolérer certaines redondances, ce qui serait inacceptable dans une entreprise traditionnelle où l’efficacité est l’objectif principal.
Chez Amazon, la rapidité, l’innovation rapide et un canal expérimental à long terme sont primordiaux. Ainsi, on accepte certaines redondances et on tolère une certaine dette technique, à condition de savoir qu’on devra la rembourser.
Par conséquent, il est difficile de trouver dans les livres classiques de MBA les compromis que Amazon est prêt à faire. La plupart du temps, Amazon a dû développer ses propres technologies, processus et flux opérationnels. Bien sûr, avec un leader visionnaire comme Jeff Bezos, qui comprend véritablement à quoi ressemblera l’avenir et comment devrait être le monde moderne.
Les clés de la croissance
Bien qu’Amazon ait déjà connu un grand succès en termes d’échelle, nous faisons face au défi de continuer à croître davantage. Pour passer à la phase suivante de croissance, nous devons réfléchir et agir plus rigoureusement.
Prenons l'exemple des performances. Comment mesurer les performances ? De quelle infrastructure avons-nous besoin pour effectuer ces mesures ? Pour devenir une entreprise véritablement pilotée par les données et prendre des décisions basées sur les données, il faut d’abord posséder les données, puis instaurer une culture centrée sur la façon d’évaluer et d’interpréter ces mesures.
Même un léger retard de 1,2 seconde dans le chargement d’une page peut nuire à l’expérience client. Cela signifie simplement que 50 % de l’expérience client se détériore — vous devez comprendre à quel point la situation est grave. D’un point de vue technique, des indicateurs comme 99 % ou 99,9 % deviennent également plus importants. Ensuite, vous devez mettre en place un mécanisme capable de maîtriser réellement la discipline de l’ingénierie à 99 %, et la relier aux décisions commerciales.
Je pense qu’en 2004, notre fiabilité était déjà assez élevée. Certaines règles nous encadraient, par exemple, nous devions utiliser des centres de données spécifiques (SEA). Toute opération effectuée sur ces centres de données SEA devait être répliquée dans d'autres centres, de sorte qu’en cas de panne d’un centre, les clients ne seraient pas affectés.
Les clients pourraient subir des retards, mais les fonctionnalités resteraient intactes. Nous étions très compétents dans la gestion de toutes ces règles, jusqu’au jour où nous avons décidé de déconnecter un centre de données pour voir ce qui se passerait. Un simple ajustement du réseau permettait d’isoler un centre de données des autres.
Cependant, en pratique, tout ce qui semblait parfait sur papier ne fonctionnait pas aussi bien qu’attendu. Même si la première tentative impliquait encore de nombreux processus manuels, comme le transfert manuel de base de données, nous avons continué à répéter ces scénarios toute l’année. Et lorsque vous arrivez à la troisième ou quatrième exécution, vous êtes presque en mesure d’automatiser totalement, sans intervention humaine. Cela est essentiel pour assurer une haute disponibilité et une tolérance aux pannes du système.
Dans nos efforts, nous accordons également une attention particulière au développement de l’analyse de données et des insights. Amazon dispose de vastes quantités de données, mais en extraire des informations utiles reste un défi. Nous nous efforçons de construire des outils puissants d’analyse de données et des modèles afin de mieux comprendre le comportement des clients, les tendances du marché et les opportunités commerciales. Cette approche fondée sur les données nous permet de prendre de meilleures décisions et d’offrir des produits et services personnalisés.
En outre, nous travaillons activement à améliorer l’expérience utilisateur. Nous étudions en profondeur les besoins et préférences des utilisateurs durant leur parcours d’achat, et améliorons l’expérience via l’optimisation du design, l’amélioration de l’interface et des recommandations personnalisées. Nous visons une expérience d’achat simple, intuitive et fluide, afin de répondre aux attentes des clients et gagner leur fidélité.
L’évolution du rôle du CTO
Le rôle du CTO change lorsqu’une entreprise devient fournisseur technologique.
J’ai abordé ce sujet dans un billet de blog. Selon moi, le CTO peut occuper quatre types de fonctions distincts :
- Premièrement, le CTO d’entreprise, généralement responsable de l’infrastructure, rapportant au directeur informatique (CIO), et chargé de la gestion d’infrastructures massives.
- Deuxièmement, le CTO cofondateur technologique, fréquent dans les jeunes entreprises, doté d’une vision technique. Mais je pense que ce rôle comporte un risque, car de nombreuses autres responsabilités, comme la gestion d’équipes d’ingénieurs, sont souvent incluses. Or, un CTO n’est pas nécessairement qualifié pour ces tâches — nous y reviendrons.
- Troisièmement, le CTO « penseur stratégique », qui impulse l’innovation. Par exemple, chez AT&T ou Lucent, le CTO ou son bureau se concentrent sur la recherche et l’expérimentation des technologies de prochaine génération.
- Enfin, le CTO expert technique orienté vers l’extérieur, qui, dans une entreprise fournissant des technologies, interagit profondément avec les clients, comprend comment ils utilisent les produits, et identifie des modèles plus profonds, plus larges, ainsi que les points douloureux des clients. Ce rôle va au-delà de la technologie elle-même pour embrasser l’ensemble du contexte.
Il est important de noter que ces rôles sont plus centrés sur le client, et pas uniquement sur la technologie. Il s’agit surtout de ramener les retours des clients à l’entreprise, et de réfléchir aux nouvelles fonctionnalités ou produits à développer, ou aux processus à modifier, afin de mieux servir les clients.
Ainsi, le rôle du CTO chez un fournisseur technologique est fortement orienté client, bien plus que centré sur la technologie seule.
La culture spécifique d’Amazon
Comme Amazon a été mon premier vrai emploi, j’ai longtemps cru que la culture d’entreprise ailleurs ressemblait à celle d’Amazon. En réalité, ce n’est pas le cas.
Amazon possède une culture unique, particulièrement efficace pour les entreprises en forte croissance. Elle encourage les équipes à être aussi autonomes que possible, en réduisant les niveaux hiérarchiques et la structure organisationnelle. La hiérarchie est perçue comme artificielle.
On privilégie les équipes auto-organisées, composées de personnes désireuses de travailler de façon indépendante et de s’approprier leurs produits. Les jeunes entreprises ont particulièrement besoin de cela, plutôt que de suiveurs ou de simples codeurs.
Amazon a mis en place un ensemble de principes de leadership, notamment l’obsession du client, le sens de la propriété, l’analyse approfondie, etc., au nombre de 14, qui guident sa culture.
Lors des entretiens d’embauche chez Amazon, l’accent est surtout mis sur l’adéquation culturelle, car un employé mal adapté peut gravement perturber une petite équipe. Amazon privilégie fortement les petites équipes, généralement composées de 10 à 12 personnes, chacune sachant clairement ce qu’elle doit accomplir.
Au fur et à mesure de la croissance de l’entreprise, le rôle du directeur technique évolue : au départ responsable de tous les aspects techniques, il se concentre progressivement sur la gestion des équipes et sur la capacité des ingénieurs à livrer les technologies et produits attendus.
Comparé au vice-président ingénierie, le CTO accorde davantage d’attention aux aspects techniques, tels que la construction de la bonne technologie et l’utilisation des bons outils.
Comment Amazon a-t-il grandi ?
Amazon a traversé plusieurs phases internes. Il a créé des équipes indépendantes, semblables à des startups, maîtrisant leurs propres objectifs et agendas d’innovation. Toutefois, par le passé, pour croître rapidement, Amazon a enfreint certains principes d’architecture, rendant l’infrastructure de base de données en arrière-plan fragile et incapable de croître davantage.
Pour résoudre ce problème d’inefficacité, l’entreprise a adopté une architecture orientée services, en divisant le système en blocs fonctionnels indépendants, autrement dit les microservices.
Mais avec l’augmentation des équipes, chaque service devant gérer sa propre base de données, les communications se sont multipliées tandis que l’innovation diminuait.
Pour améliorer la situation, Amazon a créé des plateformes de services partagés, utilisant la virtualisation et les API pour gérer les serveurs. Ces technologies ont d’abord été développées en interne, puis commercialisées sous forme de produits comme Amazon S3 et EC2. Ces services ont rendu le stockage et la puissance de calcul programmables et extensibles, offrant un excellent rapport coût-efficacité pour les entreprises.
L’objectif d’Amazon est d’offrir une capacité de stockage et de calcul à l’échelle d’Internet, accessible à toutes sortes d’entreprises.
La voie de l’innovation
L’innovation chez Amazon se décline en deux niveaux :
- D’abord, l’innovation au niveau des équipes : chaque équipe élabore son propre plan d’innovation pour l’année suivante et travaille de façon autonome, par exemple en améliorant le moteur de recommandation pour réduire les retours. Elle trace sa feuille de route, acquiert de nouvelles sources de données et interagit différemment avec les clients.
- L’autre niveau concerne les innovations nécessitant d’importants investissements en capital, comme Kindle ou Amazon Prime. Ces projets exigent de gros financements. Amazon a fixé une règle : un investissement massif n’est envisagé que si l’innovation a une chance de réussir et d’avoir un impact significatif sur le bilan de l’entreprise.
Amazon a pris conscience que certaines décisions prises au début du développement technologique étaient très judicieuses, et que, face à la croissance d’échelle, il fallait réexaminer l’architecture et développer des logiciels adaptés aux changements. Cela implique l’utilisation de multiples architectures et versions pour relever des défis techniques comme les moteurs de stockage.
Par ailleurs, comme d’autres entreprises, Amazon a constaté que, outre l’extension technologique, il fallait aussi résoudre des facteurs non techniques comme les ventes, l’architecture des solutions, les gestionnaires techniques clients et le support client. Tous ces éléments sont essentiels pour bâtir une entreprise performante.
Comment lancer un nouveau service ?
Nous voulons que toutes les équipes restent étroitement liées aux clients, car environ 95 % des fonctionnalités et services que nous proposons répondent directement à leurs besoins. Initialement, les premiers services que nous avons créés couvraient presque toutes les attentes des clients : infrastructure IT de base, stockage, calcul, base de données, réseau et sécurité.
Cependant, avec le temps, les clients ont exprimé d’autres besoins : analytique, cloud computing, développement mobile, et aujourd’hui la blockchain, entre autres. Ils souhaitent pouvoir utiliser ces technologies sans avoir à les gérer eux-mêmes. Aider les clients à construire les bonnes fonctionnalités et outils est donc devenu crucial.
Lorsque nous lançons un nouveau produit ou service, nous suivons une culture forte : commencer avec un ensemble minimal de fonctionnalités (MVP). Mais cela n’est qu’un point de départ pour construire la technologie nécessaire à l’activité. Nous ne pouvons pas simplement publier une version mince ; nous devons garantir sa stabilité et sa fiabilité. Ensuite, nous discutons avec les clients des autres fonctionnalités souhaitées.
Au stade initial, nous ne savons pas toujours exactement ce que veulent les clients. Par exemple, quand nous avons lancé DynamoDB, nous ignorions que les index secondaires seraient demandés. Nous ne les avons pas intégrés dès le départ, mais il est vite apparu que c’était ce que voulaient les clients. En démarrant avec un MVP, nous observons comment les clients utilisent le produit, puis itérons progressivement pour ajouter de nouvelles fonctionnalités et services.
Par exemple, quand nous avons lancé Lambda, un environnement sans serveur, le développement est devenu simple : il suffit d’écrire du code et de le déployer sur S3, sans se soucier des serveurs. Vous payez uniquement ce que vous utilisez, sans craindre les périodes d’inactivité.
Cette approche a transformé le processus de développement. Nous pouvons observer comment les clients utilisent le produit. Rapidement, ils ont commencé à itérer avec des environnements de débogage type rayons X, et à construire des applications plus complexes grâce à des fonctions en escalier. En observant leurs usages, nous comprenons leurs besoins : par exemple, avec DynamoDB, nous avons réalisé que les index secondaires comptaient plus pour les clients que les centres de données secondaires.
Finalement, les clients redéfinissent notre feuille de route. Nous commençons à offrir les fonctionnalités les plus importantes pour eux. C’est une partie cruciale. Même si cela ressemble à un MVP, nous ne pouvons pas le traiter comme tel, car les gens construisent leur activité dessus et en dépendent. Un autre type de culture émerge donc autour du produit.
L’an dernier, nous avons publié 1 400 nouvelles fonctionnalités et services. Avec l’augmentation du nombre d’équipes, ce chiffre continuera naturellement à croître. Chez AWS, nous utilisons la même structure : chaque équipe collabore avec un groupe de clients spécifique et construit sa feuille de route selon leurs besoins. Plus les services augmentent, plus les feuilles de route se multiplient.
Toutefois, c’est un environnement en évolution rapide, où les méthodes de développement logiciel ont radicalement changé. Si nous décidions comment les clients devraient développer leurs logiciels, nous en serions probablement encore aux méthodes d’il y a cinq ou dix ans. Au contraire, nous devons collaborer étroitement avec les clients, les laisser alimenter notre moteur d’innovation, et développer des logiciels selon les méthodes de 2020 ou 2025.
Nous ne pouvons donc pas décider à la place des clients, mais devons travailler étroitement avec eux, en les laissant guider notre innovation. Nous devons observer attentivement comment ils utilisent nos produits et itérer continuellement en fonction de leurs retours.
En résumé, Amazon Web Services (AWS) adopte une double approche de l’innovation : au niveau des équipes et via des investissements en capital. Grâce à une collaboration étroite avec les clients, en comprenant leurs besoins et en observant leurs usages, AWS parvient à offrir des fonctionnalités et services adaptés. Parallèlement, AWS investit massivement dans la R&D et le lancement de nouveaux produits, services et fonctionnalités pour répondre aux besoins changeants du marché.
Cette méthode d’innovation permet à AWS de maintenir un lien étroit avec ses clients, en garantissant des solutions stables, fiables et conformes à leurs attentes. Grâce à une stratégie de publication basée sur un ensemble minimal de fonctionnalités et à une itération continue, AWS répond rapidement aux besoins des clients et propose constamment de nouvelles fonctionnalités avancées.
La voie de l’innovation chez Amazon est un processus continu d’évolution, toujours centré sur le client. En comprenant profondément les besoins des clients, en observant leurs habitudes d’utilisation et en investissant continuellement dans la R&D, AWS pousse constamment les limites technologiques et commerciales, offrant des solutions exceptionnelles en matière de cloud computing.
Construire des produits centrés sur le client
Nous sommes omniprésents, que ce soit en partant des clients ou à l’interne chez Amazon. En tant qu’entreprise technologique, nous accordons une grande importance à développer des choses qui comptent vraiment pour les clients. Même si nous sommes une entreprise très technique, la conception et les ingénieurs prennent aussi des risques.
Notre priorité est le produit, pas seulement la technologie. Nous voulons savoir ce que nous pouvons faire pour les clients. Nous nous efforçons de construire des technologies impressionnantes, mais ce n’est pas notre seule motivation. Ce qui nous importe, c’est de résoudre les problèmes des clients.
Pour rester constamment centrés sur le client, nous utilisons un processus appelé « travail inversé ». D’abord, nous rédigeons un communiqué de presse décrivant clairement et succinctement ce que nous allons construire. Puis, nous préparons un document de 20 questions fréquentes, y répondant en langage simple. Dans les cas complexes, nous pouvons réviser plusieurs fois ces deux documents jusqu’à ce que nous soyons absolument clairs sur ce que nous construisons.
Ensuite, nous rédigeons un document d’expérience utilisateur (UX), détaillant comment les clients utiliseront notre produit et interagiront avec lui. Nous produisons aussi des manuels, glossaires et autres documents associés.
Finalement, nous disposons d’un ensemble de quatre documents précis décrivant exactement ce que nous allons faire.
Chez Amazon, nous respectons strictement ce principe : notre livraison ne dépasse jamais nos engagements. Nous n’ajoutons pas arbitrairement des fonctionnalités de la version 2 à la version 1. Nous nous concentrons uniquement sur la construction de ce que nous avons promis. Cette méthode offre une structure solide pour réfléchir aux besoins des clients, à l’expérience produit et aux aspects techniques.
Dans les réunions Amazon, nous n’utilisons ni diapositives ni présentations orales. Nous avons un document appelé « mémorandum de six pages », que chacun lit silencieusement 30 minutes avant la réunion. Ce mémorandum est crucial, car il assure que tout le monde a une compréhension claire du sujet discuté.
Rédiger une histoire est difficile, nous encourageons donc la collaboration et les retours. Nous révisons et améliorons plusieurs fois ce mémorandum jusqu’à ce que la fonctionnalité, le produit ou le domaine métier soit clairement décrit. Après 30 minutes de lecture, tout le monde est aligné, ce qui favorise des discussions de haute qualité.
En résumé, nous disposons d’une culture et de processus uniques garantissant que nous restons constamment concentrés sur la résolution des problèmes des clients et la fourniture de produits et services exceptionnels.
La technologie des conteneurs
De plus en plus d’entreprises sautent l’étape des conteneurs, notamment dans la poursuite d’un environnement plus microservices. L’un des motifs de popularité des conteneurs est leur capacité à monter et descendre en charge facilement, ce qui correspond bien à la philosophie des microservices. Beaucoup commencent à découper des conteneurs à partir d’une architecture monolithique, particulièrement dans le cadre du développement autour d’environnements sans serveur.
Toutefois, avant l’arrivée de Fargate, l’utilisation des conteneurs posait certains problèmes. Vous deviez gérer plusieurs conteneurs fonctionnant dans plusieurs zones de disponibilité, et les mapper sur des machines virtuelles. Ainsi, même si les conteneurs constituent un bon choix pour le développement, ils nécessitaient encore beaucoup de travail pour être exécutés et gérés. Pour simplifier cela, nous avons introduit Fargate, une solution qui supprime pratiquement toute gestion des machines virtuelles sous-jacentes : il suffit de placer le conteneur dedans pour qu’il fonctionne.
À l’avenir, je pense que de plus en plus d’outils, plateformes d’appui et infrastructures seront développés autour de la capacité à construire des environnements sans serveur plus complexes. Une meilleure intégration avec d’autres services deviendra une direction clé.
* Note de TechFlow : Fargate est un service de calcul fourni par Amazon Web Services (AWS), constituant un moteur de calcul sans serveur (serverless). Fargate permet aux développeurs de déployer et gérer plus facilement des applications conteneurisées sans se soucier de l’infrastructure sous-jacente ni des serveurs.
La technologie des conteneurs est une technologie de virtualisation qui consiste à empaqueter une application et ses dépendances dans des conteneurs indépendants et portables, permettant un déploiement rapide et une portabilité accrue. Elle utilise un moteur de conteneurs (comme Docker) pour créer, gérer et exécuter ces conteneurs, garantissant ainsi un fonctionnement cohérent de l’application dans différents environnements informatiques, indépendamment des différences d’infrastructure sous-jacente. La conteneurisation est largement utilisée dans le développement et le déploiement modernes d’applications, offrant une plus grande flexibilité, évolutivité et portabilité.
Protéger les clients
Je pense que la sécurité deviendra un sujet central. Dans les cinq prochaines années, chacun — PDG, CTO ou ingénieur — devrait faire de la sécurité sa priorité absolue. Nous devons tous être conscients de la sécurité et jouer le rôle d’ingénieurs sécurité. Pendant des années, des violations massives de données se sont produites chaque semaine. En tant qu’experts technologiques et leaders du commerce numérique, nous devrions en être embarrassés et indignés. Protéger les données des clients est notre responsabilité, car sans protection des clients, il n’y a pas d’affaires.
Nous devons commencer à réfléchir à la protection des données collectées auprès des clients, que ce soit pour la location de voiture ou d’autres services de consommation. La sécurité doit être intégrée par défaut, par exemple en déclenchant des vérifications de sécurité dans les pipelines d’intégration et de déploiement continus, en examinant et évaluant chaque ajout de bibliothèques open source.
Le pipeline de développement lui-même doit être sécurisé, équipé d’outils automatisés pour tester les vulnérabilités. Dans les secteurs médical et financier, il faut respecter diverses réglementations et exigences.
Dans cinq ans, j’espère que nous serons tous hautement sensibilisés à la sécurité et que protéger les clients sera notre priorité absolue. Chez Amazon, que ce soit en capital intellectuel ou financier, la protection des clients restera toujours notre domaine d’investissement principal.
Erreurs courantes des startups utilisant AWS
Premièrement, pour ceux ayant une expérience traditionnelle des centres de données, l’utilisation initiale d’AWS peut engendrer un manque de confiance. Bien qu’AWS offre des avantages en termes d’élasticité et de disponibilité, sans utiliser des services plus avancés (comme la sécurité, l’analyse de données ou le mobile), on ne peut pas exploiter pleinement son potentiel, surtout dans le développement à grande échelle et haute fiabilité.
Deuxièmement, il est essentiel de définir le type et les objectifs de l’entreprise. Il existe deux styles distincts : l’un vise une croissance rapide avec de nombreux clients, peu soucieux des revenus, investissant massivement pour s’étendre rapidement et potentiellement être racheté ; l’autre vise un développement durable, souhaitant construire une entreprise pérenne plutôt que de viser uniquement une acquisition.
Ces deux types d’entreprises utilisent AWS de façons très différentes. Pour celles en croissance rapide, elles peuvent utiliser plus librement la capacité et les services d’AWS, sans trop s’inquiéter des coûts. Pour celles axées sur la durabilité, elles doivent concevoir des architectures différentes, se concentrer davantage sur le contrôle des coûts, et s’assurer d’un lien clair entre les coûts et l’acquisition de clients.
Concernant les fondateurs de startups, Jeff Bezos les distingue souvent entre mercenaires et missionnaires. Les mercenaires cherchent l’argent, tandis que les missionnaires sont motivés par l’amour de leur produit. Les deux approches sont valides, mais le soutien technologique et l’architecture technique construite seront différents.
Bienvenue dans la communauté officielle TechFlow Groupe Telegram :https://t.me/TechFlowDaily Compte Twitter officiel :https://x.com/TechFlowPost Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
