Linux-Services con Delphi en producción

Los servicios en segundo plano son, en muchas aplicaciones empresariales, la palanca silenciosa de productividad: importaciones y exportaciones de datos, procesamiento de ficheros y EDI, sincronización con ERP/DMS/CRM, flujos de trabajo programados, notificaciones o la exposición de interfaces técnicas. En la práctica no basta la función de negocio pura; la cuestión decisiva es: ¿se puede operar el servicio de forma fiable, actualizarlo, supervisarlo y restaurarlo controladamente en caso de fallo?

Precisamente aquí merece la pena una mirada sobria a Linux-Services con Delphi. Delphi ya sostiene la lógica de negocio en muchas organizaciones. Si esa lógica puede reutilizarse razonablemente en el servidor, se obtiene una arquitectura global coherente: las reglas de negocio no se implementan por duplicado, las interfaces permanecen estables y los equipos trabajan con un conjunto de herramientas ya establecido. Al mismo tiempo, Linux aporta en el entorno servidor componentes probados para operación, automatización y seguridad.

El punto decisivo: un servicio Linux no es un “pequeño utilitario” que se arranca de paso. Es una parte del producto con responsabilidad operativa. Este artículo muestra de forma concreta cómo desplegar servicios Delphi basados en Linux de forma robusta en producción: desde el modelo de procesos y estados, integración con systemd, logging, despliegue y actualizaciones, hasta monitorización, acceso a datos, seguridad y patrones de fallo típicos. El objetivo es una configuración que funcione en el día a día —incluida la madrugada a las 3:00.

Cuándo tiene sentido Delphi-Services sobre Linux

Un servicio Delphi-Linux es recomendable siempre que se cumpla uno o varios de los siguientes patrones:

• Se desea reutilizar lógica de negocio existente en Delphi en el servidor (p. ej. validaciones, cálculos, motores de reglas, parser de import/export).
• El procesamiento en segundo plano es parte integral de la aplicación (p. ej. pipelines de PDF/reporting, colas de jobs, procesamiento por lotes).
• Aumenta la carga de integración: muchos sistemas, muchas interfaces, muchos formatos; la repetibilidad fiable (idempotencia) se vuelve importante.
• Modernización sin empezar de cero: partes de la lógica se externalizan a servicios, mientras el cliente de escritorio se simplifica gradualmente.
• REST-Server y servicios se diseñan de forma conjunta: mismo estándar de código, mismo logging/monitoring, mismos procesos de despliegue.

No es adecuado un servicio Delphi-Linux si un equipo no tiene ninguna competencia en Delphi y, además, la organización impone estrictamente una plataforma estandarizada (p. ej. un ecosistema Java/.NET existente). En ese caso el problema no es Delphi sino la integración organizativa. En muchas empresas, sin embargo, Delphi es un activo existente que puede reutilizarse de forma estable en la capa de servicios —siempre que arquitectura y operación se planifiquen correctamente.

Fundamentos de arquitectura: modelo de proceso, estados, responsabilidades

Un servicio productivo rara vez fracasa por su “función principal”. Con mayor frecuencia falla por estados poco claros: ¿qué ocurre ante una caída de red? ¿cómo se comporta el servicio ante un failover de base de datos? ¿se procesa un job dos veces? ¿está definido el comportamiento ante SIGTERM? Por eso cada servicio necesita un modelo claro de procesos y estados.

Tipos de servicio: Always-on vs. Worker vs. Job-Runner

En entornos B2B se han establecido tres tipos básicos:

• Daemon Always-on: proceso en ejecución continua, p. ej. listener, consumidor de colas, despachador de eventos, componente websocket/push.
• Worker-Pool: varias instancias que procesan jobs en paralelo desde una cola. La escalabilidad se consigue mediante el número de procesos.
• Job-Runner (Timer): arranca periódicamente, realiza tareas y finaliza. En Linux suele ser mejor usar timers de systemd/cron que hilos de scheduler propios.

