HERRAMIENTAS DEVSECOPS

C.D.G. - 1
 HERRAMIENTAS DEVSECOPS

1.- Transición a DevSecOps. 3

1.1.- Incentivos para la Transición DevSecOps. 3
1.2.- Requerimientos: Una Renovación de la Red de Centros de Datos. 4
2.- Herramientas Ciberseguridad 5
2.1.- Responsabilidades en la Cadena de Suministro de Aplicaciones. 5
2.2.- Herramientas para cada Responsabilidad. 6
3.- Herramientas Automatización en la Producción de Aplicaciones. 7
3.1.- Responsabilidades en los Procesos de Fabricación de Aplicaciones. 9
3.2.- Herramientas para cada Responsabilidad: RedHat Code Ready Portafolio. 10
4.- Ciberseguridad: La Necesidad de una Nube Empresarial. 7
5.- Suministro de Medios de Producción. 11
5.1.- Las Plataformas de Entrega Continua. 11
5.2.- La Estructura de la Cadena de Valor. 12
5.3.- Mitigación de Riesgos. 13
6.- Bibliografía. 14

C.D.G. - 2
 HERRAMIENTAS DEVSECOPS

1.- TRANSICIÓN A DEVSECOPS.

1.1.- INCENTIVOS PARA LA TRANSICIÓN DEVSECOPS.
uatro pilares vertebran las motivaciones que llevaron a las Fuerzas
Aéreas de Defensa de Estados Unidos a realizar una modernización radical de
todo su sistema de producción de aplicaciones, que se intentan dilucidar aquí:
Blindar el sistema de armas más grande del mundo dentro del contexto del
inminente internet de las cosas adoptando los siguientes principios:
a. USUARIO - Eliminar la suplantación de identidad, al emplear un sistema
de credenciales basado en tarjetas SIM en lugar de contraseñas (en línea
de lo que viene proyectándose para el internet de las cosas)… similar a
una asignación nominal de una línea telefónica y que podrá llegar a ser
equiparable a un DNI electrónico… con una normativa en constante
evolución.
b. USUARIO - Sin simplicidad de uso, la seguridad no es posible: el empleo
de tarjetas SIM hace innecesarias muchas incómodas medidas
empleadas para impedir la suplantación de identidad (memorización de
muchas y complejas contraseñas, renovación frecuente de esas
contraseñas, un dispositivo asociado para autorizar transacciones, etc.).
c. PLATAFORMA - Entorno de ejecución de aplicaciones cerrado: las
plataformas DevSecOps son sistemas mucho más controlables al ser
Ciberseguridad gestionadas en su totalidad vía software.
d. PLATAFORMA - Microsegmentación reduce mucho la superficie y el tiempo
de exposición del plano de datos. Políticas de lista blanca por servicio
controla visibilidad entre servicios, minimizando la superficie de datos
expuesta. Además, cada frontal da acceso a un fragmento de esa
superficie de datos, y cada refresco de esos frontales renueva
propiedades de autenticación reduciendo su tiempo de exposición.
e. FACTORÍA - Análisis continuo del comportamiento de las aplicaciones:
gracias a especialistas en seguridad que continuamente estudian y
corrigen el comportamiento de las aplicaciones que producen las
factorías.
Software Defined Datacenter (Software Defined {Network & Storage &
Compute}): centros de datos gestionados por software reduce hasta un
60% los costes de mantenimiento de la maquinaria.

Reducción Costes
Velocidad de Entrega: La integración y automatización de todos los
procesos de una factoría garantizan poder afrontar los retos que impone
esta nueva sociedad de la información.
Entrega Continua
a. Garantiza una evolución futura en cada una de las piezas que componen
la solución final, para adaptarse a la vertiginosa evolución de estas
tecnologías de nube.
b. Descartar sistemas obsoletos, reduciendo costes de mantenimiento de
todo el legacy que va amontonándose en los centros de datos (ejm.:
abandonar las máquinas virtuales cuya complejidad de gestión implica
Solución de
elevados costes de mantenimiento al punto de impedir la escalabilidad
futuro
de las aplicaciones; sustituir por contenedores).
C.D.G. - 3
 HERRAMIENTAS DEVSECOPS

