1

IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

C.D.G. - 1
 2
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.- Introducción: La era de la Nube. 3

1.1.- La Industrialización del Software. 3
1.1.1.- Contextualización de RedHat OpenShift. 3
1.1.2.- Transición a una Filosofía Orientada a Servicios. 3
1.1.3.- Sistema de Entrega Continua. 4
1.2.- SOA: Service Oriented Architecture. 5
1.2.1.- Filosofía de Diseño. 5
1.2.1.1 El Diseño de Aplicaciones: Domain Driven Design and Strangle Pattern. 5
1.2.1.2 La Estructura del Servicio: Entidad-Controlador-Frontera. 6
1.2.1.2.1 Esquema de Roles: Entity-Control-Boundary Pattern. 6
1.2.1.2.2 Despliegue: FE, BE, Datos. 6
1.2.1.2.3 Tecnologías Java: J2EE, Microprofile, Quarkus. 6
1.2.1.3 Comunicaciones entre Servicios: API y Middleware. 6
1.2.1.3.1 Esquema de Roles: Enterprise Integration Patterns. 6
1.2.1.3.2 Despliegue: Sistemas de Mensajería. 6
1.2.1.3.3 Tecnologías: REST, SOAP. 6
1.2.2.- Metodología de Desarrollo. 7
1.2.2.1 La Metodología: Prácticas DevSecOps. 7
1.2.2.2 La Ciberseguridad: Modelo Zero-Trust. 8
1.3.- Plataforma de Desarrollo: Entorno de Ejecución de Servicios. 9
1.3.1.- El Ecosistema de Desarrollo Software. 9
1.3.2.- Modelo de Sistema: Capas de Operación y Articulación. 9
1.3.3.- Capas de Operación: Despliegue Aplicaciones. 10
1.3.4.- Capas de Articulación: Monitorización y Control. 11
1.4.- Estructura del Documento. 11
2.- Entorno de Ejecución de Servicios 12
2.1.- Modelos de Sistema e Infraestrutura 12
2.2.- El Sistema: Run-Time Distribuido de Contenedores. 12
2.3.- La Infraestructura: Kubernetes. 12
3.- Arquitectura: Esquema de Roles 13
3.1.- Plano de Control: Administración del Cluster. 13
3.2.- Plano de Operación: Distribución de Lógica y Datos de Aplicación. 13
4.- Funcionalidad: Build y Deploy 14
4.1.- Orquestación Contenedores: Despliegue de Pods. 14
4.2.- Build: Construcción de Imágenes de Contenedor 14
4.3.- Deploy: Despliegue de Contenedores 14
4.4.- Troubleshooting. 14
4.4.1.- Diagnóstico: Procedimiento. 14
4.4.2.- Resolución. 14
5.- Diseño: Administración del Cluster 15
5.1.- Plano de Control: Procedimientos Administrativos 15
5.2.- Plano de Operación: Políticas Almacenamiento y Red. 15
6.- Despliegue: Integración en la Plataforma. 16
6.1.- CI/CD: Aprovisionamiento Software. 16
6.2.- Service Mesh: Modelo de Cooperación entre Servicios. 16

C.D.G. - 2
 3
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.- INTRODUCCIÓN: LA ERA DE LA NUBE.

1.1.- LA INDUSTRIALIZACIÓN DEL SOFTWARE.
1.1.1.- CONTEXTUALIZACIÓN DE REDHAT OPENSHIFT.

l presente documento tiene como objetivo una descripción funcional

de RedHat OpenShift, la distribución de Kubernetes de RedHat. Kubernetes es

una estándar de facto para la gestión de racimos de ordenadores (o clústeres
en inglés) para desplegar aplicaciones orientadas a servicios. Esta
introducción es una contextualización de esta tecnología particular dentro del
diseño de aplicaciones, qué papel juega dentro y por qué es importante.

1.1.2.- TRANSICIÓN A UNA FILOSOFÍA ORIENTADA A SERVICIOS.

a imagen representa la evolución de las técnica de desarrollo software

en los últimos años. Esencialmente consiste en la industrialización de la

producción del software gracias a una programación orientada a
servicios, que reduce tiempos de entrega a la vez que mejora la calidad del
producto final.
os servicios son piezas software preconstruidas que conforman un

