Fonctions serverless vs. microservices : lequel choisir ?

Une fonction serverless est une unité de déploiement unique de logique backend ; un microservice est un service complet exploité de façon indépendante. Cette seule phrase est toute la comparaison en miniature — tout le reste (charge d’ops, courbes de coût, cold starts, état) découle de ce qu’est l’unité de déploiement : une fonction que vous confiez à une plateforme, ou un service que vous exploitez vous-même.

Points clés

L’unité de déploiement, en code

Voici le déployable complet d’une opération de checkout — une fonction, pas de dépôt par service, pas d’image de conteneur, pas de pipeline :

// JavaScript / Node.js — the function is the whole deployable
// cloud/main.js — runs on the platform; there is no service to operate
Parse.Cloud.define('checkout', async (request) => {
  const cart = await new Parse.Query('Cart').get(request.params.cartId, {
    sessionToken: request.user.getSessionToken(),
  });
  // …price the cart, reserve stock, write the order…
  return { orderId: cart.id, status: 'confirmed' };
});

// Any client calls it by name — no gateway, container, or pipeline
const result = await Parse.Cloud.run('checkout', { cartId });

// Flutter / Dart — Back4app Flutter SDK
// Calling the function: one named endpoint, no service discovery
final checkout = ParseCloudFunction('checkout');
final response = await checkout.execute(
  parameters: {'cartId': cartId},
);
if (response.success) {
  print(response.result['status']); // confirmed
} else {
  print(response.error?.message);
}

// iOS / Swift — Back4app Swift SDK
// Calling the function: one named endpoint, no service discovery
struct Checkout: ParseCloudable {
    typealias ReturnType = [String: String]
    var functionName: String = "checkout"
    var cartId: String
}

let result = try await Checkout(cartId: cartId).runFunction()
print(result["status"] ?? "") // confirmed

// Android / Kotlin — Back4app Android SDK
// Calling the function: one named endpoint, no service discovery
val params = hashMapOf("cartId" to cartId)
ParseCloud.callFunctionInBackground<Map<String, String>>(
    "checkout", params
) { result, e ->
    if (e == null) {
        Log.i("Checkout", result["status"] ?: "")
    } else {
        Log.w("Checkout", "failed: ${e.code}")
    }
}

L’équivalent microservice de ce snippet est un dépôt entier : un serveur HTTP, un build de conteneur, des manifestes de déploiement, du service discovery, des health checks, un dashboard et une rotation d’astreinte — avant la première ligne de logique de checkout.

Fonctions serverless vs. microservices sur mesure

La littérature des microservices est explicite : les bénéfices de l’architecture s’achètent avec une sérieuse maturité opérationnelle — déploiement automatisé, monitoring sophistiqué, conception pour la panne. Les fonctions externalisent exactement cette facture à la plateforme, et c’est pourquoi l’analyse serverless de Mike Roberts présente le FaaS comme l’échange du contrôle contre radicalement moins d’ops. Aucun des deux échanges n’est gratuit ; la question est de savoir quel impôt votre équipe peut payer.

Ce qui arrive réellement à une requête

Remarquez ce que la moitié du bas ajoute et que celle du haut ne peut pas exprimer : des appels de service à service, des magasins de données par service et une gateway — la surface de coordination où vit réellement la complexité des microservices. Les transactions distribuées, les retries et les pannes partielles entre les services panier et commandes sont votre code ; dans le modèle fonction, le même workflow est généralement une fonction et une base de données, et les briques orientées événements (triggers, jobs planifiés) s’accrochent à la plateforme plutôt qu’à des files que vous exploitez.

Quand les fonctions remplacent une flotte de microservices — et quand elles ne peuvent pas

L’observation honnête derrière le pattern BaaS : la plupart des microservices d’un produit typique sont minces. Ils valident une entrée, appliquent une règle, lisent ou écrivent une base de données et appellent un voisin — la coquille opérationnelle autour de cette logique représente 90 % de leur poids. Les fonctions cloud dans un BaaS suppriment la coquille : la base de données, l’authentification, le stockage de fichiers et les API sont des services de la plateforme, si bien que chaque « service » se réduit à une poignée de fonctions et de triggers. Les équipes de une à dix personnes qui livrent des produits CRUD-plus-logique ont rarement besoin de plus.

Le plafond est tout aussi honnête. Les fonctions ne peuvent pas héberger un modèle de recommandation qui exige du matériel spécialisé, un transcodeur vidéo qui tourne une heure, un moteur de fan-out WebSocket au tuning sur mesure, ni un composant dont le débit soutenu fait du prix à l’invocation l’option coûteuse. Quand un composant franchit ces lignes, extrayez-le comme un vrai service et laissez-le interopérer avec les fonctions — extraire un hot spot avéré est une migration bien moins chère que décomposer une flotte spéculative construite trop tôt, la même leçon que l’argument monolith-first enseigne un niveau au-dessus.

Cas d’usage courants

• Fonctions : backends d’API et mobiles. De la logique en forme de requête sur une base de données gérée — le cas dominant, et celui que les plateformes BaaS empaquettent de bout en bout.
• Fonctions : triggers et glu. Valider à la sauvegarde, redimensionner à l’upload, synchroniser vers une API tierce, lancer des jobs nocturnes — des réactions brèves qui feraient honte à un service dédié.
• Fonctions : trafic en pics ou inconnu. Lancements, campagnes, MVP — la retombée à zéro absorbe le pic comme le silence.
• Microservices : composants lourds et soutenus. Recherche, feeds, moteurs de prix — une charge régulière où la capacité toujours active est moins chère et réglable.
• Microservices : runtimes particuliers. Langages hors standard, dépendances natives, GPU, processus de longue durée.
• L’hybride. Des fonctions pour la surface d’API et les événements ; un ou deux services extraits pour les composants dont les chiffres l’exigent.

Devriez-vous construire des fonctions ou des microservices ? Matrice de décision

Limites et trade-offs

• Fonctions : les limites d’exécution sont des murs infranchissables. Le travail long doit migrer vers des systèmes de jobs ou des services — aucune astuce n’étire un timeout avec élégance.
• Fonctions : cold starts et chaînes. Rares par invocation, mais les architectures de fonction-appelle-fonction les empilent ; gardez les chemins chauds peu profonds.
• Fonctions : le couplage à la plateforme. Le runtime et ses API appartiennent à la plateforme — une fondation open-source que vous pouvez auto-héberger est la couverture pratique contre le lock-in.
• Microservices : la facture d’ops est par service. Pipelines, monitoring, contrats versionnés et astreinte se multiplient avec la flotte ; la sous-estimer est le mode d’échec classique.
• Microservices : les problèmes de systèmes distribués arrivent dès le premier jour. Partitions réseau, pannes partielles et cohérence inter-services sont des constantes architecturales, pas des cas limites.
• Les deux : l’état est externalisé de toute façon. Les fonctions l’imposent ; les services bien exploités le choisissent. C’est la base de données, pas le calcul, qui finit par détenir la vérité dans les deux conceptions.

Fonctions serverless et microservices sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. C’est le côté fonctions de cette comparaison livré en entier : Cloud Code exécute des fonctions nommées comme le checkout ci-dessus, plus des triggers de base de données et des jobs planifiés, à côté de tout ce qu’une flotte de microservices existe pour fournir — si bien que la flotte que la plupart des produits auraient construite devient des fonctions sur des services gérés. Et parce que la fondation est open source et auto-hébergeable, le chemin d’extraction reste ouvert : quand un composant dépasse le modèle fonction, il peut être promu en service dédié sans abandonner la plateforme qui l’entoure.