| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| wiki:microservicios [2024/11/11 11:59] – admin | wiki:microservicios [2024/11/11 12:22] (current) – admin |
|---|
| Una segunda ventaja de los microservicios es la escalabilidad. Cuando un monolítico enfrenta problemas de rendimiento, una solución consiste en desplegar instancias del sistema en diferentes máquinas, como muestra la siguiente figura. Esta solución se llama escalabilidad horizontal. Por ejemplo, permite dividir a los clientes del sistema entre las dos instancias que se muestran en la figura. Como se trata de un monolítico, ambas instancias son idénticas, es decir, tienen los mismos módulos. | Una segunda ventaja de los microservicios es la escalabilidad. Cuando un monolítico enfrenta problemas de rendimiento, una solución consiste en desplegar instancias del sistema en diferentes máquinas, como muestra la siguiente figura. Esta solución se llama escalabilidad horizontal. Por ejemplo, permite dividir a los clientes del sistema entre las dos instancias que se muestran en la figura. Como se trata de un monolítico, ambas instancias son idénticas, es decir, tienen los mismos módulos. |
| |
| {{ :wiki:micro_3.png?250 |}} | {{ :wiki:micro_3.png?400 |}} |
| |
| Sin embargo, los problemas de rendimiento pueden deberse a servicios específicos, como el servicio de autenticación de usuarios. Entonces, los microservicios permiten replicar solo los componentes directamente relacionados con esos problemas de rendimiento. La figura siguiente muestra una nueva instalación de nuestro sistema basado en microservicios. | Sin embargo, los problemas de rendimiento pueden deberse a servicios específicos, como el servicio de autenticación de usuarios. Entonces, los microservicios permiten replicar solo los componentes directamente relacionados con esos problemas de rendimiento. La figura siguiente muestra una nueva instalación de nuestro sistema basado en microservicios. |
| |
| {{ :wiki:micro_4.png?250 |}} | {{ :wiki:micro_4.png?400 |}} |
| |
| El segundo servidor disponible incluye solo instancias del servicio ''M1'', con la suposición de que ''M1'' es responsable de la mayoría de los problemas de rendimiento de la instalación inicial. En la primera instalación, teníamos una única instancia de M1. Ahora tenemos seis instancias, todas ellas ejecutándose en un nuevo servidor. | El segundo servidor disponible incluye solo instancias del servicio ''M1'', con la suposición de que ''M1'' es responsable de la mayoría de los problemas de rendimiento de la instalación inicial. En la primera instalación, teníamos una única instancia de M1. Ahora tenemos seis instancias, todas ellas ejecutándose en un nuevo servidor. |
| **Profundización**: Los microservicios constituyen un ejemplo de aplicación de la Ley de Conway. Formulada en 1968 por Melvin Conway, esta es una de las leyes empíricas sobre desarrollo de software, al igual que la Ley de Brooks. La Ley de Conway afirma lo siguiente: las empresas tienden a adoptar arquitecturas de software que son copias de sus estructuras organizacionales. En otras palabras, la arquitectura de los sistemas de una empresa tiende a reflejar su organigrama. Por eso, no es coincidencia que los microservicios sean utilizados principalmente por grandes empresas de Internet que tienen cientos de equipos de desarrollo distribuidos en diversos países. Estos equipos, además de estar descentralizados, son autónomos y siempre están incentivados a producir innovaciones. | **Profundización**: Los microservicios constituyen un ejemplo de aplicación de la Ley de Conway. Formulada en 1968 por Melvin Conway, esta es una de las leyes empíricas sobre desarrollo de software, al igual que la Ley de Brooks. La Ley de Conway afirma lo siguiente: las empresas tienden a adoptar arquitecturas de software que son copias de sus estructuras organizacionales. En otras palabras, la arquitectura de los sistemas de una empresa tiende a reflejar su organigrama. Por eso, no es coincidencia que los microservicios sean utilizados principalmente por grandes empresas de Internet que tienen cientos de equipos de desarrollo distribuidos en diversos países. Estos equipos, además de estar descentralizados, son autónomos y siempre están incentivados a producir innovaciones. |
| |
| | ===== Administración de Datos ===== |
| |
| | Al menos en su forma pura, los microservicios deben ser autónomos también desde el punto de vista de los datos. Es decir, deben gestionar los datos que necesitan para proporcionar su servicio. Por lo tanto, el escenario ilustrado en la siguiente figura — en el que dos microservicios comparten la misma base de datos — no es recomendable en una arquitectura basada en microservicios. |
| | |
| | {{ :wiki:micro_5.png?200 |}} |
| | |
| | Lo ideal es que ''M1'' y ''M2'' sean independientes también desde el punto de vista de las bases de datos, como se muestra en la siguiente figura. La razón principal es que tener una única base de datos también puede convertirse en un obstáculo para la evolución del sistema. |
| | |
| | |
| | {{ :wiki:micro_6.png?200 |}} |
| | |
| | Por ejemplo, en equipos y arquitecturas de desarrollo tradicionales suele haber un administrador de datos, responsable de gestionar las tablas de la base de datos. Cualquier cambio en la base de datos — como la creación de una columna en una tabla — necesita la aprobación del administrador de datos. Esta autoridad central tiene que conciliar los intereses, muchas veces conflictivos, de los distintos equipos de desarrollo. Por ello, sus decisiones pueden volverse lentas y burocráticas, retrasando la evolución del sistema. |
| | |
| | ===== ¿Cuando no usar Microservicios ===== |
| | |
| | Hasta este punto, hemos presentado las ventajas y beneficios de los microservicios. Pero es importante señalar que esta arquitectura es más compleja que una arquitectura monolítica. Esto se debe a que los microservicios son procesos independientes, lo que, por diseño, da lugar a sistemas distribuidos. Por lo tanto, al usar microservicios, debemos enfrentar todos los desafíos que aparecen al implementar un sistema distribuido. Entre ellos, podemos mencionar: |
| | |
| | * Complejidad: cuando dos módulos se ejecutan en el mismo proceso, la comunicación entre ellos se realiza mediante llamadas a métodos. Cuando estos módulos están en máquinas diferentes, la comunicación entre ellos debe usar algún protocolo de comunicación, como HTTP/REST. Es decir, los desarrolladores tendrán que dominar y utilizar un conjunto de tecnologías para la comunicación en redes. |
| | |
| | * Latencia: la comunicación entre microservicios también implica una mayor demora, conocida como latencia. Cuando un cliente llama a un método en un sistema monolítico, la latencia es mínima. Por ejemplo, rara vez un desarrollador dejará de usar una llamada de método solo para mejorar el rendimiento de su sistema. Sin embargo, este escenario cambia cuando el servicio llamado está en otra máquina, quizás al otro lado del mundo en el caso de una empresa global. En tales situaciones, existe un costo de comunicación que no es insignificante. Cualquiera que sea el protocolo de comunicación utilizado, esta llamada tendrá que atravesar el cable de la red — o por el aire y la fibra óptica — hasta llegar a la máquina de destino. |
| | |
| | * Transacciones Distribuidas: Como hemos visto, los microservicios deben ser autónomos también desde el punto de vista de los datos. Esto hace más complejo garantizar que las operaciones que actúan sobre dos o más bases de datos sean atómicas, es decir, que se ejecuten con éxito en todas las bases o que fallen en todas. Supongamos, por ejemplo, dos microservicios de pago con tarjeta de crédito, a los que llamaremos X e Y. Supongamos que una tienda en línea permite dividir el valor de una compra entre dos tarjetas. Por ejemplo, una compra de US$ 2,000.00 puede pagarse debitando US$ 1,500.00 de la tarjeta X y US$ 500.00 de la tarjeta Y. Sin embargo, estas transacciones deben ser atómicas: o ambas tarjetas son debitadas o ninguna lo es. Por eso, en arquitecturas basadas en microservicios, pueden ser necesarios protocolos de transacciones distribuidas, como el two-phase commit, para garantizar una semántica de transacción en operaciones que escriben en más de una base de datos. |
| |
| |