Delphi puede implementar los tres patrones. Para la operación es crítico que el patrón se elija deliberadamente. Un proceso “Always-on” que solo hace algo cada 15 minutos añade complejidad innecesaria (fugas de memoria aparecen más tarde, los estados inactivos no se manejan correctamente). Por el contrario, un Job-Runner puro puede ser inadecuado cuando se exige baja latencia.

Idempotencia y reejecución: el núcleo de la robustez en producción

Operar en producción significa: los servicios se reinician, los despliegues se ejecutan, las redes son temporalmente inestables, las bases de datos tienen ventanas de mantenimiento y los jobs llegan duplicados. Por eso la idempotencia (ejecuciones múltiples sin efectos secundarios adicionales) en importaciones, exportaciones e integraciones es un principio rector.

En la práctica eso implica:

• Cada job tiene una ID de job única y un estado (queued, running, succeeded, failed, dead-letter).
• Los efectos secundarios (p. ej. “factura enviada”) se guardan con una prueba dedicada, no se infieren implícitamente de los logs.
• Las estrategias de reintento están controladas: backoff, intentos máximos, criterios claros de abortar, cola de dead-letter.

Quien aplica idempotencia de forma disciplinada gana mucho en operación: un reinicio deja de ser una crisis y pasa a ser un caso estándar.

systemd como fundamento operativo: Start, Stop, Restart, límites

En Linux systemd es en la mayoría de distribuciones la herramienta central para gestionar servicios en producción. Para servicios Delphi systemd no es “solo” un script de arranque, sino parte de la arquitectura de estabilidad. Un Unit-File bien definido suele ser la diferencia entre “funciona de alguna manera” y “se puede operar profesionalmente”.

Parámetros importantes en el Unit-File

Para daemons típicos Delphi son relevantes los siguientes aspectos:

• Restart-Policy: p. ej. Restart=on-failure o always, combinado con RestartSec para evitar bucles de crash.
• TimeoutStopSec y KillSignal: permiten un apagado ordenado (vaciar colas, cerrar transacciones DB correctamente).
• User/Group: los servicios rara vez deberían ejecutarse como root; principio de menor privilegio.
• WorkingDirectory y Environment: rutas y entornos reproducibles en lugar de suposiciones implícitas.
• LimitNOFILE y límites de recursos: importantes con muchas conexiones/archivos simultáneos.
• Integración de logging: StandardOutput/StandardError a journald, y opcionalmente reenvío a sistemas centralizados de logs.

Las políticas de reinicio deben elegirse con cuidado. Un proceso que falla por un error de configuración no debería reiniciarse en bucle infinito y saturar el sistema. En esos casos son útiles los códigos de salida y una estrategia de “fail fast” con mensaje de error claro.

Graceful Shutdown en Delphi: SIGTERM no es un detalle

En operación sobre Linux un servicio suele terminarse con SIGTERM. Un servicio Delphi debe tratar ese caso como un estado normal: no cortes abruptos, sino cierre ordenado.

En la práctica esto incluye:

• Marcar una flag de parada, no aceptar nuevos jobs.
• Finalizar jobs en curso o abortarlos de forma controlada (según la semántica).
• Commit/rollback de transacciones, cierre de conexiones.
• Persistir información de estado importante (p. ej. “Job X abortado, reintento posible”).

Un servicio que “muere” de forma brusca ante SIGTERM genera inconsistencias y complica cualquier mantenimiento.

Configuración: reproducible, versionable, segura

Muchos problemas en producción son, en el fondo, problemas de configuración: host DB equivocado, credenciales incorrectas, rutas faltantes, timeouts divergentes entre entornos. Por eso la configuración no es “solo un fichero INI”, sino un concepto.

Fuentes de configuración y prioridades

Se recomienda un modelo en capas:

• Configuración por defecto en el código (baseline segura, timeouts razonables).
• Configuración en fichero (p. ej. INI/JSON/YAML) desplegable y versionable.
• Variables de entorno para secrets y especificidades del entorno (cercanas a contenedores/CI; no poner secrets en el repo).

Importante es una prioridad clara (p. ej. Env sobrescribe fichero sobrescribe Default) y una verificación al inicio que valide la configuración: campos obligatorios, alcanzabilidad, permisos de fichero, rangos mínimos.

