Server y Serverless
Nuestras aplicaciones eventualmente necesitan correr en algún lado. Ese "algún lado" típicamente se reduce a dos opciones: servidores tradicionales (donde vos sos el dueño de la casa) o ambientes serverless (donde sos un nómada de la nube). Ambos enfoques mantienen tu código corriendo en la nube, pero uno te da las llaves de la sala de servidores mientras que el otro te da una factura tipo Uber. Vamos a analizar estas opciones.
Server
Aunque serverless se lleva toda la atención, las arquitecturas basadas en servidores tradicionales todavía alimentan los sistemas empresariales. Esto es lo que necesitás saber:
- Vos sos el dueño de la caja: física (hardware on-premise) o virtual (VMs en la nube como AWS EC2 o Google Compute Engine), tenés control total sobre:
- Parches de SO y actualizaciones de seguridad.
- Estrategias de escalado (vertical/horizontal).
- Asignación de recursos (CPU, RAM, almacenamiento).
- Costos predecibles: Facturas mensuales fijas sin importar los picos de tráfico.
Serverless
El término "Serverless" es un poco engañoso. Todavía hay servidores involucrados, pero nunca los ves ni los administrás.
- En lugar de preocuparte por hardware, actualizaciones de software, o escalado, los desarrolladores se enfocan puramente en escribir código.
- Los proveedores de nube (como AWS, Google Cloud, o Microsoft Azure) se encargan del trabajo pesado: levantando servidores cuando se necesitan, parchando agujeros de seguridad, balanceando tráfico, e incluso haciendo backup de datos automáticamente.
El Sueño Serverless Puede Convertirse Rápidamente en una Pesadilla
La computación serverless promete escalabilidad sin paralelo, pero esa flexibilidad a menudo viene con una estructura de costos impredecible.
Un ejemplo impactante de esto salió a la luz cuando cara.app, un pequeño proyecto indie, se volvió viral. Construido usando serverless functions, la repentina popularidad de la app llevó a una factura de nube asombrosa de $96,000 para su creador.
Este no es un incidente aislado. Los precios serverless están fuertemente basados en el uso, y aunque eso puede parecer rentable al principio, un pico en la demanda puede enviar tus costos rápidamente a la estratosfera.
Conclusión: No es Uno u Otro
| Criterio | Server | Serverless |
|---|---|---|
| Estructura de Costo | Predecible (fijo/mes) | Variable (pago por ejecución) |
| Escalado | Setup manual/auto-scaling | Automático (pero picos caros) |
| Mantenimiento | Alto (vos administrás todo) | Cero (responsabilidad del proveedor de nube) |
| Control | Control total sobre el ambiente | Limitado a runtime/config |
| Cold Starts | Ninguno (siempre corriendo) | Hay latencia |
| Ideal Para | Cargas de trabajo estables, apps stateful | Event-driven, tráfico en ráfagas |
La mayoría de los equipos a los que te sumes ya tomaron esta decisión años antes de tu llegada. Pero acá va por qué esto te importa a vos:
- Discusiones de arquitectura: Entendé los tradeoffs cuando los colegas debaten migrar a Lambda.
- Contexto de debugging: Los problemas en serverless (cold starts/timeouts) son diferentes de los de servidores (thread pool).
- Movimientos de carrera: Las certificaciones de nube esperan este conocimiento.
- Potencial de promoción: Roles como Tech leads necesitan asesorar sobre elecciones de infraestructura.
Ya sea que estés manteniendo un servidor viejo o construyendo microservicios serverless, la mejor arquitectura es la que tu equipo puede operar.