1.2.- REQUERIMIENTOS: UNA RENOVACIÓN DE LA RED

DE CENTROS DE DATOS.
a transición a una metodología DevSecOps impone una renovación de
los antiguos centros de datos por nuevos, por tres motivos principales:
1. Control centralizado de la red de Centros de Datos1: aumentar
criterios de seguridad y adaptarse al inminente internet de las cosas…
conducen a sistemas de difusión de aplicaciones y autenticación de
usuarios centralizados en todo el sistema de nube, tal como hacen las
operadoras de telefonía móvil con sus recursos de red a nivel nacional.
2. Diseño específico de cada Centro de Datos para un ‘Software
Defined Datacenter’2 que garantice evolución futura: la transición
a una computación controlada por software no puede hacerse sin un
diseño específico de los centros de datos (según su papel dentro de la
red, se instalará OpenStack sobre la maquinaria, o no quedará otra que
reemplazarla por una nueva)… eventualmente pueda integrarse los
sistemas de autenticación de la telefonía móvil que formarán parte de
la interfaz de infraestructura (en la líneas de cómo hace la industria del
automóvil3). Los operadores de telefonía móvil exponen su base de
usuarios a los proveedores de servicios de red a través de una interfaz
(OSA=Open Services Access), tal vez pueda emplearse este mismo
mecanismo en la capa L0 de los centros de datos, y mantener así un
único sistema centralizado de credenciales basado en tarjetas SIM para
todo el ecosistema de computación.
3. Certificación de cada Centro de Datos4 antes de su puesta en
funcionamiento: al tratarse de una estructura compacta (una
plataforma con todas las piezas integradas) son imprescindibles las
sinergias necesarias para lograr un eficaz andamiaje de pruebas de
integración capaz de evaluar y versionar la evolución de la plataforma.

btener retorno a una inversión de

estas características implica diversificar
los resultados. En otras palabras, certificar
plataformas para todos los posibles
escenarios (tiempo real en Telco Clouds,
persistencia para la Banca, etc.). Para ello
resulta vital una estandarización de las
interfaces de cada capa de la plataforma
para que admita cualquier implementación
interna… y así poder levantar una misma arquitectura con distintas
combinaciones tecnológicas, según estrategia a seguir en cada escenario.

1
Lt. Gen. Jack Shanahan (director del centro de inteligencia artificial del Departamento
de Defensa de Estados Unidos), “la falta de nube empresarial” https://fcw.com/it-
modernization/2020/05/pentagons-ai-chief-lack-of-enterprise-cloud-has-slowed-us-
down/196057/
2
ETSI, OSM Hackfest 9, “OSM Architecture and Installation, the Software Defined Datacenter”:
https://osm.etsi.org/wikipub/index.php/OSM9_Hackfest
3
Ciberseguridad, “iSIM, eSIM, XDR”: https://www.nokia.com/networks/cyber-
security/cybersecurity-tech-talk/
4
OPNFV, “Andamiaje Pruebas de Certificación Telco Clouds”: https://www.opnfv.org/
C.D.G. - 4
 HERRAMIENTAS DEVSECOPS

2.- HERRAMIENTAS CIBERSEGURIDAD

2.1.- RESPONSABILIDADES EN LA CADENA DE
SUMINISTRO DE APLICACIONES.
a seguridad informática no es posible abordarla sin un enfoque
holístico que involucre a todos los eslabones de la cadena de
suministro de aplicaciones. Este capítulo aspira a definir las
responsabilidades que tiene cada eslabón de la cadena. En el siguiente
capítulo, algunas propuestas de herramientas para cumplir con estas
responsabilidades:

• Acceso, despliegue de aplicaciones: plataforma de despliegue de

servicios y sistema de identidad para acceder al ecosistema de
aplicaciones, con la necesaria automatización extremo a extremo.
• Distribución, homologación de servicios: garantizar las condiciones
de despliegue de los servicios que, cual piezas de lego, se emplean para
componer aplicaciones finales… siendo suministrados y actualizados, de
manera continua, a través de un sistema de repositorios.
• Producción, factorías de aplicaciones: diseñar aplicaciones bajo
metodología DevSecOps que garantiza parámetros de estabilidad y
seguridad. Esto implica:
o Datos – Diseño de la Exposición de la Superficie de Datos: políticas de
acceso de cada llamada de la API al plano de datos.
o Lógica – Diseño Interfaces: Visualizar el sistema de dependencias
entre servicios, para mantener estables los contratos de
funcionalidades que ofrece cada servicio.
o Contenedor – Diseño del encapsulado: metodología de encapsulado y
securización en contenedores para su posterior distribución.
o Certificación de Artefactos – sistema de puntos de autorización en la
cadena de suministro software para acelerar las autorizaciones
necesarias de cada entrega a producción.

C.D.G. - 5
 HERRAMIENTAS DEVSECOPS

2.2.- HERRAMIENTAS PARA CADA RESPONSABILIDAD.

DISEÑO – Factoría de Aplicaciones

Certificaciones
Exposición Diseño APIs Construcción
antes de
Datos (Dependencias) Contenedor
Producción

Políticas de
Acceso a
Filogenética Metodología Continuous Authorization to
los Datos
de Servicios NSA & CISA Operate
( Visibilidad
FE -> BE)

ENTORNO DE EJECUCIÓN – Operadoras de Centros de Datos

Tarjeta SIM Condiciones Conexión µSegmentación

Secure Access
Service Edge Manifiesto Lenguaje de
IP eXtended (SASE) Malla Políticas Lista
Multimedia Detection and (Automatización Servicios Blanca por
Subsystem Response (XDR) extremo a extremo, (Sidecar Servicio
(AAA para (Escaneo Continuo Control central de Container, (Gestión de la
Tarjetas SIM) de Accesos) accesos a cada Monitorización Superficie de Datos
recurso de la nube Plataforma) Expuesta)
empresarial)
Metodología NSA &CISA, “Guía de securización Kubernetes” https://www.nsa.gov/Press-
Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/
Departamento de Defensa de Estados Unidos cATO, “Continuous Authorization to Operate”,
https://media.defense.gov/2022/Feb/03/2002932852/-1/-1/0/CONTINUOUS-AUTHORIZATION-TO-
OPERATE.PDF

C.D.G. - 6
 HERRAMIENTAS DEVSECOPS

3.- CIBERSEGURIDAD Y LA NUBE EMPRESARIAL .

al como se ilustra en la página anterior, la ciberseguridad depende de
dos factores: aplicaciones seguras de fábrica y entorno de ejecución seguro:
• Factorías - Diseño aplicaciones seguras, para ello han de
gestionar:
o El diseño del plano de lógica: APIs y dependencias.
o El diseño del datos de datos: políticas de acceso.
o El diseño de las comunicaciones internas de aplicación: políticas
de lista blanca entre servicios.
o Encapsulado de artefactos, las condiciones de instanciación.
• Operadora de Centro de Datos – El Entorno de Ejecución, las
operadoras deben contar con una nube empresarial5, es decir, la
capacidad de gestionar centralmente todos los recursos de una red de
centros de datos (tanto físicos como lógicos), con sus políticas de
acceso.

n la imagen se representa la simulación de una nube empresarial,

donde se aprecia su arquitectura básica:

• Capa Emulación: Infraestructura operativa de la red de centros de

datos. Aparecen dos capas claramente desacopladas:

o Capa L0: Software Defined Data Center... en Telco Cloud esta capa
recibe el nombre de VIM (Virtual Infrastructure Manager, Gestor de
la Infraestructura de Virtualización), se simula cada uno de los
centros de datos de la red con OpenStack metido en una máquina
virtual. En un entorno de computación cada centro de datos
consistiría en una red de clústeres kubernetes, que admite tres
posibles esquemas de montaje: máquinas físicas directamente,
sobre OpenStack o sobre un Network Operating System (Arista
CloudVision, Juniper Apstra, Cisco ACI, Nokia NOS).

5
Simulación de una nube empresarial:
https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1493-2
C.D.G. - 7
 HERRAMIENTAS DEVSECOPS

o Capa L1-L2-L3-L4: Plataforma de Entrega Continua... la simulación

prescinde de toda esta estructura, despliegan las funciones
virtualizadas de red directamente sobre Docker. En un entorno de
computación, consistiría en las configuraciones de los clústeres, un
sistema de entrega continua (como Jenkins) y un sistema de malla
de servicios (como Istio).

• Capa MANO: Articulación de la red de centros de datos. Aparecen dos

elementos principales:

o Capa MANO: controlador que distribuye las funciones virtualizadas

de red por toda la red de centros de datos. En computación, no existe
un equivalente, cada factoría de aplicaciones debe diseña un gestor
que permita distribuir sus aplicaciones por la nube empresarial desde
un único centro de control.

o Interfaz VIM: API a través de la cual el controlador MANO actúa sobre

cada centro de datos (representada por un punto blanco en cada
VIM). En un entorno de computación, se trata de un controlador de
área de servicio capaz de gestionar la red de clústeres de cada centro
de datos. Estas áreas de servicio se federan y se controlan desde una
cabecera principal, lo que recibe el nombre Universal Networking
Fabric (UNF).

a imagen inferior representa la UNF de Nokia Nuage Networks6 donde

se aprecia claramente la federación de controladores de área de servicio
gestionadas desde una cabecera principal, algo que recuerda mucho a la
arquitectura de la telefonía básica convencional7:

6
Nokia, The Universal Networking Fabric: https://onestore.nokia.com/asset/212701
7
OVH Installs Nuage SDN for OpenStack as a Service, https://convergedigest.com/ovh-installs-
nuage-sdn-for-openstack-as/
C.D.G. - 8
 HERRAMIENTAS DEVSECOPS

4.- HERRAMIENTAS AUTOMATIZACIÓN EN LA

PRODUCCIÓN DE APLICACIONES.
4.1.- RESPONSABILIDADES EN LOS PROCESOS DE
FABRICACIÓN DE APLICACIONES.
l punto de partida consistiría en normalizar la estructura de
procesos de una factoría8 DevSecOps a través de instituciones
europeas como el ETSI.
partir de una estructura de responsabilidades bien perfilada, surgen
las herramientas9 que cada proceso necesita para realizar satisfactoriamente
sus funciones. Las herramientas que cada factoría va a necesitar para cumplir
con esas funciones variarán según el tipo de aplicaciones que deba producir.
n la imagen, un resumen de las herramientas más comunes en cada
etapa del ciclo de vida de producción de aplicaciones.

a seguridad10 debe estar presente en cada etapa del ciclo de vida

DevOps que aplican las factorías software, sin embargo, debido a la necesidad
de un enfoque holístico de toda cadena de suministro, tanto la toma de
decisiones sobre medidas a aplicar en cada etapa por las distintas factorías,
como la evaluación del rendimiento de esas medidas de seguridad y los
correctivos asociados, se realizan en un proceso paralelo al de producción…
especializado en mejorar la seguridad informática de cada una de las
aplicaciones de manera independiente, y conjunta dentro del ecosistema de
aplicaciones donde vaya a integrarse.