Secrets: no en texto plano, no en logs

En entornos B2B, passwords de BD, tokens API, certificados y claves privadas son activos operativos críticos. Estándares mínimos:

• No almacenar secrets en Git ni en ficheros de configuración desplegados en texto claro siempre que sea posible.
• Permisos de lectura de config/secrets reservados al usuario del servicio.
• Las salidas de logs deben enmascarar secrets de forma consistente (también en excepciones).

Tanto si se usa un sistema de vault como despliegues clásicos con permisos restrictivos: lo relevante es un manejo sistemático de secrets.

Logging: del “texto de error” a la capacidad de diagnóstico operacional

Un servicio Linux productivo solo es tan bueno como su capacidad de diagnóstico. “Hubo un error” no ayuda. Ante una incidencia, operación y desarrollo deben poder reconstruir: ¿cuál fue la entrada? ¿qué versión estaba en ejecución? ¿en qué paso falló? ¿fue un error transitorio o un problema de datos?

Logging estructurado y IDs de correlación

Para servicios con interfaces (REST, MQ, importaciones de ficheros) son centrales dos aspectos:

• Logging estructurado (key-value, similar a JSON): service, version, env, job_id, customer_id (si está permitido), duration_ms, result.
• ID de correlación: una ID que se propaga entre componentes (p. ej. desde la petición REST al job del worker).

Con esto no solo se encuentran errores de producción, sino que se acotan: ¿afecta a todos los clientes? ¿solo a una fuente de datos? ¿solo a una versión? ¿solo a una instancia?

Niveles de log, ruido y señales operativas

Un anti-patrón frecuente es el exceso de logs sin señal: megabytes de “Processing…” en cada poll. En su lugar:

• INFO: cambios de estado relevantes (Start, Stop, configuración cargada, Job iniciado/finalizado).
• WARNING: desviaciones esperables (Retry, error de red transitorio, timeouts).
• ERROR: no esperado, requiere acción manual.
• DEBUG: activable de forma selectiva y temporal.

En entornos systemd/journald conviene planificar rotación y retención de logs. Sin política de retención, los logs o se almacenan por poco tiempo (sin diagnóstico) o consumen espacio (problema operativo).

Monitorización y health: no solo “está en ejecución”, sino “cumple”

Un proceso puede estar en ejecución y, sin embargo, estar muerto en términos funcionales (bloqueado por un deadlock, esperando IO o sin procesar jobs). La madurez productiva exige: la monitorización verifica no solo el estado del proceso, sino la salud del servicio.

Health Checks: Liveness, Readiness, Business-Checks

Para servicios Delphi son útiles tres niveles:

• Liveness: el proceso vive (estado systemd, watchdog, endpoint de ping simple).
• Readiness: el servicio está listo (conexión a BD posible, configuración válida, sistemas dependientes accesibles).
• Business-Check: ¿el servicio está realmente procesando? p. ej. “último job exitoso < 10 minutos” o “longitud de cola < umbral”.

La capa de negocio suele ser la más importante en operación B2B, porque mide la creación real de valor.

Métricas: tiempos, tasas de error, backlog

Cuando los servicios crecen, los logs ya no bastan. Las métricas permiten ver tendencias:

• Throughput (jobs/min), duración media de job, tiempos p95/p99.
• Tasa de reintentos, tasa de errores por clase (red, datos, autenticación).
• Backlog de colas, tiempos de espera, contador de dead-letter.

Incluso sin un stack complejo de observabilidad se puede avanzar mucho con exportadores simples (p. ej. un endpoint HTTP interno o parsing basado en logs). Lo importante es definir de forma consistente las métricas y los umbrales.

Acceso a datos y transacciones: FireDAC, manejo de conexiones, pooling

Muchos servicios Delphi están centrados en bases de datos. En Linux el acceso con Delphi suele organizarse mediante la BDE-Ablösung con binding nativo y bibliotecas cliente nativas. Para la madurez productiva importan menos los “drivers correctos” que el modelo de conexión y transacción.

