Funzioni serverless vs. microservizi: quale scegliere?

Una funzione serverless è una singola unità di deployment di logica di backend; un microservizio è un servizio intero gestito in autonomia. Quell’unica frase è tutto il confronto in miniatura: tutto il resto – carico di ops, curve di costo, cold start, stato – discende da che cosa sia l’unità di deployment, una funzione affidata a una piattaforma o un servizio da gestire in proprio.

Punti chiave

L’unità di deployment, in codice

Questo è l’intero deployabile di un’operazione di checkout: una funzione, nessun repository per servizio, nessuna immagine di container, nessuna 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’equivalente a microservizio di quello snippet è un repository intero: un server HTTP, una build di container, i manifest di deployment, il service discovery, gli health check, una dashboard e un turno di reperibilità – prima della prima riga di logica di checkout.

Funzioni serverless vs. microservizi su misura

La letteratura sui microservizi è esplicita: i benefici di quell’architettura si comprano con una seria maturità operativa – deployment automatizzato, monitoring sofisticato, progettazione orientata al guasto. Le funzioni esternalizzano esattamente quel conto alla piattaforma, ed è il motivo per cui l’analisi del serverless di Mike Roberts inquadra il FaaS come uno scambio di controllo in cambio di molte meno ops. Nessuno dei due scambi è gratuito; la domanda è quale imposta un team possa permettersi.

Che cosa succede davvero a una richiesta

Vale la pena notare che cosa aggiunge la metà inferiore e la metà superiore non riesce a esprimere: chiamate da servizio a servizio, archivi dati per ogni servizio e un gateway – la superficie di coordinamento in cui vive davvero la complessità dei microservizi. Transazioni distribuite, retry e guasti parziali tra il servizio carrello e il servizio ordini sono codice da scrivere; nel modello a funzioni lo stesso flusso di lavoro è di solito una funzione e un database, e i pezzi orientati agli eventi (trigger, job pianificati) si agganciano alla piattaforma invece che a code da gestire in proprio.

Quando le funzioni sostituiscono una flotta di microservizi – e quando non possono

L’osservazione onesta dietro il pattern BaaS: la maggior parte dei microservizi di un prodotto tipico è sottile. Validano un input, applicano una regola, leggono o scrivono un database e chiamano un vicino, e il guscio operativo attorno a quella logica è il 90 % del loro peso. Le funzioni cloud dentro un BaaS eliminano il guscio: database, autenticazione, archiviazione di file e API sono servizi della piattaforma, così ogni “servizio” si riduce a una manciata di funzioni e trigger. I team da una a dieci persone che rilasciano prodotti fatti di CRUD più logica hanno raramente bisogno di più.

Il soffitto è altrettanto onesto. Le funzioni non possono ospitare un modello di raccomandazione che richiede hardware specializzato, un transcodificatore video che gira per un’ora, un motore di fan-out WebSocket con tuning su misura, né un componente il cui throughput costante rende il prezzo a invocazione l’opzione cara. Quando un componente supera quelle linee, conviene estrarlo come servizio vero e lasciarlo interoperare con le funzioni: estrarre un hot spot dimostrato è una migrazione molto meno costosa che scomporre una flotta speculativa costruita troppo presto, la stessa lezione che l’argomento monolith-first insegna un livello più in alto.

Casi d’uso tipici

• Funzioni: backend di API e mobile. Logica a forma di richiesta su un database gestito: il caso dominante, e quello che le piattaforme BaaS impacchettano da un capo all’altro.
• Funzioni: trigger e collante. Validare al salvataggio, ridimensionare al caricamento, sincronizzare verso un’API di terze parti, far girare job notturni: reazioni brevi che farebbero vergognare un servizio dedicato.
• Funzioni: traffico a picchi o sconosciuto. Lanci, campagne, MVP: la discesa a zero assorbe sia il picco sia il silenzio.
• Microservizi: componenti pesanti e costanti. Ricerca, feed, motori di prezzo: carico regolare dove la capacità sempre attiva costa meno e si può regolare.
• Microservizi: runtime particolari. Linguaggi fuori standard, dipendenze native, GPU, processi di lunga durata.
• L’ibrido. Funzioni per la superficie di API e per gli eventi; uno o due servizi estratti per i componenti i cui numeri lo impongono.

Funzioni o microservizi? Matrice decisionale

Limiti e trade-off

• Funzioni: i limiti di esecuzione sono muri invalicabili. I lavori lunghi devono spostarsi su sistemi di job o su servizi: nessuna astuzia allunga un timeout con eleganza.
• Funzioni: cold start e catene. Rari per singola invocazione, ma le architetture in cui una funzione chiama una funzione li impilano; i percorsi caldi conviene tenerli poco profondi.
• Funzioni: l’accoppiamento alla piattaforma. Il runtime e le sue API appartengono alla piattaforma: una base open-source ospitabile in proprio è la copertura pratica contro il lock-in.
• Microservizi: il conto delle ops è per servizio. Pipeline, monitoring, contratti versionati e reperibilità si moltiplicano con la flotta; sottovalutarlo è la modalità di fallimento classica.
• Microservizi: i problemi dei sistemi distribuiti arrivano il primo giorno. Partizioni di rete, guasti parziali e coerenza tra servizi sono costanti architetturali, non casi limite.
• Entrambi: lo stato viene esternalizzato comunque. Le funzioni lo impongono; i servizi ben gestiti lo scelgono. In entrambi i progetti è il database, non il calcolo, a finire per detenere la verità.

Funzioni serverless e microservizi su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È il lato funzioni di questo confronto consegnato per intero: Cloud Code esegue funzioni con nome come il checkout qui sopra, più trigger di database e job pianificati, accanto a tutto ciò per cui esiste una flotta di microservizi – così la flotta che la maggior parte dei prodotti avrebbe costruito diventa funzioni sopra servizi gestiti. E poiché la base è open source e ospitabile in proprio, la via dell’estrazione resta aperta: quando un componente supera il modello a funzioni, può essere promosso a servizio dedicato senza abbandonare la piattaforma che lo circonda.