8
IBM RedHat Secure Software Factory: http://redhatgov.io/workshops/secure_software_factory/
9
Michael Bryzek, Design Microservices the Right Way: https://youtu.be/j6ow-UemzBc
10
Nokia Berlin Security Centre, análisis y mejora continua de la seguridad en aplicaciones
informáticas: https://youtu.be/JIEoRChIus8
C.D.G. - 9
 HERRAMIENTAS DEVSECOPS

4.2.- HERRAMIENTAS PARA CADA RESPONSABILIDAD:

REDHAT CODE READY PORTAFOLIO.
n la imagen la Suite integrada para desarrollo de aplicaciones para
una metodología DevOps que está desarrollando RedHat, cuyo nombre
comercial es RedHat Code Ready11.

a suite no es completa, y requiere ser ampliada con otras

herramientas, especialmente validación de APIs , análisis de dependencias13
12

y microsegmentación. Esto implica un complejo proceso de evaluación hasta

lograr integrar satisfactoriamente todas estas herramientas en una solución
final de la que inferir una metodología única de trabajo para toda la factoría
(similar a Métrica v314 en administraciones del Estado):

• Red Hat CodeReady Workspaces & Eclipse Che: IDE basada

en Eclipse para trabajar con Kubernetes.
• Red Hat CodeReady Containers: despliegue local de clusteres
OpenShift.
• Odo: CLI para automatizar despliegues abstrayendo todos los
aspectos técnicos de Kubernetes. Puede integrarse en Eclipse.
• Red Hat OpenShift developer console.
• OpenShift Pipelines and Tekton for CI/CD.
• OpenShift Serverless and Knative.
• VS Code / IntelliJ: IDEs alternativos.
• Red Hat CodeReady analytics: análisis de dependencias.
• Red Hat CodeReady toolchain.

11
Developer Tools, RedHat Code Ready Roadmap:
https://developers.redhat.com/summit/2020/developer-tools-codeready-roadmap
12
API Builder: https://www.apibuilder.io/
13
Endor Labs, gestion de dependencias: https://www.endorlabs.com/
14
Métrica v3:
https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3
.html
C.D.G. - 10
 HERRAMIENTAS DEVSECOPS

5.- SUMINISTRO DE MEDIOS DE PRODUCCIÓN.

5.1.- LAS PLATAFORMAS DE ENTREGA CONTINUA.
as factorías de todas las industrias requieren de una sofisticada
maquinaria para poder producir aquello que deben suministrar a la sociedad.
Para el caso de factorías de aplicaciones, se trata de plataformas de entrega
continua que permitan desplegar aplicaciones orientadas a servicios.
n la computación se da la anomalía de que las factorías de aplicaciones
tienen la titánica labor de ensamblar sus propias plataformas DevSecOps, es
decir, su propia maquinaria de producción. Tarea que abordan sin guía alguna
y a partir de toda la tornillería que suministra el código abierto. Tanto
operadoras de centros de datos como las factorías de aplicaciones tienen dos
posibilidades: bien suscribirse a plataformas de grandes capacidades (como
Amazon); bien montar sus propias plataformas propietarias de bajo
rendimiento y dudosa viabilidad futura.
lquilar computación compartida por millones de usuarios (como
Amazon) para alojar lógica crítica de negocio no es una práctica segura. Así
que para reducir costes, las operadoras barajan complejos equilibrios entre
qué parte queda alojada en servidores externos (tipo Amazon), y qué parte
en plataforma privada más segura, pero de bajas prestaciones y alto coste.
l resultado final de estas estructuras híbridas, compuestas en base
retales no concebidos para integrarse en una estructura final (y en muchas
ocasiones, incompatibles entre sí y/o inviables a largo plazo) son plataformas
difíciles de operar y mantener, con serios problemas de seguridad y costes
desorbitados.
urge la necesidad de establecer una cadena de valor capaz de
suministrar este tipo de plataformas, tanto a factorías de
aplicaciones, como a operadoras de centros de datos, evitando todos
los riesgos de seguridad que implica alquilar computación, además de
simplificar la operativa de estas plataformas con diseños especializados,
reduciendo enormemente sus costes de operación y mantenimiento.

