Las tres oraciones resumen el documento de la siguiente manera: 1) El documento habla sobre la transformación a una operación Cloud Native y cómo muchas empresas aún no pueden implementar nuevas funciones rápidamente a pesar de instalar herramientas como Kubernetes. 2) Explica que a menudo hay una relación disfuncional entre TI y el negocio, con procesos rígidos como ITIL que no permiten mejora continua. 3) Introduce el concepto de los tres horizontes para equilibrar recursos entre el negocio actual y futuro, y cómo

1. The Lord of Cloud Native – Part 2
The Two or Four Towers

2. Luciano Moreira
• Chief DevSecOps strategy Officer en Cloud Legion
• Embajador del DevOps Institute
• Master en Ciberseguridad por la Universidad Camilo José Cela.
• Seleccionado como uno de los "50 Influential DevSecOps Professionals“
• MVP - Most Valuable Professional Microsoft Azure y Developer Technologies
• Co-Fundador y Tribe lider de DevSecOps Argentina y Latam,
• Presidente del capítulo argentino de la CSA Cloud Security Alliance
• Primer Auditor CSA STAR certificado en la región SOLA
• Auditor Líder ISO 27001:2013, 27018, 27017, 22301, 20000, 25000 y 9001
• Elegido Cybersecurity Consultant of the Year en los premios Cybersecurity Excellence Awards del 2016 al 2019,
• Instructor acreditado de los cursos (DevSecOps Foudation, DevSecOps Enginier y DevSecOps Master Professional)
Luciano_m_cruz lucianomoreiradacruz

3. Introduccion
Operación Cloud Native
Los 3 Horizontes
SRE y Cloud Native
Contenido
SLs…
!!! smeagol is
good !!!
Las 4 torres de la operación

4. Hechos (No Pasaras)
Con demasiada frecuencia estamos luchando en la lucha inmediata (los orcos), en las
batallas de hoy con un gran equipo, pero contra todo pronóstico, sentimos que podemos
perseverar y salir victoriosos. Esto no es suficiente. Tenemos que tener una visión más
amplia de nuestra situación, ahora más que nunca, ya que todo lo que nos rodea está
cambiando muy rápido.
El Balrog de nuestra organización necesita ser reconocido, temido y enfrentado. Al igual que
Gandalf, como líderes, debemos proteger a nuestros equipos y enfrentar al enemigo de
frente: "¡No pasarás!" Dejar caer al enemigo en un barranco no es suficiente: debemos
perseguirlo, luchar contra él, luchar hasta que desaparezca.
Al enfrentar la verdad de nuestra situación y lidiar con ella, nuestros equipos, como Frodo,
pueden pensar que estamos locos o sentir que nos están perdiendo, pero debemos ir a
donde debemos ir. Debemos luchar contra lo que debemos luchar. En palabras de
Sutherland, “Adaptarse o morir”.

5. El cambio está llegando, estes listo o no
A medida que las organizaciones cambian sus estrategias de aplicaciones para adoptar el mundo
nativo de la nube, el propósito de la nube pasa de ahorrar dinero a entregar y administrar
aplicaciones.
Cloud Native es sobre cultura y no solo contenedores.
Previamente…
Como vimos en la primer parte de esta trilogía
The Lord of Cloud Native - The Concentric
Rings of the Cloud-Native Enterprise
https://youtu.be/ugPf27soo6M

6. Cloud Native Assessment y Roadmap
Diseño, Preparación y planificación
Construcción de
capacidades / cultura
Onboarding
/Migración de
Aplicaciones
Automatización de la
instalación y la
supervisión
Soporte/ SRE
Pensar
2 a 6 semanas
Diseñar
3 a 4 meses
Construir
3 a 12 meses
Ejecutar
N Meses
Transformación
Cloud Native
Previamente…

7. Introducción
Muchas empresas hoy en día todavía miran
los modelos de operación exitosos de
empresas como Amazon, Apple, Netflix y
Spotify con algo de envidia
Otras se apresuran a comenzar su
transformación Cloud Native, solo para
descubrir que no se puede lograr una
transformación exitosa y sostenible
simplemente creando algunas diapositivas de
PowerPoint increíbles 
Algunas forman tribu, Células, Squads
organizacionales o adoptan SAFe ( Scaled
Agile Framework) y modelos similares sin
lograr el objetivo esperado
Instalan software de última generación como
Kubernetes . Pero descubren que todavía no
pueden implementar nuevas funciones de
forma rápida y sencilla.
Sienten que estan dando vueltas en el mismo lugar sin avanzar hacia el objetivo

8. Introducción
Como Gandalf el Gris todas las empresas deben tener historias de innovación
brillantes, una posición en el mercado y una misión que las ha mantenido en
marcha a lo largo del tiempo. Pero, especialmente en tiempos de
incertidumbre como los actuales (Por fuego y agua, entre calabozo y
montanas), van a notar que han perdido cosas en el camino.
Muchas de las grandes empresas no invirtieron constantemente en innovación,
como prescribe el modelo de los tres horizontes de McKinsey, y perdieron su
capacidad de reaccionar rápidamente a las cambiantes demandas de los
clientes en un panorama siempre cambiante.
En estas organizaciones, la comunicación entre el departamento de TI y el
resto de la empresa sólo se produce a través de las solicitudes de servicio, y
esas solicitudes sólo fluyen en una dirección, hacia los ingenieros.
Vemos en muchas empresas un marco de operaciones de TI (ITIL) bien
intencionado y ampliamente utilizado de forma incorrecta, creando en su lugar
procesos rígidos y engorrosos como el mismo Balrog de Morgoth, y no de
mejora continua y retroalimentación.

