Clase 1 - Lectura

Created @February 3, 2021 7:33 PM

Class

Type

Materials

Reviewed

Microservicios
El término "Arquitectura de microservicio" ha surgido en los últimos
años para describir una forma particular de diseñar aplicaciones de
software como conjuntos de servicios de implementación
independiente.

El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola

aplicación como un conjunto de pequeños servicios, cada uno se ejecuta en su propio
proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP
Estilo monolítico → Una aplicación monolítica construida como una sola unidad

Las aplicaciones empresariales normalmente se componen de 3 partes:

Interfaz del lado del cliente (HTML, JS)

Base de datos

Aplicación del lado del servidor → esta app es un monolito: un único ejecutable
lógico. Cualquier cambio en el sistema implica la creación e implementación de una
nueva versión de la aplicación del lado del servidor

Clase 1 - Lectura 1
 El estilo arquitectónico de microservicios consiste en crear aplicaciones como conjuntos
de servicios. Los servicios se pueden implementar y escalar de forma independiente,
estos módulos pueden incluso ser escritos en distintos lenguajes t ser gestionados por
distintos equipos.

Características de una arquitectura microservicio

No todas las arquitecturas de microservicios tienen estas características, pero sí la
mayoría exhiben la mayoría de estas

Componentización a través de servicios

Un componente es una unidad de software que se puede

reemplazar y actualizar de forma independiente

Las arquitecturas de microservicios utilizan bibliotecas, pero su principal forma de

componente es dividiéndolas en servicios

Las bibliotecas son Los servicios son

Clase 1 - Lectura 2
 componentes que están
vinculados a un programa y se
llaman mediante llamadas a
funciones en memoria
componentes fuera de
proceso que se comunican
con un mecanismo como una
solicitud de servicio web o una
llamada a procedimiento
remoto

Una de las principales razones para usar los servicios como componentes es que los
servicios se pueden implementar de forma independiente
El uso de servicios como este tiene desventajas. Las llamadas remotas son más caras
que las llamadas en proceso, por lo que las API deben ser más generales y a menudo
esto es más complicado de usar.

Los servicios se asignan a los procesos en tiempo de ejecución. Sin embargo, un

servicio puede constar de varios procesos que siempre se desarrollarán e
implementarán juntos, como un proceso de aplicación y una base de datos que solo
ese servicio usará

Organizado en torno a las capacidades comerciales

Cuando se busca dividir una aplicación grande en partes, normalmente se dividen
grupos de UI, backend y base de daots. Cuando los equipos se separan, cualquier
cambio simple puede llevar a que un proyecto requiera tiempo y aprobación
presupuestaria. Un equipo inteligente optimizará en torno a esto.

Cualquier organización que diseñe un sistema (definido

ampliamente) producirá un diseño cuya estructura es una copia de
la estructura de comunicación de la organización.
- Melvin Conway, 1968

Clase 1 - Lectura 3
 Productos, no proyectos
La mayoría de los esfuerzos de desarrollo de aplicaciones que vemos utilizan un
modelo de proyecto: donde el objetivo es entregar una pieza de software que luego se
considera completada. Una vez finalizado, el software se entrega a una organización
de mantenimiento y el equipo del proyecto que lo construyó se disuelve.

Los defensores de los microservicios tienden a evitar este modelo, prefiriendo en

cambio la noción de que un equipo debe poseer un producto durante toda su vida útil

Endpoints inteligentes y pipelines tontos

La comunidad de microservicios favorece un enfoque alternativo: endpoints
inteligentes y pipelines tontos. Las aplicaciones creadas a partir de microservicios
tienen como objetivo ser lo más desacopladas y cohesivas posible.
Los dos protocolos que se utilizan con mayor frecuencia son:

HTTP request-response con API

Clase 1 - Lectura 4
 Mensajería ligera

El mayor problema al convertir un monolito en microservicios radica en cambiar el

patrón de comunicación.

Gobernanza descentralizada
Una de las consecuencias de la gobernanza centralizada es la tendencia a estandarizar
en plataformas tecnológicas únicas.

Quizás el apogeo de la gobernanza descentralizada es el espíritu de construirlo /

ejecutarlo popularizado por Amazon. Los equipos son responsables todo el tiempo de
todos los aspectos del software que crean

Gestión de datos descentralizada

Esto significa que el modelo conceptual del mundo diferirá entre sistemas. (Las
opciones no son las mismas para el encargado de ventas que para el gerente)

Los microservicios también descentralizan las decisiones de almacenamiento de datos.

Estos prefieren permitir que cada servicio administre su propia base de datos, ya sea
diferentes instancias de la misma tecnología de base de datos o sistemas de base de
datos completamente diferentes, un enfoque llamado Polyglot Persistence .

