La clave de un entorno backend está en entregar datos al usuario de forma estable. Para lograrlo, se necesitan obligatoriamente tres elementos clave: servidor web, WAS y base de datos. Estos tres han ido evolucionando para resolver los problemas que surgieron durante el desarrollo de la web. Tecnologías avanzadas como monitoreo, balanceo de carga, caché, pipelines de CI/CD y Kubernetes son, sin entender primero estos tres elementos, como construir una casa que podría venirse abajo en cualquier momento.
Primero, el papel del servidor web
La función principal del servidor web era actuar como un servidor de archivos que entrega archivos, y entre los servidores web más representativos están Nginx, Apache, IIS y Caddy. Estos servidores web están altamente optimizados y se enfocan en su función básica de servir archivos estáticos.
Segundo, la aparición y el papel del WAS (Web Application Server)
El WAS funciona de manera que, al recibir una solicitud específica, ejecuta un programa previamente definido y entrega al usuario el resultado generado por ese programa. Puede decirse que esta forma marcó el verdadero nacimiento del backend: fue el momento en que el servidor dejó de limitarse a mostrar archivos y comenzó a pensar, calcular y procesar lógica. El servidor web siempre devuelve la misma página estática, mientras que el WAS devuelve páginas dinámicas.
Tercero, la necesidad y el papel de la base de datos
La base de datos cumple la función de almacenar los datos de forma permanente, administrarlos de manera segura y controlar el acceso concurrente.
Además, entre los conocimientos muy útiles para la planeación de backend están el diseño de API RESTful (diseño de URL centrado en recursos, significado de HTTP como GET, POST, PUT, DELETE, uso de códigos de estado y otros principios de diseño de API basados en el estilo arquitectónico REST), la autenticación (comprensión básica de los métodos de autenticación y autorización de usuarios, como la autenticación basada en sesiones, así como la definición de políticas de gestión de usuarios) y el manejo de errores (conceptos sobre el tratamiento de casos de excepción, indispensable para asegurar la estabilidad del sistema).
8 comentarios
Hay gente que cree que el backend en el mundo solo usa protocolos web.
Dicen que son los 3 elementos clave del backend y sale un servidor web, así que marea.
Ya hay cosas como el ALB o el CDN que se encargan de todo lo que uno esperaría que hiciera el servidor web, así que no entiendo por qué insistir en eso. ¿Ustedes han tenido algún caso real, como de seguridad, que solo pudieron detener porque había un servidor web?
Si funcionalmente el ALB reemplaza al servidor web y los usuarios no pueden acceder directamente al backend, como el WAS, entonces se considera que cumple con la configuración del entorno de seguridad existente. Y además, muchos servicios todavía funcionan en entornos on-premise.
Desde el punto de vista de la seguridad, sigo pensando que todavía es necesario separar el servidor web y el servidor WAS. El hecho de estar en un entorno cloud-native no cambia eso. Los backends, como el WAS, no deberían estar en una capa a la que el usuario pueda conectarse directamente.
¿Sigue siendo útil conocer el concepto de servidor web / WAS?
En la época en que Java EE, php y CGI estaban de moda, sí era una distinción adecuada, pero hoy en día la mayoría de los lenguajes ya traen su propio servidor HTTP integrado, y con la aparición y normalización de conceptos como ALB, API Gateway, CDN y Object Storage, los tiempos han cambiado.
Más bien, sin ese contexto histórico, siento que el concepto de Web Server y WAS, que además es muy distinto de lo actual, ya no es un concepto apropiado y que solo terminará generando todavía más confusión para quienes están empezando.
En el sector fintech, debido a los requisitos de seguridad, todavía hay muchos entornos donde Web-WAS sigue estando separado. Como no sabes en qué tipo de entorno te va a tocar trabajar, creo que lo correcto es prepararse para todo jaja.
Incluso ahora, en un entorno de nube, se utiliza para balancear de forma eficiente múltiples WAS dentro de una sola instancia a fin de procesar grandes volúmenes.
Si hay pocas solicitudes de red, probablemente no sea necesario.
Estoy de acuerdo. Creo que sería más práctico enseñar los principios de la aplicación de 12 factores y los patrones cloud-native. El concepto en sí ya es demasiado antiguo.