Primero el servidor, después las funciones: arranca ProCat Solutions

Un único servidor en el que corre todo, sin copias de seguridad. La nueva versión sale a mano, por SSH, un viernes por la tarde. En los últimos años hemos visto de cerca varios proyectos que funcionaban así, hasta la primera carga seria o el primer incidente de seguridad. Esta es la primera entrada del blog de ProCat Solutions Kft. Somos una microempresa de Budapest, un equipo de pocas personas, y desarrollamos software, como otros cientos de empresas de la ciudad. La diferencia está en el orden: partimos de la infraestructura sobre la que el sistema va a correr en producción, y la lista de funcionalidades llega después.

Cuando faltan los cimientos

Aquellos proyectos arrancaron rápido y de forma vistosa. Los fallos se repetían:

• un único servidor en el que corre todo, sin copias de seguridad,
• claves de API en el código fuente, sin gestión de permisos,
• una base de datos que nadie indexó porque en la máquina del desarrollador iba rápida,
• despliegue a mano, por SSH, un viernes por la tarde.

Ninguno es un error exótico. Todos se derivan de construir un sistema que “funciona si pulso el botón”. Nadie lo diseñó para que siguiera funcionando con mil personas pulsando a la vez y un disco cayéndose a mitad.

Nosotros empezamos por el otro extremo. Primero aclaramos dónde va a correr el sistema, qué carga tiene que aguantar, qué pasa cuando algo falla, cómo sale la nueva versión y quién accede a los datos. Las funcionalidades se apoyan en eso. No significa sobredimensionar cada proyecto. Significa tomar las decisiones con antelación y de forma consciente, antes de que las circunstancias las impongan.

Cuatro principios

Los aplicamos en todos los proyectos.

Arquitectura lista para producción desde el primer día. El entorno de desarrollo corre en Docker igual que el de producción. La misma configuración de Nginx, las mismas variables de entorno, la misma versión de PostgreSQL. El “en mi máquina funciona” no llega a aparecer.

Estructura de API segura. Diseñamos todas las API como si fueran públicas: autenticación, gestión de permisos, validación de entrada, rate limiting. Se nota el día en que una API interna pasa, de repente, a estar expuesta a socios.

Alta disponibilidad. No todos los proyectos necesitan redundancia multizona. Todos necesitan copias de seguridad automáticas, health checks, reinicio en caso de fallo y un procedimiento de recuperación documentado.

Infraestructura gestionada por nosotros. Trabajamos sobre VPS y servidores dedicados, con Linux, Docker y Nginx. No tenemos nada contra los proveedores cloud; es una elección consciente. La mayoría de nuestros clientes necesita costes predecibles y control total. Una factura que escala en minutos pero que resulta difícil de seguir les sirve de menos.

Un stack estrecho

Nuestro stack es estrecho a propósito. En el backend, Node.js (NestJS y Express) y Laravel; como base de datos, PostgreSQL; como caché y cola de mensajes, Redis. Docker para la contenerización, Nginx como reverse proxy y Linux debajo. En frontend y móvil, React, Angular y React Native.

La moda no tuvo nada que ver. Conocemos desde hace años también los defectos de estas herramientas. Solo llevamos una tecnología a producción cuando sabemos cómo se comporta si escasea la memoria, qué hace si se corta la conexión con la base de datos y cómo se actualiza con seguridad.

También nos interesan las telecomunicaciones (SIP, VoIP, integración con la PSTN) y seguimos lo que ocurre en blockchain y en aprendizaje automático. Escribiremos sobre ello cuando haya experiencia real detrás.

Lo que se publicará aquí

Ni presentaciones de producto ni notas de prensa. Escribiremos sobre lo que aprendemos trabajando:

• decisiones de arquitectura concretas y sus consecuencias,
• errores que hemos cometido y que otros podrían ahorrarse,
• experiencia de operación: monitorización, copias de seguridad, pruebas de carga,
• territorios nuevos en los que entramos y en los que documentamos los primeros pasos.

Escribimos para desarrolladores que hacen un trabajo parecido y para responsables de decisión que quieren entender qué ocurre bajo el capó de su sistema. Si una solución no nos ha funcionado, también lo contaremos.

Próximas entregas

Los primeros temas serán el diseño de API REST de alta carga y las arquitecturas SaaS multi-tenant, porque es ahí donde ahora mismo se concentra nuestro trabajo. Quien quiera opinar, o esté con un problema parecido, puede escribirnos a hello@procats.hu.

La próxima entrada ya traerá código y configuración.