Centro de Estudios TIC

www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

TEMA II.08. MODELO DE DESARROLLO DE APLICACIONES BASADO EN

CONTENEDORES Y MICROSERVICIOS. ARQUITECTURA Y SOLUCIONES.
DESPLIEGUE, MONITORIZACIÓN Y ESCALADO.

1
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

ÍNDICE
1. INTRODUCCIÓN A LOS MICROSERVICIOS Y PATRONES DE DISEÑO 4
1.1 ARQUITECTURAS BASADAS EN MICROSERVICIOS 4
1.2 ORIGEN DE LOS MICROSERVICIOS 5
1.3 PATRONES DE ARQUITECTURA Y DE DISEÑO 6
1.4 FRAMEWORKS 6
1.4.1 FRAMEWORKS JAVA 7
1.4.2 FRAMEWORKS OTROS LENGUAJES. 7
1.5 PERSISTENCIA. 7

2. MICROSERVICIOS. 8
2.1 MODELADO DE MICROSERVICIOS 10
2.2 GESTIÓN DE LA INFORMACIÓN 10
2.3 CÓMO INTEGRAR LOS MICROSERVICIOS 11
2.4 ORQUESTACIÓN VS COREOGRAFÍA. 11
2.5 TECNOLOGÍAS DE COMUNICACIÓN ENTRE MICROSERVICIOS.. 12
2.6 INTERFACES DE USUARIO. 12

3. DESPLIEGUE. 13
3.1 INTEGRACIÓN CONTINUA (CONTINUOUS INTEGRATION CI). 13
3.2 ENTREGA CONTINUA (CONTINUOUS DELIVERY CD). 14
3.2.1 ARTIFACTS. 14
3.3 DESPLIEGUE DE MICROSERVICIOS. 15
3.4 CONTENEDORES. 15
3.4.1 DOCKERS. 15
3.4.2 KUBERNETES. 15
3.4.3 ARQUITECTURA KUBERNETES. 16

4. MONITORIZACIÓN. 18
4.1 PATRONES DE MONITORIZACIÓN. 18

2
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

5. SEGURIDAD Y RESILIENCIA. 18
5.1 SEGURIDAD. 19
5.2 RESILIENCIA. 21

6. CONCLUSIÓN 22

3
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

1. INTRODUCCIÓN A LOS MICROSERVICIOS Y PATRONES DE DISEÑO

1.1 ARQUITECTURAS BASADAS EN MICROSERVICIOS

Para poder introducir el concepto de “microservicio” tenemos que detenernos en analizar de

dónde proviene la palabra, en concreto, su origen lo tenemos del concepto de “Servicio Web”.
Éstos lo definimos como un conjunto de tecnologías capaces de intercambiar datos entre sí con
independencia de las arquitecturas donde se encuentran desplegadas, cuyo intercambio está
basado en el protocolo HTTP.
El concepto que subyace a la arquitectura basada en microservicios es el de dividir la
funcionalidad de las aplicaciones en servicios de modo que éstos sean lo más independientes
entre sí, que sean fácilmente mantenibles e incluso reemplazables.
Fundamentalmente encontramos los microservicios en la capa del “negocio”, si atendemos al
modelo MVC (modelo vista controlador), es por ello que seguimos necesitando en las
aplicaciones una capa de interfaz que sea capaz de mostrar los resultados generados por la
ejecución de los microservicios.

Veamos ahora cómo podemos dar una definición de microservicio. Existen discrepancias en el
ámbito del desarrollo del software en cuanto a cómo definirlos. Si atendemos a la definición
dada por Martin Fowler y James Lewis, los definen como “estilo arquitectural en el que
múltiples servicios, cada uno ejecutándose de manera individual y desplegados de la forma más
automatizada posible, se comunican entre sí mediante mecanismos ligeros, fundamentalmente
un API basado en HTTP”.
Otra duda que nos surge es delimitar el “tamaño” que debe de tener un microservicio. Aquí
según Sam Newman lo marca como “todo servicio web funcional que pueda ser reescrito por
un desarrollador en menos de dos semanas”.
Lo que sí que debe de cumplir un microservicio es :
● Debe desplegarse de manera individual.
● Independencia del resto de microservicios, en la medida que sea posible.
● Capaz de comunicarse con el resto.
● Escalable de manera individual.

4
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

En resumen, la idea que subyace al concepto de microservicio está muy cercana a la