Ciclo de vida de la conexión: efímera vs. persistente

Para jobs en segundo plano una práctica probada es:

• Abrir una conexión por job o por lote de jobs, trabajar y cerrar (robusto ante fallos de red).
• En jobs de alta frecuencia, usar pooling de conexiones, pero solo con un reset limpio entre jobs.

Las conexiones largas pueden funcionar, pero tienden a entrar en estados difíciles de diagnosticar ante interrupciones de red o failovers de BD. Las conexiones efímeras suelen ser la estrategia por defecto más robusta, con timeouts y reintentos adecuados.

Límites de transacción y comportamiento de bloqueo

Los problemas en producción suelen surgir por transacciones demasiado grandes: locks prolongados, tablas bloqueadas, “todo se queda colgado”. Mejor:

• Alinear transacciones con unidades de negocio (p. ej. “un registro de importación” o “un documento”).
• Persistir resultados intermedios para permitir reejecuciones.
• Clasificar errores limpiamente: error de datos (no reintentar), error de red (reintentar), efecto secundario ya aplicado (manejar idempotencia).

En entornos con workers paralelos, el comportamiento de locks y deadlocks es un factor de diseño —no solo un asunto de DBAs.

Despliegue y actualizaciones: reproducible, reversible, con riesgo mínimo

Un servicio nunca está “terminado”; se actualiza. Por eso el despliegue no es trabajo final, sino parte de la solución. En producción importan tres cualidades: reproducibilidad, capacidad de rollback y baja ventana de indisponibilidad.

Versionado y artefactos

Es recomendable:

• Cada build lleve una versión única (SemVer o Build-ID) y la registre en logs al arrancar.
• Los artefactos sean inmutables: la misma versión no se vuelve a construir y sobrescribir.
• Las dependencias (p. ej. librerías nativas) formen parte del despliegue o estén documentadas claramente.

Así se evita el problema habitual de que la “versión X” sea en realidad ligeramente distinta por servidor.

Estrategias de actualización: Rolling, Blue/Green, Stop/Start

La estrategia adecuada depende del patrón:

• Stop/Start: para job-runners o servicios no críticos; simple, pero con downtime corto.
• Rolling Update: varias instancias reiniciadas secuencialmente; adecuado para sistemas basados en colas.
• Blue/Green: dos entornos separados y conmutación por balanceador; mayor esfuerzo, riesgo mínimo.

Importante: una actualización es “segura” solo si el servicio al arrancar acepta una versión de esquema/BD compatible o las migraciones se ejecutan de forma controlada. Los cambios de esquema son una fase de despliegue en sí misma con un plan (compatibilidad hacia delante/atrás o ventana de mantenimiento).

Seguridad y hardening operativo: medidas pequeñas, gran efecto

Los servicios Linux suelen estar próximos a datos, interfaces y credenciales. Por eso el hardening no es un lujo. Unos pocos estándares reducen significativamente el riesgo.

Least Privilege y permisos de ficheros

• Usuario del servicio propio sin shell de login, permisos de grupo mínimos.
• Ficheros de configuración y secrets legibles solo por ese usuario.
• Permisos de escritura solo donde sean necesarios (p. ej. Working-Directory, spool, temp).

Límites de red y gestión de puertos

Si un servicio Delphi abre puertos (p. ej. como REST-Server), conviene:

• Bind a interfaces internas si no es necesaria accesibilidad externa.
• Reglas de firewall y redes segmentadas, en lugar de “abierto en la LAN”.
• Planificar la terminación TLS (reverse proxy, rotación de certificados) según el entorno.

Incluso internamente, los servicios no deben asumir que solo clientes “buenos” llaman. Autenticación y autorización forman parte del diseño.

Patrones de fallo típicos en la práctica —y cómo evitarlos

En producción suelen repetirse ciertos patrones que consumen tiempo a los equipos. Algunos casos típicos y contramedidas:

“El servicio está en ejecución, pero no procesa nada”

• Causa: deadlock, IO bloqueante, problema de reconexión silenciosa.
• Contramedida: timeouts en todos los puntos; watchdog/health business-check; arquitectura de workers en lugar de single-thread; fail-fast ante dependencia rota.

