Quand choisir App Engine sur les fonctions cloud?
Désolé, s'il s'agit d'une question naïve, mais j'ai suivi de nombreuses conférences de la part du personnel de Google et je ne comprends toujours pas pourquoi j'utiliserais AE au lieu de CF?
Si j'ai bien compris, le concept de ces deux services consiste à construire une "architecture de microservice".
- cF et AE sont apatrides
- tous deux supposés exécuter pendant une période limitée
- les deux peuvent interagir avec dbs et d'autres apis gcp.
Cependant, AE doit être intégré à son propre serveur. Fondamentalement, il utilise beaucoup de complexités en plus des mêmes capacités que les FC. Alors, quand devrais-je l'utiliser au lieu de CF?
Les fonctions de cloud (CF) et Google App Engine (GAE) sont des outils différents pour des tâches différentes. Utiliser le bon outil pour le travail est généralement une bonne idée.
Enfoncer un clou avec une pince pourrait être possible, mais cela ne sera pas aussi pratique que d'utiliser un marteau. De même, la construction d'une application complexe à l'aide de CF pourrait être possible, mais la construire à l'aide de GAE serait certainement plus pratique.
Les CF présentent plusieurs inconvénients par rapport à GAE (dans le contexte de la construction d'applications plus complexes, bien sûr):
- ils sont limités à
Node.JS, Python et Go. GAE supporte plusieurs autres langages de programmation populaires - ils sont vraiment conçus pour des fonctionnalités légères, standalone , tenter de créer des applications complexes à l’aide de tels composants devient vite "maladroit". Oui, le contexte inter-relationnel de chaque demande individuelle doit également être restauré sur GAE, seul ce dernier bénéficiant de moyens plus pratiques de réaliser ce qui n'est pas disponible sur les FC. Par exemple, la gestion de session utilisateur, comme indiqué dans d'autres commentaires
- Les applications GAE ont un contexte d'application qui survit dans les demandes individuelles, les CF ne l'ont pas. Un tel contexte rend l’accès à certains services Google plus efficace/performant (ou même tout simplement possible) pour les applications GAE, mais pas pour les FC. Par exemple memcached.
- la disponibilité du contexte d'application pour les applications GAE peut prendre en charge des bibliothèques client plus efficaces/performantes pour d'autres services qui ne peuvent pas fonctionner sur des FC. Par exemple, accéder à la banque de données à l'aide de la bibliothèque client
ndb(disponible uniquement pour les env standard GAE python apps) peut être plus efficace/performant que d'utiliser la bibliothèque client de magasin de données générique. - GAE peut être plus rentable car son prix est "en gros" (basé sur le nombre d'heures d'instance, quel que soit le nombre de demandes traitées par une instance donnée) par rapport au prix "de détail" des FC (où chaque invocation est facturée séparément).
- les temps de réponse pourraient être généralement plus courts pour les applications GAE que pour les applications de fichier car, comme cela est généralement le cas avec l'instance d'application gérant la demande,
- le contexte de l'application GAE n'a pas besoin d'être chargé/restauré, il est déjà disponible, les FC doivent le charger/le restaurer
- le code de traitement est (la plupart du temps) déjà chargé, le code des CF doit encore être chargé. Pas sûr de celui-ci, mais je suppose que cela dépend de l'implémentation sous-jacente.
App Engine convient mieux aux applications, qui disposent de nombreuses fonctionnalités se comportant de différentes manières liées (voire non liées), tandis que les fonctions cloud sont plus spécifiquement des fonctions à usage unique qui répondent à certains événements et exécutent des actions spécifiques.
App Engine offre de nombreux choix de langue et davantage d'options de gestion, tandis que les fonctions cloud sont limitées dans ces domaines.
Vous pouvez facilement répliquer des fonctions de cloud sur App Engine, mais la réplication d'une application à grande échelle App Engine à l'aide d'un tas de fonctions discrètes pourrait être compliquée. Par exemple, le backend de Spotify est basé sur App Engine.
Une autre façon de le dire est que, pour une application de grande taille, commencer avec un système plus complexe comme App Engine peut conduire à une base de code moins complexe, ou du moins, plus facile à gérer ou à comprendre.
En fin de compte, ces deux systèmes fonctionnent sur une infrastructure sous-jacente similaire chez Google, et il vous appartient de choisir celle qui convient à la tâche à accomplir. De plus, rien ne vous empêche de mélanger des éléments des deux dans un même projet.