arquitectura de servicios SOA (Services Oriented Architecture, es más, podríamos decir que los
microservicios pueden ser una evolución natural de SOA.

1.2 ORIGEN DE LOS MICROSERVICIOS

Aunque el origen de la arquitectura SOA tuvo muchos problemas (falta de conocimiento de los
desarrolladores y ausencia de tecnologías para su implantación), podemos decir que los
microservicios guardan ciertas similitudes con ella, y ahora si que está más maduras las
tecnologías que los implementan, así como el conocimiento de los desarrolladores.
Aunque el origen está relacionado, presentan diferencias importantes entre ambas:
● En SOA los servicios se exponen a través de contratos, mientras que en microservicios es
mediante API RestFul.
● El SOA los servicios se despliegan manualmente, mientras que en microservicios se hace
de manera automatizada.
En ambos casos encontramos el concepto de arquitectura software, que nos brinda un
mecanismo para poder realizar un análisis temprano para garantizar que el diseño cumplirá con
los objetivos del sistema en cuanto a funcionalidad, rendimiento, seguridad, etc.
Cuando hablamos de un sistema, éste se compone de una serie de módulos con propiedades y
relaciones entre ellos. Las propiedades pueden ser internas o externas. Las internas definen al
módulo mientras que las externas son las que definen los “contratos” y acuerdos que nos
permiten la relación entre los módulos. Estos contratos son vitales para lograr la perfecta
integración de los módulos.
Es fundamental dividir la funcionalidad del sistema en diferentes módulos y definir sus
propiedades y cómo se relacionarán entre sí.

Si observamos la imagen vemos que se ha dividido la funcionalidad del sistemas en varios

microservicios, las propiedades de éstos, las tablas , colecciones de datos. Etc se definen en las
bases de datos, mientras que cada microservicio debe de contener un documento API en el que
se especifique las entradas, salidas, el lenguaje en el que está definido,… Para finalizar tenemos
una interfaz de usuario encargada de presentar la información transformada a los usuarios.

5
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

1.3 PATRONES DE ARQUITECTURA Y DE DISEÑO

A la hora de diseñar una arquitectura software se puede optar por una estrategia desde “cero”
o bien “adaptar” una solución ya existente.
En el caso que nos ocupa, los patrones de diseño, el enfoque es el segundo, adaptar una
solución ya existente, precisamente ese el concepto detrás del patrón de diseño.
Los patrones son un mecanismo de reutilización ante funcionalidades comunes.
Podemos encontrarnos:
● Patrones creacionales. Para la creación de nuevos objetos.
● Patrones estructurales. Facilitan la Modelización del software.
● Patrones de comportamiento. Para gestionar relaciones entre objetos.
En el caso de los patrones de arquitectura, éstos no nos dicen como deben de estar escritos los
componentes, pero si nos dicen como deben de estar organizados y cuales de ellos son
importantes para la aplicación. Al igual que los patrones de diseño, nos aportan soluciones a
problemas comunes de una forma reutilizable.
Los más usados son:
● Programación por capas.
● Cliente-Servidor.
● Arquitectura SOA (orientada a servicios).
● Arquitectura de microservicios.
● Pipeline.
● Arquitectura en Pizarra.
● Dirigida por Eventos.
● Peer-to-Peer.
Para concluir este apartado, indicar que siempre que se desarrolla un servicio web es necesario
el establecer un protocolo de comunicación. Los más importantes son SOAP y REST.

1.4 FRAMEWORKS

Otra opción para no tener que desarrollar una arquitectura software desde cero es acudir a un
framework.
El framework nos brinda estructuras de software ya implementadas que facilitan al
desarrollador la creación de un proyecto nuevo.

6
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Existen framework para casi cualquier lenguaje de programación.

1.4.1 FRAMEWORKS JAVA

Aquí tenemos como ejemplos:

● Spring.
● Struts. Basado en arquitectura Modelo Vista Controlador.
o En 2004 surge como evolución Stripes (más ligero y eficiente).
En el caso de framework específicos para microservicios, tenemos :
● Spring Boot.
● Cricket. Contiene un servidor HTTP incorporado. Serialización JSON automática.
● Dropwizard. Arquitectura por capas.
● Eclipse Vert.X Microservices. Admite varios lenguajes.
● Helidon. Oracle.
● Molecular (NodeJS Microservices framework). Muy popular al estar relacionado con
NodeJS.
● Micronaut.
● AxonIQ.
● GoMicro.
● ….

1.4.2 FRAMEWORKS OTROS LENGUAJES.

Aquí vamos a presentar los más representativos de otros lenguajes de programación :

● Angular, implementado en Typescript y orientado al desarrollo del front-end de
aplicaciones web. Propiedad de Google pero de código libre.
● React, propiedad de Facebook, para el desarrollo de front-end.
● Ionic, nació en el 2013, para el desarrollo de aplicaciones híbridas (aplicaciones móviles
diseñadas en un lenguaje de programación web) junto con el framework (Cordova) que
permite adaptar la vista web a cualquier dispositivo móvil.

1.5 PERSISTENCIA.

Dentro de la definición de una arquitectura software es muy importante la persistencia de la

información que se maneja.

7
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Por ello es necesario el disponer de elementos que nos brinden esta funcionalidad. Estamos por
tanto hablando de las bases de datos.
Aquí podemos optar por los modelos clásicos basados en bases de datos relacionales (Oracle,
SQL Server, etc) o bien optar por modelos de bases de datos no relacionales. (MongoDB, Redis,
Elasticsearch y Cassandra)

8
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

2. MICROSERVICIOS.

Atendiendo a su definición, nos encontramos ante algo pequeño e independiente que funciona
junto con otros (microservicios) para lograr la funcionalidad del sistema.
De esto podemos concretar que debe de ser algo que no sea grande y que funcione bien, a
diferencia de los tradicionales sistemas monolíticos.
Las arquitecturas de microservicios resultan útiles si para desarrollar una aplicación, dividimos
ésta en pequeños servicios, los cuales se ejecutan de manera independiente y se comunican
entre sí a través de protocolos sencillos, en este caso HTTP.
Un aspecto importante es saber dimensionar el tamaño adecuado que tiene que tener un
microservicio. Según Newman debería ser “algo que se pueda ser escrito (lenguaje de
programación) en dos semanas”. Esto es más o menos unas 80 horas de desarrollo.
Otra característica importante es que debe de ser independiente. Esto es, debe de funcionar de
forma aislada donde se ejecute y no debe de seguir el modelo de “empaquetamiento de varios
servicios” en la misma máquina.
Para lograr esta independencia y que, a su vez, colaboren entre ellos, nos basamos en la
comunicación mediante llamadas de red.
Con esta característica, la independencia, logramos que un microservicio pueda ser sustituido
por otro sin que afecte al resto, y sobre todo a la funcionalidad del sistema.
Ventajas :
● Heterogeneidad tecnológica.
● Resiliencia.
● Escalado.
● Facilidad de despliegue.
● Facilidad organizativa. (equipos de desarrollo más pequeños y más productivos).
● Reutilización.
● Facilidad de sustitución.
Desventajas :
● Pruebas más complicadas.
● Mayor complejidad de gestión al existir más servicios.
● Complejidad de integración.
● Alto consumo de memoria.
● Proceso de fragmentación de la funcionalidad de una aplicación puede ser complejo.

9
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

2.1 MODELADO DE MICROSERVICIOS

A la hora de diseñar microservicios deberemos atender a :

● Bajo acoplamiento.

Un cambio en el servicio no debe de requerir el cambio en otro.

● Alta cohesión.
Toda la funcionalidad semejante debe de estar en el mismo microservicio.
● Delimitación del contexto.
Cualquier funcionalidad consiste en múltiples contextos acotados.

● Herramientas adecuadas para el desarrollo (framework y tecnologías).

● Asegurar los microservicios. Las seguridad es fundamental.
o Contenedor, red, servidor virtual,….
o API Gateway.
o Autorización y Autenticación.
o Gestión de Passwords.
o

2.2 GESTIÓN DE LA INFORMACIÓN

Una duda que nos surge es a la hora de manejar la persistencia en una arquitectura de
microservicios, ya que el objetivo de la arquitectura es de mantener la máxima autonomía de
éstos.
Hay varias implementaciones:
● Tener una base de datos por cada microservicio.
● Base de datos compartida por varios microservicios.
● Command query responsibility segregation. (vista de solo lectura expuesta por la bbdd
de un microservicio que es usada por otro.)

Nos encontramos ante el verdadero problema que aparece a la hora de diseñar aplicaciones
basadas en microservicios, y es el de lograr particionar una base de datos monolítica.

Posibles soluciones a esta necesidad de particionamiento son :

● Romper las relaciones a nivel de claves secundarias.
● Tablas de datos compartidos.

10
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

● Fronteras Transaccionales.

2.3 CÓMO INTEGRAR LOS MICROSERVICIOS

En este apartado vamos a analizar cómo realizamos la comunicación entre los distintos
microservicios que conforman una aplicación.
Como premisa común vamos a imponer que las API de comunicaciones sean los más
independientes posibles de la tecnología.
Opciones :
● Acceso a los datos.
o Base de datos compartida. Múltiples problemas.
● Formas de comunicación.
o Asincronía vs Sincronía.
● Formas de invocación.
o Directa.

o API Gateway (Kong, NGINX, Ocelot, Goku, AWS, Azure).

2.4 ORQUESTACIÓN VS COREOGRAFÍA.

En este apartado vamos a analizar cómo realizamos la comunicación entre los distintos
microservicios que conforman una aplicación.
Conforme la funcionalidad de las aplicaciones se hace más compleja, aparece un nuevo
problema, y es el de administrar los procesos de negocio que se prestan a través de servicios
externos.
Además cuando nos encontramos ante el problema de las transacciones que llevan están
compuestas por acciones llevadas a cabo por cada microservicio en su propia base de datos, se
hace necesario el garantizar la coherencia de dicha transacción en este escenario. Esta situación
se denomina patrón SAGA que nos soluciona este problema de coherencia de transacciones
entre microservicios.
Tenemos tres formas de organizar la comunicación entre microservicios:
● Coreografía, que permite que cada microservicio funcione de forma independiente, y se
comuniquen a través de eventos.

11
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

● Acoplamiento estrecho, cada microservicio llama a su vez a otros microservicios para

coordinarse.
● Orquestación, se crea una nueva capa, orquestación, encargada de la coordinación entre
los microservicios.

Ventajas de la orquestación son facilidad de mantenimiento y procesamiento síncrono, mientras

que adolece de dependencias de servicios acoplados, así como ser un nodo central de fallos. En
cuanto a la coreografía, presenta como beneficios, procesamiento rápido sin dependencias de
nodos centralizadores, y es más fácil agregar nuevos servicios, así como actualizarlos.
Decir que existe un modelo híbrido donde aparece un servicio centralizado (orquestación)
dentro de cada servicio y un enfoque coreográfico para comunicarse con otros servicios a través
de eventos.

2.5 TECNOLOGÍAS DE COMUNICACIÓN ENTRE MICROSERVICIOS..

A continuación vamos a enumerar diferentes tecnologías utilizadas para la comunicación entre

microservicios :
● RPC (Remote Procedure Calls).
● REST (REpresentational State Transfer). Soporta sobre HTTP (XML, XPATH, JSON).
o RESTFul : framework para crear servicios web.
● GrapQL. Evolución de REST. Acceso estructurado a los recursos basado en comandos
HTTP bien definidos. Proporciona un lenguaje de consulta : CRUD.

Poor último indicar que necesitamos gestionar como nuestros microservicios emiten eventos y
como los que los deben de consumir son avisados de ellos. Para esto tenemos dos enfoques,
utilizar HTTP como propagador de eventos a través de ATOM, o bien utilizar los message
brokers, un ejemplo de ellos es RabbitMQ a través de una API de suscripciones.

2.6 INTERFACES DE USUARIO.

Para finalizar este recorrido por la arquitectura de microservicios, una vez analizada la parte de
lógica de negocio, comunicación y persistencia, nos queda analizar la parte de comunicación
con el usuario final y como le mostramos la información procesada por los microservicios.

12
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Se ha producido una evolución de las viejas interfaces web pesadas a las modernas interfaces
para dispositivos móviles que requieren una mayor agilidad, pero también se nos plantean una
serie de limitaciones (resoluciones, capacidad de procesado, etc).
Para dar solución a ello tenemos distintos patrones o modelos para el desarrollo de estas
interfaces de usuario :
● Patrón API Composition / Monolithic UI / Client-side UI Composition : la API habla
directamente a través de JSON o XML con los servicios expuestos.
● Patrón Fragmented UI Composition / Server Side UI Composition : los propios servicios
proporcionan parte de la interfaz de usuario.
● Patrón Backends for Frontends. API Gateway : como solución al masivo intercambio de
mensajes entre servicios, exponiendo un punto de conexión agregado. Éste se encarga
de realizar las llamadas necesarias a los microservicios del back-end.

3. DESPLIEGUE.

El despliegue de una aplicación monolítica es un proceso relativamente sencillo frente al

despliegue de una arquitectura de microservicios con múltiples servicios con sus dependencias
entre ellos.
Aparecen soluciones para facilitar este trabajo, en concreto, la integración y entregas continuas.
Vamos por tanto a describir cada una de ellas.

3.1 INTEGRACIÓN CONTINUA (CONTINUOUS INTEGRATION CI).

Su fin es que todo el equipo involucrado en el desarrollo de la arquitectura esté correctamente

sincronizado. Para ello hay que asegurar que cada nuevo desarrollo de código nuevo se integra
perfectamente con el código viejo. Esto lo realiza el servidor de integración continua a través de
la detección del código nuevo, revisándolo y comprobando su integración con el resto del
código ya integrado.

Martin Fowler define la integración continua de la siguiente manera: La integración continua es

una práctica de desarrollo de software, es decir, los miembros de desarrollo de equipos a menudo

13
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

integran su trabajo, generalmente cada miembro se integra al menos una vez al día, lo que significa
que pueden ocurrir integraciones múltiples todos los días
Durante este proceso se crearán artefactos para probar los microservicios nuevos y sus
llamadas.
Existen varios modelos:
● Un único árbol de fuentes con todo el código, donde las diferentes compilaciones se
asignen a ramas de este árbol.
● El enfoque más usado es el tener una compilación de integración continua por cada
microservicio.

3.2 ENTREGA CONTINUA (CONTINUOUS DELIVERY CD).

La entrega continua es un enfoque mediante el cual obtenemos retroalimentación constante

sobre la preparación de nuestro software candidato al paso a producción.
Hay que modelar todos los procesos involucrados en el envío de nuestro software desde las
primeras pruebas hasta el paso a producción, y poder identificar cualquier versión dada del
software validada para su paso a producción. Para ello en la entrega continua hacemos uso del
concepto de “Pipeline” para modelar cada una de las fases por la que tiene que pasar el
software.

3.2.1 ARTIFACTS.

Nos encontramos con este concepto cuando estamos ante herramientas de automatización de
integración continua como Maven, Jenkins o Ant.
Son elementos que facilitan el desarrollo y puesta en producción de los elementos que
programamos.
Ejemplos :
● Ruby tiene gems.
● Java tiene JAR y WAR.
● Python tiene eggs.

14
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Desde el punto de vista de los microservicios puede que por si solo un artefacto no sea
suficiente y necesitamos otro software para implementar y lanzar nuestros artefactos. Ejemplos
de este tipo de herramientas son Puppet y Chef.

3.3 DESPLIEGUE DE MICROSERVICIOS.

En este punto nos planteamos cuantos microservicios tendremos por cada máquina, teniendo
en cuenta que actualmente no hablamos ya de host puros en entornos virtualizados.
Por tanto podremos tener :
● Varios microservicios por host.
● Contenedores de aplicaciones.
● Un solo microservicio por host.
● PaaS. Serverless : Heroku, AWS o Azure.

3.4 CONTENEDORES.

Los contenedores nos aportan un espacio de proceso independiente en el que conviven otros
procesos.

3.4.1 DOCKERS.

Plataforma construida sobre LXC (Linux Containers). Se encarga de gran parte del trabajo
alrededor de la manipulación de contenedores. En esta plataforma se crean e implementan
aplicaciones. La plataforma administra el aprovisionamiento de contenedores, controla
problemas inherentes a la comunicación, y permite almacenar y versionar las aplicaciones.

3.4.2 KUBERNETES.

Dockers en sí mismo es solamente un PaaS. Pero esto solo no nos vale y necesitamos
herramientas que nos ayuden a administrar servicios en varias instancias de Dockers y en varios
host, por tanto necesitamos otra capa.
Con Dockers podemos manejar contenedores de manera independiente, pero como lo hacemos
con varios a la vez, la respuesta es Kubernetes.
Kubernetes presenta una arquitectura de un nodo maestro y varios nodos esclavos que el
usuario puede definir.

15
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Nos aporta:
● Despliegues automatizados.
● Descubrimiento de nuevos servicios y balanceo de carga.
● Propias direcciones IP´s y nombre único DNS.
● Gestionar el almacenamiento.
● Administración de la configuración de los servicios.
● Empaquetado automático de contenedores.
● Escalado horizontal de recursos.
● Self-healing : reinicia los contenedores que fallan, reemplaza los contenedores cuando
los nodos mueren, …..
● Kubernetes Pods : objeto más pequeño y básico desplegable. Unidad básica de ejecución que
representa procesos corriendo en el cluster.
● Nodos : Un pod se ejecuta siempre en un nodo. Un nodo es una máquina de trabajo que
puede ser una máquina virtual o física, dependerá del cluster. Cada nodo es administrado por
un maestro.
● Cada nodo de kubernetes ejecuta :
o Kubelet : proceso responsable entre el maestro y el nodo, administra los pods.
o Conteiner runtime : desempaquetar el contenedor y ejecutar la aplicación.
● Cluster de Kubernetes : formado por :
o Master : coordina el cluster.
o Nodos : workers que ejecutan aplicaciones.
● ReplicaSet : regla definida mediante un Deployment y se usa para garantizar un número
específico de pods iguales.
● Deployment : conjunto de directrices que se dan en el cluster para que tanto los ReplicaSet
como los pods cumplan con lo que diga el Deployment.
● Servicio de Kubernetes : manera abstracta de exponer la aplicación definida en el Deployment
como un grupo de Pods.

3.4.3 ARQUITECTURA KUBERNETES.

Un cluster de kubernetes está formado por el nodo Master y los nodos Worker (o nodos).

Elementos de la arquitectura :

16
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

● Plugins de red: Permiten la conexión entre pods de nodos diferentes y la integración de

soluciones de red diferentes (overlay, L3, …​)

● etcd: una base de datos clave-valor donde Kubernetes guarda todos los datos del cluster.

● API server: Componente del Master que expone la API de Kubernetes. Es el front-end del
plano de control de Kubernetes.

● Control Manager: Se encarga de comprobar si el estado deseado coincide con la realidad

(p.e. número de réplicas)

● Scheduler: Componente del master que observa qué pods se han creado nuevos y no
tienen nodo asignado, y les selecciona un nodo donde se puedan ejecutar.

● kubelet: Agente que se se ejecuta en cada nodo worker del cluster y que asegura que los
nodos están en ejecución y sanos. kubelet no gestiona los pods que no han sido creados
por Kubernetes.

● kube-proxy: Mantiene las reglas de networking en los nodos para los pods que se
ejecutan en él de acuerdo con las especificaciones de los manifiestos.

● cAdvisor: Recoge datos de uso de los contenedores.

● Plano de control o Control plane: Nivel de orquestación de contenedores que expone la

API para definir, desplegar y gestionar el ciclo de vida de los contenedores.

● Plano de datos o Data Plane: Nivel que proporciona los recursos, como CPU, memoria,
red y almacenamiento, para que los pods se puedan ejecutar y conectar a la red.

17
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

4. MONITORIZACIÓN.

En el mundo de la aplicación monolítica, tenemos un lugar muy obvio para comenzar nuestras
investigaciones. ¿Sitio web lento? Es el monolito. ¿Sitio web que da errores extraños? Es el
monolito. CPU al 100%? monolito.
Ahora tenemos varios microservicios para supervisar, varios archivos de registro para
inspeccionar y varios lugares donde la latencia de red podría causar problemas. Tenemos que
dar sentido a lo que de otra manera podría ser un desorden caótico.

4.1 PATRONES DE MONITORIZACIÓN.

• Un único servicio en un único servidor

Es lo más simple, monitorizamos cpu, memoria, también los logs del servidor, y finalmente la
aplicación en sí mismo.
• Un único servicio en múltiples servidores
Aquí tenemos varias copias del mismo servicio en diferentes servidores. Esto nos obliga a
monitorizar lo mismo que antes pero en varios servidores. E investigar a partir de ahí si todos
los servidores tienen el problema o solamente uno, etc. Es decir necesitamos información
agregada del servicio pero también la posibilidad de hacer un drill-down bajar a una instancia
en concreto.
• Múltiples Servicios en Múltiples Servidores.
Aquí el problema anterior se complica exponencialmente. La solución es la recopilación y
agregación central de todo, desde los registros hasta las métricas de la aplicación.

Ahora presentaremos algunas herramientas que nos permiten la gestión de Logs :

● Elasticsearch. Basado en JSON. Motor de búsqueda y análisis.
● Logstash. Herramienta ETL para refinar información para Elasticsaearch.
● Kibana. Frontend de visualización para Elasticsearch.

18
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

5. SEGURIDAD Y RESILIENCIA.

5.1 SEGURIDAD.

Para las aplicaciones monolíticas, es habitual que la propia aplicación controle la autenticación y
la autorización. Sin embargo, cuando se trata de sistemas distribuidos, tenemos que pensar en
esquemas más avanzados. No queremos que todos los servicios tengan que iniciar sesión por
separado para diferentes sistemas, utilizando un nombre de usuario y una contraseña diferentes
para cada uno. El objetivo es tener una identidad única que podamos autenticar una vez.

● SAML Single Sign-On

SAML, que es la implementación dominante, y OpenID Connect proporcionan capacidades en

esta área. Cuando una entidad intenta tener acceso a un recurso (como una interfaz basada en
web), se le indica que se autentique con un proveedor de identidades. Este puede pedirle que
proporcione un nombre de usuario y una contraseña. Una vez que el proveedor de identidades
está convencido de que la entidad de seguridad se ha autenticado, proporciona información al
proveedor de servicios, lo que le permite decidir si desea concederle acceso al recurso.
Este proveedor de identidades podría ser un sistema hospedado externamente o algo dentro de
su propia organización. Google, por ejemplo, proporciona un proveedor de identidades de
OpenID Connect. Para las empresas, sin embargo, es común tener su propio proveedor de
identidad, como LDAP o Active Directory.

● Single Sign-On Gateway

Dentro de una configuración de microservicios, cada servicio podría decidir controlar la

redirección y el protocolo de enlace con el proveedor de identidades. Pero en lugar de hacer
que cada servicio administre el protocolo de enlace con su proveedor de identidades, puede
usar una puerta de enlace para actuar como un proxy, entre sus servicios y el mundo exterior.

● Autenticación y autorización de un servicio a otro servicio

19
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Hasta este punto hemos estado usando el término entidad para describir cualquier cosa que
pueda autenticarse y estar autorizado para hacer cosas, Pero, ¿qué pasa con los programas, u
otros servicios, que se autentican entre sí?
Nuestra primera opción podría ser simplemente asumir que cualquier llamada a un servicio
realizada desde dentro de nuestro perímetro es de confianza. Dependiendo de la sensibilidad
de los datos, esto podría ser suficiente.
Para esto podríamos utilizar simplemente autenticación básica HTTP permite que un cliente
envíe un nombre de usuario y una contraseña en un encabezado HTTP estándar. A continuación,
el servidor puede comprobar estos detalles y confirmar que el cliente puede acceder al servicio.
Podríamos mejorar la seguridad con HTTPS e incluir por lo tanto la seguridad asociada a los
certificados SSL.
Si ya se está utilizando SAML u OpenID Connect también podría usarlo para las interacciones
entre servicios Si está usando una SSO Gateway , deberá enrutar todo el tráfico dentro de la red
a través del SSO Gateway. Esta aproximación centralizada hace muy cómoda la revocación de
credenciales a los servicios si están resultan comprometidas.
Otro enfoque es hacer uso de las capacidades de Seguridad de la capa de transporte (TLS), el
sucesor de SSL, en forma de certificados de cliente. Aquí, cada cliente tiene un certificado X.509
instalado que se utiliza para establecer un vínculo entre el cliente y el servidor. Pero la gestión
de tanto certificado (1 por microservicio) puede llegar a ser muy compleja.
Un enfoque alternativo, utilizado ampliamente por las API de S3 de Amazon para AWS y en
partes de la especificación OAuth, es utilizar hash-based messaging code (HMAC) para firmar la
solicitud. Con HMAC, se aplica un algoritmo hash al cuerpo de la solicitud del cuerpo junto con
una clave privada y el hash resultante se envía junto con la solicitud. A continuación, el servidor
utiliza su propia copia de la clave privada y el cuerpo de la solicitud para volver a crear el hash y
verificar así la autenticidad de la petición.
Api Keys
Todas las API públicas de servicios como Twitter, Google, Flickr y AWS hacen uso de API keys que
permiten a un servicio identificar quién está realizando una llamada y poner límites a lo que
pueden hacer.
A nivel de autenticación microservicio a microservicio algunos sistemas utilizan una única clave
de API que se comparte y utilizan un enfoque similar a HMAC. Un enfoque más común es
utilizar un par de claves pública y privada. La administración de las claves se hace de forma
centralizada, del mismo modo que administraríamos las identidades de las personas y el SSO
GateWay se utiliza también mucho.
El uso de API keys es muy sencillo a nivel de programación en comparación con el manejo de un
protocolo de enlace SAML.

20
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Tratar errores inesperados es uno de los problemas más difíciles de resolver, especialmente en
un sistema distribuido. Gran parte del código que los desarrolladores escriben implica controlar
las excepciones, y aquí también es donde se dedica más tiempo a las pruebas. El problema es
más complejo que escribir código para controlar los errores. ¿Qué ocurre cuando se produce un
error en la máquina en que se ejecuta el microservicio? No solo es necesario detectar este error
de microservicio (un gran problema de por sí), sino también contar con algo que reinicie su
microservicio.

Un microservicio debe ser resistente a errores y poder reiniciarse a menudo en otra máquina a
efectos de disponibilidad. Esta resistencia también se refiere al estado que se guardó en nombre
del microservicio, en los casos en que el estado se puede recuperar a partir del microservicio, y
al hecho de si el microservicio puede reiniciarse correctamente. En otras palabras, debe haber
resistencia en la capacidad de proceso (el proceso puede reiniciarse en cualquier momento), así
como en el estado o los datos (sin pérdida de datos y que se mantenga la consistencia de los
datos).

5.2 RESILIENCIA.

Tratar errores inesperados es uno de los problemas más difíciles de resolver, especialmente en
un sistema distribuido. Gran parte del código que los desarrolladores escriben implica controlar
las excepciones, y aquí también es donde se dedica más tiempo a las pruebas. El problema es
más complejo que escribir código para controlar los errores. ¿Qué ocurre cuando se produce un
error en la máquina en que se ejecuta el microservicio? No solo es necesario detectar este error
de microservicio (un gran problema de por sí), sino también contar con algo que reinicie su
microservicio.

Un microservicio debe ser resistente a errores y poder reiniciarse a menudo en otra máquina a
efectos de disponibilidad. Esta resistencia también se refiere al estado que se guardó en nombre
del microservicio, en los casos en que el estado se puede recuperar a partir del microservicio, y
al hecho de si el microservicio puede reiniciarse correctamente. En otras palabras, debe haber
resistencia en la capacidad de proceso (el proceso puede reiniciarse en cualquier momento), así
como en el estado o los datos (sin pérdida de datos y que se mantenga la consistencia de los
datos).

21
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Medidas de seguridad a nivel de arquitectura

Hay algunos patrones arquitectónicos, que podemos usar para asegurarnos de que, si algo sale
mal, no cause efectos desagradables en cascada.
Una parte esencial de la creación de un sistema resiliente, especialmente cuando la
funcionalidad se distribuye en varios microservicios diferentes que pueden funcionar o caerse
es la capacidad de degradar la funcionalidad de forma segura. Es decir, elegir que se puede
quedar levantado o que hay que parar para asegurar un funcionamiento mínimo.

TIMEOUTS
Los tiempos de espera son importantes para el rendimiento de los sistemas. ¿Cuánto tiempo
puedo esperar antes de poder considerar que un sistema aguas abajo está realmente caído?

Son necesarios tiempos de espera para cualquier llamada y registrar cuándo se producen estos
tiempos de espera que sucede y, si es necesario, cambiarlos.

CIRCUIT BREAKERS
Cuando una aplicación empieza a recibir respuestas con retrasos de los otros sistemas (servicios
web externos, base de datos, etc.. ) , antes de devolver finalmente un error, el sistema se va
degradando poco a poco y se van teniendo cada vez más retrasos hasta que se colapsa.

6. CONCLUSIÓN

En este tema hemos abordado el concepto de los microservicios como nuevo ejemplo de
arquitectura de desarrollo de aplicaciones en contrapartida a los modelos clásicos de
aplicaciones monolíticas o cliente-servidor.
Se ha presentado el modelo de desarrollo de esta arquitectura a través del uso de patrones de
arquitectura que hace el no tener que desarrollar “desde cero” una aplicación y basándose en el
concepto de reutilización poder aprovechar servicios ya implementados para realizar nuevas
aplicaciones.
Se ha analizado el concepto de microservicio y lo que ello significa, a saber, algo autónomo y
que realiza una función muy especializada dentro de la arquitectura, para en colaboración con
otros microservicios llevar a cabo funcionalidades más complejas. Ello aporta como beneficios
el poder escalar la arquitectura de manera sencilla y además el mantenimiento de estos
microservicios es más sencillo.

22
Centro de Estudios TIC
www.cetic.es
Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

Se han analizado unos conceptos claves de este tipo de arquitecturas como son la integración
continua y los despliegues automatizados.
También hemos visto el concepto de contenedor, ejemplarizado en Dockers, y cómo estos
artefactos dotan a los microservicios un ecosistema para su ejecución sin tener que preocuparse
de los recursos físicos de las máquinas.
Posteriormente hemos visto cómo articular una red de contenedores en una arquitectura, en
concreto hemos presentado Kubernetes, y sus características principales.
Por último, hemos analizado los aspectos de seguridad y monitorización de este tipo de
arquitecturas ya que debido a su carácter distribuido y acceso fundamentalmente desde la web
hacen necesario gestionarlos correctamente.

23