C.D.G. - 11
 HERRAMIENTAS DEVSECOPS

5.2.- LA ESTRUCTURA DE LA CADENA DE VALOR.

FASE OBJETIVO DESCRIPCIÓN

• Arquitectura - Modelo de Sistema: instituciones de

1
normalización, como ETSI, coordinan todo el ecosistema
productivo gracias a un único modelo de sistema para la
plataforma, tomando como punto de partida las
especificaciones de fabricación de las plataformas Cloud One
y Platform One del Departamento de Defensa de Estados
Arquitectura Unidos, disponibles al público en internet.
• Diseño - Factorías de Plataforma y Componentes: dos

2
piezas claramente diferenciadas:
o L0 - Software Defined Data-Center: la infraestructura
física de estas plataformas. Hay varias soluciones en el
mercado, entre ellas Nokia Datacenter Fabric, cuya
ventaja es la imposibilidad de vendor-lockin (las
operadoras necesitan instalar un mix de fabricantes en sus
Telco Clouds, además de OpenStack).
Diseño o L1-L2-L3-L4 - Plataforma de entrega continua: solo existe
en el mercado una solución que contemple las cuatro
capas de la entrega continua (Kubernetes, CI/CD, Malla de
Servicios y Serverless): RedHat OpenShift.
• Pruebas - Homologación de Plataforma: los andamiajes

3
de pruebas de certificación evalúan las diferentes opciones
tecnológicas, estableciendo modelos de infraestructura para
cada caso de uso que permitan versionar cada evolución.
OPNFV certifica núcleos de red 5G sobre Telco Clouds, siendo
Pruebas el instituto Fraunhofer su representante más destacado.
• Clientes – Sistema de Necesidades: la evolución depende
de las directrices provenientes del sistema de necesidades:
4 las factorías de aplicaciones y los operadores de centros de
datos de las distintas actividades económicas. Es necesaria la
colaboración de sectores estratégicos, como la banca, las
Despliegue telecomunicaciones o la aeronáutica.
C.D.G. - 12
 HERRAMIENTAS DEVSECOPS

5.3.- MITIGACIÓN DE RIESGOS.

mpresas individuales que han intentado resolver este desafío, como
Sun Microsystems, han desaparecido por el alto riesgo que implica una
inversión de estas características: el umbral hasta lograr un producto viable
comercialmente es muy alto, es fácil quedarse en el camino. Se trata de datos
críticos de negocio, con una natural inercia al cambio.
al vez sea este el motivo por el cual la inversión actual se dirige a
establecer distintos parques temáticos donde la publicidad masiva garantiza
retorno rápido a la inversión, en detrimento de inversiones en el legítimo uso
de la computación, que no es otro más que aliviar las tareas administrativas.
e torna vital, pues, localizar una metodología que sortee todas las
dificultades que entraña la producción de esta vital maquinaria. Un riesgo
similar al que asumió IBM a la hora de miniaturizar los primeros ordenadores,
pero que le otorgó un 90% de penetración de mercado.
ara este caso, se parte de una base ya establecida: el sistema de
normas elaborado por el Departamento de Defensa de Estados Unidos para
todas sus factorías de aplicaciones (Cloud One y Platform One). La superficie
de investigación es mucho menor respecto al caso de IBM y con expectativas
de venta de unidades a todo el mundo con alta tasa de penetración de
mercado, igual que la telefonía móvil global.
ocalizar una metodología que mitigue los riesgos implica analizar el
punto de vista de cada agente involucrado en este proceso productivo:
➢ Operadores de centros de datos – Las necesidades: debido a
responsabilizarse de datos críticos de negocio, solo invertirán en
adoptar nuevos sistemas si presentan ventajas muy contundentes que
compensen el esfuerzo de la adopción. Tal vez un proceso abierto
(similar al Java Community Process) sobre una infraestructura piloto,
donde las operadoras puedan evaluar los prototipos además de
manifestar sus necesidades para la mejora de los mismos, pueda
agilizar los tiempos de aceptación de producto.
➢ Ecosistema de fabricación – Los intereses: la computación es un
sector reciente, sin consolidar, como las telecomunicaciones o la
aeronáutica. En otras palabras, no hay una tradición de coordinación,
no existe un modelo que garantice beneficios superiores por el hecho
de cooperar que trabajando en competición. Sin dilucidar estos
mecanismos de coordinación, no hay garantía de que este ecosistema
crezca y se diversifique para una futura miniaturización de esos centros
de datos, la única vía efectiva para su democratización.
➢ Instituciones de normalización – Los costes: las operadoras de
centros de datos padecen una determinada sintomatología. Sin
embargo, sólo una visión de conjunto de todo el sistema productivo es
capaz de diagnosticar las causas de esos síntomas de manera certera,
lo que se traduce en minimizar los costes de resolución de las
necesidades planteadas, garantizando viabilidad futura a todo el
proceso productivo. Una financiación pública da la estabilidad necesaria
a este proceso de normalización de la estructura, reduciendo los riesgos
de una falta de modelo de gobierno.