9. Introducción
Al trabajar solo a través de
tickets, TI se trata como un
contratista externo. Esto hace que
sea fácil subcontratar las
funciones de TI en tiempos de
reducción de costos
Algunas empresas
crean laboratorios de innovación,
pero siguen sin poder ofrecer
ninguna idea nueva y oportuna a sus
clientes.
Es fácil culpar a la cultura de la
empresa, a los problemas de
organización, a la rigidez de los
procesos, a la aversión al riesgo o a
la burocracia.
Pero el verdadero reto es que que
estos problemas tienen su origen en
una relación, a veces incluso tóxica,
entre las TI y "el negocio", y los
muros que se han creado para
eliminar la necesidad de hablar el
uno con el otro. entre sí. ( El muro
de compliance)

10. !!!my precious humor !!!

11. tres horizontes
Uno de los elementos más difíciles de abordar para las
empresas a la hora de definir su estrategia de innovación
(Cloud Native) y crecimiento es de qué manera encontrar
un punto de equilibrio entre los recursos que se dedican a
los negocios del presente y los que se deben invertir en
los negocios del futuro.
Esto esconde una realidad bastante compleja porque es
totalmente diferente la explotación y optimización de un
negocio maduro que la empresa ya sabe hacer muy bien
frente a un proceso de búsqueda de nuevas
oportunidades (a veces con éxito, pero muchas más
veces con fracaso)

12. tres horizontes
•Engloba los negocios maduros de los que la empresa saca la mayor parte de su retorno y generación de caja en
el momento actual, es lo que la empresa sabe hacer bien y lleva tiempo haciendo. Se trata de productos de
sobra conocidos y explotados y donde tiene competencias clave que le dan ventaja competitiva, pero que ya han
alcanzado su pico de crecimiento. Aquí clave reside en cumplir el presupuesto milimétricamente y en llevar los
negocios a la frontera de la eficiencia operativa.
Horizonte H1
•Cubre nuevos negocios y productos en áreas adyacentes al negocio core de la compañía. Puede consistir en
utilizar un nuevo canal de distribución para el mismo producto o un nuevo producto para la base de clientes existente,
se trata de negocios de rápido crecimiento donde la compañía tiene ciertas capacidades y el nivel de riesgo es
moderado, pero que requieren esfuerzos de inversión para capturar la oportunidad, un cierto
grado de experimentación hasta afinar su explotación, y un perfil de empleado más emprendedor y constructor de
negocios.
Horizonte H2
•Aquí se incluyen las apuestas en negocios a más largo plazo en áreas totalmente nuevas para la compañía,
donde no tiene fortalezas y debe construir o adquirir las capacidades necesarias, con un nivel de riesgo alto, y
muchas veces con planteamientos muy disruptivos para la propia compañía (tecnologías sustitutivas del core
business). Se trata de un proceso de exploración a largo plazo para asegurar el crecimiento futuro de la compañía
cuyos proyectos requieren de dedicación del senior management para poder sobrevivir (muchas veces físicamente
separados del resto de la organización). Aquí la clave es tener un sistema eficiente de realización de experimentos
rápidos a un coste razonable.
Horizonte H3

13. tres horizontes
La figura al lado muestra gráficamente el despliegue
temporal de cada horizonte y su impacto en el
crecimiento de la compañía.
También se muestran los posibles pesos a la hora de
asignar recursos e inversiones a los proyectos en cada
horizonte, tomando como ejemplo el esquema de
distribución de esfuerzos que utiliza una compañía
como Google, aunque esta asignación puede variar en
función de la industria y del tipo de compañía que se
trate.
Lo relevante, más que el número concreto, es el orden
de magnitud y lo que ello implica.
La mayor parte de la dedicación de los esfuerzos de crecimiento de la compañía están en el horizonte
H1 porque es lo que alimenta la caja de la empresa, pero tienen que existir equipos más pequeños y con
menos presupuesto trabajando en paralelo en los horizontes H2 y H3 para ir preparando la empresa para el
futuro, o en caso contrario cuando se agote el crecimiento de los productos y servicios del H1 la compañía
dejará de ser relevante.

14. tres horizontes
Horizonte 1 Horizonte 2 Horizonte 3
Riesgos Bajo Medio Alto
Cacidades Capacidades existentes Algunas Capacidades nuevas Capacidades totalmente nuevas
Perfiles
Gestores experimentados para explotar el
negocio core
Emprendedores capaces de construir un
negocio desde cero
Visionarios para reconfigurar toda una industria
Foco
Ejecución eficiente para defender y aumentar
el negocio core de la compañía
Dedicar recursos e inversión a negocios de alto
crecimiento en áreas adyacentes al core
Explorar oportunidades disruptivas y hacer
apuestas selectivas de futuro
Resultado Forecast y Plan anual detallado
Planes de negocio con inversión para los
nuevos negocios y su valor presente neto
Selección de oportunidades, planes de proyectos y
nivel de cumplimiento de objetivos
El modelo esta más vigente que nunca por la alta incertidumbre que impera en todas las industrias, donde las ventajas
competitivas son temporales y las empresas deben reinventarse con mucha rapidez y seguir siendo relevantes.
En este sentido, el modelo supone una potente herramienta para ligar la innovación con la estrategia de la compañía, y
proporciona una guía mientras se elabora la estrategia a medio y largo plazo.
“El foco debe estar en las necesidades de sus partes interesadas”

15. SLs y su Terminología
Muchas empresas están familiarizadas con el concepto de SLA, pero los términos SLI y SLO son nuevos y
merece la pena explicarlos.
Los SLAs estan cada día mas complejos y pueden tener varios matices según el contexto.
Las prácticas de SRE se están volviendo más frecuentes y los despliegues nativo en la nube. Y el requisito
previo para el éxito en SRE es la disponibilidad.
Para establecer objetivos operativos es necesario entender y mantener los SLI, los SLO y los SLA.
Estos pueden ser vistos como jerárquicos:
SLIs
(X) debe ser cierto (¿Cómo lo
hemos hecho?)
SLOs
(Y) proporción de tiempo (¿ Cual es
el Objetivo?)
SLAs
SLA: o de lo contrario
(Promesa)