catálogo de componentes básicas reutilizables que pueden combinarse para

crear cualquier aplicación. En la electrónica, existe un catálogo de circuitos
integrados con los que crear cualquier dispositivo electrónico para
automoción, electrodomésticos, calderas, equipos de música, etc. Los
servicios vienen a ser esto mismo, pero para la producción de aplicaciones
software.

C.D.G. - 3
 4
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.1.3.- SISTEMA DE ENTREGA CONTINUA.

s necesario encapsular esos servicios en entornos aislados

(terminaciones de lógica), y levantar un sistema que permita su ensamblado

para crear cualquier aplicación final, es decir, un entorno de ejecución (o Run-
Time) de servicios. Los entornos de ejecución actuales despliegan más o
menos réplicas de cada servicio al son del tráfico de peticiones entrantes,
adaptándose así a cualquier carga de usuarios.
- Proceso de entrega continua… explicación.
a producción artesanal del software probablemente quede relegada a

las aplicaciones que van en los terminales de usuario (SmartPhones, Tablets,

etc.), adoptando esta filosofía más industrial para la lógica crítica de negocio
que reside en centros de datos.

C.D.G. - 4
 5
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.2.- SOA: SERVICE ORIENTED ARCHITECTURE.

1.2.1.- FILOSOFÍA DE DISEÑO.
1.2.1.1 EL DISEÑO DE APLICACIONES: DOMAIN DRIVEN DESIGN AND STRANGLE PATTERN.

as aplicaciones orientadas a Servicios siguen una filosofía de diseño

basada en dominios (DDD=Domain Driven Design) que consiste en dividir una

aplicación monolítica en dominios independientes, esto es, dominios que
admiten ser implementados por diferentes equipos de desarrollo de manera
totalmente autónoma, sin acoplo entre dominios. Si aparecen acoplamientos,
es mejor mantener una única aplicación monolítica, por los problemas
derivados de un diseño con responsabilidades compartidas por varios equipos
de desarrollo, y con difícil ensamblado final al ser muy complejo diagnosticar
y resolver incidencias… llegando a ser necesaria una reorganización completa
del código fuente.
a transición de una estructura monolítica a una orientada a Servicios,

se realiza siguiendo el “Strangle Pattern” que permite re-arquitecturar la

aplicación a la par que se van incorporando nuevas funcionalidades, es decir,
no detener la evolución del código fuente a raíz de su reorganización interna.

C.D.G. - 5
 6
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.2.1.2 LA ESTRUCTURA DEL SERVICIO: ENTIDAD-CONTROLADOR-FRONTERA.

1.2.1.2.1 ESQUEMA DE ROLES: ENTITY-CONTROL-BOUNDARY PATTERN.

ada dominio puede ser implementado por uno o varios servicios, cada

uno de ellos empleando las mejores tecnologías para resolver la su

funcionalidad específica. Pero en todos los casos suelen diseñarse siguiendo
el patrón de diseño “Entidad-Controlador-Frontera” para facilitar su
interconexión con el resto de servicios.

1.2.1.2.2 DESPLIEGUE: FE, BE, DATOS.

1.2.1.2.3 TECNOLOGÍAS JAVA: J2EE, MICROPROFILE, QUARKUS.

1.2.1.3 COMUNICACIONES ENTRE SERVICIOS: API Y MIDDLEWARE.

1.2.1.3.1 ESQUEMA DE ROLES: ENTERPRISE INTEGRATION PATTERNS.

1.2.1.3.2 DESPLIEGUE: SISTEMAS DE MENSAJERÍA.

1.2.1.3.3 TECNOLOGÍAS: REST, SOAP.

xisten varios modelos para los sistemas de ensamblado de esos

servicios, el más exitoso de ellos es el de Microservicios: servicios web

encapsulados en APIs (Application Programming Interfaces) y un modelo de
comunicaciones HTTP para su coordinación. Una de las claves de su éxito es
la enorme plataforma de desarrollo existente para aplicaciones web; además
un modelo HTTP de mensajería entre servicios más ligero y rápido que otras
opciones.

C.D.G. - 6
 7
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.2.2.- METODOLOGÍA DE DESARROLLO.

