Ruben Civeira

Despliegue ordenado de microservicios PHP y Angular sobre Apache En mi artículo anterior expliqué cómo estructurar un servidor Apache para servir distintos proyectos web mediante subdominios locales, combinando una configuración de DNS flexible con VirtualHosts. Ese entorno se ha convertido en la base sobre la que he construido una herramienta que facilita la gestión y despliegue de proyectos: swarm-dashboard. ¿Qué es swarm-dashboard? swarm-dashboard es una pequeña aplicación que permite organizar y desplegar múltiples proyectos basados en PHP y Angular directamente desde repositorios Git. Está diseñado para entornos de desarrollo y también para despliegues de producción ligera, donde no se justifica la complejidad de un sistema de orquestación, pero se quiere mantener orden, trazabilidad y acceso rápido a herramientas complementarias. El panel detecta automáticamente los proyectos presentes en el servidor y ofrece una interfaz para: Actualizar código desde el repositor...

Muchos de los conceptos detras de los microservicios son excepcionales: el aislamiento de dependencias externas, y la capacidad de desplegar de forma autónoma permiten una enorme flexibilidad a cualquier proyecto empresarial en el que conviben diferentes lineas de negocio, con requisitos cambiantes y en ocasiones contradictorios. Las implementaciones existentes de micro servicios actuales funcionan en base a imagenes docker que en muchos casos ejecutan un springboot, y que son desplegados en openshift o kubernetes... Lo que resultan en unas necesidades de RAM extraordinarias: montar un entorno de desarollo capaz de ejecutar seis microservicios con springboot (acceso, notificaciones, inventario, tarifas, pagos, y transportes) va a consumir unos 5Gb de RAM. Con quarkus el consumo podría bajar a unos 2Gb, pero sigue siendo un consumo enormemente elevado. Hay que tener en cuenta que a mayores en muchos casos se va a necesitar al menos un servidor de base de datos, y otros servicio...

Cuando en 1805 la francia imperial de Napoleon se enfrentó a Austria y Rusia en Austerliz, Rusos y Austríacos confiaban en su superioridad númerica. El ejercito de Napoleon estaba dividido, y su núcleo principal de 65.000 soldados estaba en desventaja frente a los 70.000 soldados ruso y 15.000 austriacos. La caballería de Napoleón estaba dispersa, pero confiaba en que sus unidades supieran interpretar los ruidos de la batalla.   La ventaja que Napoleón supo aprovechar en Austerliz fue la confianza en sus hombres. Los ejércitos austríaco y ruso eran dos ejércitos prácticamente medievales, dirigidos por la nobleza y en los que se formaban enormes cuadros de tropas que debían responder con fe ciega a las órdenes de un único noble que los dirigía. El ejercito francés estaba formado en gran medida por ciudadanos, a los que se les confiaba una responsabilidad. Las unidades de combate francesas eran mucho más pequeñas porque no necesitaban de un noble de alta cuna para ...

REST es un conjunto de principios arquitectónicos que define cómo las aplicaciones se comunican a través de la web. Se basa en un sistema sin estado, donde las solicitudes y respuestas son independientes y se comunica mediante estándares como HTTP. En REST, los datos y la funcionalidad son considerados recursos, y estos recursos son identificados y accedidos mediante URI (Uniform Resource Identifiers). Las características más aceptadas que definene un api REST, son: Interfaz Uniforme : Para simplificar y desacoplar la arquitectura, REST impone una interfaz uniforme que desacopla al cliente de los detalles del servidor. Sin estado : Cada petición de un cliente contiene toda la información que el servidor necesita para procesarla. El servidor no retiene ninguna información de estado del cliente entre solicitudes. Esto hace que las aplicaciones REST sean más escalables y simplifica el diseño del servidor. Cacheable : Las respuestas deben definir claramente si son cacheables...

Un "commit" es una acción que registra los cambios realizados en el código fuente en un sistema de control de versiones, como Git. Cada commit representa una instantánea del código en un punto específico del tiempo, y estos se organizan en una línea de tiempo para permitir a los desarrolladores rastrear y revisar la evolución del proyecto. Ahora, imagina revisar este historial sin tener ninguna pista sobre lo que cada commit hace. Sería como intentar leer un libro sin capítulos ni títulos. Aquí es donde entra en juego la importancia de un mensaje de commit claro. Al proporcionar una breve y precisa descripción de los cambios, estos mensajes actúan como títulos o guías que iluminan el propósito de cada cambio. Un mensaje de commit claro no solo ayuda a entender rápidamente lo que se hizo, sino que también facilita la colaboración entre equipos. Cuando varios desarrolladores trabajan en un mismo proyecto, poder interpretar el historial de cambios sin ambigüedades evita co...

 Los microservicios son una arquitectura que permite desarrollar aplicaciones como servicios independientes que se comunican entre sí. Esta comunicación puede ser síncrona, utilizando llamadas API, o asíncrona, a través de Publicación y Suscripción mediante Message Queues. Los microservicios son altamente escalables, desplegables de forma independiente, débilmente acoplados, fáciles de mantener y verificar, y están organizados en torno al dominio empresarial. Además, son manejados por equipos pequeños y autónomos y están pensados para trabajar en integración continua a través de canalizaciones CI/CD automatizadas para una entrega rápida al mercado y tienen alta resiliencia ante fallos.   En contraste, la arquitectura monolítica tradicional es una aplicación estrechamente acoplada en un solo código base que contiene diferentes capas como presentación, lógica empresarial y persistencia de la base de datos. Esta aplicación es un contenedor único que contiene los archivos de clase...

La arquitectura de microservicios se utiliza para desarrollar aplicaciones más escalables y flexibles. En lugar de tener una sola aplicación monolítica, se divide en múltiples servicios pequeños y independientes que se pueden desarrollar, probar y desplegar de forma independiente. Esto permite una mayor eficiencia en el desarrollo, ya que cada equipo puede trabajar en un servicio específico sin afectar al resto de la aplicación. También facilita el escalamiento y la resolución de problemas, ya que si un servicio falla, solo afecta a ese servicio y no a toda la aplicación. La mejor forma de dividir una aplicación en microservicios depende del caso específico y de los requisitos de la aplicación. Sin embargo, hay algunas prácticas recomendadas que pueden ayudar a dividir una aplicación en microservicios: Por responsabilidad: Cada servicio debe tener una responsabilidad específica y no debería estar sobrecargado con múltiples funciones. Por lógica de negocio: Los servicios deben estar ...