--- term: 'Funciones Serverless vs. Microservicios' seoTitle: 'Funciones Serverless vs. Microservicios: Cómo Elegir' headline: 'Funciones Serverless vs. Microservicios: ¿cuál elegir?' slug: funciones-serverless-vs-microservicios category: backend-compute shortDefinition: 'Una función serverless es una unidad única de deploy de lógica de backend; un microservicio es un servicio completo operado de forma independiente.' relatedTerms: - cloud-code-serverless-functions - microservices-vs-monolith - serverless-architecture - event-driven-architecture contrastsWith: - microservices-vs-monolith aboutTerms: - 'Funciones Serverless' - 'Microservicios' faq: - question: '¿Una función serverless es un microservicio?' answer: 'No exactamente — la granularidad difiere en un orden de magnitud. Un microservicio es dueño de una capacidad de negocio: su propio proceso, su base de datos, su pipeline de deploy y su superficie de API. Una función es dueña de una operación. Un solo microservicio típicamente se descompone en varias funciones, y es la plataforma, no tu equipo, la que aporta el proceso, el escalado y el runtime alrededor de cada una.' - question: '¿Las funciones serverless pueden reemplazar a los microservicios?' answer: 'Para muchos productos, sí — sobre todo cuando los servicios harían poco más que envolver una base de datos con validación y un workflow ligero. Las funciones en un BaaS heredan la base de datos, la autenticación y las APIs, dejando solo la lógica de negocio genuina por escribir. Las excepciones son reales: trabajo de larga duración, runtimes personalizados, throughput pesado y sostenido y pisos estrictos de latencia siguen favoreciendo a un servicio operado por ti.' - question: '¿Qué sale más barato: funciones o microservicios?' answer: 'Con volumen bajo o con picos, las funciones — pagas por ejecución y el costo ocioso es cero, mientras que una flota de microservicios factura contenedores todo el día, más el tiempo de ingeniería para operarlos. Con volumen pesado y sostenido, las curvas se cruzan: la capacidad siempre activa se vuelve más barata por request. Incluye el salario de ops en la comparación; suele dominar la línea de infraestructura.' - question: '¿Los cold starts hacen a las funciones más lentas que los microservicios?' answer: 'Solo en la fracción de invocaciones que cae en una instancia ociosa — típicamente de milisegundos a alrededor de un segundo, frente a la latencia consistente de un servicio siempre warm. El tráfico constante mantiene warm las instancias de las funciones, y las funciones encadenadas son el caso a vigilar, porque cada salto puede sumar su propio cold start. Para presupuestos estrictos de latencia de cola, un servicio siempre activo todavía gana.' - question: '¿Cuándo ganan claramente los microservicios propios?' answer: 'Trabajo largo o stateful que supera los timeouts de las funciones, runtimes personalizados o dependencias de sistema que la plataforma no ofrece, hardware especializado, throughput alto y sostenido donde la capacidad siempre activa sale más barata, y equipos que necesitan control total de la red y de la topología de deploy. Si varios de esos puntos aplican a un componente, ese componente quiere ser un servicio.' - question: '¿Las funciones serverless pueden mantener estado?' answer: 'No entre invocaciones — cada llamada a una función parte de cero, y cualquier cosa que valga la pena guardar debe vivir en la base de datos o en un caché. Los microservicios pueden mantener estado en memoria, al precio de complicar el escalado y el failover. En la práctica, ambas arquitecturas convergen en la misma disciplina: externaliza el estado, trata el cómputo como desechable.' - question: '¿Se pueden combinar funciones y microservicios?' answer: 'Sí, y los sistemas maduros normalmente lo hacen. La división pragmática: las funciones se encargan de la lógica de API request/response, los triggers de base de datos, los jobs programados y el pegamento entre eventos; los servicios dedicados se encargan de los pocos componentes con carga pesada y constante o con necesidades especiales de runtime. Empezar con funciones y extraer un servicio cuando los números lo exijan es más barato que la migración inversa.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' - name: 'Microservices — Lewis & Fowler (martinfowler.com)' url: 'https://martinfowler.com/articles/microservices.html' - name: 'Microservices (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Microservices' - name: 'Back4app Cloud Code documentation' url: 'https://www.back4app.com/docs/get-started/cloud-functions' cta: title: 'La flota de funciones, sin la flota' text: 'Cloud Code en Back4app corre tus funciones junto a una base de datos gestionada, autenticación y APIs generadas automáticamente — las partes que una flota de microservicios existe para proveer, ya aprovisionadas. Escribe la lógica de negocio; sáltate la ingeniería de plataforma.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-27' translationKey: serverless-functions-vs-microservices --- **Una función serverless es una unidad única de deploy de lógica de backend; un microservicio es un servicio completo operado de forma independiente.** Esa sola frase es la comparación entera en miniatura — todo lo demás (carga de ops, curvas de costo, cold starts, estado) se desprende de cuál es la unidad de deploy: una función que le entregas a una plataforma, o un servicio que operas tú mismo. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | La diferencia central | Unidad de deploy: una operación (función) vs. una capacidad propia (servicio) | | Quién lo opera | Funciones: la plataforma. Microservicios: tu equipo, por servicio | | Costo ocioso | Las funciones escalan a cero; una flota de servicios factura todo el día | | El impuesto de las funciones | Cold starts, límites de tiempo de ejecución, ausencia de estado | | El impuesto de los servicios | Pipelines, orquestación, monitoreo, guardias — multiplicados por servicio | ## La unidad de deploy, en código Este es el deployable completo de una operación de checkout — una función, sin repositorio por servicio, sin imagen de contenedor, sin pipeline: **JavaScript:** ```javascript // 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 // 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); } ``` **Swift:** ```swift // 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 ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Calling the function: one named endpoint, no service discovery val params = hashMapOf("cartId" to cartId) ParseCloud.callFunctionInBackground>( "checkout", params ) { result, e -> if (e == null) { Log.i("Checkout", result["status"] ?: "") } else { Log.w("Checkout", "failed: ${e.code}") } } ``` El equivalente en microservicio de ese snippet es un repositorio: un servidor HTTP, un build de contenedor, manifiestos de deploy, service discovery, health checks, un dashboard y una rotación de guardias — antes de la primera línea de lógica de checkout. ## Funciones serverless vs. microservicios propios | Dimensión | Funciones serverless | Microservicios propios | | --- | --- | --- | | Unidad de deploy | Una función | Un servicio (proceso + API + datos) | | Infraestructura que operas | Ninguna — gestionada por la plataforma | Contenedores, orquestación y red por servicio | | Escalado | Automático, por invocación, hasta cero | Lo configuras tú; la capacidad corre incluso ociosa | | Estado | Stateless por contrato; el estado vive en la base de datos | Puede mantener estado en memoria (a un precio) | | Perfil de latencia | Las llamadas warm son rápidas; las instancias ociosas pagan un cold start | Consistente — el proceso siempre está arriba | | Runtime | Provisto por la plataforma (típicamente un runtime JavaScript gestionado) | Cualquier cosa que puedas contenedorizar | | Trabajo de larga duración | Cortado por los límites de tiempo de ejecución | Ilimitado | | Forma del equipo | Solo ingenieros de producto | Exige capacidad de plataforma/DevOps | | Curva de costo | Por ejecución; imbatible con picos, se cruza con carga sostenida | Plana; eficiente con volumen alto y constante | La [literatura de microservicios](https://martinfowler.com/articles/microservices.html) es explícita: los beneficios de la arquitectura se compran con una madurez operativa seria — deploy automatizado, monitoreo sofisticado, diseño para el fallo. Las funciones tercerizan exactamente esa cuenta a la plataforma, y por eso el [análisis de serverless de Mike Roberts](https://martinfowler.com/articles/serverless.html) encuadra el FaaS como cambiar control por radicalmente menos ops. Ninguno de los dos intercambios es gratis; la pregunta es qué impuesto puede pagar tu equipo. ## Qué le pasa realmente a una request ```mermaid flowchart TB accTitle: Camino de una request por una función serverless versus una flota de microservicios propios accDescr: En el modelo de funciones, un cliente llama a un endpoint gestionado y la plataforma corre la función contra la base de datos gestionada, escalando instancias automáticamente. En el modelo de microservicios, el cliente pasa por un API gateway hasta uno de varios servicios operados por el equipo, cada uno con su propio deploy de contenedor y su propio almacén de datos. subgraph F ["Modelo de funciones — operado por la plataforma"] C1["Cliente"] --> E["Endpoint gestionado"] E --> FN["checkout()"] FN --> DB[("Base de datos gestionada")] end subgraph M ["Modelo de microservicios — operado por el equipo"] C2["Cliente"] --> G["API gateway"] G --> S1["Servicio de carrito"] G --> S2["Servicio de pedidos"] S1 --> D1[("BD del carrito")] S2 --> D2[("BD de pedidos")] S1 <--> S2 end ``` Fíjate en lo que la mitad de abajo agrega y la de arriba no puede expresar: llamadas de servicio a servicio, almacenes de datos por servicio y un gateway — la superficie de coordinación donde realmente vive la complejidad de los microservicios. Las transacciones distribuidas, los reintentos y los fallos parciales entre los servicios de carrito y de pedidos son código tuyo; en el modelo de funciones, el mismo workflow suele ser una función y una base de datos, y las piezas [orientadas a eventos](/glossary/event-driven-architecture/) (triggers, jobs programados) cuelgan de la plataforma y no de colas que tú operas. ## Cuándo las funciones reemplazan una flota de microservicios — y cuándo no pueden La observación honesta detrás del patrón BaaS: la mayoría de los microservicios de un producto típico son delgados. Validan entrada, aplican una regla, leen o escriben una base de datos y llaman a un vecino — el caparazón operativo alrededor de esa lógica es el 90% de su peso. Las [funciones en la nube](/glossary/es/cloud-code-funciones-serverless/) dentro de un BaaS borran el caparazón: la base de datos, la autenticación, el almacenamiento de archivos y las APIs son servicios de la plataforma, así que cada "servicio" colapsa en un puñado de funciones y triggers. Los equipos de una a diez personas que entregan productos de CRUD-más-lógica rara vez necesitan más. El techo es igual de honesto. Las funciones no pueden hospedar un modelo de recomendaciones que necesita hardware especializado, un transcodificador de video que corre una hora, un motor de fan-out de WebSocket con tuning a medida, ni un componente cuyo throughput sostenido convierte el precio por invocación en la opción cara. Cuando un componente cruza esas líneas, extráelo como un servicio de verdad y deja que interopere con las funciones — extraer un hot spot comprobado es una migración mucho más barata que descomponer una flota especulativa construida demasiado pronto, la misma lección que el [argumento monolith-first](/glossary/microservices-vs-monolith/) enseña un nivel más arriba. ## Casos de uso comunes - **Funciones: backends de API y mobile.** Lógica con forma de request sobre una base de datos gestionada — el caso dominante, y el que las plataformas BaaS empaquetan de punta a punta. - **Funciones: triggers y pegamento.** Validar al guardar, redimensionar al subir, sincronizar con una API de terceros, correr jobs nocturnos — reacciones cortas que harían pasar vergüenza a un servicio dedicado. - **Funciones: tráfico con picos o desconocido.** Lanzamientos, campañas, MVPs — escalar a cero absorbe tanto el pico como el silencio. - **Microservicios: componentes pesados y sostenidos.** Búsqueda, feeds, motores de precios — carga estable donde la capacidad siempre activa es más barata y ajustable. - **Microservicios: runtimes especiales.** Lenguajes fuera del estándar, dependencias nativas, GPUs, procesos de larga duración. - **El híbrido.** Funciones para la superficie de API y los eventos; uno o dos servicios extraídos para los componentes cuyos números lo exigen. ## ¿Deberías construir funciones o microservicios? Matriz de decisión | Tu situación | Inclínate por | | --- | --- | | Equipo pequeño, la lógica del producto es sobre todo CRUD + reglas | Funciones en un BaaS — la flota agrega costo, no capacidad | | El tráfico tiene picos, es bajo o impredecible | Funciones — escalar a cero es el argumento completo | | Un componente corre de minutos a horas por job | Microservicio (o un sistema de background jobs) — los timeouts descartan las funciones | | Throughput alto y sostenido en una ruta caliente | Microservicio — la capacidad de tarifa plana gana la curva de costo | | Presupuesto estricto de latencia de cola en cada request | Microservicio — sin varianza de cold start | | Runtime personalizado, dependencias nativas, hardware especial | Microservicio — las plataformas corren lo que corren | | No tienes capacidad de ops dedicada | Funciones — el impuesto de la flota llega, lo hayas presupuestado o no | | Un hot spot dentro de un producto con forma de funciones | Híbrido — extrae ese único servicio, mantén el resto como funciones | ## Limitaciones y trade-offs - **Funciones: los límites de ejecución son paredes duras.** El trabajo largo debe mudarse a sistemas de jobs o a servicios — ninguna astucia estira un timeout con elegancia. - **Funciones: cold starts y cadenas.** Raros por invocación, pero las arquitecturas de función-llama-función los apilan; mantén las rutas calientes poco profundas. - **Funciones: acoplamiento a la plataforma.** El runtime y sus APIs son de la plataforma — una base open-source que puedes auto-hospedar es la cobertura práctica contra el lock-in. - **Microservicios: la cuenta de ops es por servicio.** Pipelines, monitoreo, contratos versionados y guardias se multiplican con la flota; subestimarlo es el modo clásico de fallar. - **Microservicios: los problemas de sistemas distribuidos llegan el primer día.** Las particiones de red, los fallos parciales y la consistencia entre servicios son constantes arquitectónicas, no casos borde. - **Ambos: el estado se externaliza de todos modos.** Las funciones lo obligan; los servicios bien operados lo eligen. Es la base de datos, no el cómputo, la que termina guardando la verdad en ambos diseños. ## Funciones serverless y microservicios en Back4app Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es el lado de las funciones de esta comparación entregado completo: [Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions) corre funciones con nombre como la `checkout` de arriba, más triggers de base de datos y jobs programados, junto a todo lo que una flota de microservicios existe para proveer — así la flota que la mayoría de los productos habría construido se convierte en funciones sobre servicios gestionados. Y como la base es open source y auto-hospedable, la ruta de extracción sigue abierta: cuando un componente supera el modelo de funciones, puede graduarse como servicio dedicado sin abandonar la plataforma que lo rodea.