16. SLIs, SLOs y SLAs
SLI SLO SLA
Que es?
SLI o Indicador de Nivel de Servicio es una
métrica que el proveedor de servicios utiliza
para el cumplimiento del objetivo.
SLO u objetivo de nivel de servicio es un objetivo
que el proveedor de servicios quiere alcanzar.
SLA o Acuerdo de nivel de servicio es un contrato que
el proveedor de servicios promete a los clientes sobre
la disponibilidad del servicio, el rendimiento, etc.
Descripción
Son los parámetros que indican las
transacciones exitosas, las solicitudes
atendidas por el servicio en los intervalos de
tiempo predefinidos. Estos parámetros
permiten medir el rendimiento y la
disponibilidad del servicio. La medición de
estos parámetros también permite mejorarlos
gradualmente.
Define el tiempo de inactividad aceptable del
servicio. Para múltiples componentes del servicio,
puede haber diferentes parámetros que definan el
tiempo de inactividad aceptable. Es un patrón
común comenzar con un SLO bajo y aumentarlo
gradualmente.
Define la penalización que el proveedor de servicios
debe pagar en caso de indisponibilidad del servicio
durante un periodo de tiempo predefinido. El
proveedor de servicios debe definir claramente los
factores de fallo de los que será responsable (ámbito
de responsabilidad).
Los ejemplos
clave son:
• Disponibilidad/Uptime del servicio.
• Número de transacciones/solicitudes
exitosas.
• Consistencia y durabilidad de los datos.
• La durabilidad de los discos debe ser 99,9%.
• La disponibilidad del servicio debe ser 99,95%.
• El servicio debe cumplir con el 99,999% de las
solicitudes/transacciones.
• Reembolso parcial de la tarifa de suscripción del
servicio.
• Tiempo de suscripción adicional agregado
Es fácil perderse en una niebla de acrónimos, así que antes de profundizar, aquí hay una definición rápida y fácil
My Precious SLA, SLI and SLO….

17. SLIs, SLOs y SLAs
Como se mencionó anteriormente, el trabajo de Operaciones no es sólo trabajar con tickets, automatizar todas las cosas, y
sostener el mando.
Su trabajo es un equilibrio entre las tareas operativas y ingeniería impulsada por los SLs.
Los SRE defienden los SLs a corto plazo para poder mantenerlos a largo plazo.

18. Operaciones modernas
Entonces, ha invertido en la
nube. Las aplicaciones ahora estan
allí. Sin embargo, todavía no se
está moviendo tan rápido, tan lejos
o de manera rentable como le
gustaría. Si esto le suena familiar,
probablemente necesite
comenzar a modernizar las
operaciones.
Hoy en día, muchos ingenieros de
operaciones se encuentran en una
posición desafiante. Deben lidiar
con los desarrolladores que
desarrollan a un ritmo acelerado,
mientras que las presiones sobre la
seguridad y la estabilidad mayores
que nunca.
A menos que la organización haya
invertido en DevOps, simplemente
no cuenta con los procesos,
herramientas o capacidades
adecuados para satisfacer las
demandas de la era digital. Esto
puede causar fricciones
La empresa no puede adaptarse a
las necesidades cambiantes de los
clientes lo suficientemente rápido
porque las operaciones se
convierten en un cuello de botella
en cada nueva iniciativa.
Al mismo tiempo, el negocio está
en riesgo si no puede adoptar las
últimas medidas para maximizar la
seguridad y la resiliencia.
Los sistemas y aplicaciones
basados ​​en la nube merecen, de
hecho requieren, soporte de
operaciones sofisticadas .
Intentar replicar los enfoques de
operaciones tradicionales en
entornos modernos es una receta
para la ineficiencia y el
agotamiento.
Es hora de romper el punto
muerto. Lo que significa desafiar la
sabiduría convencional que impide
que las operaciones se muevan con
los tiempos.
Las operaciones basadas en la
nube requieren enfoques y
habilidades diferentes. Reconocer
esto y luego tomar medidas para
modernizar y mejorar la forma en
que opera en la nube generará una
ventaja competitiva.

19. Operabilidad por diseño
Operaciones
Fiabilidad
DRP
Soportabilidad
Seguridad
Optimización
de costes
Observabilidad
Eficiencia del
rendimiento
Es importante considerar la operabilidad en una etapa temprana en
cualquier desarrollo de sistema o producto.
Pero, ¿qué entendemos por 'operabilidad’?
Es características que hacen que sea más fácil, seguro y rentable
administrar un producto/sistema en producción. Ejemplo, el diseño de
un sistema puede ser 'escalable horizontalmente’, lo que facilita y agiliza
el manejo de los cambios en patrones de demanda de los clientes.
Tomarse un poco más de tiempo al inicio para garantizar que los
sistemas sean fáciles de ejecutar mejora la velocidad y la eficiencia a
largo plazo.
Hacer correcciones importantes en producción siempre es más costoso
y disruptivo que identificar y rectificar problemas durante el diseño.
Sea disciplinado en esto. Reduce la probabilidad de que surjan
problemas más adelante y reduce el costo total de propiedad.

