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
Lesson 1 of 7

Video de inmersión

01:44

CO N T I N UA R
Lesson 2 of 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, [Link]

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 N TA J A S D E S V E N TA J A S

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 N TA J A S D E S V E N TA J A S

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 /[Link] HTTP/1.1

Figura 2. Arquitectura cliente-servidor

 Fuente: Gómez, 2020, [Link]

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://[Link]/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://[Link]/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://[Link]/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, [Link]

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 distribuidos Sistemas electrónicos para el

masivos cuidado de la 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:
[Link]

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, [Link]

Figura 7. Tipo grid

Fuente: Mora, 2008, [Link]

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, [Link]

Arquitectura en capas para tipos grid

Figura 8. Grid

Fuente: Aguilera y Gómez, 2014, [Link]

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,
[Link]

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, [Link]

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:
[Link]
 Fuente: [Imagen sin título sobre escalabilidad]. (s. f.). Recuperado de:
[Link]

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., [Link]

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., [Link]

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é?

CO N T I N UA R
Lesson 3 of 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, [Link]

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, [Link]
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, [Link]

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, [Link]

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, [Link]

Figura 12. Microservicios

 Fuente: Garzas, 2015, [Link]

Figura 13. Microservicios

 Fuente: Bersano, 2020, [Link]

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, [Link]

V E N TA J A S D E S V E N TA J A S

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 N TA J A S D E S V E N TA J A S
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, [Link]

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,
[Link]

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, [Link]
 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,
[Link]

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,
[Link]
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, [Link]

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., [Link]

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

Docker

Figura 15. Docker

Fuente: Digital Guide IONOS, 2019, [Link]

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, [Link]

Figura 16. Aplicaciones .NET

Fuente: De la Torre, 2018, [Link]

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, [Link]

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., [Link]

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, [Link]

Amazon

En 2001, el sitio web minorista de [Link] 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, [Link]

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?
CO N T I N UA R
Lesson 4 of 7

Glosario

Término Descripción

Application programming interface. Es un

conjunto de subrutinas, funciones y procedimientos
API
que ofrece una biblioteca que puede ser utilizada
por otro software.

Fue una red de computadoras que creó el

Departamento de Defensa de Estados Unidos. Lo
ARPANET
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
Arquitectura contar con dependencias externas que
monolítica complementen su 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, [Link]
 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, [Link]

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
CLI línea de texto simple. 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

DAO (Data
abstracta a algún tipo de base de datos u otro
Access Object)
mecanismo de persistencia.