Clase 1 - Lectura 5
 La descentralización de la responsabilidad de los datos en los microservicios tiene
implicaciones para la gestión de actualizaciones. El enfoque común para lidiar con las
actualizaciones ha sido utilizar transacciones para garantizar la coherencia al actualizar
varios recursos. Este enfoque se usa a menudo dentro de los monolitos.

Automatización de infraestructura
Muchos de los productos o sistemas que se están construyendo con microservicios
están siendo construidos por equipos con amplia experiencia en Continuous Delivery y
su precursor, Continuous Integration . Los equipos que crean software de esta manera
hacen un uso extensivo de las técnicas de automatización de la infraestructura.
Otra área en la que vemos equipos que utilizan una amplia automatización de la
infraestructura es la gestión de microservicios en producción.

Diseño para el fracaso

Una consecuencia del uso de servicios como componentes es que las aplicaciones
deben diseñarse de modo que puedan tolerar la falla de los servicios. Cualquier
llamada de servicio podría fallar debido a la indisponibilidad del proveedor, el cliente
debe responder a esto de la manera más amable posible. Esta es una desventaja en

Clase 1 - Lectura 6
 comparación con un diseño monolítico, ya que introduce una complejidad adicional
para manejarlo.

Dado que los servicios pueden fallar en cualquier momento, es importante poder
detectar las fallas rápidamente y, si es posible, restaurar el servicio automáticamente.

Diseño evolutivo
Los profesionales de microservicios, por lo general, provienen de un fondo de diseño
evolutivo y ven la descomposición de servicios como una herramienta más para
permitir a los desarrolladores de aplicaciones controlar los cambios en su aplicación sin
ralentizar los cambios.

Cada vez que se intenta dividir un sistema de software en componentes, se enfrenta a

la decisión de cómo dividir las piezas. La propiedad clave de un componente es la
noción de reemplazo independiente y capacidad de actualización, lo que implica que se
buscan puntos en los que se pueda imaginar la reescritura de un componente sin
afectar a sus colaboradores.
Si se encuentra cambiando repetidamente dos servicios juntos, eso es una señal de
que deberían fusionarse, pues se desea mantener las cosas que cambian al mismo
tiempo en el mismo módulo.

Continuous delivery
Es una disciplina del desarrollo en la que se crea software de tal manera que este se
pueda lanzar a producción en cualquier momento.

Se hace continuous delivery cuando:

El software se puede implementar durante toso su ciclo de vida

El equipo prioriza mantener la implementación del software en lugar de desarrollar

nuevas funcionalidades

Cualquiera puede obtener retroalimentación rápida y automatizada sobre la

preparación de producción de sus sistemas cada vez que alguien les haga un
cambio.

Clase 1 - Lectura 7
 Puede realizar implementaciones de botón de cualquier versión del software en
cualquier entorno bajo demanda

C/D se logra integrando continuamente el software realizado por el equipo de

desarrollo, creando ejecutables y ejecutando pruebas automatizadas en esos
ejecutables para detectar problemas
Un caso es que un patrocinador empresarial podría solicitar que la versión de
desarrollo actual del software se pueda implementar en producción en cualquier
momento, y nadie se inmutará, y mucho menos entrará en pánico.
Para lograr esto se necesita:

Una relación de trabajo estrecha y colaborativa entre todos los involucrados en la

entrega (a menudo denominada DevOpsCulture)

Amplia automatización de todas las partes posibles del proceso de entrega, por lo
general utilizando un DeploymentPipeline

Continuous Integration
Es una práctica de desarrollo en la que los miembros de un equipo integran su trabajo
con frecuencia; por lo general, cada persona se integra al menos a diario, lo que
genera múltiples integraciones por día. Cada integración se verifica mediante una
compilación automatizada (incluida la prueba) para detectar errores de integración lo
más rápido posible.

Prácticas de integración continua

Mantener un repositorio de fuente única

Automatizar el build

Hacer que el build haga self-testing

Commits a la rama principal todos los días

Cada commit debe hacer build a la linea principal en una máquina de integración

Arreglar builds rotos inmediatamente

Clase 1 - Lectura 8
 Mantener el build rápido

Probar en un clon del entrono de producción

Hacer fácil para cualquiera acceder al último ejecutable

Todos pueden ver lo que está sucediendo

Automatizar la implementación

Beneficios de la integración continua

Reducción del riesgo

No elimina los errores, pero los hace más fáciles de encontrar y eliminar

Los proyectos tienen menos errores tanto en producción como en proceso

Es más fácil implementar un deployment frecuente

Cómo empezar?
Automatizar la compilación

Introducir pruebas automatizadas

Acelerar el commit build

Clase 1 - Lectura 9