20. Es hora de que nosotros, como profesionales de operaciones, reconsideremos cómo abordamos nuestros
trabajos en este nuevo mundo.
Deberíamos preguntarnos, ¿cómo aprovechan nuestras organizaciones el Cloud Native como un nuevo modo
de entrega de aplicaciones?
Al abordar esta pregunta, debemos esforzarnos por hacer que nuestras plataformas y servicios sean lo más
fáciles de consumir posible. Tanto el desarrollador como el consumidor confían en nosotros para ocultar la
complejidad operativa y mantener la libertad de elección.
Creemos que hay cuatro aspectos centrales de las operaciones modernas. Sin embargo, no es práctico
abarcarlos a todos de una sola vez en todo el negocio.
Las 4 Torres
Componibilidad
• Los componentes de
la aplicación deben
componerse y
conectarse
fácilmente para crear
servicios de nivel
superior.
Flexibilidad
• El equipo de
aplicaciones moderno
no debe percibir sus
opciones como
limitadas.
Programabilidad
• Debemos apegarnos
a un enfoque de API
primero para el
aprovisionamiento, la
implementación y la
administración.
Frictionlessness
• Debemos ocultar la
complejidad y los
detalles de la
infraestructura y las
operaciones del
equipo de
aplicaciones
modernas.

21. componibilidad
La componibilidad ha sido una
característica importante de la nube
desde sus inicios. La típica analogía de
la composición de bloques de Lego
ya se ha convertido en un cliché.
Entonces, para refrescar nuestra
perspectiva, probemos un ejemplo del
mundo real: algunos argumentarían que
el rápido crecimiento de AWS es un
subproducto de su ventaja de ser el
primero en moverse. Otros argumentan
que es porque AWS entendió esta
idea de componibilidad
Elastic Compute Cloud fue uno de los
primeros servicios de AWS ofrecidos,
brindando a los usuarios una forma
más fácil de solicitar infraestructura
informática a través de una solicitud de
API. Para AWS, EC2 proporcionó una
base para todos sus otros servicios en
el futuro.
AWS entendió que EC2 no era el juego
final, sino la base para servicios de
nivel superior como SimpleDB y
Elastic MapReduce. Estos servicios
aprovecharon grandes grupos de
instancias informáticas en la parte
superior.
Con las operaciones nativas de la nube,
debe considerar los servicios de nivel
superior que podría componer para los
clientes, sobre la base que ya ha
construido.
Los servicios pueden convertirse en
bases en sí mismos si se asegura de
que se puedan volver a componer
fácilmente en servicios de nivel
superior. Ciertamente, aún no ha
descubierto todos los casos de uso.

22. Flexibilidad
La flexibilidad se puede describir como “libertad de elección”.
Como cuando los Haldir y los Elfos de Rivendel eligieron ayudar en
la batalla del abismo de Helm
Los equipos de aplicaciones modernas deben tener la libertad de
elegir los leguajes de aplicación, los tiempos de ejecución y los
servicios de respaldo que necesitan.
La tecnología cambia con demasiada rapidez, por lo que los
desarrolladores no deben limitar su elección en función de los
requisitos de servicio del pasado.
Cada plataforma debe admitir una amplia gama de lenguajes y
servicios de respaldo, o bien proporcionar la capacidad de
ampliarse fácilmente para admitir nuevos leguajes o servicios que
los desarrolladores puedan necesitar.

23. programabilidad
Ofrecer servicios en la nube con un punto final
de API, junto con la componibilidad de los
servicios a través de esta API, garantiza la
programabilidad.
Esto juega bien con el principio de flexibilidad:
extender fácilmente un servicio en la nube a
través de una interfaz bien definida.
El servicio en la nube no solo debe ofrecer su API
abierta, sino que debe ofrecer la capacidad de
crear fácilmente puntos finales de API
adicionales.
Algunos excelentes ejemplos de esto son el
servicio API Gateway de AWS y las definiciones
de recursos personalizados de Kubernetes, que
ofrecen extensibilidad a través de una API para
sus propios servicios.
La arquitectura evolutiva es la práctica de
considerar un espectro de dimensiones
alrededor de la arquitectura.

24. Frictionlessness
Durante años has oído hablar del conocido concepto de NoOps , que sostiene que en un mundo Cloud Native, las operaciones
se vuelven prácticamente inexistentes.
Como era de esperar, este argumento ha sido recibido con el grito: "¡Pero todavía hay operaciones!"
La idea básica detrás de NoOps es generalmente correcta: las operaciones se vuelven transparentes y sin fricciones, desde la
perspectiva del equipo de aplicaciones moderno.
Sí, todavía hay operaciones, pero son varias capas eliminadas del consumidor. Al presentar sus servicios en la nube, debe
reforzar esta idea de reducción de la fricción.
Debe refinar sus procesos para que, a medida que agregue nuevos servicios, reduzca aún más los gastos generales operativos
del equipo de aplicaciones, acercándolos cada vez más a cero.
Los servicios de construcción para el equipo de aplicaciones moderno requieren cuidado y reflexión.
Estas cuatros torres de Cloud-Native Operations brindan conceptos guía para que los profesionales de operaciones satisfagan
las necesidades de sus equipos de aplicaciones.
Los servicios en la nube deben centrarse en hacer que el consumo sea fácil y fluido

25. Operación Cloud Native
Un proyecto de Cloud Native no termina cuando se crea un nuevo sistema; necesita ser mantenido y mejorado
una vez que esté en funcionamiento. Alguien debe estar preparado para manejar incidentes y evitar
interrupciones del servicio que puedan molestar a los clientes y obstaculizar la actividad comercial.
En los próximos slides vamos a ver nueve patrones de operaciones para ayudar a las organizaciones a
mantener todo funcionando sin problemas.
Estos patrones se centran en los aspectos técnicos y arquitectónicos de cómo crear y operar servicios nativos
de la nube al tiempo que garantizan su confiabilidad y seguridad.
• CI/CD as Platform
• Customization Through Microservices
• Dynamic Secrets
• Ephemeral Environments
• GitOps
• Metrics over Logs
• Network Isolation
• Runbooks
• Service Priority