1.2.2.1 LA METODOLOGÍA: PRÁCTICAS DEVSECOPS.

l conjunto de prácticas para el desarrollo de este tipo de aplicaciones

orientadas a servicios reciben el nombre de DevSecOps (representados en la

imagen inferior), una evolución de la metodología Agile cuya finalidad es
agilizar el desarrollo software a la par de mejorar su calidad. El desarrollo de
las metodologías DevSecOps exceden los objetivos de este documento, que
se limita a representarlas en la imagen inferior.

C.D.G. - 7
 8
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.2.2.2 LA CIBERSEGURIDAD: MODELO ZERO-TRUST.

a abreviatura Sec en DevSecOps alude al hecho de incorporar dentro

de la metodología de diseño de aplicaciones estructuras de seguridad en lugar

de delegar la seguridad en los recipientes (los centros de datos) donde van a
desplegarse, estrategia que surge como respuesta ante la ubicuidad y
diversidad de las infraestructuras de despliegue modernas. Suele decirse que
se aplica un modelo ZeroTrust de ciberseguridad en sustitución al antiguo
modelo de Perímetro de Seguridad anclado a las localizaciones geográficas de
los centros de datos donde finalmente se ejecutan esas aplicaciones.

l modelo Zero-Trust se aplica durante las tres etapas del ciclo de vida

de las aplicaciones:

FASE OBJETIVO TECNOLOGÍAS

Diseño Servicio • Políticas de acceso a los
datos por petición de API.
Despliegue • Autenticación de Servicios: • Manifiesto de la Malla
Aplicación fabricantes de servicios de Servicios.
autorizados a desplegar. • Aporeto.
• Autorización de Servicios:
políticas de lista blanca por
servicio y cifrado de
conexiones entrantes.
Acceso al • cATO - Continous • Software Defined
Ecosistema de Authorization to Operate: Network que
Aplicaciones. políticas RBAC (Role Based automatiza el despliegue
Access Controlled) y contexto de políticas de acceso a
de aplicación de las políticas las aplicaciones para
crear un sistema de
contextos de
autorización.

C.D.G. - 8
 9
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.3.- PLATAFORMA DE DESARROLLO: ENTORNO DE

EJECUCIÓN DE SERVICIOS.
1.3.1.- EL ECOSISTEMA DE DESARROLLO SOFTWARE.

nte la falta de instituciones que elaboren sistemas de

recomendaciones de fabricación para plataformas de aplicaciones orientadas

