Módulo 2.

Modelos de sistemas distribuidos

Video de inmersión

Unidad 1: Introducción a distribución de servicios

Unidad 2. Microservicios

Glosario

Video de habilidades

Referencias

Descarga la lectura
Lección 1 de 7

Video de inmersión

Verify to continue
We detected a high number of errors from your connection. To
continue, please confirm that you’re a human (and not a
spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

C O NT I NU A R
Lección 2 de 7

Unidad 1: Introducción a distribución de servicios

Haciendo un poco de historia, desde los inicios de la informática, la evolución es una constante que se ha mantenido al ritmo de los avances tecnológicos. En
este sentido, los modelos de este desarrollo se basan en que la tecnología ha permitido que la informática pase del uso netamente individual a uno más
integrado y compartido. Por lo tanto, se hizo necesario buscar una manera más eficiente de compartir información, de forma segura y eficiente. Esto trajo
como consecuencia una evolución histórica que sin duda marcó el inicio de todo lo que actualmente nos parece natural y cotidiano.

El concepto de transmisión de mensajes se originó a finales de la década del sesenta cuando las redes de computadoras todavía no existían. Sin embargo,
nació el concepto de organizar un sistema operativo como una colección de procesos de comunicación. En este sistema, cada proceso tendría una función
específica. Poco después, en los años setenta, surgieron los primeros sistemas distribuidos generalizados: las redes de área local (LAN).

Tema 1. ¿Qué es este tipo de modelo?

Los sistemas distribuidos son aquellos en los cuales los componentes de hardware (componentes físicos de la computadora) y de software (conjunto de
programas) están ubicados en computadoras de una red y en los cuales las acciones se comunican y coordinan solamente por medio de mensajes.

Nos encontramos con numerosos ejemplos de sistemas distribuidos, algunos de ellos son:

World Wide Web.

Servidor de archivos de red.

Red bancaria.

Redes peer-to-peer (red de pares).

Sistemas de control de procesos.

Redes de sensores.

Grid computing (computación en malla).

Características

Colección de elementos de computación autónomos.

Constan de toda clase de nodos, desde computadoras de alto rendimiento a pequeños dispositivos.

Se programan para alcanzar objetivos comunes, gracias al intercambio de mensajes entre ellos.
 Como consecuencia, no hay un reloj común.

Sistema coherente único. Transparencia.

Vista de sistema único a transparente al usuario final.

No se debería saber en qué nodo está ejecutando una tarea.

No debería importar dónde se almacenen los datos.

No debería importar si el sistema réplica datos para mejorar el rendimiento.

Conjunto de procesadores conectados por una red.

Sin memoria compartida.

Sistema débilmente acoplado.

No existe un reloj común.

Dispositivos de E/S asociados a cada procesador.

Fallos independientes de componentes del SD.

Carácter heterogéneo.

Middleware.

Los SD se organizan como una capa de software que es lógicamente separada entre una capa de alto nivel
que consta de usuarios y aplicaciones y una capa subyacente formada por sistemas operativos y recursos
básicos de comunicación.

Soporte a computadoras y redes heterogéneas.

Vista de un sistema único.

Figura 1. Procesos y procesadores en sistemas distribuidos

 Fuente: David, 2002, https://n9.cl/mhx4

Un middleware (lógica de intercambio de información) a un SD es lo mismo que un SO a un computador: un gestor de recursos.

Para que sus aplicaciones compartan y desplieguen los recursos a través de una red.

Otros servicios:

Comunicación entre aplicaciones.

Servicios de seguridad.

Servicios de contabilidad.

Enmascaramiento y recuperación de errores.

La mayoría de los servicios son útiles para muchas aplicaciones. El middleware es un contenedor de componentes y funciones que no tienen que ser
implementadas por las aplicaciones de forma separada.

Ejemplos de servicios middleware

Comunicación
–
 RPC (Remote Procedure Call- llamada a procedimiento remoto): permite invocar a una función que es implementada y ejecutada en una máquina remota como si
estuviera localmente.

El desarrollador solo especifica el encabezado de la función.

Transacciones
–

Soporte para ejecutar servicios en una forma de todo o nada = transacción atómica.

El desarrollador solo necesita los servicios remotos implicados. Siguiendo un protocolo estándar, el middleware asegura que se invoquen todos los servicios o ninguno.

Composición de servicio
–

Permite desarrollar nuevas aplicaciones tomando programas existentes y pegándolos.

Middleware basado en web: mashups (integración) (Google Maps + información de viaje + pronóstico meteorológico, etc.).

Confiabilidad
–

El middleware proporciona funciones mejoradas para crear aplicaciones distribuidas.

El desarrollador puede construir una aplicación como un grupo de procesos. De este modo, se garantiza que cualquier mensaje enviado por un proceso sea recibido por
todos o ninguno.

Ventajas y desventajas de los sistemas distribuidos

V E NTAJ AS DE S V E NTAJ AS

Economía: buena relación rendimiento/costo.

Avances en tecnología de microprocesadores y redes de área local.

Alto rendimiento: procesamiento paralelo.

Soporte de aplicaciones inherentemente distribuidas. Por ejemplo: empresa distribuida geográficamente.

Capacidad de crecimiento: escalabilidad.

Fiabilidad y disponibilidad: tolerancia a fallos.

Carácter abierto y heterogéneo.

Estándares de interoperabilidad.
 Compartir recursos y datos.

V E NTAJ AS DE S V E NTAJ AS

Necesidad de un nuevo tipo de software:

Más complejo.

No hay todavía un acuerdo de cómo debe ser.

La red de interconexión produce nuevos problemas:

Pérdida de mensajes y saturación.

Latencia: puede provocar que al recibir un dato ya esté obsoleto.

La red es un elemento crítico.

Seguridad y confidencialidad.

Definición alternativa de SD.

Aplicaciones de los sistemas distribuidos

Entornos empresariales: redes corporativas e intranets.

Sustituye a los clásicos mainframes (unidad central).

Sistema de información distribuido.

Entornos de computación de altas prestaciones.

Procesamiento paralelo, alternativa a costosos supercomputadores.

“Sistema de computación distribuido”.

Servicios con alta disponibilidad y rendimiento.

Sistemas distribuidos de gestión de bases de datos.

Aplicaciones multimedia.

Sistemas industriales distribuidos y aplicaciones de control.

Internet: un enorme sistema distribuido. (Pérez, Pérez y Peña, s. f., p. 6).

Objetivos
Transparencia
–

Ocultar qué procesos y recursos están físicamente distribuidos a través de múltiples computadoras.

Un sistema es transparente si se presenta como una sola computadora.

Rendimiento
–

Rendimiento para un servicio multiusuario:

Objetivo: rendimiento no peor que un sistema centralizado.

Rendimiento para la ejecución paralela de aplicaciones:

Objetivo: rendimiento proporcional a procesadores empleados.

Factores: uso de esquemas caché.

Intentar que muchos accesos se hagan localmente.

Usos de esquema de replicación:

Reparto de carga entre componentes replicados.

En ambos casos: coste de mantener la coherencia.

Capacidad de crecimiento
–

Diseño de un SD debe evitar “cuellos de botella”:

Componentes centralizados y tablas centralizadas.

Algoritmos centralizados.

Estrategias:

Reparto de estructuras de datos entre varios nodos.

Replicación y caché.

Realización de parte del procesamiento en los nodos cliente.

Carácter abierto
–

SD abierto: servicios, protocolos, etc. Publicados y estándares.

Facilita la interacción con otros sistemas abiertos.

Posibilita la migración de aplicaciones desde otros SD abiertos.

 Flexibilidad para cambiar y extender el SD.

Esconde heterogeneidad de HW, SO, lenguajes.

Fiabilidad
–

Teóricamente: OR-lógico de sus componentes.

Sin embargo, a veces: AND-lógico de varios componentes.

Evitar componentes críticos (punto único de fallo).

Uso de replicación activa / pasiva:

Mantenimiento de coherencia entre réplicas.

Tema 2. Tipo de sistemas

Antes de hablar de los tipos de sistemas, tenemos que hablar de los diferentes tipos de arquitectura:

Arquitecturas cliente-servidor.

Similar a biblioteca de servicio y programa que lo usa, pero en SD.

Interacción 1 – N.

Características

Arquitectura asimétrica: dos roles en la interacción.

Cliente: solicita servicio.

Activo: inicia interacción.

Servidor: proporciona servicio

Pasivo: responde a petición de servicio.

Desventajas de arquitectura C/S.

Servidor: “cuello de botella”, problemas de escalabilidad.

Servidor: punto crítico de fallo.

 Mal aprovechamiento de recursos de la máquina.

Servidor: ofrece una colección de servicios que el cliente debe conocer.

Normalmente, la petición especifica recurso, operación y argumentos. Ejemplos:

NFS: READ, file_handle, offset, count –

HTTP: GET /index.html HTTP/1.1

Figura 2. Arquitectura cliente-servidor

Fuente: Gómez, 2020, https://n9.cl/yie6r

Arquitectura editor-subscriptor.

Facilita el desacoplamiento espacial, y potencialmente, el temporal.

Interacción M – N.

Características
 Sistema de eventos distribuidos.

Suscriptor S (subscriber): interés por ciertos eventos (filtro).

Editor E (publisher): genera un evento. Se envía a suscriptores interesados en el mismo.

Paradigma asíncrono y desacoplado en espacio.

Editores y suscriptores no se conocen entre sí (diferente a cliente/servidor).

Normalmente, push (notificación push): suscriptor recibe evento.

Alternativa, pull: suscriptor pregunta si hay eventos de interés.

Pull: requiere que se almacenen eventos (más complejo).

Facilita el uso en sistemas heterogéneos.

Diversos aspectos relacionados con la calidad de servicio.

Orden de entrega, fiabilidad, persistencia, prioridad, transacciones.

Ejemplos: mercado bursátil, subastas, chat y app (aplicación) domótica.

Figura 3. Push y pull

Fuente: [Imagen sin título sobre push y pull]. (s. f.). Recuperado de: htps://ichi.pro/es/modelo-de-editor-suscriptor-para-aplicaciones-y-flujos-
de-ingestion-de-datos-203111126133138
 Fuente: [Imagen sin título sobre push y pull]. (s. f.). Recuperado de: htps://ichi.pro/es/modelo-de-editor-suscriptor-para-aplicaciones-y-flujos-
de-ingestion-de-datos-203111126133138

Figura 4. Cliente-servidor vs. editor-suscriptor

Fuente: [Imagen sin título sobre cliente/servidor y editor/suscriptor]. (s. f.). Recuperado de: htps://ichi.pro/es/modelo-de-editor-suscriptor-para-
aplicaciones-y-flujos-de-ingestion-de-datos-203111126133138

Arquitectura peer-to-peer

Procesos cooperantes con el mismo rol.

Interacción N – N.

Características
 Todos los nodos tienen el mismo rol y funcionalidad servents (servicio).

No hay cuellos de botella ni puntos críticos de fallo.

Se aprovechan los recursos de todas las máquinas.

Se suelen caracterizar además por:

Volatilidad: nodos entran y salen del SD.

Capacidad de autogestión sin una autoridad global centralizada.

Uso de red superpuesta:

Red lógica sobre la física.

Nodos de proceso como nodos de red.

Gestionan esquemas de encaminamiento y localización de recursos.

Desventajas:

Difícil administración conjunta y mayores problemas de seguridad.

Aplicaciones:

Sistemas de fichero P2P.

Cachés P2P.

Mensajería instantánea.

VoIP.

Videoconferencia.

Streaming (transmisión P2PTV).

Computación distribuida.

Figura 5. Arquitectura peer to Peer (P2P)

 Fuente: Blancarte, 2020, https://n9.cl/hvrlt

Tipos de sistemas distribuidos

Los sistemas computacionales distribuidos pueden ser clasificados en varios grupos.

Distribuido tipo clúster.

Sistemas computacionales
Distribuido tipo grid (red).
 Sistemas de procesamiento de
transacciones.
Sistemas distribuidos de información
Integración de aplicaciones empresariales.

Sistemas caseros.

Sistemas electrónicos para el cuidado de la

Sistemas distribuidos masivos salud.

Redes de monitoreo.

A continuación, desarrollaremos las características de cada uno de los sistemas distribuidos.

Tipo clúster

Figura 6. Clúster
 Fuente: [Imagen sin título sobre clúster]. (s. f.). Recuperado de: https://sites.google.com/site/pagwebquestsistdistribelec1/beneficios-y-tipos-
de-cluster

Los sistemas de cómputo en clúster adquirieron popularidad cuando mejoró la relación precio-rendimiento de las computadoras personales y
las estaciones de trabajo.

Se volvió económico la construcción de una supercomputadora usando tecnologías económicas y computadoras simples (homogéneas)
ubicadas dentro de una red de alta velocidad. En virtualmente todos los casos, la computación en clúster se utiliza para la ejecución de
aplicaciones paralelas, donde un solo programa (de cálculo intensivo) corre paralelamente en múltiples máquinas.

Un ejemplo muy conocido de computadora clúster, es la formada por clústeres basados en distintas distribuciones de Linux.

Cada clúster consta de una colección de nodos de cómputo controlados, y se accede a ellos mediante un solo maestro.

El nodo maestro manipula la ubicación de los nodos para el programa paralelo i. e. mantienen una cola de procesamiento por lotes de
trabajos enviados y proporciona una interfaz para los usuarios del sistema.

Realmente el nodo maestro ejecuta un middleware necesario para la ejecución de los programas y la administración del clúster.

Una parte importante del middleware está formada por las bibliotecas necesarias para la ejecución de programas (bibliotecas de interfaz de
paso de mensajes generalmente).

También existen otro tipo de herramientas como MOSIX para intentar proporcionar una imagen de sistema único del clúster. (Franco
Martínez, 2015, https://cutt.ly/xmX4W64).

Figura 7. Tipo grid

 Fuente: Mora, 2008, https://cutt.ly/zmX7toJ

Una característica de los clústeres es la homogeneidad (mismo sistema operativo conectado a la misma red). Por el contrario, los sistemas
basados en Grid tienen un alto grado de heterogeneidad (no se establecen características específicas de hardware, sistemas operativos,
redes, dominios administrativos, políticas de seguridad, etc.).

El propósito de un sistema de cómputo en Grid es reunir los recursos de diferentes organizaciones para permitir la colaboración de un grupo
de personas o instituciones.

Tal colaboración se realiza de la forma de una organización virtual. La gente que pertenece a la misma organización virtual tiene derechos de
acceso a los recursos que proporciona la organización.

Los recursos generalmente constan de servidores (incluso supercomputadoras).

Facilidades de almacenamiento.

Bases de datos.

Cómputo de alto rendimiento.

Telescopios.

Sensores. (Franco Martínez, 2015, https://cutt.ly/xmX4W64).

Arquitectura en capas para tipos grid

Figura 8. Grid
 Fuente: Aguilera y Gómez, 2014, https://n9.cl/t84pq

Capa de fabricación. Proporciona interfaces para recursos locales ubicados en un sitio específico. Por lo general, proporcionan funciones
para consultar el estado y las capacidades de un recurso.

Capa de conectividad. Consiste en protocolos de comunicación para dar soporte a las transacciones del grid que abarcan el uso de
múltiples recursos. Capa de recursos. Encargado de la administración de un solo recurso. Utilizando las funciones de la capa de
conectividad y de fabricación (llamada a las interfaces).

Capa colectiva. Encargado de manipular el acceso a múltiples recursos, a diferencia de las capas anteriores, esta capa consta de una
colección estándar de protocolos relativamente pequeña.

Capa de aplicaciones. Aplicaciones que operan dentro de una organización virtual haciendo uso del sistema de cómputo basado en grid.
(Tanembaum y Van Steen, 2012, p. 64).

Por lo general, las capas colectivas, de conectividad y de recursos forman el núcleo de lo que podríamos llamar una capa grid middleware (red de
intercambio de información).

En conjunto, estas capas proporcionan acceso y administración de los recursos que están potencialmente dispersos a través de muchos sitios (idea de un
solo sitio o unidad de administración común).

Se basa en arquitecturas orientadas a servicios SOA.

Figura 9. Servicios SOA

 Fuente: Departamento de Ciencia la Computación e Inteligencia Artificial, 2008, https://n9.cl/vsofo

Tema 3. ¿Qué es la escalabilidad?

La escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para reaccionar y adaptarse sin
perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin
perder calidad en los servicios ofrecidos. (Tokio New Technology School, 2021, https://n9.cl/kq6pg).

El crecimiento o escalabilidad de un sistema distribuido depende de factores como la tecnología a usar, la complejidad del sistema, el costo
de la solución.

El tema de escalabilidad casi siempre lo relacionan con el hardware, pero ¿qué pasa con el software? El software de sistema y aplicación
no tiene por qué cambiar cuando la escala del sistema se incremente.

Por ejemplo: una aplicación de software es escalable si al añadir procesadores a un nodo de la red, el rendimiento crece proporcionalmente.

En cambio, se dice que el software no es escalable si el rendimiento no crece al aumentar los procesadores al nodo de la red. (Coulouris,
2001, p. 19).

Existen distintas herramientas para trabajar o generar escalabilidad:

Uso de software eficiente en tiempo y espacio.

Patrones de diseño y de código para manejar eficientemente conexiones, threads, etc.

Uso de cachés, consistencia eventual, replicación y balanceo de carga.

Tipos de escalabilidad

Figura 10. Escalabilidad vertical simple y escalabilidad horizontal simple

 Fuente: [Imagen sin título sobre escalabilidad]. (s. f.). Recuperado de: https://pensandoensoa.wordpress.com/2016/09/27/escalabilidad-en-
sistemas-distribuidos/

Fuente: [Imagen sin título sobre escalabilidad]. (s. f.). Recuperado de: https://pensandoensoa.wordpress.com/2016/09/27/escalabilidad-en-
sistemas-distribuidos/

Según Tanenbaum y Van Steen (2012), la escalabilidad de un sistema distribuido se puede medir según las siguientes dimensiones:

Respecto a su tamaño. Significa agregar recursos y usuarios fácilmente.

Respecto a su ubicación. Indica que los usuarios y los recursos pueden estar muy lejos entre sí.

Respecto a la administración. Esto significa que debe ser fácil de usar y manejar sin importar cuantas organizaciones compartan el
mismo sistema distribuido.

Estas dimensiones pueden ser consideradas como retos en la escalabilidad de los sistemas distribuidos.
Tema 4. Dimensiones de escalabilidad en un sistema distribuido

Existen dos tipos de escalabilidad.

El crecimiento vertical

Ocurre cuando se agregan más recursos a un nodo de la red. Por ejemplo: más memoria, otro disco duro, cambiar el tipo de procesador, etc. Escalar hacia
arriba viene a significar una migración de todo el sistema a un nuevo hardware más potente y eficaz que el actual. Una vez que se ha configurado el sistema
futuro, se realizan una serie de validaciones y copias de seguridad. Luego, entra en funcionamiento. Las aplicaciones que estén funcionando bajo la
arquitectura hardware antigua no sufren con la migración. El impacto en el código es mínimo.

Este modelo de escalabilidad tiene un aspecto negativo. Al aumentar la potencia con base en ampliaciones de hardware, llegará un
momento que existirá algún tipo de limitación hardware. Además, a medida que se invierte en hardware de muy altas prestaciones, los
costos se disparan tanto de forma temporal (ya que, si se ha llegado al umbral máximo, hay componentes de hardware que tardan mucho
tiempo en ampliar su potencia de forma significativa) como económicos. Sin embargo, a nivel estructural no supone ninguna modificación
reseñable, lo que la convierte en una buena opción si los costos anteriores son asumibles. (MADEJA, s. f., https://n9.cl/qz34f).

El crecimiento horizontal

Sucede cuando se añade un nodo en la red.

La escalabilidad horizontal consiste en potenciar el rendimiento del sistema desde un aspecto de mejora global, a diferencia de aumentar la
potencia de una única parte del mismo. Este tipo de escalabilidad se basa en la posibilidad de modular su funcionalidad. Por ello suele estar
conformado por una agrupación de equipos que dan soporte a la funcionalidad completa. Normalmente, en una escalabilidad horizontal se
añaden equipos para dar más potencia a la red de trabajo.

Con un entorno de este tipo, es lógico pensar que la potencia de procesamiento es directamente proporcional al número de equipos de la red.
El total de la potencia de procesamiento es la suma de la velocidad física de cada equipo transferida por la partición de aplicaciones y datos
extendida a través de los nodos.

Si se aplica un modelo de escalabilidad basado en la horizontalidad, no existen limitaciones de crecimiento a priori. Como principal e
importante defecto, este modelo de escalabilidad supone una gran modificación en el diseño, lo que conlleva a un gran trabajo de diseño y
reimplantación. Si la lógica se ha concebido para un único servidor, es probable que se tenga que estructurar el modelo arquitectónico para
soportar este modelo de escalabilidad.

El encargado de cómo realizar el modelo de partición de datos en los diferentes equipos es el desarrollador. Existen dependencias en el
acceso a la aplicación. Es conveniente, realizar un análisis de actividad de los usuarios para ir ajustando el funcionamiento del sistema. Con
 este modelo de escalabilidad, se dispone de un sistema al que se pueden agregar recursos de manera casi infinita y adaptable al crecimiento
de cargas de trabajo y nuevos usuarios.

La escalabilidad cuenta como factor crítico el crecimiento de usuarios. Es mucho más sencillo diseñar un sistema con un número constante
de usuarios (por muy alto que sea este) que diseñar un sistema con un número creciente y variable de usuarios. El crecimiento relativo de
los números es mucho más importante que los números absolutos.

Dentro de la escalabilidad existe un concepto importante por la trascendencia que tiene la gestión de los recursos a la hora de compartir y
distribuir la carga de trabajo de los mismos en ambas direcciones tanto horizontal como vertical; por esta razón es fundamental conocer
sobre el balance de carga.

Balance de carga

A la hora de diseñar un sistema con compartición de recursos, es necesario considerar cómo balancear la carga de trabajo. Se entiende este
concepto, como la técnica usada para dividir el trabajo a compartir entre varios procesos, ordenadores, u otros recursos. Está muy
relacionada con los sistemas multiprocesales, que trabajan o pueden trabajar con más de una unidad para llevar a cabo su funcionalidad.
Para evitar los cuellos de botella, el balance de la carga de trabajo se reparte de forma equitativa a través de un algoritmo que estudia las
peticiones del sistema y las redirecciona a la mejor opción.

Balance de carga por hardware

Presenta las siguientes características:

A partir de un algoritmo (Round Robin, LRU), examina las peticiones HTTP entrantes y selecciona el más apropiado entre los distintos clones
del sistema.

La selección del clon del sistema está basada en el algoritmo de sustitución y es aleatoria.

Este último punto provoca problemas en el diseño, ya que no garantiza que si un usuario realiza varias peticiones sean atendidas por el
mismo clon del sistema. Por lo tanto, no hay mantenimiento de la sesión del usuario en el servidor y condiciona el diseño.

La sesión debe de ser mantenida por el desarrollador.

Al ser un proceso hardware, es muy rápido.

Balance de carga por software

Examinan el paquete con respecto al protocolo HTTP para garantizar el mantenimiento de la sesión de usuario.

Distintas peticiones del mismo usuario son servidas por el mismo clon del servidor.

Más lentos que los balanceadores hardware.

Normalmente son soluciones baratas. (MADEJA, s. f., https://n9.cl/qz34f).

Preguntas de reflexión

Después de leer este contenido, ¿te parece una buena estrategia usar microservicios?

¿Cuáles son las mejores ventajas a la hora de implementar estándares actuales como el CI/CD en una plataforma de datos?
¿El desarrollo de soluciones ya no se debería trabajar con estructuras monolíticas? Para responder, se deben revisar las ventajas y las
desventajas de dicha estructura.

Indicar qué similitudes tiene el modelo de sistema distribuido en relación con algún servicio conocido (Mercado Libre, Rappi, PedidosYa,
etc.).

Si buscamos varias redes o estructuras similares y de acuerdo a las estructuras de los sistemas distribuidos: ¿qué ventajas y
desventajas podemos encontrar?

Si te pidieran desarrollar una red con sistema distribuido para una cadena de automercados, ¿qué tipo elegirías y por qué?

C O NT I NU A R
Lección 3 de 7

Unidad 2. Microservicios

En un primer acercamiento al concepto, podríamos decir que es un tipo de arquitectura que sirve para diseñar aplicaciones. Lo que distingue
a la arquitectura de microservicios de los enfoques tradicionales y monolíticos es la forma en que desglosa una aplicación en sus funciones
principales. Cada función se denomina servicio y se puede diseñar e implementar de forma independiente. Esto permite que funcionen
separados (y también, fallen por separado) sin afectar a los demás. (Red Hat, 2021, https://n9.cl/nagj8).

La arquitectura de microservicios es un método de desarrollo de aplicaciones software que funciona como un conjunto de pequeños
servicios que se ejecutan de manera independiente y autónoma, proporcionando una funcionalidad de negocio completa. En ella, cada
microservicio es un código que puede estar en un lenguaje de programación diferente, y que desempeña una función específica. Los
microservicios se comunican entre sí a través de API, y cuentan con sistemas de almacenamiento propios, lo que evita la sobrecarga y
caída de la aplicación.

Los microservicios han creado infraestructuras IT más adaptables y flexibles. Porque si se quiere modificar solamente un servicio, no es
necesario alterar el resto de la infraestructura. Cada uno de los servicios se puede desplegar y modificar sin que ello afecte a otros servicios
o aspectos funcionales de la aplicación. (Decide Soluciones, 2019, https://n9.cl/srxdq).

Javier Garzas (2015), por su parte, afirma que:

Una “arquitectura de microservicios” es un enfoque para desarrollar una aplicación software como una serie de pequeños servicios, cada uno
ejecutándose de forma autónoma y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus API.

Normalmente hay un número mínimo de servicios que gestionan cosas comunes para los demás (como el acceso a base de datos), pero
cada microservicio es pequeño y corresponde a un área de negocio de la aplicación.

Además, cada uno es independiente y su código debe poder ser desplegado sin afectar a los demás. Incluso cada uno de ellos puede
escribirse en un lenguaje de programación diferente, ya que solo exponen la API (una interfaz común, a la que le da igual el lenguaje de
programación en la que el microservicio esté programado por debajo) al resto de microservicios.

No hay reglas sobre qué tamaño tiene que tener cada microservicio, ni sobre cómo dividir la aplicación en microservicios, pero algunos
autores como Jon Eaves caracterizan un microservicio como algo que en el código podría ser reescrito en dos semanas. (Garzas, 2015,
https://n9.cl/1mxxy).

Podemos entender los microservicios a través de un ejemplo. Imaginemos que queremos realizar una aplicación web tipo Amazon, pero más sencilla. Los
usuarios entran por nuestra web, ven los productos que tenemos en venta y, cuando compran un artículo, gestionamos el envío del producto a su domicilio.
Figura 11. Microservicios

Fuente: Garzas, 2015, https://n9.cl/1mxxy

1. Visión monolítica

Una primera idea de cómo afrontar esta aplicación sería la siguiente arquitectura monolítica.

Podemos acceder a la página web de la tienda, realizar compras, etc., gracias a un servidor, una máquina que está ejecutando el código de
la aplicación, en forma de archivo war, que eventualmente se conecta a una base de datos para recuperar información.

Cuando un usuario compre un producto vía web, mostremos los productos disponibles, etc., la aplicación responderá de una forma u otra,
según la hayamos programado, pero el código de las distintas lógicas de negocio (inventario, pagos, envíos) aunque puede estar separado
en distintos módulos del código, finalmente se empaqueta en un único archivo ejecutable. Por eso la llamo arquitectura monolítica.

Si hago un cambio en el módulo de pagos, tendré que subir a producción de nuevo todo el código, incluido los módulos de inventario y
envíos, a pesar de no haberlos cambiado.
 Además, para escalar la aplicación (por ejemplo, dar servicio a muchos usuarios) tendré que ir ejecutando copias de mi aplicación bajo
balanceadores de carga, que vayan redireccionando a los usuarios hacia un sitio u otro, en función de si el sistema está muy saturado. En
este caso, tendré que replicar toda la aplicación, aunque solo sea el módulo de pagos el que concentre la sobrecarga.

Pero, por otra parte, si mi aplicación no es muy compleja, la subida será sencilla y fácil de gestionar, ya que en este caso hablamos de un
único archivo ejecutable.

2. Visión de microservicios

En vez de tener un único ejecutable, cada componente es un ejecutable por sí mismo, y los servicios se comunican entre sí a través de
llamadas

En este caso también tenemos un microservicio que implementa la interfaz web con la que interactúan los usuarios y cierta lógica por debajo
para llamar al microservicio de pagos, inventario y envíos cuando sea necesario.

Como beneficios con respecto al anterior enfoque tenemos que:

Cada microservicio se puede desplegar de forma independiente: un cambio en el módulo de inventario, no afectará a los demás, solo
tendremos que subir ese módulo.

Es fácil de entender, ya que la lógica de negocio está bien separada.

Facilita la gestión de equipos multifuncionales y autónomos. Por sí mismo, cada microservicio es multifuncional: tiene una parte de base de
datos, backend (parte del desarrollo que se ocupa de la lógica del programa), etc., además de ser independiente de los demás. Podemos
formar equipos multifuncionales que se encarguen de varios microservicios, escalando el proceso de desarrollo de forma más sencilla (la ley
de Conway, tu arquitectura es reflejo de la organización de tu equipo y al revés, y puede llegar a facilitar o dificultar la gestión técnica).

Es más fácil de escalar en el software, ya que en lugar de replicar toda la aplicación y gestionarlo con balanceadores, duplicaremos los
microservicios que tengan más carga. (Garzas, 2015, https://n9.cl/1mxxy).

Figura 12. Microservicios

 Fuente: Garzas, 2015, https://n9.cl/1mxxy

Figura 13. Microservicios

 Fuente: Bersano, 2020, https://n9.cl/1epir

Ventajas y desventajas de los microservicios

Veamos cuáles son las ventajas y las desventajas de la aplicación de una arquitectura de microservicios frente a otros tipos de arquitectura.

Hay que tener en cuenta estos puntos a la hora de identificar qué tipo de arquitectura software será la mejor para un determinado proyecto u organización.

Teniendo en cuenta las ventajas e inconvenientes de la implantación de una arquitectura de microservicios, lo más importante antes de
decidir qué arquitectura elegir, será determinar qué solución es la que mejor se adapta a las necesidades del proyecto o la organización y que
ayudará a conseguir los objetivos propuestos. (Decide Soluciones, 2019, https://n9.cl/srxdq).

V E NTAJ AS DE S V E NTAJ AS

Modularidad: al tratarse de servicios autónomos, se pueden desarrollar y desplegar de forma independiente. Además, un error en un servicio
no debería afectar la capacidad de otros servicios para seguir trabajando según lo previsto.

Escalabilidad: como es una aplicación modular, se puede escalar horizontalmente cada parte según sea necesario, aumentando el escalado
de los módulos que tengan un procesamiento más intensivo.

Versatilidad: se pueden usar diferentes tecnologías y lenguajes de programación. Esto permite adaptar cada funcionalidad a la tecnología
más adecuada y rentable.
 Rapidez de actuación: el reducido tamaño de los microservicios permite un desarrollo menos costoso, así como el uso de “contenedores de
software” permite que el despliegue de la aplicación se pueda llevar a cabo rápidamente.

Mantenimiento simple y barato: al poder hacerse mejoras de un solo módulo y no tener que intervenir en toda la estructura, el
mantenimiento es más sencillo y barato que en otras arquitecturas.

Agilidad: se pueden utilizar funcionalidades típicas (autenticación, trazabilidad, etc.) que ya han sido desarrolladas por terceros, no hace falta
que el desarrollador las cree de nuevo.

V E NTAJ AS DE S V E NTAJ AS

Alto consumo de memoria: al tener cada microservicio sus propios recursos y bases de datos, consumen más memoria y CPU.

Inversión de tiempo inicial: al crear la arquitectura, se necesita más tiempo para poder fragmentar los distintos microservicios e
implementar la comunicación entre ellos.

Complejidad en la gestión: si contamos con un gran número de microservicios, será más complicado controlar la gestión e integración de
los mismos. Es necesario disponer de una centralización de trazas y herramientas avanzadas de procesamiento de información que permitan
tener una visión general de todos los microservicios y orquesten el sistema.

Perfil de desarrollador: los microservicios requieren desarrolladores experimentados con un nivel muy alto de experiencia y un control
exhaustivo de las versiones. Además de conocimiento sobre solución de problemas como latencia en la red o balanceo de cargas.

No uniformidad: aunque disponer de un equipo tecnológico diferente para cada uno de los servicios tiene sus ventajas, si no se gestiona
correctamente, conducirá a un diseño y arquitectura de aplicación poco uniforme.

Dificultad en la realización de pruebas: debido a que los componentes de la aplicación están distribuidos, las pruebas y test globales son
más complicados de realizar.

Coste de implantación alto: una arquitectura de microservicios puede suponer un alto coste de implantación debido a gastos en
infraestructura y en pruebas distribuidas.

Figura 14. Microservicios vs. arquitectura monolítica

Fuente: Almeida, 2019, https://n9.cl/t4oy6

En una arquitectura monolítica, todo el código está en un archivo ejecutable principal, que puede ser más difícil de solucionar, probar y
actualizar. Si hay un problema en una base de código, ese problema podría ubicarse en cualquier lugar dentro del software. Habría más
pruebas, y estas tardarían más debido a la cantidad de código monolítico involucrado. En una aplicación monolítica, cualquier pequeño
 cambio o actualización requiere compilar e implementar una versión completamente nueva de la aplicación. Esto significa que cualquier
desarrollo de aplicaciones monolíticas implica una planificación, preparación, tiempo y gasto significativos.

Además, las aplicaciones monolíticas son más difíciles de escalar. Cuando una aplicación monolítica alcanza una limitación de su
capacidad, como el rendimiento de datos o algún otro cuello de botella, la única alternativa práctica es implementar otra iteración completa
de toda la aplicación monolítica: administrar el tráfico entre las instancias utilizando balanceadores de carga.

En comparación, es posible escalar solo los servicios de una aplicación de microservicio agregando instancias de contenedor de solo esos
servicios. Esto hace que el microservicio de escala sea mucho más eficiente en recursos que las aplicaciones de escala utilizando una
arquitectura monolítica.

Los microservicios facilitan la prueba y el despliegue de cambios. Debido a que cada uno está separado de los otros, se mejora el
aislamiento de fallas. Si hay un problema en el software, el servicio problemático puede ser aislado, remediado, probado y redistribuido sin la
necesidad de realizar una prueba de regresión de toda la aplicación como ocurre con las arquitecturas de aplicaciones monolíticas
tradicionales. La arquitectura de microservicios mejora la agilidad empresarial con un desarrollo e implementación de software más rápido en
comparación con la arquitectura de software monolítica.

Sin embargo, los microservicios no son libres de gestión. Con la misma cantidad de servicios que un producto de software monolítico, la
administración requerida en una arquitectura de microservicios podría ser más compleja, ya que cada servicio está separado uno del otro.
Esto puede llevar a dificultades para manejar todas las partes de un todo. Por ejemplo, se necesita una cuidadosa supervisión y
administración para rastrear la disponibilidad y el rendimiento de todos los servicios de componentes que operan dentro de una aplicación de
microservicio. (Evaluando Software, 2021, https://n9.cl/53nlx).

Tema 1. La arquitectura de los microservicios

La mayor parte de las arquitecturas de microservicios tienen las siguientes características:

Los componentes son servicios. La principal manera de crear componentes (unidad de software independientemente reemplazable y actualizable) es
mediante la inserción de un botón que automáticamente por detrás, gestione la descomposición en servicios en lugar de bibliotecas. Los servicios son
componentes separados que se comunican mediante mecanismos como los servicios web o los RPC en lugar de usar llamadas a funciones en memoria
como hacen las bibliotecas.

Organizada en torno a las funcionalidades del negocio. El sistema se divide en distintos servicios donde cada uno está organizado en torno a una
capacidad del negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada servicio implementa toda la funcionalidad del negocio que agrupa
desde la interfaz de usuario, la persistencia en el almacenamiento y cualquiera de las colaboraciones externas.

Productos, no proyectos. En esta arquitectura normalmente se sigue la idea de que un equipo debe estar a cargo de un componente (servicio) durante todo
el ciclo de vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta la de mantenimiento. Esta mentalidad se acopla bien con
la vinculación a una capacidad del negocio. En lugar de ver el software como un conjunto de funcionalidades terminadas se ve como una relación continua,
donde la pregunta es cómo puede el software ayudar a sus usuarios a mejorar la funcionalidad del negocio que implementa. Esto es facilitado por el bajo nivel
de granularidad que ofrecen los microservicios.

Extremos inteligente. Las aplicaciones creadas desde microservicios pretenden ser tan disociadas y cohesivas como sea posible, ellas poseen su propia
lógica de dominio y actúan como filtros en el clásico sentido UNIX: recibe una solicitud, aplica la lógica apropiada y produce una respuesta. Estos pasos son
coreografiados usando protocolos simples (típicamente HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos
como WS-BPEL.
Tener un gobierno descentralizado permite usar tecnologías que se adapten mejor a cada funcionalidad. Con el sistema con múltiples servicios
colaborativos, podemos decidir utilizar diferentes lenguajes de programación y tecnologías dentro de cada servicio. De esta forma podemos elegir la
herramienta adecuada para cada tipo de trabajo en lugar de tener una estandarizada. Por ejemplo, si una parte del sistema necesita mejorar su rendimiento es
posible usar una tecnología, quizás más complicada, que permita alcanzar el nivel de rendimiento requerido. Otro ejemplo sería usar para ciertas cosas
(reflejar interacciones entre usuarios) una base de datos orientada a grafos, y usar para otra bases de datos orientadas a documentos. La arquitectura de
microservicios permite adoptar nuevas tecnologías más rápido y en aquellos lugares donde se puede aprovechar su potencial, ya que se acota el impacto.

Gestión de datos descentralizada. Los microservicios prefieren dejar a cada servicio que gestione su propia base de datos, sean estas diferentes instancias
de la misma tecnología de base de datos o sistemas de base de datos completamente diferentes. Por ejemplo podríamos tener Redis para sesiones de
usuarios (base de datos en memoria), MySQL (relacional) para los datos de pago, MongoDB (orientada a documentos) para el catálogo de productos, Neo4j
(orientada a grafos) para las recomendaciones y Apache Cassandra (orientado a clave-valor) para el análisis de logs (registros) y analíticas. El estilo de
microservicios tiene implicaciones en el manejo de las actualizaciones las cuales tradicionalmente han usado transacciones para garantizar la consistencia.
Las transacciones imponen un acoplamiento temporal lo que se vuelve problemático cuando hay varios servicios. Como las transacciones distribuidas son
mucho más difíciles de implementar, las arquitecturas de microservicios promueven la coordinación no transaccional entre servicios, con el reconocimiento
explícito de que la consistencia puede ser una consistencia eventual y los problemas son compensados operativamente. El sistema merece la pena siempre
y cuando el costo de solucionar los errores sea menor que el costo de perder negocios por una mayor consistencia. Los microservicios no obligan a tener
distintas tecnologías de almacenamiento, solo lo permiten.

Diseño tolerante a fallos. Las aplicaciones necesitan ser diseñadas de modo que puedan tolerar las fallas de los distintos servicios. Cualquier llamada de
servicio puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor facilidad y eficacia posible, evitando los muy habituales fallos en
cascada de las arquitecturas distribuidas. Patrones más importantes para conseguir estabilidad que se usan en la arquitectura de microservicios:

Usar tiempos de espera máximos. Es un mecanismo simple que permite dejar de seguir esperando por una respuesta que consideramos que ya no vendrá.
Asociado al vencimiento de un tiempo de espera es frecuente que aparezcan:

Reintento. Consiste en repetir una operación para la cual finalizó su tiempo de espera.

Encolar para reintentar la operación para ser realizada más tarde.

Disyuntores. Funcionan de forma similar a los interruptores automáticos accionados por sobrecargas que hay en las instalaciones eléctricas. En el
software existen para permitir que un subsistema ante una falla no destruya el sistema entero por sobrecarga y una vez que el peligro ha pasado pueda
restablecerse. Este mecanismo se suele usar para envolver operaciones peligrosas con un componente y así poder esquivar las llamadas cuando el
sistema no esté operativo. Si el disyuntor detecta que las fallas superan una frecuencia umbral el disyuntor salta abriéndose y las llamadas fallan sin
realizar ningún intento de ejecutar una operación real. Después de esperar un tiempo adecuado se decide que la operación tiene una oportunidad y pasa
a un estado de semi abierto en el que la próxima llamada es permitida, si tiene éxito entonces el disyuntor se vuelve a cerrar y todo vuelve a funcionar
normalmente, si falla el disyuntor se vuelve a abrir y se vuelve a esperar el tiempo adecuado para intentar.

Compartimentos estancos para contención de daños manteniéndolos aislados. La forma más común de tenerlos es usando redundancia física teniendo
por ejemplo varios servidores y dentro de cada servidor varias instancias. A gran escala podríamos tener varias granjas de servidores.

Automatización de la infraestructura. La mayoría de los productos y sistemas desarrollados con el enfoque de microservicios han sido construidos por
equipo que usan entrega continua y su precursor la integración continua. Para conseguir esto es necesario:

Automatizar todo el proceso, desde el chequeo del código, pruebas y despliegue.

Control de versiones y gestión de configuración. Todo el software tiene que estar versionado y poder gestionar las distintas configuraciones para
conseguir la entrega continua.

Arquitectura adecuada. La arquitectura tiene que permitir realizar cambios sin que afecten al resto del sistema. La arquitectura de microservicios lo
hace posible.

Diseño evolutivo. Cuando se divide el sistema en servicios hay que tener en cuenta que cada uno tiene que poder ser reemplazado o actualizado de forma
independiente. Es decir, tiene que permitir una fácil evolución. El diseño del servicio tiene que ser de tal forma que evite en lo posible que la evolución de los
servicios afecte a sus consumidores.
Seguridad de la arquitectura de microservicios

La arquitectura de microservicios puede aliviar algunos problemas de seguridad que surgen con las aplicaciones monolíticas. Los
microservicios simplifican el monitoreo de seguridad porque las diversas partes de una aplicación están aisladas. Una brecha de seguridad
podría ocurrir en una sección sin afectar otras áreas del proyecto. Los microservicios ofrecen resistencia contra los ataques distribuidos de
denegación de servicio (DDoS) cuando se usan con contenedores al minimizar una toma de control de la infraestructura con demasiadas
solicitudes de servidor.

Sin embargo, todavía existen desafíos al proteger aplicaciones de microservicios, que incluyen:

Más áreas de red están abiertas a vulnerabilidades.

Una menor coherencia general entre las actualizaciones de la aplicación permite más violaciones de seguridad.

Hay una mayor área de ataque, a través de múltiples puertos API.

Hay una falta de control de software de terceros.

La seguridad debe mantenerse para cada servicio.

Despliegue de aplicaciones de microservicio

Se han producido tres avances principales para hacer viable la arquitectura de microservicios.

El primer avance, los contenedores, permite un medio consistente y eficiente de recursos para empaquetar servicios individuales. Docker es
una herramienta popular para desarrolladores, que permite el uso de contenedores en las instalaciones o en la nube pública o privada. Esto
ofrece una amplia variedad de alternativas de implementación para desarrolladores de microservicios y empresas.

El segundo desarrollo importante es la aparición de herramientas de orquestación, como Kubernetes. Estas herramientas ayudan a
automatizar el escalado, la implementación y la administración de contenedores.

Un tercer avance importante para los microservicios es la evolución de la malla. Una malla de servicios es una capa de infraestructura
dedicada a la comunicación entre servicios individuales. Las mallas de servicio hacen que estas comunicaciones sean más rápidas, más
seguras, visibles y confiables. (Evaluando Software, 2021, https://n9.cl/53nlx).

Así se implementa una arquitectura de microservicios

Los microservicios se mantienen aislados los unos de los otros y se ejecutan en su propio entorno. Solo se comunican entre sí a través de
interfaces. Con objeto de conseguir este aislamiento puede recurrirse a diferentes opciones:

Contenedores: la forma quizá más común de desarrollar una arquitectura de microservicios es la basada en contenedores. Estos
representan un método muy ligero de virtualización, puesto que no se crean máquinas virtuales completas, sino que se parte de un mismo
sistema operativo y se utiliza su núcleo o kernel. En los contenedores, los microservicios son completamente autónomos, pues todo lo que
necesitan para funcionar está ya contenido en ellos.

Máquinas virtuales: es posible crear una máquina virtual para cada microservicio. También en este caso cada uno de ellos puede funcionar
de forma aislada del resto. El problema de este formato frente a una tecnología de contenedores como Docker es que cada máquina
necesita su propio sistema operativo y con él muchos recursos. (Digital Guide IONOS, 2020, https://n9.cl/d74ut).

Tema 2. ¿Cómo utilizar los microservicios?

La pregunta que se hacen los responsables que tengan intención de automatizar los servicios es, ¿cuándo resulta conveniente usar microservicios?

Algo natural que suele pasar, y más en el rubro IT, es querer usar la última tecnología disponible o aquello que está de moda (que es un poco
lo que pasa a día de hoy con los microservicios). Pero como suele pasar con muchas preguntas, la respuesta es: depende.

Para responder eso, primero hay que profundizar en algunas de las ventajas y desventajas que tienen los microservicios.

Ventajas

Ciclo de vida de aplicaciones independientes. Cada uno de los microservicios que componen la solución es 100% independiente del otro
desde el punto de vista tecnológico (arquitectura interna, lenguaje de programación, etc.), del equipo que lo trabaja y cómo se organiza. Esto
permite que cada uno de esos microservicios evolucione, crezca o disminuya de forma independiente al resto de los microservicios.

Orientación a la evolución tecnológica. Al ser aplicaciones independientes cada una puede estar en un lenguaje o arquitectura diferente.
Esto puede ayudar a hacer pruebas de nuevos conceptos o tecnologías en algún microservicio puntual que, dada la función de negocio
particular que debe cumplir, se adapte a eso. Lo mismo ocurre con la actualización tecnológica, es mucho más simple actualizar versiones
de SDK y librerías de un microservicio puntual (o varios) que de una aplicación grande y monolítica. Esto último lo digo con experiencia, me
ha pasado en aplicaciones grandes que actualizar una librería era una cuestión de estado en el proyecto. Y actualizar el SDK, era presentar
una propuesta de páginas a los sponsors explicando el porqué se necesitaba hacer eso. Ahora mismo por ejemplo en el trabajo estamos
actualizando microservicios en Go y Java de forma independiente a medida que cada equipo tiene tiempo y sin afectar en nada al resto de
las aplicaciones.

Evita los cuellos de botella. Al ser aplicaciones distribuidas, no estamos en la situación donde tenemos una sola aplicación centralizada
que gestione todo el tráfico y ante una degradación de performance se vea afectada de forma completa. Al ser distribuida, si habría
degradación debería ser solamente en ese microservicio, sin afectar al resto.

Además de que es mucho más fácil escalar estas aplicaciones de forma vertical (más hardware en la misma instancia, alto costo y límites)
pero principalmente de forma horizontal (N instancias corriendo en paralelo). Esto está promovido por el uso de containers (contenedores) y
de que cada microservicio es reducido en tamaño y dependencias, permitiendo que rápidamente se pueda reaccionar a aumentos de tráfico.

Promueve la resiliencia. Tener múltiples microservicios en vez de una sola aplicación monolítica tiene como ventaja de que no hay un solo
punto de fallo. Si un microservicio sufre una afectación/caída va a tener un impacto (si no, nos deberíamos preguntar qué hace ese
microservicio por sí mismo), pero debería estar limitado a un contexto puntual y el resto de microservicios no debería verse afectado de
forma directa.

Así mismo, al tener una naturaleza distribuida el diseño de las mismas promueve ya mecanismos de respaldo ante fallos de otros
microservicios (ya que hay interacciones de distintos microservicios entre sí) y cómo recuperarse cuando el mismo esté disponible.

Trabajo más efectivo por parte de los equipos. Cada equipo suele trabajar en un conjunto limitado de microservicios, generalmente
enfocados en una parte común del negocio. Eso logra que el equipo conozca en mayor detalle tanto el negocio que tienen que resolver (algo
que es fundamental) como la parte técnica de los mismos. Eso, sumado a que cada microservicio es reducido, hace que el trabajo sea ágil y
efectivo. Si a su vez a eso le sumamos a varios equipos trabajando en paralelo en múltiples microservicios, se puede llegar a tener nuevas
funcionalidades en plazos más cortos, con calidad y alto rendimiento.

Desventajas
Requiere experiencia previa en esta arquitectura. Después de todo, los microservicios son una implementación de una arquitectura
distribuida de aplicaciones lo cual no es algo sencillo sin haberlo trabajado con anterioridad. En una arquitectura distribuida se maximizan los
posibles problemas y errores de diseño que podemos tener en una aplicación monolítica estándar.

Mayores costos. Desde la perspectiva de que tenemos muchas aplicaciones corriendo en vez de una (aunque son varias más chicas en
vez de una grande) ya tenemos un mayor costo de procesamiento. Esto sumado a que cada microservicio debería correr en instancias
totalmente aisladas con respecto a los otros, por lo que se tienen muchas plataformas (sistema operativos y plataforma de ejecución del
lenguaje) corriendo en vez de una sola. Esto claramente es una ventaja, porque se pueden escalar aplicaciones en infraestructura de forma
separada, pero dependiendo del tipo de empresa y aplicación pueden ser gastos totalmente innecesarios.

Otro costo que tenemos también son los tiempos, ya que al ser una solución más compleja y con una mayor escalabilidad vamos a
necesitar más tiempo para tenerla productiva si partimos de crear una solución de cero y sin experiencia previa. Cosas sencillas y naturales
como puede ser la transaccionalidad en el guardado de información al ser distribuido se pierde y debemos ver cómo resolverlo (pronto vamos
a ver en un post cómo resolver esto).

Mayor configuración de la infraestructura. El aislamiento que mencionamos en el punto anterior, viene dado generalmente por el uso de
containers para desplegar y ejecutar cada microservicio. Eso implica la configuración de los mismos, del proceso de CI/CD (integración y
despliegue continuo), herramientas de monitoreo y de métricas (no podemos tener N aplicaciones sin un chequeo constante del estado
interno y performance de las mismas).

Dificultad para pruebas integrales. Si bien las pruebas sobre cada aplicación son mucho más sencillas, la complejidad aparece cuando
queremos probar soluciones completas, implicando un flujo que conecta varios microservicios. Además de gestionar que cualquier cambio
que se haga a un microservicio no afecte la normal operación de los otros con los cuales se relaciona. En una aplicación monolítica nos
daría un error de compilación y problema resuelto, acá en cambio si no se gestiona y comunica de forma adecuada puede hacer que el
problema se encuentre con usuarios reales en producción.

Dificultad para debugging (depuración) y búsqueda de problemas. Si tenemos una aplicación estándar (o monolítica) ante cualquier
problema está claro dónde buscar el detalle para entender qué es lo que está pasando, tanto para errores en producción como en desarrollo.
Si hablamos de una aplicación distribuida usando microservicios, cada uno de ellos debe ser capaz de registrar su estado y saber cuándo
falla y por qué. Recordemos que, como mencionamos anteriormente, generalmente tenemos muchos equipos trabajando, cada uno en un
conjunto de microservicios. No sería práctico ni escalable que ante un problema cada uno se ponga a revisar el estado de su aplicación.

Para el desarrollo en el entorno local y debugging también tenemos mayor complejidad, ya que no podemos ejecutar todos los
microservicios relacionados localmente, y menos usar los productivos. Por lo tanto, los demás microservicios deberán estar disponible en
algún entorno de pruebas para todos los desarrolladores, o bien se pueden usar mocks (objeto simulado) de las respuestas esperadas
(básicamente en vez de hacer una llamada se lee un archivo json (formato de texto sencillo para el intercambio de datos) con la respuesta
que se espera).

Entonces, ¿cuándo es recomendable usarlos?

Habiendo repasado los puntos anteriores debemos preguntarnos, ¿cuándo es recomendable usar microservicios? Es que nos pueden dar un
paso adelante o evolución en muchos aspectos (técnicos de los equipos que desarrollan, de los productos que hacemos e incluso de las
soluciones que le damos al problema de negocio). La clave es ser conscientes de que hay algunas características para usar microservicios
en un proyecto nuevo y que no le agreguemos riesgo de problemas desde el punto de vista tecnológico:

Se cuenta con experiencia previa: eso no quiere decir que equipos que no tengan experiencia no usen microservicios, sino el cómo
obtendrán esa experiencia. Pero si es el caso, no sería ideal pensar en hacer una aplicación completa usando microservicios, sino mejor
usando la experiencia previa para hacer una aplicación bien modularizada y que permita escalar luego individualmente aquellos puntos que
sean necesarios en microservicios.

Tamaño de empresa y del producto a realizar: muchas veces pasa que una empresa chica, con poco presupuesto, tiene una idea que quiere
poner en marcha. En esos casos el tiempo y no excederse con los presupuestos disponibles es fundamental, lo cual no quiere decir que no
 debamos usar microservicios. Hay que usarlos si es necesario y si su uso nos da una ventaja para lograr los objetivos. Si no, siempre habrá
una oportunidad de evolución a futuro.

La madurez de la empresa y sus procesos: diseñar y llevar adelante una aplicación usando microservicios requiere una madurez de la
empresa en sus procesos, ya que debe tener bases sólidas en diseños de arquitecturas, buena comunicación y coordinación entre los
distintos equipos, procedimientos de CI/CD, métricas y monitoreo.

Esto no quiere decir que no debamos usarlos si no cumplimos con todas estas características, pero hay que ser conscientes de sus
características para decidir cuándo comenzar a usarlos y de qué forma.

Lo que sin dudas puedo recomendar es intentar buscar la oportunidad para hacerlo, tal vez en algo puntual que queramos empezar a separar
de nuestra aplicación de tipo monolítica, o bien cuando tengamos una parte de nuestra aplicación que puntualmente requiere alguna
característica puntual de escalabilidad y separemos solo esa parte en un microservicio.

Cuando se empieza a tomar práctica en el diseño e implementación de microservicios, vamos a poder ver cómo pensamos soluciones con
mayor calidad y robustez, a la vez que podemos usarlo como mecanismo para ir evolucionando y mejorando los procesos de la empresa.
Además de que nos pueden dar herramientas para ayudar a la escalabilidad del negocio y agilidad a la hora de realizar cambios y
adaptaciones. (Bersano, 2020, https://n9.cl/1epir).

A continuación, analizaremos qué necesitamos para comenzar a trabajar con microservicios.

Estos son los cinco elementos que un microservicio necesitará antes de que pueda utilizarse en una arquitectura de aplicación distribuida:

1. Funcionalidad con un alcance adecuado. El primer elemento de un microservicio es definir lo que debe hacer. Una forma de definir el ámbito
adecuado es particionar los servicios a lo largo de las líneas de funcionalidad lógica. Otro enfoque de alcance es reflejar la estructura de la
organización de desarrollo. Un tercer enfoque es minimizar un servicio a la cantidad de código que podría ser reintroducido por el equipo en
un período de dos semanas.

2. Preparación de una API. Una vez que descomponemos una aplicación en múltiples servicios que cooperan, ¿cómo deben hablar esos
servicios entre sí? Normalmente, esto se hace con llamadas a API de servicios web REST, aunque también pueden utilizar otros
mecanismos de transporte. Una buena idea es evitar saltar a la codificación de la API de forma inmediata. En su lugar es mejor hacer algún
trabajo en papel o pizarra para definir lo que un servicio específico debe exponer para funcionar correctamente.

3. Gestión del tráfico. Desde la perspectiva del servicio de llamada, siempre debe realizar un seguimiento de sus llamadas y estar preparado
para terminar si la respuesta toma demasiado tiempo. Desde la perspectiva del servicio llamado, el diseño de API debe incluir la posibilidad
de enviar una respuesta que indique sobrecarga. Los servicios deben ser capaces también de generar y matar nuevas instancias de servicio
según sea necesario para acomodar variaciones en la carga de tráfico.

4. Descarga de datos. Tener necesidad de una operación continua es muy diferente de lo que necesitan las aplicaciones tradicionales, que a
menudo dejan de funcionar si falla la infraestructura subyacente. Para asegurarse de que los usuarios pueden seguir trabajando cuando falla
una instancia, se pueden migrar datos específicos del usuario fuera de las instancias de servicio a un sistema compartido de
almacenamiento redundante accesible desde todas las instancias de servicio. Otro enfoque de descarga de almacenamiento es insertar un
sistema compartido de caché basado en memoria entre un servicio dado y el almacenamiento asociado con ese servicio.

5. Monitorización. El sistema de monitorización de una aplicación basada en una arquitectura de microservicios debe permitir el cambio
continuo de recursos, ser capaz de capturar datos de monitorización en una ubicación central y mostrar información que refleje la naturaleza
con frecuencia cambiante de las aplicaciones de microservicios. (PowerData, 2017, https://n9.cl/aqpz).

Tema 3. Características de los microservicios en distintos lenguajes

La arquitectura de microservicios, en la práctica no ha llegado a masificarse tanto como en la teoría, es decir, es más conocida que usada.
Sin embargo, cada día más, muchos desarrolladores están implementando por ser un modelo de desarrollo de software que mejora las
variables tiempo, rendimiento y estabilidad dentro de los proyectos donde se aplica. Además, su sencilla escalabilidad asociada la hace
especialmente adecuada en los desarrollos en los que la compatibilidad multiplataforma (web, móvil, wearables (tecnología que se puede
usar), IoT) es imprescindible.

Los microservicios pueden ser vistos como una evolución de la arquitectura SOA (Service-Oriented Architecture- Arquitectura orientada a
servicios). Esta guía a los desarrolladores a crear aplicaciones más modulares, que sean funcionales y autónomas, con alta capacidad de
ser reutilizadas de una forma eficaz, tal como se hace de forma análoga, cuando optimizamos la utilización de algún hardware, en el que se
despliega solo lo realmente necesario, en lugar de desplegar todo su potencial por completo sin necesidad.

Para entender bien la arquitectura de software de los microservicios es bueno conocer puntualmente un poco sobre todas las más conocidas
arquitecturas de software existentes, pero según el famoso libro llamado “Libro de diseño de patrones” los patrones existentes pueden ser
clasificados como:

Creacionales

Aquellos que tratan con las formas de crear instancias de objetos y cuyo objetivo es abstraer el proceso de instanciación y ocultar los
detalles de cómo los objetos son creados o inicializados. En esta clase, se encuentran los siguientes:

Abstract factory.

Builder.

Factory method.

Prototype.

Singleton.

Estructurales

Aquellos que describen cómo las clases y objetos (simples o compuestos) pueden ser combinados para formar grandes estructuras y
proporcionar nuevas funcionalidades. En esta clase, se encuentran los siguientes:

Adapter.

Bridge.

Composite.

Decorator.

Facade.

Flyweight.

Proxy.

Comportamiento

Aquellos que nos ayudan a definir la comunicación e iteración entre los objetos de un sistema. El propósito de este patrón es reducir el
acoplamiento entre los objetos. En esta clase se encuentran los siguientes:

Chain of responsibility.

Command.

Interpreter.
 Iterator.

Mediator.

Memento.

Observer.

State.

Strategy.

Template method.

Visitor.

Otros

Los anteriores patrones de diseño expresaban esquemas que definen estructuras de diseño con las que construir sistemas de software. Pero
cuando deseamos expresar mejor un esquema organizativo y estructural fundamental para los sistemas de software creados, solemos
encontrar esta otra clasificación:

Arquitectura en pizarra.

DAO: Data Access Object.

DTO: Data Transfer Object.

EDA: arquitectura dirigida por eventos.

Invocación implícita.

Objetos desnudos.

Programación por capas.

Peer-to-peer.

Pipeline.

SOA: arquitectura orientada a servicios.

También existe el “Modelo Vista Controlador” que es muy conocido y usado, y se divide a su vez en:

Modelo/Vista/Controlador.

Modelo/Vista/Presentador.

Modelo/Vista/Presentador con Presentador del Modelo.

Modelo/Vista/Vista-Modelo.

Modelo/Vista/Presentador con Vista Pasiva.

Modelo/Vista/Presentador con Controlador Supervisor.

Siendo el “Modelo Vista Controlador” uno de los más conocidos e implementados en la actualidad, el mismo se encuentra insuficiente
para dotar de las funcionalidades requeridas a una aplicación corporativa, y esta es una de las principales razones por las cuales, la
arquitectura de microservicios está reemplazando a la del Modelo-Vista-Controlador (MVC). (Desde Linux, s. f., https://n9.cl/80e6p).

Lenguajes de programación, su arquitectura y características

Docker

Figura 15. Docker

 Fuente: Digital Guide IONOS, 2019, https://n9.cl/52day

Es un proyecto de código abierto para automatizar la implementación de aplicaciones como contenedores portátiles y autosuficientes que se
pueden ejecutar en la nube o localmente.

Docker implementa contenedores en todas las capas de la nube híbrida.

Los contenedores de Docker se pueden ejecutar en cualquier lugar, a nivel local en el centro de datos de cliente, en un proveedor de
servicios externo o en la nube, en Azure. Los contenedores de imagen de Docker se pueden ejecutar de forma nativa en Linux y Windows.
Sin embargo, las imágenes de Windows solo pueden ejecutarse en hosts de Windows y las imágenes de Linux pueden ejecutarse en hosts
de Linux y hosts de Windows (con una máquina virtual Linux de Hyper-V, hasta el momento), donde host significa un servidor o una máquina
virtual.

Los desarrolladores pueden usar entornos de desarrollo en Windows, Linux o macOS. En el equipo de desarrollo, el desarrollador ejecuta un
host de Docker en que se implementan imágenes de Docker, incluidas la aplicación y sus dependencias. Los desarrolladores que trabajan en
Linux o macOS usan un host de Docker basado en Linux y pueden crear imágenes solo para contenedores de Linux. (Los desarrolladores
que trabajan en macOS pueden editar código o ejecutar la CLI de Docker en macOS, pero en el momento de redactar este artículo, los
contenedores no se ejecutan directamente en macOS). Los desarrolladores que trabajan en Windows pueden crear imágenes para
contenedores de Windows o Linux.

Para ejecutar contenedores, hay dos tipos de tiempos de ejecución:

Los contenedores de Windows Server ofrecen aislamiento de aplicaciones a través de tecnología de aislamiento de proceso y de espacio de
nombres. Un contenedor de Windows Server comparte el kernel con el host de contenedor y con todos los contenedores que se ejecutan en
el host.

Los contenedores de Hyper-V amplían el aislamiento que ofrecen los contenedores de Windows Server mediante la ejecución de cada
contenedor en una máquina virtual altamente optimizada. En esta configuración, el kernel (núcleo) del host (anfitrión) del contenedor no se
comparte con los contenedores de Hyper-V, lo que proporciona un mejor aislamiento. (Microsoft, 2020, https://n9.cl/44jfp).

Figura 16. Aplicaciones .NET

 Fuente: De la Torre, 2018, https://n9.cl/2g2ar

Controla las solicitudes mediante la ejecución de lógica de negocios, el acceso a bases de datos y, después, la devolución de respuestas
HTML, JSON o XML. Diremos que la aplicación debe admitir varios clientes, incluidos exploradores de escritorio que ejecuten aplicaciones
de página única (SPA), aplicaciones web tradicionales, aplicaciones web móviles y aplicaciones móviles nativas. También es posible que la
aplicación exponga una API para el consumo de terceros. También debe ser capaz de integrar sus microservicios o aplicaciones externas de
forma asincrónica, para que ese enfoque ayude a la resistencia de los microservicios en caso de errores parciales.

La aplicación consta de estos tipos de componentes:

Componentes de presentación. Estos componentes son los responsables del control de la interfaz de usuario y el consumo de servicios
remotos.

Lógica de dominio o de negocios. Este componente es la lógica de dominio de la aplicación.

Lógica de acceso a bases de datos. Este componente está formado por componentes de acceso a datos responsables de acceder a las
bases de datos (SQL o NoSQL).

Lógica de integración de aplicaciones. Este componente incluye un canal de mensajería basado en agentes de mensajes.

La aplicación requerirá alta escalabilidad, además de permitir que sus subsistemas verticales se escalen horizontalmente de forma
autónoma, porque algunos subsistemas requerirán mayor escalabilidad que otros. (Microsoft, 2021, https://n9.cl/nhf6h).

Tema 4. Ejemplos y casos prácticos de microservicios

Entre la gran cantidad de sitios webs que prestan servicios de aplicaciones a gran escala y han implementado progresivamente la
arquitectura de microservicios para mejorar el mantenimiento y la escalabilidad de su plataforma de servicios y productos haciéndola simple,
efectiva y rápida, podemos mencionar tres grandes de la industria que son: Amazon, Ebay y Netflix. (Desde Linux, s. f., https://n9.cl/80e6p).

Netflix: esta plataforma tiene una arquitectura generalizada que, desde hace ya un par de años (coincidiendo con su “boom” en U.S.A.), se
pasó a los microservicios para el funcionamiento de sus productos. A diario recibe una media de mil millones de llamadas a sus diferentes
servicios (se dice que es responsable del 30% del tráfico de Internet) y es capaz de adaptarse a más de 800 tipos de dispositivos mediante
su API de streaming de vídeo, la cual, para ofrecer un servicio más estable, por cada solicitud que le pedimos, esta realiza cinco solicitudes
a diferentes servidores para no perder nunca la continuidad de la transmisión.

Ebay: cómo no, una de las empresas con mayor visión de futuro, siendo pionera en la adopción de tecnologías como Docker o esta que nos
ocupa. Su aplicación principal comprende varios servicios autónomos, y cada uno ejecutará la lógica propia de cada área funcional que se
ofrece a los clientes. (Desarrollo por microservicios, 2018, https://n9.cl/p5wx).

Amazon

En 2001, el sitio web minorista de Amazon.com era un gran monolito arquitectónico. Estaba estructurado en varios niveles, y esos niveles
tenían muchos componentes en ellos, pero estaban muy juntos y se comportan como un gran monolito. Tenían una gran cantidad de
desarrolladores trabajando en un gran sitio web monolítico, y aunque cada uno de estos desarrolladores solo trabajaba en una parte muy
pequeña de esa aplicación, aún necesitaban ocuparse de coordinar sus cambios con todos los demás que también trabajaban en el mismo
proyecto. Cuando agregan una nueva función o realizaban una corrección de errores, tenían que asegurarse de que el cambio no rompería
ninguna otra cosa en ese proyecto. Si querían actualizar una biblioteca compartida para aprovechar una nueva característica, necesitaban
convencer a todos los demás en ese proyecto de que actualizaran a la nueva biblioteca compartida al mismo tiempo. Si querían hacer una
solución rápida para enviarla rápidamente a sus clientes, no podían hacerlo en su propio calendario, tenían que coordinar eso con todos los
demás desarrolladores que habían procesado los cambios al mismo tiempo. A principios de los 2000, Amazon incluso tenía un grupo de
ingeniería cuyo único trabajo era tomar nuevas versiones de la aplicación y empujarla manualmente a través del entorno de producción de
Amazon.

Fue, literalmente, un proceso muy largo y complejo, fue un infierno. Frustrante para los ingenieros de software, y lo más importante, fue la
desaceleración del ciclo de vida del desarrollo de software, la capacidad de innovar, por lo que hicieron cambios arquitectónicos y
organizativos.

Estos grandes cambios comenzaron en un nivel arquitectónico: Amazon pasó por su aplicación monolítica en una arquitectura orientada a
servicios. Amazon también implementó cambios en cómo operaba su organización. Desglosaron su único equipo de desarrollo de productos
jerárquico y central en pequeños “equipos de dos pizzas”. Querían equipos tan pequeños que pudieran alimentarlos con solo dos pizzas. En
realidad, ahora hay entre 6 y 8 desarrolladores por equipo.

Cada uno de estos equipos recibió la propiedad total de uno o unos pocos microservicios. Así que definieron su propia hoja de ruta de
características, diseñaron sus características, implementaron sus características, luego las probaron, implementaron y operaron.

Después de todos estos cambios, Amazon mejoró dramáticamente su ciclo de vida de desarrollo front-end (desarrollo de la interfaz gráfica).
Ahora los equipos de productos pueden tomar decisiones rápidamente y generar nuevas características para sus microservicios. Ahora la
compañía realiza 50 millones de implementaciones al año, gracias a la arquitectura de microservicio y sus procesos de entrega continua.

Spotify

Crea una experiencia de usuario excepcional con los microservicios. Kevin Goldsmith, vicepresidente de ingeniería de Spotify, sabe por su
experiencia que una empresa que intenta moverse rápido y mantenerse innovadora en un mercado altamente competitivo requiere una
arquitectura que pueda escalar.

Spotify brinda servicios a más de 75 millones de usuarios activos al mes, con una duración promedio de sesión de 23 minutos, mientras
ejecuta roles empresariales increíblemente complejos entre bastidores.

Por lo tanto, Spotify llegó a la conclusión de que, si le preocupa el escalado a cientos de millones de usuarios, construye su sistema de
manera que escale los componentes de forma independiente. Y Spotify construyó una arquitectura de microservicio con equipos autónomos
 de pila completa a cargo para evitar el infierno de sincronización dentro de la organización. Estos equipos son autónomos y su misión no se
superpone con la misión de otros equipos.

Ahora, Spotify tiene alrededor de 90 equipos, 600 desarrolladores y 5 oficinas de desarrollo en 2 continentes construyendo el mismo
producto, por lo que necesitan minimizar estas dependencias tanto como sea posible.

Lo que a Spotify realmente le gusta de los microservicios es que no tienen grandes fallos; los grandes servicios fallan, los servicios
pequeños fallan en menor implicación. La construcción de una arquitectura de microservicios permite a Spotify tener una gran cantidad de
servicios al mismo tiempo sin que los usuarios lo noten. Han construido su sistema suponiendo que los servicios pueden fallar todo el
tiempo, por lo que los servicios individuales que podrían estar fallando no tienen demasiada implicación total, por lo que no pueden arruinar la
experiencia de usar Spotify.

Walmart

Este es un buen ejemplo de lo que se debe hacer cuando la arquitectura antigua comienza a afectar negativamente a las empresas. Esta es
la pregunta multimillonaria que el Departamento de IT de Walmart Canadá tuvo que abordar después de que fallaran en Black Fridays durante
dos años seguidos. El problema era que no podía manejar 6 millones de páginas vistas por minuto e imposibilitaba el mantenimiento de
cualquier tipo de experiencia positiva para el usuario. Antes de aceptar los microservicios, Walmart tenía una arquitectura para internet de
2005, diseñada en computadoras de escritorio, computadoras portátiles y monolitos. La compañía decidió reforzar su viejo sistema heredado
en 2012, ya que no podía escalar para 6 millones de páginas vistas por minuto y estuvo inactivo la mayor parte del día durante los
momentos pico. Querían prepararse para el mundo de 2020, con 4 mil millones de personas conectadas, más de 25 millones de aplicaciones
disponibles. Entonces, Walmart Reply formó una arquitectura de microservicios con la intención de lograr cerca del 100% de disponibilidad
con costes razonables. La migración a microservicios realmente trajo resultados notables. (Novoseltseva, 2018, https://n9.cl/fwdel).

Preguntas de reflexión

¿Qué tipo de escalabilidad resultará más viable para una organización que cuenta con servidores locales para los servicios y el manejo de
datos?

En un proyecto que busque la escalabilidad, ¿cómo deberíamos estructurar un servicio de atención posventa de una empresa de ventas al
por mayor con servidores en la nube?

Si tuviéramos una red compuesta por un híbrido de diferentes tecnologías, con bases de datos locales basados en UNIX, y se nos pidiera
presentar un proyecto de mejora con microservicios para el manejo de esa información, ¿cómo podríamos llevarlo a cabo?

Si tuviéramos que desarrollar una estructura con microservicios, ¿cómo reduciríamos las desventajas que este modelo presenta,
buscando el menor impacto posible?

¿Es conveniente utilizar microservicios en una red local con diez equipos y un sistema administrativo de ventas al detalle?

Imaginemos que tenemos a nuestro cargo una flota de reparto sobre la que debemos expandir la comunicación con cada integrante para
mejorar el flujo de información compartida (entregas, recepciones, devoluciones, etc.). ¿Qué modelo deberíamos implementar?

C O NT I NU A R
Lección 4 de 7

Glosario

Término Descripción

Application programming interface. Es un conjunto de subrutinas, funciones y

API
procedimientos que ofrece una biblioteca que puede ser utilizada por otro software.

Fue una red de computadoras que creó el Departamento de Defensa de Estados

ARPANET
Unidos. Lo utilizaron como medio de comunicación entre distintas instituciones.

El estilo arquitectónico monolítico consiste en crear una aplicación autosuficiente que

contenga absolutamente toda la funcionalidad necesaria para realizar la tarea para la
cual fue diseñada, sin contar con dependencias externas que complementen su
Arquitectura monolítica
funcionalidad. En este sentido, sus componentes trabajan juntos, compartiendo los
mismos recursos y memoria. En pocas palabras, una aplicación monolítica es una
unidad cohesiva de código. (Blancarte, 2020, https://n9.cl/hvrlt).

La CI/CD es un método para distribuir aplicaciones a los clientes con frecuencia

mediante el uso de la automatización en las etapas del desarrollo de aplicaciones. Los
principales conceptos que se atribuyen a la CI/CD son la integración continua, la
CI/CD distribución continua y la implementación continua. La CI/CD es una solución para los
problemas que puede generar la integración del código nuevo a los equipos de
desarrollo y de operaciones (también conocida como integration hell). (Red Hat, 2021,
https://n9.cl/nagj8).

Interfaz de línea de comandos o interfaz de línea de órdenes. Es un método que

posibilita proveer instrucciones a algún programa a través de una línea de texto simple.
CLI
Hay que diferenciar entre: CLI, Shell y emulador de terminal. CLI consiste en un
método. Shell y emulador de terminal son programas informáticos.

Es un patrón que proporciona una interfaz abstracta a algún tipo de base de datos u
DAO (Data Access Object)
otro mecanismo de persistencia.

Docker es una plataforma de software que permite crear, probar e implementar

aplicaciones rápidamente. Docker empaqueta software en unidades estandarizadas
llamadas contenedores que incluyen todo lo necesario para que el software se ejecute,
Docker incluidas bibliotecas, herramientas de sistema, código y tiempo de ejecución. Con
Docker, puede implementar y ajustar la escala de aplicaciones rápidamente en
cualquier entorno con la certeza de saber que su código se ejecutará. (Amazon, 2021,
https://n9.cl/gnw5p).

DTO (Data Transfer Object) El patrón DTO tiene como finalidad de crear un objeto plano (POJO) con una serie de
 atributos que puedan ser enviados o recuperados del servidor en una sola invocación,
de tal forma que un DTO puede contener información de múltiples fuentes o tablas y
concentrarlas en una única clase simple. (Blancarte, 2020, https://n9.cl/hvrlt).

La Arquitectura dirigida por eventos, Event-driven architecture o EDA, es un patrón

EDA: arquitectura dirigida por
de arquitectura software que promueve la producción, detección, consumo de, y
eventos
reacción a eventos.

HTML, siglas en inglés de HyperText Markup Language (‘lenguaje de marcado de

HTML
hipertexto’), es el lenguaje de marcado para la elaboración de páginas web.

Hyper-V Hyper-V es un programa de virtualización de Microsoft.

Se considera una técnica de integración conocida como invocación implícita.

Los componentes son módulos cuyas interfaces proveen una colección de

procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera
usual, pero el componente también puede activar algunos de sus procedimientos con
los eventos del sistema. Esto hará que estos procedimientos sean invocados cuando
Invocación implícita
los eventos ocurren en tiempo de ejecución. Los generadores de eventos no saben
cuáles componentes se afectarán por el evento. Ejemplos de este estilo son los
sistemas de gestión de bases de datos cuando aseguran la consistencia de los datos,
las aplicaciones con interfaces de usuarios al separar la representación de los datos de
las aplicaciones que las administran. (Pérez de Ovalles y Mendoza, s. f.,
https://n9.cl/pnkz).

JSON (acrónimo de JavaScript Object Notation, «notación de objeto de JavaScript») es

JSON
un formato de texto sencillo para el intercambio de datos.

La ley de Conway es un enunciado formulado por el informático estadounidense Melvin

Conway en 1967. El adagio dice lo siguiente:

La ley de Conway
Las organizaciones dedicadas al diseño de sistemas están abocadas a producir
diseños que son copias de las estructuras de comunicación de dichas organizaciones.
Melvin Conway. (Garzas, 2015, https://n9.cl/1mxxy).

LAN Red de área local. Conforma una red de computadoras que abarca un área reducida.

Microservicios Los microservicios son tanto un estilo de arquitectura como un modo de programar
software. Con los microservicios, las aplicaciones se dividen en sus elementos más
pequeños e independientes entre sí. A diferencia del enfoque tradicional y monolítico de
las aplicaciones, en el que todo se compila en una sola pieza, los microservicios son
elementos independientes que funcionan en conjunto para llevar a cabo las mismas
tareas. Cada uno de esos elementos o procesos es un microservicio. Este enfoque de
desarrollo de software valora el nivel de detalle, la sencillez y la capacidad para
 compartir un proceso similar en varias aplicaciones. Es un elemento fundamental de la
optimización del desarrollo de aplicaciones hacia un modelo nativo de la nube. (Red
Hat, 2021, https://n9.cl/nagj8).

Middleware es software que se sitúa entre un sistema operativo y las aplicaciones

que se ejecutan en él. Básicamente, funciona como una capa de traducción oculta para
permitir la comunicación y la administración de datos en aplicaciones distribuidas. A
veces, se le denomina “plumbing” (tuberías), porque conecta dos aplicaciones para que
Middleware
se puedan pasar fácilmente datos y bases de datos por una “canalización”. El uso de
middleware permite a los usuarios hacer solicitudes como el envío de formularios en
un explorador web o permitir que un servidor web devuelva páginas web dinámicas en
función del perfil de un usuario. (Microsoft Azure, s. f., https://n9.cl/kom8z).

“Mosix es un paquete de software diseñado para añadir a Linux la capacidad de

procesamiento clúster. Incluye balanceo de carga, ushering y algoritmos de
MOSIX
optimización de E/S que responden a las variaciones del uso de los recursos del
clúster”. (Climent, 2016, p. 15).

“Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa

MVC los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres
componentes distintos”. (Universidad de Alicante, s. f., https://n9.cl/4jkh).

Es el espacio en el que convergen algunas de las conexiones de otros espacios reales

Nodos o abstractos que comparten sus mismas características y que a su vez también son
nodos.

En informática, NoSQL (a veces llamado “no solo SQL”) es una amplia clase de
NoSQL
sistemas de gestión de bases de datos que difieren del modelo clásico de SGBDR.

Una red peer-to-peer es una red de ordenadores en la que todos o algunos aspectos
P2P
funcionan sin clientes ni servidores fijos”.

El pipeline es una técnica para implementar simultaneidad entre instrucciones dentro

Pipeline
de un solo procesador.

Es un modelo de desarrollo de Software en donde el objetivo principal es la separación

Programación por capas
de las partes que conforman un sistema software o una arquitectura cliente-servidor.

RPC (Remote Procedure Es un programa que utiliza una computadora para proceder a ejecutar un código en
Call) otra.

Software development kit o SDK es una herramienta que permite crear aplicaciones
SDK
para sistemas concretos.

Es un conjunto de ordenadores que pueden atender las distintas necesidades de un

Servidor
cliente y, además, brinda respuestas certeras.

SOA (arquitectura orientada a Service Oriented Architecture es una arquitectura que trabaja para la orientación de
 servicios) servicios, su construcción y resultados.

Single-page application es una aplicación o sitio web que tiene como finalidad brindar
SPA
una experiencia fluida a los usuarios.

Structured Query Language es un lenguaje que se utiliza para administrar y recuperar

SQL
información de sistemas de gestión de bases de datos relacionales.

TCP/IP Es utilizado en comunicaciones en redes y provee conectividad de extremo a extremo.

Unix (registrado oficialmente como UNIX®) es un sistema operativo portable,

UNIX
multitarea y multiusuario.

Web Services - Business Process Execution Language, WS-BPEL es un lenguaje

WS-BPEL
que se utiliza para la composición de servicios web.

eXtensible Markup Language es un metalenguaje que permite definir lenguajes que

XML
fueron desarrollados por World Wide Web.

Hardware Componentes físicos de la computadora.

Software Conjunto de programas.

Grid computing Computación en malla.

Mashups Integración.

Mainframes Unidad central.

Subscriber Suscriptor.

Publisher Editor.

Servents Servicio.

Streaming Transmisión.

Grid Red.

Grid middleware Red de intercambio de información.

Backend Parte del desarrollo que se ocupa de la lógica del programa.

Logs Registros.

Containers Contenedores.

Debugging Depuración.

Mocks Objeto simulado.

Wearables Tecnología que se puede usar.

Kernel Núcleo.
 Host Anfitrión.

Front-end Desarrollo de la interfaz gráfica.

C O NT I NU A R
Lección 5 de 7

Video de habilidades

Verify to continue
We detected a high number of errors from your connection. To
continue, please confirm that you’re a human (and not a
spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

1. De acuerdo con las actividades sugeridas en el video, configuraremos el servicio de productos en el

microservicio de búsqueda.

2. Debemos confeccionar una interfaz llamada “CódigoProductoServicio”. Dicho recurso tendrá los miembros
abstractos para poder crear el servicio de productos.

3. Para cerrar la actividad, debemos corroborar la imagen del microservicio compilado.

Luego de hacer la actividad, verificá que hayas realizado correctamente las consignas. Descargá el ítem de
resolución a continuación:

Resolución M2.docx.pdf
219.2 KB

C O NT I NU A R
Lección 6 de 7

Referencias

Aguilera, P. y Gómez, E. (2014). Clustering y Grid computing en sistemas de alta disponibilidad para servicios web y mail. Universidad de las
Fuerzas Armadas “ESPE”. Recuperado de: https://www.researchgate.net/figure/Arquitectura-de-capas-en-Grid_fig2_276058088

Blancarte, O. (2020). Arquitectura Peer to Peer (P2P). Recuperado de: https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/p2p

Bersano, D. (2 de abril de 2020). ¿Cuándo usar microservicios? Repaso de las ventajas y desventajas. Recuperado de:
https://diegobersano.com.ar/2020/04/02/cuando-usar-microservicios-repaso-de-las-ventajas-y-desventajas/

Coulouris, G. (2001). Sistemas distribuidos. Conceptos y diseño. España: Pearson Educación.

David, L. (2002). Procesos y procesadores en sistemas distribuidos. Recuperado de: http://exa.unne.edu.ar/informatica/SO/SO10.htm

De la Torre, C. (2018). Microsoft eBook gratuito en español: “Microservicios .NET – Arquitectura para aplicaciones .NET contenerizadas”. Docker,
.NET Core, Kubernetes, Service Fabric, Azure. Recuperado de: https://devblogs.microsoft.com/cesardelatorre/microsoft-ebook-gratuito-en-espanol-
microservicios-net-arquitectura-para-aplicaciones-net-contenerizadas/

Departamento de Ciencia la Computación e Inteligencia Artificial (2008). Arquitectura orientada a servicios (SOA). Universidad de Alicante. Recuperado
de: http://www.jtech.ua.es/j2ee/2007-2008/restringido/int/sesion02-apuntes.html

Desde Linux (s. f.). Microservicios: arquitectura de software y frameworks de código abierto. Desde Linux. Recuperado de:
https://blog.desdelinux.net/microservicios-arquitectura-software-frameworks-codigo-abierto/

Digital Guide IONOS (9 de julio de 2019). Tutorial de Docker: instalar y gestionar la plataforma de contenedores. Recuperado de:
https://www.ionos.es/digitalguide/servidores/configuracion/tutorial-docker-instalacion-y-primeros-pasos/

Digital Guide IONOS (2 de marzo de 2020). Microservicios: más que la suma de sus partes. Recuperado de: https://www.ionos.es/digitalguide/paginas-
web/desarrollo-web/los-microservicios-en-el-desarrollo-de-aplicaciones/

Evaluando Software (9 de junio 2021). Qué es la arquitectura de microservicios. Evaluando Software. Recuperado de:
https://www.evaluandosoftware.com/que-es-la-arquitectura-de-microservicios/

Franco Martínez, E. D. (2015). Sistemas operativos II. México: Instituto Politécnico Nacional. Recuperado de:
https://www.academia.edu/34493387/1_12_y_13_Tipos_de_Sistemas_Distribuidos_e_Investigación_01

Garzas, J. (19 de junio de 2015). ¿Qué es eso de los microservicios? Javiergarzas.com. Recuperado de:
https://www.javiergarzas.com/2015/06/microservicios.html

Gómez, Y. (7 de julio de 2020). Arquitectura cliente servidor en la base de datos. Tecno Informatic. Recuperado de: https://tecnoinformatic.com/c-
informatica-basica/arquitectura-cliente-servidor-en-la-base-de-datos/
[Imagen sin título sobre clúster]. (s. f.). Recuperado de: https://sites.google.com/site/pagwebquestsistdistribelec1/beneficios-y-tipos-de-cluster

Marco de Desarrollo de la Junta de Andalucía (s. f.). Conceptos sobre escalabilidad. MADEJA. Recuperado de:
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/220

Microsoft (13 de enero de 2021). Diseño de una aplicación orientada a microservicios. Docs Microsoft. Recuperado de: https://docs.microsoft.com/es-
es/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design

Mora, L. (2008). ¿Qué es la computación grid? Recuperado de: https://apuntescomputacion.wordpress.com/2008/08/16/¿que-es-y-como-funciona-un-grid/

Novoseltseva, E. (18 de abril de 2018). Beneficios y ejemplos de la implementación de los microservicios. Apiumhub. Recuperado de:
https://apiumhub.com/es/tech-blog-barcelona/los-microservicios/

Pérez, M. S., Pérez, F. y Peña, J. M. (s. f.) Sistemas distribuidos. Recuperado de: http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/sd-
introduccion-1pp.pdf

PowerData (7 de septiembre de 2017). ¿Cuándo y cómo deberías utilizar una arquitectura de microservicios? PowerData. Recuperado de:
https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/cuando-y-como-deberias-utilizar-una-arquitectura-de-microservicios

Tanenbaum, A. S. y Van Steen, M. (2012). Sistemas distribuidos: principios y paradigmas. Madrid: Pearson.

Tokio New Technology School (2021). Todos los detalles de la escalabilidad en redes. Recuperado de: https://www.tokioschool.com/noticias/detalles-
escalabilidad-en-redes/

Wikipedia (s. f.). Arquitectura en microservicios. Recuperado de: https://es.wikipedia.org/wiki/Arquitectura_de_microservicios

C O NT I NU A R
Lección 7 de 7

Descarga la lectura

Gestión de configuración - Audiolectura M2.mp3

27 MB

Módulo 2.pdf
2.5 MB