C.D.G. - 13
 HERRAMIENTAS DEVSECOPS

6.- BIBLIOGRAFÍA.

ESTADO DEL ARTE

IBM Secure Software Factory http://redhatgov.io/workshops/secure_software_factory/
Thomal Erl, SOA: Analysis and Design https://www.arcitura.com/books/
for Services and Microservices
Nokia, The Universal Networking https://onestore.nokia.com/asset/212701
Fabric
MuleSoft Microservices https://youtu.be/SouNISAnXlo
Cloud LandScape https://landscape.cncf.io/
IDC, Cloud Centric Infrastructures https://info.idc.com/cloud-centric-digital-infrastructure-
infographic.html
David Cheriton: Arista/Apstra OS https://youtu.be/LA_LEdV8Cq4
Dimitri Stiliadis, arquitecto Nokia https://youtu.be/O7UrGrjnYV4?t=88
Nuage Networks
Arquitectura Microservicios https://youtu.be/j6ow-UemzBc

RETOS QUE ENFRENTAR

Stanford, estrategias para la http://web.stanford.edu/class/cs349d/
nube
Stanford, Zero Trust https://youtu.be/ooAPzzYkyaE?t=3593
Discussion
VM Ware, Rawlinson Ribera, https://youtu.be/dFySwm2bKTg?t=220
Fragmentación Datos
EUROPA, PROBLEMA SOBERANÍA DIGITAL
GAIA-X https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html
Oliver Wyman https://www.expansion.com/economia-
digital/2020/11/22/5fba2e48e5fdea66688b458c.html
PROYECTOS DE REFERENCIA
Data-Center OS https://cs.stanford.edu/~matei/papers/2011/hotcloud_datacenter_os.pdf
Platform One, Air Force https://p1.dso.mil/#/
Karl Isenberg, D2IQ https://www.youtube.com/watch?v=qku6ilFG5RM
Java Community Process https://www.jcp.org/en/home/index

TELCO CLOUD
OSM ETSI https://osm.etsi.org
OPNFV Pharos Lab https://www.opnfv.org/community/projects/pharos
Enterprise Cloud https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1493-2
Simulation
LÍNEAS DE INVESTIGACIÓN
Single Unix Specification https://es.wikipedia.org/wiki/Single_Unix_Specification
Constellation System https://en.wikipedia.org/wiki/Sun_Constellation_System
INCOSE, International Council https://www.incose.org/
for Systems Engineering
C.D.G. - 14