a servicios, nos vemos obligados a tomar como referencia las más sólidas de
las que haya constancia, como sería la del Departamento de Defensa de
Estados Unidos (https://p1.dso.mil).

omo se aprecia en la imagen, el ensamblado de servicios lo realiza

una sola plataforma, que emplearán tanto consumidores como productores

de software, vendría a jugar el papel del sistema operativo de un ordenador.
Este apartado contextualiza el rol de Kubernetes dentro de estas plataformas.

1.3.2.- MODELO DE SISTEMA: CAPAS DE OPERACIÓN Y ARTICULACIÓN.

C.D.G. - 9
 10
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

1.3.3.- CAPAS DE OPERACIÓN: DESPLIEGUE APLICACIONES.

a imagen representa la estructura de capas de las plataformas

DevSecOps. Entre capa y capa una API (Application Programming Interface)

que encapsula toda su funcionalidad… comercialmente se identifica con la
terminación “as a Service” (IaaS, PaaS, CaaS, etc.). Estos nombres
comerciales son muy genéricos, por eso aquí se emplea como referencia la
nomenclatura de Platform One, en cuyo documento de diseño se especifica
qué prestaciones ha de ofrecer cada capa.

https://p1.dso.mil

https://www.cloud.mil/

C.D.G. - 10
 11
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

CAPA OBJETIVO TECNOLOGÍAS

L0 • Máquinas Físicas: despliegue y • Cisco Application Centric
Infraestructura control de una federación de racimos de Infrastructure (ACI)
ordenadores (o clústeres en inglés) • Juniper Apstra
desde una cabecera principal. • Arista CloudVision
• Nokia Data-Center Fabric
L1 • Terminaciones de Lógica: instanciar • RedHat OpenShift
Plataforma terminaciones de lógica (con sus • Novell Rancher
contenedores) donde desplegar • Canonical Charmed
servicios sobre la federación de Kubernetes
clústeres de la infraestructura L0. • VM Ware
L2 • Servicios: Aprovisionamiento y • Tekton, fachada para
CI/CD actualización continua de servicios cualquier sistema CI/CD.
desplegados en terminaciones de lógica • Jenkins.
gestionadas por la plataforma L1.
L3 • Aplicación: automatización del • RedHat OpenShift Service
Service Mesh despliegue de todas los servicios de una Mesh
aplicación, esto es, ensamblar los • Istio
servicios aprovisionados por la capa L2. • Traffik
L4 • Ecosistema Aplicaciones: sistema de • RedHat OpenShift
Serverless contextos para crear modelos de Serverless
cohesión en el diseño de aplicaciones • Knative
(similar a la inyección de dependencias
en J2EE), es decir, facilitar la creación
de ecosistemas de aplicaciones tal como
hace un servidor de aplicaciones.

1.3.4.- CAPAS DE ARTICULACIÓN: MONITORIZACIÓN Y CONTROL.

as capas de articulación monitorizan y controlan de manera

centralizada todo el ecosistema de aplicaciones orientadas a servicios. En la

imagen de la página anterior se representan con una doble flecha azul
etiquetada con “Continuous Monitoring”, queriendo indicar que son
transversales a todas las capas de operación, es decir, que coordinan las
operaciones a lo largo de toda la estructura de capas y así se articulan el
ecosistema de aplicaciones de una manera sencilla.

1.4.- ESTRUCTURA DEL DOCUMENTO.

Tal como se mencionó anteriormente, este documento es una
descripción funcional de la capa L1, el entorno de ejecución de contenedores
que se ha convertido en un estándar de facto: Kubernetes.

En la imagen infe

C.D.G. - 11
 12
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

2.- ENTORNO DE EJECUCIÓN DE SERVICIOS

2.1.- MODELOS DE SISTEMA E INFRAESTRUTURA

2.2.- EL SISTEMA: RUN-TIME DISTRIBUIDO DE

CONTENEDORES.

2.3.- LA INFRAESTRUCTURA: KUBERNETES.

DEF.:Kubernetes es un perfil de estrategias para implementar un
entorno de ejecución de servicios de tipo distribuido sobre un racimo
de ordenadores Linux. Este documento es un análisis funcional de
OpenShift, la distribución de Kubernetes de RedHat.

C.D.G. - 12
 13
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

3.- ARQUITECTURA: ESQUEMA DE ROLES

3.1.- PLANO DE CONTROL: ADMINISTRACIÓN DEL
CLUSTER.

3.2.- PLANO DE OPERACIÓN: DISTRIBUCIÓN DE

LÓGICA Y DATOS DE APLICACIÓN.

C.D.G. - 13
 14
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

4.- FUNCIONALIDAD: BUILD Y DEPLOY

4.1.- ORQUESTACIÓN CONTENEDORES: DESPLIEGUE DE
PODS.

4.2.- BUILD: CONSTRUCCIÓN DE IMÁGENES DE

CONTENEDOR

4.3.- DEPLOY: DESPLIEGUE DE CONTENEDORES

4.4.- TROUBLESHOOTING.

4.4.1.- DIAGNÓSTICO: PROCEDIMIENTO.

4.4.2.- RESOLUCIÓN.

C.D.G. - 14
 15
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

5.- DISEÑO: ADMINISTRACIÓN DEL CLUSTER

5.1.- PLANO DE CONTROL: PROCEDIMIENTOS

ADMINISTRATIVOS

5.2.- PLANO DE OPERACIÓN: POLÍTICAS

ALMACENAMIENTO Y RED.

C.D.G. - 15
 16
IFCD36: 20-631 – DEVOPS EN ARQUITECTURA DE MICROSERVICIOS

6.- DESPLIEGUE: INTEGRACIÓN EN LA

PLATAFORMA.
6.1.- CI/CD: APROVISIONAMIENTO SOFTWARE.

6.2.- SERVICE MESH: MODELO DE COOPERACIÓN ENTRE

SERVICIOS.

C.D.G. - 16