26. CI/CD como
plataforma
• La complejidad de la entrega de software empresarial puede alcanzar fácilmente un nivel en el que
un equipo dedicado tendría que ser responsable de su mantenimiento.
• Los servicios de CI/CD a escala empresarial son difíciles de implementar. Tener en cuenta los
requisitos de auditoría, cumplimiento y flexibilidad del equipo conducirá a un sistema que se
personaliza en un alto grado. A menudo, la responsabilidad de estos servicios termina en el Equipo de
la plataforma, que administra la infraestructura. Si bien CI/CD está relacionado con la plataforma de
infraestructura, tiene sus propios objetivos y un dominio diferente (en términos de DDD).
Contexto
• Cree un equipo de producto dedicado, que creará y administrará los servicios de CI/CD. Este equipo
será un consumidor de la plataforma de infraestructura y un proveedor de servicios para los equipos
de desarrollo. El equipo de la plataforma de CI/CD debe tratar los servicios de CI/CD como un
producto que se ofrece a todos los equipos de desarrollo.
• Esto significa que las solicitudes de funciones deben redactarse de una manera que sea útil para
todos los usuarios de la plataforma. Todos los servicios de la plataforma deben ser de autoservicio,
los miembros del equipo de la plataforma CI/CD solo deben interactuar con los desarrolladores de
aplicaciones de manera limitada (por ejemplo, soporte) para que puedan concentrarse en la creación
de funcionalidad. Por lo tanto, el equipo es un equipo de producto interno, no un equipo habilitador
Por lo tanto
• + Los servicios de CI/CD se tratan como ciudadanos de primera clase en la plataforma nativa de la
nube más grande
• + Los equipos de aplicaciones pueden consumir servicios de CI/CD sin esperar las acciones de otro
equipo
• + El conocimiento especializado se puede desarrollar y utilizar más fácilmente en un equipo con
menos responsabilidades
Consecuencia

27. Personalización
a través de
microservicios
• El objetivo de una plataforma SaaS es aprovechar la multitenencia, es decir, todos los usuarios del
sistema comparten la misma plataforma. Entonces, ¿cómo podemos tener un código personalizado
para cada cliente? Agregar el código personalizado a la aplicación principal, como suele hacerse con
las aplicaciones heredadas que se ejecutan en los propios servidores del cliente, no es una opción
viable en un modelo SaaS de múltiples inquilinos.
• El código personalizado y las características pueden inflar rápidamente una base de código, a
medida que se agregan más clientes.
• Aislar la lógica personalizada de cada cliente es un desafío.
• Alto riesgo de que el código de personalización afecte la funcionalidad principal.
• El código personalizado generalmente lo desarrolla un equipo separado, esto no puede afectar a
otros clientes
Contexto
• Al crear una interfaz de "personalización" (API) bien definida, se pueden crear microservicios
específicos del cliente para ejecutar toda la lógica personalizada. Los microservicios personalizados
solo se llaman en puntos designados, y el enrutamiento es manejado por una puerta de enlace API
interna o malla de servicio.
Por lo tanto
• La personalización se puede ofrecer a los clientes sin afectar negativamente a los servicios
principales ni a otros clientes.
• + El código personalizado está bien contenido dentro de su propio microservicio.
• + Si el código personalizado se rompe, no afecta a otros usuarios.
• + Podemos establecer límites de red y límites de recursos en los microservicios personalizados para
crear el nivel necesario de aislamiento.
• + Los servicios principales no necesitan tener conocimiento de la lógica personalizada o los
microservicios.
Consecuencia

28. SECRETOS
DINÁMICOS
•Creación de una arquitectura distribuida de microservicios. Muchos servicios requieren contraseñas,
claves, tokens u otros datos confidenciales que no se pueden almacenar en texto sin formato.
•Los equipos tienden a terminar con uno de dos conjuntos de problemas:
•Alta Seguridad - Baja Agilidad: Todas las credenciales son administradas (manualmente) por un
equipo de seguridad. Por lo general, nadie sabe dónde se sienta realmente este equipo, la única
interfaz es un oscuro sistema de archivo de boletos.
•Alta agilidad - Baja seguridad: Los equipos de desarrollo son responsables de administrar sus
propios secretos.
•En ambos casos: Al implementar su aplicación en un nuevo entorno (por ejemplo, desarrollo local
para integración o control de calidad para producción), las aplicaciones suelen fallar porque las
credenciales o la forma en que se accede a las credenciales difieren en cada entorno.
Contexto
•Utilice una herramienta específica para gestionar y abstraer datos secretos de sus aplicaciones.
•Resuma la herramienta y el método para recuperar datos secretos de sus servicios.
•Agregar/solicitar un nuevo secreto (por ejemplo, contraseña de la base de datos) debe ser de
autoservicio.
•Los datos secretos se montan como un volumen para que las aplicaciones los lean localmente.
•Los secretos deben rotarse con frecuencia.
•Los datos secretos deben cifrarse en reposo.
Por lo tanto
• Los secretos se pueden gestionar sin ningún impacto negativo en la agilidad sin comprometer la
seguridad.
• + Los desarrolladores no tienen que preocuparse por cómo o desde dónde recuperar los datos
secretos.
• + El equipo de seguridad no necesita ralentizar o detener el proceso de liberación.
• + Los datos secretos están bien protegidos, idealmente ningún ser humano verá los secretos reales.
• + El riesgo se reduce considerablemente, ya que incluso si se comprometen, los secretos se pueden
revocar o rotar fácilmente.
Consecuencia

