--- term: 'PaaS vs. BaaS' seoTitle: '¿Qué es PaaS? Platform as a Service vs. BaaS Explicado' headline: '¿Qué es PaaS (Platform as a Service)?' slug: paas-vs-baas category: cloud-architecture shortDefinition: 'PaaS es un modelo de nube donde el proveedor opera la plataforma sobre la que despliegas tu código, pero tú sigues escribiendo y manteniendo la aplicación.' relatedTerms: - baas-vs-custom-backend - infrastructure-as-a-service - serverless-architecture - cloud-vendor-lock-in - baas-vs-serverless contrastsWith: - infrastructure-as-a-service aboutTerms: - 'Platform-as-a-Service (PaaS)' - 'Backend-as-a-Service (BaaS)' faq: - question: '¿Qué es PaaS en términos simples?' answer: 'PaaS significa alquilar la plataforma en lugar de las máquinas. El proveedor es dueño de los servidores, el sistema operativo, el runtime y las herramientas de deploy; tú haces push de tu código de aplicación y este se compila, ejecuta y mantiene en línea. Tú sigues escribiendo y manteniendo toda la aplicación — la plataforma solo elimina el trabajo de infraestructura debajo de ella.' - question: '¿Cuál es la diferencia entre IaaS, PaaS y SaaS?' answer: 'Son peldaños de una escalera de abstracción definida por quién gestiona qué. IaaS te alquila infraestructura cruda — máquinas virtuales, almacenamiento, redes — y todo lo que va del sistema operativo hacia arriba es tu trabajo. PaaS te alquila una plataforma gestionada: tú aportas solo código de aplicación y datos. SaaS es el peldaño más alto: una aplicación terminada que simplemente usas. Cada paso hacia arriba cambia control por velocidad.' - question: '¿Cuál es la diferencia entre PaaS y BaaS?' answer: 'PaaS te da un lugar para ejecutar el backend que todavía tienes que escribir; BaaS te da el backend mismo. En un PaaS escribes la aplicación de servidor — rutas, auth, cableado de base de datos — y la plataforma la hospeda. En un BaaS, las funcionalidades estándar como autenticación, CRUD de base de datos y almacenamiento de archivos vienen preconstruidas y se consumen desde SDKs de cliente, así que para los casos comunes no hay aplicación de servidor que escribir.' - question: '¿PaaS es lo mismo que serverless?' answer: 'No. Una aplicación PaaS típicamente corre de forma continua en instancias que configuras y pagas, y escala solo según lo configurado. El cómputo serverless se aprovisiona por evento: las funciones se levantan bajo demanda, facturan por invocación y tiempo de ejecución, escalan a cero cuando están ociosas y pueden pagar una penalización de cold start en la primera request. PaaS es hospedar una app siempre encendida; serverless es ejecutar código solo cuando algo sucede.' - question: '¿Kubernetes o Docker son un PaaS?' answer: 'No — son bloques de construcción open-source, no plataformas. Docker empaqueta aplicaciones en contenedores; Kubernetes orquesta contenedores entre máquinas. Un PaaS puede estar construido sobre ellos y esconder su complejidad detrás de un comando de deploy. Si tu equipo opera Kubernetes directamente, estás más cerca de IaaS con mejores herramientas que de PaaS.' - question: '¿Cuáles son las desventajas de PaaS?' answer: 'Las más citadas son el vendor lock-in (las apps escritas contra servicios específicos de la plataforma son costosas de mover), menos control sobre el runtime y el sistema operativo, precios que pueden escalar fuerte con carga sostenida, dependencia del uptime y las decisiones de producto del proveedor, y restricciones de cumplimiento cuando la regulación exige control de la infraestructura. Elegir plataformas basadas en estándares abiertos u open source suaviza la mayoría.' - question: '¿Cómo se cobra un PaaS?' answer: 'Típicamente por instancia en ejecución o por tier de recursos, facturado por mes o por hora — pagas por la capacidad que mantiene tu aplicación en línea, llegue tráfico o no. Eso hace el costo predecible pero nunca cero. Contrasta con el precio por invocación de serverless, que cae a cero en reposo, y con los planes de BaaS, que suelen empaquetar requests, almacenamiento y usuarios en un tier gratuito más tiers planos por encima.' - question: '¿Quién debería usar PaaS?' answer: 'Equipos que quieren escribir y poseer una aplicación de servidor custom sin operar infraestructura: equipos de producto lanzando APIs web, empresas estandarizando el deploy de muchos servicios y desarrolladores que necesitan control total de la lógica de backend pero nada de la gestión de servidores. Si tus necesidades de backend son mayormente estándar — usuarios, datos, almacenamiento — un BaaS elimina incluso el paso de escribir la aplicación y suele ser el camino más rápido.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'The NIST Definition of Cloud Computing (SP 800-145)' url: 'https://csrc.nist.gov/pubs/sp/800/145/final' - name: 'Platform as a service (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Platform_as_a_service' - name: 'The Twelve-Factor App methodology' url: 'https://12factor.net' - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' cta: title: 'Sáltate la plataforma — empieza desde un backend terminado' text: 'Back4app te da lo que un PaaS todavía te pide construir: base de datos, autenticación, almacenamiento de archivos y APIs vienen preaprovisionados, con funciones Cloud Code para tu lógica custom. Pasa de cero a un backend funcionando en minutos, gratis.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-27' translationKey: paas-vs-baas --- **PaaS es un modelo de nube donde el proveedor opera la plataforma sobre la que despliegas tu código, pero tú sigues escribiendo y manteniendo la aplicación.** En términos llanos: alquilas la plataforma, pero la app sigue siendo tuya. La [definición del NIST](https://csrc.nist.gov/pubs/sp/800/145/final) traza la línea con precisión — el proveedor controla servidores, sistemas operativos y runtimes; tú controlas la aplicación desplegada y sus datos. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | Qué es | Una plataforma gestionada que compila, ejecuta y escala el código que tú haces push | | Qué sigues haciendo tú | Escribir y mantener toda la aplicación de servidor | | Problema que resuelve | Aprovisionar servidores, parchear el SO, plomería de deploy | | Modelo de cobro | Por instancia o tier — la capacidad sigue encendida, llegue tráfico o no | | vs. BaaS | PaaS hospeda el backend que escribes; BaaS entrega el backend preconstruido | ## Cómo se ve usar un PaaS La experiencia PaaS por excelencia es desplegar con un comando y sin configurar infraestructura: ```bash # El flujo PaaS típico: push del código, la plataforma hace el resto $ git push platform main -----> Runtime detected: Node.js -----> Installing dependencies, building release -----> Launching web process (2 instances) https://my-api.example.app deployed ``` Lo que ese comando despliega, eso sí, sigue siendo una aplicación de servidor completa que tú escribiste — routing, validación, cableado de base de datos, manejo de auth: ```javascript // server.js — en un PaaS, todo esto sigue siendo tuyo de escribir y mantener const app = express(); app.get('/tasks', async (req, res) => { const user = await authenticate(req); // esto lo construiste tú const tasks = await db.query( // y esto 'SELECT * FROM tasks WHERE owner = $1 AND done = false', [user.id] ); res.json(tasks); // y esto }); app.listen(process.env.PORT); ``` Ese es el trato esencial de PaaS: la infraestructura desaparece, pero la aplicación de backend — y cada parche de seguridad, upgrade de dependencias y endpoint dentro de ella — sigue siendo tu base de código. ## La escalera de abstracción Cada modelo de servicio en la nube responde una pregunta: ¿cuánto alquilas y cuánto sigues operando tú? ```mermaid flowchart LR accTitle: La escalera de abstracción de la nube accDescr: Cinco pasos desde on-premises pasando por IaaS, PaaS y BaaS hasta SaaS, donde cada peldaño alquila más del stack — las máquinas, luego la plataforma, luego el backend, luego la aplicación terminada. A["On-premises
opera todo tú mismo"] --> B["IaaS
alquila las máquinas"] B --> C["PaaS
alquila la plataforma"] C --> D["BaaS
alquila el backend"] D --> E["SaaS
alquila la app terminada"] ``` El reparto de responsabilidades, capa por capa: | Capa | On-prem | IaaS | PaaS | BaaS | SaaS | | --- | --- | --- | --- | --- | --- | | Código de aplicación | Tú | Tú | Tú | Solo lógica custom | Proveedor | | Funcionalidades de backend (auth, CRUD, almacenamiento) | Tú | Tú | Tú | Proveedor | Proveedor | | Runtime y middleware | Tú | Tú | Proveedor | Proveedor | Proveedor | | Sistema operativo y parches | Tú | Tú | Proveedor | Proveedor | Proveedor | | Servidores, almacenamiento y red | Tú | Proveedor | Proveedor | Proveedor | Proveedor | Existen variantes especializadas de PaaS para trabajos más estrechos — plataformas de integración, móviles, de base de datos, de comunicaciones — pero todas están en el mismo peldaño: un lugar gestionado para ejecutar o conectar el software que construyes. ## PaaS vs. BaaS: la diferencia práctica BaaS es el peldaño siguiente, y la diferencia se ve en lo que *no* escribes. El endpoint de la lista de tareas de arriba — chequeo de auth, query, respuesta — se reemplaza en un BaaS por una llamada directa del SDK desde cualquier cliente, con el control de acceso aplicado por la plataforma: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK const query = new Parse.Query('Task'); query.equalTo('done', false); query.descending('createdAt'); const tasks = await query.find(); console.log(`${tasks.length} open tasks`); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final query = QueryBuilder(ParseObject('Task')) ..whereEqualTo('done', false) ..orderByDescending('createdAt'); final response = await query.query(); if (response.success) { print('${response.results?.length} open tasks'); } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK let query = Task.query("done" == false) .order([.descending("createdAt")]) query.find { result in switch result { case .success(let tasks): print("\(tasks.count) open tasks") case .failure(let error): print(error.localizedDescription) } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK val query = ParseQuery.getQuery("Task") query.whereEqualTo("done", false) query.orderByDescending("createdAt") query.findInBackground { tasks, e -> if (e == null) { Log.d("Tasks", "${tasks.size} open tasks") } } ``` | Dimensión | PaaS | BaaS | | --- | --- | --- | | Qué opera el proveedor | La plataforma bajo tu app | La plataforma *y* las funcionalidades de backend | | Qué escribes tú | Toda la aplicación de servidor | Solo lógica custom, como funciones | | Unidad de deploy | Una aplicación | A menudo nada — los clientes llaman SDKs | | Auth, base de datos, almacenamiento, APIs | Tu código, su infraestructura | Preconstruidos, expuestos vía SDKs | | Escalado | Configurado por instancia/tier | Automático detrás de APIs gestionadas | | Mejor para | Apps de servidor custom que quieres poseer | Backends estándar que preferirías no escribir | ## PaaS vs. serverless Los modelos son primos, no sinónimos. Una app PaaS corre de forma continua sobre capacidad que tú configuras; el cómputo serverless se materializa por evento, [factura por invocación y escala a cero](https://martinfowler.com/articles/serverless.html) — al precio de cold starts y límites de ejecución. En la práctica la línea se difumina: las plataformas modernas atornillan funciones serverless al hosting estilo PaaS, y una [arquitectura serverless](/glossary/es/arquitectura-serverless/) puede servir una API entera que un PaaS habría hospedado como una sola app. La decisión depende de la forma del tráfico: la carga constante favorece un proceso PaaS siempre encendido; la carga con picos o mucho reposo favorece el cómputo por invocación. ## Casos de uso comunes - **APIs y servicios web custom.** Un backend con lógica demasiado específica para funcionalidades preconstruidas — motores de precios, marketplaces, herramientas internas — desplegado sin poseer servidores. - **Estandarizar muchos deployments.** Los equipos que operan decenas de servicios adoptan un PaaS para que todos compilen, desplieguen, logueen y escalen igual. - **Migrar desde servidores autogestionados.** Las aplicaciones de servidor existentes (especialmente las [twelve-factor](https://12factor.net)) se mueven a un PaaS casi sin cambios — el mismo código, sin más parcheo de SO. - **Donde BaaS reemplaza a PaaS: backends de app estándar.** Si el backend es usuarios + datos + archivos + notificaciones, las funcionalidades preconstruidas eliminan la capa de aplicación que el PaaS hospedaría — el caso común en productos móviles y web. - **Híbrido: núcleo custom estilo PaaS, BaaS para el resto.** Algunos equipos mantienen un servicio custom en una plataforma mientras la gestión de usuarios, las APIs de datos y el almacenamiento vienen de un BaaS al lado. ## ¿Deberías elegir PaaS o BaaS? Matriz de decisión | Inclínate por PaaS cuando… | Inclínate por BaaS cuando… | | --- | --- | | El backend *es* tu producto — lógica custom por todas partes | El backend es plomería estándar alrededor de tu producto | | Ya tienes una base de código de servidor que hospedar | Empiezas de cero y quieres saltarte esa base de código | | Necesitas cualquier lenguaje, framework o protocolo | Tus targets son plataformas cubiertas por SDKs (web, móvil) | | Un equipo de backend posee la aplicación de servidor | El equipo es frontend/mobile-first | | El precio por instancia encaja con tráfico constante | Un tier gratuito y escalado gestionado encajan con un MVP o carga con picos | Si la mayoría de los requisitos son estándar pero unos pocos son custom, eso no es razón para elegir PaaS — un BaaS con un runtime de funciones embebido cubre ambos lados con menos código que poseer. ## Limitaciones y trade-offs - **Sigues poseyendo una aplicación.** Upgrades de framework, parches de seguridad en dependencias, bugs de auth — un PaaS hospeda tu backend; no lo mantiene. Este es el costo que BaaS elimina y PaaS no. - **Vendor lock-in.** Las apps escritas contra servicios y formatos de deploy específicos de la plataforma son costosas de mover. Mitigaciones: apégate a estándares abiertos, usa contenedores, prefiere plataformas construidas sobre open source — la misma cautela de [vendor lock-in](/glossary/cloud-vendor-lock-in/) aplica a lo largo de toda la escalera. - **Costo con carga sostenida.** La conveniencia gestionada lleva un margen; las cargas grandes y constantes acaban siendo más baratas en peldaños inferiores de la escalera — al precio de recontratar la carga de operaciones. - **Menos control.** Sin acceso al SO, tuning de red limitado y versiones de runtime al calendario del proveedor. Los regímenes de cumplimiento que exigen control de infraestructura pueden descartar el modelo. - **Dependencia del proveedor.** Las caídas, los cambios de precio y las deprecaciones llegan en el calendario del proveedor, no en el tuyo. Evalúa su historial como parte de la arquitectura. ## PaaS vs. BaaS 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. Eso lo coloca un peldaño por encima de PaaS: cada app arranca con el backend completo ya aprovisionado. El hueco de lógica custom que de otro modo te arrastraría de vuelta a un PaaS lo cubre **[Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions)** — funciones serverless, triggers y jobs agendados. Y como el stack es open source, la objeción del lock-in se invierte: el mismo backend puede auto-hospedarse en cualquier infraestructura, así que bajar la escalera más adelante sigue siendo posible sin reescritura.