“Tras una actualización, los jobs aparecen duplicados”

• Causa: falta de idempotencia, ausencia de tabla de jobs dedicada, efectos secundarios no atómicos.
• Contramedida: estado de job en DB, constraints únicos, patrón Outbox/Inbox, eventos desduplicables.

“Los logs no ayudan —solo stacktraces sin contexto”

• Causa: logging no estructurado, sin ID de correlación, sin contexto de job.
• Contramedida: campos de log estructurados, Job-ID, fuente de entrada, duración, resultado, clase de error.

“El servicio colapsa bajo carga”

• Causa: paralelismo descontrolado, falta de backpressure, demasiadas conexiones DB, transacciones demasiado grandes.
• Contramedida: límites de workers, longitudes de cola, límites de conexión, transacciones pequeñas, buffers y reintentos.

Interacción con REST-Server y software empresarial existente

En muchas arquitecturas no existe “un servicio único”, sino un paquete que incluye REST-Server, workers en segundo plano y clientes. En proyectos Delphi suele tener sentido mantener la lógica de negocio común en módulos claros, separando las partes de transporte y operación.

Separar capas de forma limpia (lógica de negocio y técnica)

Una estructura pragmática:

• Domain/Lógica de negocio: reglas, validación, cálculos, casos de uso.
• Infraestructura: acceso a BD, sistema de ficheros, clientes HTTP, mensajería.
• Adaptadores: endpoints REST, bucle de servicio, CLI-runner, lógica de arranque cercana a systemd.

Esta separación no es académica: permite que la misma lógica de negocio se use en el REST-Server y en el worker, mientras que los aspectos operativos (timeouts, reintentos, logging, health) se implementan de forma consistente.

Plataforma multiplataforma: Delphi como base de código unificada

Si una empresa ya usa Delphi para clientes Windows, un servicio Linux puede ser el siguiente paso lógico: mismo lenguaje, librerías similares, pipelines de build unificadas. El beneficio aparece sólo si se respetan conscientemente los límites de plataforma (rutas de archivos, case-sensitivity, locale/encoding, permisos de usuario del servicio, convenciones de despliegue). Multiplataforma en operación es siempre “trabajo de detalle” —por eso debe planificarse pronto.

Lista de verificación práctica: lo mínimo que necesita un servicio Delphi-Linux productivo

• Unit de systemd con reglas de Restart/Timeout razonables, usuario propio del servicio, rutas definidas.
• Graceful Shutdown (SIGTERM), sin inconsistencias de datos al parar.
• Modelo de configuración con validación, secrets seguros, sin secrets en logs.
• Logging estructurado con versión, Job-ID, ID de correlación, duración, clase de error.
• Health Checks (al menos Readiness + Business-Check) y métricas definidas.
• Procesamiento idempotente de jobs, retry/backoff, concepto de dead-letter.
• Despliegue con versionado claro, estrategia de rollback, migraciones de esquema planificables.
• Concepto de recursos y carga: paralelismo, límites, timeouts, manejo de conexiones.

Conclusión: Delphi sobre Linux no es un caso especial —si se piensa en la operación

Los servicios Linux con Delphi son en producción una opción muy sólida si se tratan como componentes de sistema de pleno derecho: con arquitectura clara, integración correcta en systemd, modelo de errores y estados robusto, logging trazable, monitorización y despliegue reproducible. La implementación técnica rara vez es el riesgo; el riesgo está en los “detalles operativos” que se abordan demasiado tarde.

Quien planifica estos detalles desde el inicio obtiene un paisaje de servicios mantenible, que reutiliza la lógica de negocio de forma coherente, gestiona integraciones de forma estable y se opera con fiabilidad en el día a día —incluyendo actualizaciones, reinicios e incidentes.

Si desea revisar cómo trasladar su lógica de negocio Delphi existente a servicios Linux, workers y REST-Server (incluyendo concepto de operación y despliegue), podemos clarificar las condiciones marco de forma estructurada en una primera reunión técnica: Contacto.