29. ENTORNOS
EFÍMEROS
•La tecnología de contenedores nos ha llevado un largo camino para resolver el problema 'funciona
en mi máquina'. Sin embargo, en un entorno de microservicio, la cantidad de dependencias para
validar verdaderamente la funcionalidad del servicio aún puede hacer que esto sea un gran desafío.
•Imitar la producción en la computadora portátil de un desarrollador a menudo no es factible.
•La creación de clústeres y entornos se vuelve fácil con la automatización, pero el costo, tanto
monetario como de recursos para administrar todos los clústeres, puede crecer rápidamente.
En este contexto
•Al aprovechar la automatización y una plataforma en la nube moderna, se pueden crear entornos a
pedido y eliminarlos una vez que ya no se necesiten. No hay ninguna razón por la que debamos
mantener las viejas formas de tener entornos permanentes (pruebas, control de calidad, puesta en
escena).
•Agregue etapas a la canalización de compilación para crear un nuevo entorno para cada
implementación.
•Las pruebas de validación se automatizan contra el entorno recién creado.
•Se puede poner a disposición una URL temporal para cualquier validación manual que deba
realizarse.
•Los entornos deben eliminarse automáticamente, ya sea después de completar la canalización o
después de un período de tiempo establecido.
Por lo tanto
• + En el espíritu de la infraestructura inmutable, tener entornos bajo demanda de corta duración
reduce el riesgo de cambios en la configuración con entornos de larga duración.
• + La automatización de la infraestructura se valida con frecuencia y la optimización de la
automatización se vuelve esencial.
• + La confianza de la canalización de compilación aumenta a medida que todos los cambios se
validan en entornos similares a los de producción.
• + Los costos de la nube se reducen considerablemente ya que solo ejecutamos los entornos cuando
es necesario.
Como consecuencia

30. GitOps
• Quiere entregar cambios más rápido, pero requiere seguridad y confiabilidad. ¿Cómo coordina la
entrega de aplicaciones y la gestión de la infraestructura de forma controlada y segura sin reducir la
velocidad?
• Múltiples herramientas, tecnologías
• Panorama cambiante (entornos de implementación, clústeres, etc.)
• A menudo se necesitan varios clústeres y entornos de implementación
• Las acciones manuales son lentas y propensas a errores
En este contexto
• Utilice un repositorio de Git para almacenar el estado actual (deseado) de su infraestructura y
aplicaciones en producción. Un servicio en clúster para monitorear el repositorio y ajustar el estado
actual según sea necesario.
• Almacene toda la configuración de la infraestructura en un formato declarativo en un repositorio de
Git
• Implemente un servicio (operador) en su clúster para monitorear el repositorio y aplicar cambios
• Todos los cambios de infraestructura se realizan a través de solicitudes de rama/extracción en el
repositorio
Por lo tanto
• + Obtiene la única fuente de verdad sobre su infraestructura y una manera fácil de auditar los
cambios en ella.
• + Terminamos con una única fuente de verdad para el estado (deseado) de nuestra infraestructura y
aplicaciones.
• + Usamos herramientas existentes (probadas) (Git) y flujos de trabajo para administrar los cambios
en nuestro sistema.
• + Podemos escalar mucho más fácilmente, por ejemplo, a entornos de múltiples clústeres.
• + Tenemos un proceso de aprobación incorporado y una auditoría de todos los cambios.
Como consecuencia

31. MÉTRICAS
SOBRE
REGISTROS
• Al crear aplicaciones, tradicionalmente enviamos toda la información relevante como registros. Los
monitoreos o métricas se utilizaron principalmente para la salud de nuestra infraestructura. La
aplicación de este patrón a un sistema distribuido moderno compuesto por docenas de componentes
da como resultado petabytes de datos en su mayoría inútiles.
• La falta de una estructura bien definida hace que el análisis de registros sea casi imposible
• El 99 % de los registro nunca se usan ni se ven, y solo sirven para aumentar los costos de la nube.
• Los registros no son un conjunto viable de datos que podemos crear alertas o notificaciones.
• No hay una visión clara sobre la salud real de nuestro sistema.
• Las métricas basadas en una única instancia (p. ej., contenedor de aplicaciones) no tienen sentido.
En este contexto
• Primero se debe establecer bien el propósito de cada tipo de datos, registros y métricas. Los
registros deben usarse como un método secundario para obtener más conocimiento sobre un
incidente específico (es decir, depuración). Las métricas son una forma de obtener una visión
holística de sus aplicaciones y sistema en su conjunto.
• Los datos enviados a los registros deben minimizarse tanto como sea posible.
• Se deben definir las métricas globales relevantes.
• Para cada servicio, el propietario debe definir métricas que sean relevantes y ponerlas a disposición
del sistema de monitoreo.
Por lo tanto
• + El equipo puede obtener una visión clara y centralizada del estado general del sistema y sus
componentes.
• + Los datos de registro se simplifican y reducen en gran medida (ahorro de costes).
• + Cuando se necesitan registros (para depurar un problema), encontrar los registros relevantes se
vuelve mucho más fácil.
• + Una vista precisa de la salud de su sistema está disponible.
• + Las métricas estandarizadas se pueden enviar fácilmente a una variedad de plataformas y
herramientas de monitoreo.
Como consecuencia