Docker 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, 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, [Link]

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
DTO (Data
una sola invocación, de tal forma que un DTO
Transfer Object)
puede contener información de múltiples fuentes o
tablas y concentrarlas en una única clase simple.
(Blancarte, 2020, [Link]

EDA: La Arquitectura dirigida por eventos, Event-driven

arquitectura architecture o EDA, es un patrón de arquitectura
dirigida por software que promueve la producción, detección,
eventos consumo de, y reacción a eventos.

HTML, siglas en inglés de HyperText Markup

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

Hyper-V es un programa de virtualización de

Hyper-V
Microsoft.

Invocación Se considera una técnica de integración conocida

implícita 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 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., [Link]

JSON (acrónimo de JavaScript Object Notation,

JSON «notación de objeto de JavaScript») es un formato
de texto sencillo para el intercambio de datos.

La ley de La ley de Conway es un enunciado formulado por

Conway el informático estadounidense Melvin Conway en
1967. El adagio dice lo siguiente:

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, [Link]

Red de área local. Conforma una red de

LAN
computadoras que abarca un área reducida.

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
Microservicios 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,
[Link]

Middleware 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 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.,
[Link]

“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
MOSIX
algoritmos de 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 los datos de
MVC una aplicación, la interfaz de usuario, y la lógica de
control en tres componentes distintos”.
(Universidad de Alicante, s. f., [Link]

Es el espacio en el que convergen algunas de las

conexiones de otros espacios reales o abstractos
Nodos
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 sistemas de gestión
NoSQL
de bases de datos que difieren del modelo clásico
de SGBDR.

Una red peer-to-peer es una red de ordenadores

P2P en la que todos o algunos aspectos funcionan sin
clientes ni servidores fijos”.

El pipeline es una técnica para implementar

Pipeline simultaneidad entre instrucciones dentro de un solo
procesador.

Es un modelo de desarrollo de Software en donde

Programación el objetivo principal es la separación de las partes
por capas que conforman un sistema software o una
arquitectura cliente-servidor.

RPC (Remote Es un programa que utiliza una computadora para

Procedure Call) proceder a ejecutar un código en otra.

Software development kit o SDK es una

SDK herramienta que permite crear aplicaciones para
sistemas concretos.

Es un conjunto de ordenadores que pueden

Servidor atender las distintas necesidades de un cliente y,
además, brinda respuestas certeras.

SOA Service Oriented Architecture es una

(arquitectura arquitectura que trabaja para la orientación de
 orientada a servicios, su construcción y resultados.
servicios)

Single-page application es una aplicación o sitio

SPA web que tiene como finalidad brindar una
experiencia fluida a los usuarios.

Structured Query Language es un lenguaje que

se utiliza para administrar y recuperar información
SQL
de sistemas de gestión de bases de datos
relacionales.

Es utilizado en comunicaciones en redes y provee

TCP/IP
conectividad de extremo a extremo.

Unix (registrado oficialmente como UNIX®) es un

UNIX sistema operativo portable, multitarea y
multiusuario.

Web Services - Business Process Execution

WS-BPEL Language, WS-BPEL es un lenguaje que se utiliza
para la composición de servicios web.

eXtensible Markup Language es un metalenguaje

XML que permite definir lenguajes que 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.

Parte del desarrollo que se ocupa de la lógica del

Backend
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.

CO N T I N UA R
Lesson 5 of 7

Video de habilidades

06:29

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 [Link]
219.2 KB

CO N T I N UA R
Lesson 6 of 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:
[Link]

Blancarte, O. (2020). Arquitectura Peer to Peer (P2P). Recuperado de:

[Link]

Bersano, D. (2 de abril de 2020). ¿Cuándo usar microservicios? Repaso de las ventajas y desventajas.
Recuperado de: [Link]
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:

[Link]

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: [Link]
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: [Link]
2008/restringido/int/[Link]
Desde Linux (s. f.). Microservicios: arquitectura de software y frameworks de código abierto. Desde
Linux. Recuperado de: [Link]
codigo-abierto/

Digital Guide IONOS (9 de julio de 2019). Tutorial de Docker: instalar y gestionar la plataforma de
contenedores. Recuperado de: [Link]
docker-instalacion-y-primeros-pasos/

Digital Guide IONOS (2 de marzo de 2020). Microservicios: más que la suma de sus partes.
Recuperado de: [Link]
desarrollo-de-aplicaciones/

Evaluando Software (9 de junio 2021). Qué es la arquitectura de microservicios. Evaluando Software.

Recuperado de: [Link]

Franco Martínez, E. D. (2015). Sistemas operativos II. México: Instituto Politécnico Nacional.
Recuperado de:
[Link]

Garzas, J. (19 de junio de 2015). ¿Qué es eso de los microservicios? [Link]. Recuperado
de: [Link]

Gómez, Y. (7 de julio de 2020). Arquitectura cliente servidor en la base de datos. Tecno Informatic.
Recuperado de: [Link]
base-de-datos/

[Imagen sin título sobre clúster]. (s. f.). Recuperado de:

[Link]

Marco de Desarrollo de la Junta de Andalucía (s. f.). Conceptos sobre escalabilidad. MADEJA.
Recuperado de: [Link]
Microsoft (13 de enero de 2021). Diseño de una aplicación orientada a microservicios. Docs
Microsoft. Recuperado de: [Link]
container-microservice-net-applications/microservice-application-design

Mora, L. (2008). ¿Qué es la computación grid? Recuperado de:

[Link]

Novoseltseva, E. (18 de abril de 2018). Beneficios y ejemplos de la implementación de los

microservicios. Apiumhub. Recuperado de: [Link]

microservicios/

Pérez, M. S., Pérez, F. y Peña, J. M. (s. f.) Sistemas distribuidos. Recuperado de:
[Link]

PowerData (7 de septiembre de 2017). ¿Cuándo y cómo deberías utilizar una arquitectura de

microservicios? PowerData. Recuperado de: [Link]

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: [Link]

Wikipedia (s. f.). Arquitectura en microservicios. Recuperado de:

[Link]

CO N T I N UA R
Lesson 7 of 7

Descarga la lectura

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

27 MB

Módulo [Link]
2.5 MB