32. AISLAMIENTO
DE RED
• Múltiples aplicaciones, equipos, entornos (p. ej., desarrollo/escenario) e incluso clientes
(multiinquilino) comparten la plataforma. Si bien estos servicios separados normalmente no deberían
acceder entre sí a través de ciertos límites (por ejemplo, espacios de nombres), de forma
predeterminada no hay nada que bloquee el tráfico (ya sea malicioso o por error) para que no cruce
estos límites. Las aplicaciones separadas que se ejecutan en una plataforma pueden ser susceptibles
a los ataques de otros.
Contexto
• Al aprovechar una función como NetworkPolicies en Kubernetes, podemos bloquear todo el tráfico
no deseado entre servicios.
• Comportamiento
• Determine todo el tráfico esperado entre sus servicios. (Una malla de servicio o una herramienta de
rastreo pueden generar esto dinámicamente).
• Defina reglas para bloquear todo (otro) tráfico entre servicios.
• Aplique las reglas creadas y supervise sus aplicaciones en busca de cualquier problema creado.
• (Opcional) agregar registro para todo el tráfico bloqueado
• Para cualquier tráfico imprevisto, determine si es a) intencionado o b) no deseado
• Agregue una regla para permitir el tráfico, actualice la topología de su red
• Repare la aplicación que realiza el acceso no deseado
Por lo tanto
• La seguridad de la red se mejora dentro de la plataforma compartida con la capacidad de realizar un
seguimiento de los cambios posteriores.
• + Hemos creado una solución mucho más segura.
• + Para cualquier atacante que logre comprometer un servicio, ahora está severamente limitado en
términos de daño que puede causar (#defenceInDepth)
• + Estamos protegidos contra errores cometidos en el desarrollo accediendo a servicios que no
deberían ser
• + Tenemos una imagen clara y auditable del tráfico de red real en nuestro entorno.
Consecuencia

33. Manuales
• Cuando se activa una alarma al infringir un umbral o una condición definidos, un runbook se vincula
con información o procedimientos estándar para manejar un incidente. Para ello, los equipos han
creado un runbook útil que se mantiene activamente y se integra en la infraestructura de alertas para
una fácil referencia.
En este contexto
• Al usar sus investigaciones como un registro de qué acciones y actividades han funcionado, puede
aprovechar las acciones registradas (que solucionaron el problema) para crear sus runbooks. El buen
runbook, como mínimo, debe incluir respuestas para las siguientes preguntas:
• QUÉ: Activar la alarma (qué herramientas y qué umbral)
• CÓMO: Comenzar a remediar el problema (es decir, escalar, revertir, etc.)
• QUIÉN: Quién es el equipo de producto con el que se debe contactar en caso de escalamiento.
• DÓNDE: ¿Dónde puede encontrar el ingeniero de guardia información como: documentación,
estados de actualización, etc.
Por lo tanto
• + Reduce o elimina el tiempo que le toma a su equipo "buscar" sus runbooks en un repositorio de
archivos o un enlace wiki.
• + También reduce el estrés asociado con la resolución de un problema complejo a medianoche.
Como consecuencia

34. PRIORIDAD
DE SERVICIO
• Cuando los recursos (generalmente la memoria) se agotan en un nodo/servidor, nuestra plataforma
de orquestación dinámica se ve obligada a elegir una(s) aplicación(es) para desalojar para evitar que
todo el nodo se bloquee. Esto puede tener efectos negativos si se eliminan nuestras aplicaciones
críticas.
• La naturaleza dinámica de nuestras aplicaciones dificulta la predicción del uso de recursos
• Queremos aprovechar la naturaleza dinámica de nuestras aplicaciones y su utilización para
sobreaprovisionar.
• Ciertas aplicaciones reaccionan de manera diferente a la terminación no programada
En este contexto
• Podemos especificar la prioridad relativa de nuestras diferentes aplicaciones para predeterminar
cuáles serán desalojadas primero. Esto nos permite proteger nuestros servicios más críticos.
• Comportamiento
• Determinar cuáles de nuestros servicios son los más críticos
• Definir niveles de prioridad para todos los servicios
• Asigna prioridades con la plataforma
• Por ejemplo, PodPriority en Kubernetes
Por lo tanto
• Puede aprovechar el aprovisionamiento excesivo de recursos para un uso eficiente de la
infraestructura mientras agrega una medida de protección para los servicios críticos.
• + Todos los servicios tendrán prioridad. Cuando se agotan los recursos en un nodo, la plataforma de
orquestación puede tomar decisiones más inteligentes sobre qué aplicaciones eliminar/reprogramar
• + Cuando se necesita programar servicios de mayor prioridad y no hay suficientes recursos
disponibles actualmente, la plataforma de orquestación puede desalojar aplicaciones de menor
prioridad para hacer espacio.
Como consecuencia

35. SRE y Cloud Native
Como sabemos Site Reliability Engineering (SRE) es un término acuñado por Google para explicar cómo
ejecuta sus sistemas. Fue la respuesta de Google a los desafíos actuales para garantizar el rendimiento y la
confiabilidad de las aplicaciones a una escala sin precedentes.
En SRE, la responsabilidad de la plataforma de una organización se divide entre dos equipos:
• Un equipo de producto , que se centra en la entrega del valor comercial, la aplicación o el servicio (incluida la
innovación).
• Un equipo de confiabilidad , que se enfoca tanto en mantener como en mejorar la plataforma en sí.
Para comprender por qué una organización podría necesitar SRE, debemos comprender la diferencia entre
programación e ingeniería de software. La programación es el desarrollo de software.
La ingeniería de software juega un papel integral en la programación, pero también se trata de modificaciones
(cambios) y mantenimiento del software.

36. SRE y Cloud Native
Si su organización necesita o no SRE depende de un factor: el cambio. Si la vida útil de su producto o base de
código es tan corta que nunca necesitará modificarse, entonces SRE no es una buena opción.
Pero si crea una plataforma que está destinada a durar más de un par de meses, será necesario realizar
cambios. En otras palabras, se beneficiaría de SRE.

37. SRE y Cloud Native
A medida que las plataformas y las aplicaciones se vuelven más complejas y están en constante crecimiento, los equipos de DevOps (los
equipos multifuncionales que son responsables del ciclo de vida completo de sus aplicaciones) necesitan dedicar más tiempo al soporte de
los servicios actuales.
Esto se convierte en un problema aún mayor si los equipos brindan cobertura las 24 horas del día, los 7 días de la semana en la forma típica
de DevOps 'usted lo crea, usted lo ejecuta’.
Un equipo típico de DevOps tiende a ser pequeño, generalmente de unos
cinco ingenieros, ya que el alcance de dichos equipos abarca idealmente
solo un servicio o funcionalidad. Al contar con cinco ingenieros
dispuestos y capaces de estar de guardia las 24 horas del día, los 7 días
de la semana, con uno principal y uno de respaldo, todos están en
servicio los 146 días del año, o casi cada dos semanas. Esta es una
receta para el agotamiento y la alta rotación.
Con el fin de reasignar el tiempo de TI para brindar valor a los clientes,
sin obstaculizar la velocidad de entrega y mejora del producto, más
empresas están formando equipos de SRE. Esto significa dedicar a los
desarrolladores a la mejora continua de la resiliencia de sus sistemas de
producción.

38. ¿Qué tiene que ver SRE con Cloud
Native?
Los equipos de operaciones de TI
tradicionales aún dependen, en gran
medida, de actividades manuales y
de procesos que ralentizan la
entrega de valor .
Al hacer esto, estos equipos no
pueden mantenerse al día con la
creciente demanda y complejidad
de las aplicaciones de software
modernas, y la demanda que se les
impone desde dentro y fuera de sus
empresas.
Los equipos de desarrollo y operaciones han
adoptado tradicionalmente una "mentalidad
de silo" optimizada para el uso eficiente de
los recursos y la especialización
tecnológica. Los silos requieren un traspaso
formalizado y lento entre silos.
A menudo, estos equipos aislados
incluso tienen objetivos en conflicto.
El equipo de desarrollo debe brindar
valor más rápido a los clientes
mediante el desarrollo y la
implementación de nuevas funciones
y productos, mientras que el equipo
de operaciones debe garantizar la
estabilidad de la producción
asegurándose de que las
aplicaciones no sufran degradación
del rendimiento ni interrupciones.

39. ¿Qué tiene que ver SRE con Cloud
Native?
Al adoptar Site Reliability Engineering, o SRE, puede superar los conflictos tradicionales entre desarrollo y
operaciones. SRE, aplica prácticas de ingeniería de software a la infraestructura y las operaciones, con el
objetivo principal de crear plataformas Cloud Native escalables y altamente confiables sin intervención manual.
Esto suena al principio como el movimiento DevOps, pero hay diferencias.
Muchas empresas piensan que ir a Cloud Native simplemente es configurar Kubernetes .
Con los ojos vendados, solo ven la nueva y emocionante tecnología de la que todo el mundo habla.
Pero sin comprender su propia arquitectura, sus propios procesos de mantenimiento y entrega, o, lo que es
más importante, su propia cultura interna y su papel fundamental en el proceso de transformación, terminarán
con un sistema complejo que difícilmente podrán mantener. Esto conducirá a lo contrario de ser Cloud Native.

40. ¿Qué tiene que ver SRE con Cloud
Native?
En el siguiente gráfico, “matriz de madurez Cloud Native” que
vimos en la parte 1 de esta trilogía, tiene una visión holística de
lo que significa convertirse en una organización nativa de la
nube.
SRE es parte de la misma, SRE se centra en la disponibilidad,
el rendimiento, la observabilidad, la respuesta a incidentes y
las mejoras continuas, todos los cuales son atributos de Cloud
Native.
Cloud Native utiliza microservicios como patron de
arquitectura de aplicaciones y las aplicaciones se construyen
mejor siguiendo los principios de las aplicaciones de 12
factores y ampliando estos 12 factores con
componibilidad, resiliencia y observabilidad.
https://containersolutions.github.io/maturity-matrix/

41. Los principios de diseño de las aplicaciones Cloud Native son:
Al aplicar los principios de SRE, su arquitectura gravitará hacia estándares y convenciones comunes, incluso si no están
dictados centralmente. Estos estándares suelen ser los 12 factores extendidos, para crear aplicaciones resilientes.
•Diseño para el
rendimiento (capacidad
de respuesta,
concurrencia, eficiencia)
Diseño para la
automatización
(automatización de
infraestructura y tareas
de desarrollo)
Diseño para la resiliencia
(tolerancia a fallas,
autorreparación)
Diseño para la
elasticidad (escalado
automático)
Diseño para la entrega
(minimizar el tiempo del
ciclo, automatizar las
implementaciones)
Diseño para la capacidad
de diagnóstico (registros,
seguimientos y métricas
de todo el clúster)
¿Qué tiene que ver SRE con Cloud
Native?

42. ¿Qué tiene que ver SRE
con Cloud Native?
Como Frodo y Sam, cuando una empresa emprende un viaje a Cloud
Native y empiece a adoptar el modelo operativo SRE, estos equipos
pasarán más tiempo trabajando en entornos de producción.
Al hacerlo, la organización verá una arquitectura en constante mejora y
más resistente, con, por ejemplo, opciones adicionales de conmutación
por error y capacidades de reversión más rápidas.
A través de esas mejoras continuas, su organización puede establecer
expectativas más altas para sus clientes y partes interesadas, lo que
lleva a impresionantes SLO, SLA y SLI que generan un mayor valor
comercial.
Su plataforma será más sólida y podrá cambiar todas las cosas que
debe cambiar, de forma segura, y podrá hacerlo todo el tiempo, con
comentarios inmediatos sobre la disponibilidad y el rendimiento de
cada cambio.

43. lecturas sugeridas

44. Conclusión
“No es la más fuerte de las especies la que sobrevive, ni la más inteligente, sino la que
mejor responde al cambio”.
charles darwin
“Para poder construir aplicaciones bien diseñadas y plataformas
confiables, SRE debe ser prescriptivo”.
“Desarrolle nuevas capacidades de operaciones con cuidado y en consulta con
los usuarios afectados. Una de las claves es nuestra capacidad de escuchar, una
vez escuché una frase, tenemos 2 orejas y 1 boca - utilízala proporcionalmente”
Continuará…

45. CREDITS: This presentation template was created by
Slidesgo, including icons by Flaticon, infographics &
images by Freepik & Eddie Sharam
Based
Gracias