Modernización de las

aplicaciones y el
desacoplamiento de la
infraestructura,
servicios y equipos
Por Eric Brewer y Jennifer Lin, Google

© 2019 Google Inc.

Índice
Modernización de las aplicaciones y el desacoplamiento de la
infraestructura, servicios y equipos
Resumen
Acelerar la modernización de las aplicaciones mediante el
desacoplamiento
Desacoplamiento de la infraestructura y las aplicaciones:
contenedores y Kubernetes
Desacoplamiento de equipos de nube: pods y servicios
El poder del proxy
Administración del ciclo de vida y microservicios con Istio
Seguridad confianza cero y modernización de la garantía de la nube
El modelo declarativo de configuración y Kubernetes
Conclusiones

© 2019 Google Inc.

 3

Modernización de las aplicaciones y el

desacoplamiento de la infraestructura,
servicios y equipos
Resumen

La modernización de las aplicaciones en una nube pública presenta muchas ventajas en

términos de costos y productividad, pero estas suelen venir en forma de una elección "todo
o nada": migrar a la nube y modernizar, o adiós a los beneficios. Las empresas desean
modernizarse sin migrar a una nube pública, además de contar con un método incremental
de migración que combine soluciones on-premise y basadas en la nube según sean
necesarias. Esta modernización resulta crítica para dar paso a la innovación comercial, como
la incorporación de tecnologías avanzadas de aprendizaje automático y análisis de datos.

Asimismo, las nubes públicas ofrecen plataformas bastante diferentes entre sí, lo que
dificulta la portabilidad de cargas de trabajo, tanto en lo que respecta a cuestiones técnicas
como a las habilidades de los desarrolladores. Aun así, la mayoría de las empresas acepta la
opción de usar múltiples nubes, cambiar de proveedores a lo largo del tiempo y, en general,
conservar cierto nivel de independencia con sus proveedores.

Estos dos amplios patrones (la búsqueda de la modernización on-premise y el anhelo de

contar con soluciones de múltiples nubes) plantean la necesidad de contar con una nueva
plataforma que permita una ejecución coherente en distintos entornos, así como tareas de
desarrollo y operaciones ágiles y modernas en todos estos entornos. Kubernetes es una
tecnología popular para la organización de contenedores y portabilidad de cargas de
trabajo, que se ha convertido rápidamente en el estándar líder para el desarrollo de
aplicaciones independientes de la plataforma. Constituye las bases de la amplia plataforma
que describimos anteriormente. Al abordar al mismo tiempo las necesidades de los equipos
de operaciones empresariales y desarrollo ágil, la industria ahora puede enfocarse en su
principal meta: construir una plataforma de servicios en la nube verdaderamente autónoma,
que permita que los sistemas distribuidos y dinámicos puedan evolucionar de forma
orgánica, además de un uso exhaustivo y variado del aprendizaje automático, pero que

© 2019 Google Inc.

 4

también ofrezca una experiencia coherente al desarrollador y un único punto de control

administrativo.
Google ha desarrollado Cloud Services Platform (CSP) con el objetivo de acelerar la
modernización de las aplicaciones para proveedores de SaaS, desarrolladores, operadores
de TI y sus usuarios finales. Para equilibrar la agilidad de los desarrolladores, la eficiencia
operativa y el control de la plataforma, el marco CSP permite desacoplar componentes
críticos:
• La infraestructura se desacopla respecto de las aplicaciones (a través de los
contenedores y Kubernetes)
• Los equipos se desacoplan entre sí (a través de los servicios y pods de Kubernetes)
• El desarrollo se desacopla de las operaciones (a través de la administración de políticas
y servicios)
• La seguridad se desacopla del desarrollo y las operaciones (a través de la administración
estructurada de políticas)
El desacoplamiento exitoso de la infraestructura, los servicios y los equipos minimiza la
necesidad de coordinación manual, reduce el costo y la complejidad, e incrementa
considerablemente la velocidad de los desarrolladores, la eficiencia operativa y la
productividad del negocio. Ofrece un modelo de operación e implementación y un marco
que permite asegurar la coherencia en un futuro incierto de nubes híbridas y múltiples nubes.

Cargas
de trabajo
modernizadas

Cargas
de trabajo
tradicionales

On-premise Nube

Figura 1: El camino hacia la modernización

© 2019 Google Inc.

 5

Acelerar la modernización de las

aplicaciones mediante el desacoplamiento
Desacoplamiento de la infraestructura
y las aplicaciones: contenedores y Kubernetes

La transición "nativa en la nube" consiste realmente en crear un mayor nivel de abstracción

más allá del uso exclusivo de máquinas virtuales. Las máquinas virtuales (VM) ayudan a
superar muchos desafíos, pero en teoría representan a la infraestructura, no de las
aplicaciones. En especial, el uso de imágenes de VM para aplicaciones combina el uso de la
VM, el sistema operativo (SO), la aplicación y sus bibliotecas.

En consecuencia, la primera función de los contenedores, impulsados por la tecnología de

Docker, consiste en empaquetar una aplicación independientemente de la infraestructura, lo
que incluye, idealmente, la máquina, las bibliotecas y el SO. De hecho, uno de los primeros
casos de uso exitosos de Docker consistía en compilar y probar aplicaciones en una laptop,
para luego implementarlas en la nube. Por ejemplo, los contenedores definen las
dependencias de bibliotecas correctas y las envían a la infraestructura, ignorando lo que esta
ya podría incluir, lo que crea posibles conflictos entre bibliotecas por la coexistencia de estas
en la misma máquina.

La segunda función de los contenedores, conocida como "contenedores Linux", se trata del
aislamiento entre diferentes aplicaciones en una misma máquina. Google fue pionero en esta
metodología hace ya más de diez años, de modo tal que podemos empaquetar varias
aplicaciones en el mismo hardware sin tener que preocuparnos (mucho) sobre cómo
interfieren entre sí. Esto nos permite visualizar la programación en un clúster principalmente
como un problema bin-packing independiente de las aplicaciones específicas.1

Debido al éxito de la portabilidad y el aislamiento del desempeño bajo el lema "escribir una
vez, ejecutar en cualquier ubicación" sobre infraestructuras compartidas, los contenedores
han demostrado ser un primer paso crítico hacia el desacoplamiento de las aplicaciones y la
infraestructura, así como un elemento fundamental de la modernización de las aplicaciones.

¹ Google ha resuelto el problema de empaquetamiento de forma interna, no a través de los contenedores como
Docker, sino mediante una combinación de enlaces estáticos y el uso forzoso de algunas bibliotecas de nivel inferior.
Esto funciona cuando tenemos control pleno de nuestras aplicaciones, pero es muy difícil de administrar y no es tan
flexible como el modelo de Docker. Ver: https://research.google.com/pubs/pub43438.html?hl=es

© 2019 Google Inc.

 6

Desacoplamiento de equipos de nube: pods y servicios

En el caso de aplicaciones simples, los contenedores ofrecen una estructura suficiente: un

equipo puede desarrollar su aplicación como un contenedor y luego desplegarla. Sin
embargo, en el caso de aplicaciones más complejas en las que participan múltiples equipos,
es preferible desacoplarlos entre sí. Esto resulta claramente evidente en los equipos
responsables de los servicios de infraestructura compartida, como aquellos de monitoreo o
registros. El equipo de registros debería poder avanzar en sus tareas independientemente de
las actualizaciones de la aplicación. Si el cliente utiliza solo un único contenedor por
aplicación, es necesario compilar una versión de registros en los contenedores e
implementar esa versión. La actualización de los registros requiere, entonces, que el cliente
despliegue un nuevo contenedor, lo que implica acoplar los equipos de aplicaciones y
registros, además de requerir coordinación y ralentizar a ambos.

¿Qué sucede con los pods?

Kubernetes introdujo los pods con el objetivo de ayudar en este tipo de desacoplamiento.
Un pod es un grupo de contenedores que están programados en conjunto (es decir, se
ejecutan en la misma máquina) que pueden compartir recursos, como volúmenes locales, y a
los cuales se asigna una dirección IP única. En el ejemplo del equipo de registros, el pod
contempla tanto el contenedor de aplicaciones como el contenedor de registros, y los dos se
comunican a través de los volúmenes compartidos y/o a través de las redes localhost. Este
acoplamiento flexible permite actualizaciones independientes: el contenedor de aplicaciones
solo contempla el cliente de la interfaz de programación de aplicaciones (API) de registros,
pero no la implementación de registros. Este patrón de contar con un contenedor asistente
en el pod se conoce como “archivo adicional”.

El hecho de que cada pod tenga su propia dirección IP también permite el desacoplamiento:
cada pod tiene todos los puertos disponibles. Esto es muy importante ya que, por cuestiones
de convención, la mayoría de las aplicaciones supone la disponibilidad de un puerto fijo, como
el puerto 80 para HTTP. El sistema de nombres de dominio (DNS) promueve esta convención
al no incluir números de puertos en su resolución (en condiciones normales de uso), de modo
tal que se supone la existencia del puerto.2 Tradicionalmente, los puertos son un concepto
tanto de aplicación como de máquina, por lo que, para tener diferentes aplicaciones por
máquina, es necesario contar con diferentes direcciones IP por máquina. Los pods dan
solución a este problema: una máquina con 100 pods tendrá, al menos 100 direcciones IP.

² La solución interna de Google, la cual estamos dejando de lado paulatinamente, consistía en cambiar el DNS para
incluir números de puerto y, luego, asignar de forma dinámica puertos a las aplicaciones según sea necesario. Esto no
es conveniente para la mayoría de las aplicaciones empaquetadas y, en general, lo que queremos es evitar la
necesidad de modificar las aplicaciones.

© 2019 Google Inc.

 7

Servicios básicos
Las arquitecturas modernas están "orientadas a los servicios". Pero antes de responder al
interrogante "¿qué es un servicio?", abordaremos la abstracción de servicio incorporada en
Kubernetes. Más adelante, hablaremos sobre funcionalidades más avanzadas que se han
desarrollado sobre la base de estos servicios básicos.
En Kubernetes, un servicio básico suele ser un conjunto dinámico de pods apoyados en
un mecanismo de agrupamiento que aplica diferentes políticas y mantiene la IP del
servicio. Esta clase de servicios suele denominarse microservicio, aunque los servicios no
necesariamente son pequeños, sino que hace referencia más al building block y al equipo
responsable del servicio. Google ejecuta más de 10,000 servicios en todo momento.

El hecho de contar con un nombre persistente y altamente disponible es, por mucho, el
aspecto más importante de un servicio. El nombre primario es simplemente una dirección IP:
Los servicios de Kubernetes usan una "IP de servicio" que es independiente de las IP de los
pods subyacentes que implementan ese servicio.3 El "mecanismo de agrupamiento" que
mencionamos anteriormente suele ser un proxy, aunque también puede ser una forma de
enrutamiento o traducción de direcciones de red (NAT) que mapee la IP de servicio a las IP del
pod de manera dinámica. Las formas no basadas en proxy son menos flexibles, pero tienen un
mejor desempeño.

El desacoplamiento del nombre del servicio respecto de su implementación permite acceder

a beneficios clave para el cliente:

• Actualizaciones en línea, que son posibles gracias al desacoplamiento del ciclo de vida
de los servicios y los pods que los componen
• Escalamiento más sencillo, ya que los pods pueden adaptarse a la carga transparente
(manual o automática) para los clientes
• Tareas de definición y aplicación de políticas unificadas a través de diferentes proxy
para simplificar la administración de propiedades más complejas, como la seguridad y
las operaciones

Los servicios facilitan la combinación de lenguajes entre equipos y componentes de

las aplicaciones.

³ Kubernetes también expone el DNS para localizar servicios por nombre.

© 2019 Google Inc.

 8

Cada servicio se implementa a través de su(s)propio(s) pod(s), que puede, a su vez,

implementarse en cualquier lenguaje o estilo. Los servicios representan a las API, que pueden
definirse con lenguajes de definición de interfaz (IDL) y descripciones de esquema, que
suelen ser JSON sobre HTTP. De forma similar, los clientes pueden administrarse a través de
una variedad de lenguajes. Los servicios que requieren un alto desempeño pueden usar
búferes de protocolo (protobuf) y gRPC4, que se pueden implementar en más de una docena
de lenguajes.

La independencia con respecto al lenguaje también es un gran beneficio de los archivos

adicionales, como el agente de registros. Al ser local el canal de comunicación, es común que
los archivos adicionales sean escritos en un lenguaje diferente de aquel de la aplicación
primaria. Solo la API del cliente de registros debe escribirse en el lenguaje de la aplicación, y
puede muchas veces generarse automáticamente.

Los servicios llevan a que muchos grupos implementen actualizaciones compatibles con
versiones anteriores, de manera independiente. Los números de versión ayudan a los equipos
desacoplados a comprender si los clientes cuentan con la seguridad necesaria para utilizar
una nueva versión. En la práctica, los equipos suelen usar convenciones en torno a los
números de versiones para reflejar cambios semánticos5.

Los servicios básicos en Kubernetes también son servicios sin estado. Por regla, todos
los pods de un servicio provienen de la misma especificación, y es posible reiniciarlos a partir
de esa especificación en cualquier momento. Este nivel de abstracción es suficiente para la
mayoría de los servicios y también para aplicaciones con la metodología "twelve-factor".
Estos casos suponen que el almacenamiento a lo largo del tiempo es administrado dentro de
otro servicio.

En última instancia, el objetivo real de los servicios consiste en desacoplar equipos. Se

considera que un equipo está desacoplado si puede implementar la mayoría de sus tareas de
forma independiente respecto de otros equipos, lo que siempre fue mucho más fácil en la
teoría que en la práctica. Los servicios son la unidad de implementación: representan la
unidad de encapsulamiento y la base de las API, es decir, una mejor versión de los "objetos",
ya que son más grandes, más duraderos y altamente disponibles. Toda afirmación sobre qué
ocultar dentro de los objetos es también válida para los servicios, y con la programación
orientada a objetos, los microservicios pueden ir más allá6.

4
https://grpc.io/
5
Ver, por ejemplo, https://semver.org/
6 Para acceder a un valioso debate sobre la definición de límites y tamaños de servicios, consultar la sección sobre
"módulos" en el reciente libro de Ousterhout, A Philosophy of Software Design.

© 2019 Google Inc.

 9

El poder del proxy

Como se explicó anteriormente, un proxy es la parte central de la definición de un servicio.
Esto ha sido así desde al menos la década de 19907 y todavía sigue siendo la regla en
diferentes formas de desacoplamiento; es nuestro punto de control más importante para la
implementación de políticas.

El caso de uso inicial para el proxy es simplemente el balanceo de cargas: distribución de las
solicitudes entrantes en el conjunto activo de pods. Además de permitir la alta disponibilidad
en la IP de servicio, esto también permite dividir el tráfico entre versiones para fines de
pruebas de detección de fallos y pruebas A/B. También es el mecanismo que se utiliza para
la implementación progresiva de una nueva versión.

Como hemos desarrollado hasta ahora, el proxy opera en la capa 4 (L4), y funciona a nivel de
TCP e IP. Esto es suficiente para los servicios básicos y también para las aplicaciones
heredadas que esperan DNS, una dirección IP y un número de puerto. Los servicios ubicados
en la capa 7 (L7) suelen usar solicitudes HTTPS, que ofrecen más información y, por lo tanto,
habilitan el uso de políticas más sofisticadas. A largo plazo, esperamos que se utilice L4 para
el control de acceso por partes (a un clúster o espacio de nombres dentro de un clúster) y L7
para implementar las políticas más complejas que requieren las empresas modernas y las
aplicaciones dinámicas. Estas políticas L7 pueden administrarse a través de mecanismos
modernos de control de origen que contemplan una revisión explícita y la aceptación de
cambios en el código fuente (por ejemplo: GitOps).

El proxy también es útil para la telemetría: puede medir indicadores de nivel de servicio (SLI)
para un servicio, como el throughput y la latencia de solicitudes, sin necesidad de conocer el
servicio (un punto clave del desacoplamiento). También puede verificar el estado de los pods
y eliminar cargas en estos. Su telemetría ofrece la base para el ajuste automático de escala
en el servicio.

En las próximas dos secciones, abordaremos dos usos de los proxy. El primer tipo de estos
administra el tráfico entre servicios dentro de una aplicación, lo que suele denominarse
tráfico “Este-Oeste” en virtud del diagrama típico de arquitectura donde los usuarios se
ubican en la parte superior (Norte) y los servicios se distribuyen de izquierda a derecha

7
Ver https://people.eecs.berkeley.edu/~brewer/papers/TACC-sosp.pdf.

© 2019 Google Inc.

 10

(Oeste a Este). El segundo tipo corresponde a un proxy más tradicional orientado al usuario,
que administra el tráfico hacia la aplicación (Norte-Sur) y ofrece autenticación de usuarios,
control de acceso, diferentes clases de gestión de API y mediación.

Administración del ciclo de vida y microservicios con Istio

Los proxy de Kubernetes ofrecen un mecanismo de abstracción de servicios, pero con

funcionalidades algo limitadas. Algunas implementaciones recientes en proxy (por ejemplo:
Envoy) han popularizado el concepto de un proxy de archivo adicional, lo que incorpora
mayor funcionalidad y flexibilidad. Ya que configurar proxy individuales resulta ineficiente, se
requiere una inyección fluida de proxy y una administración sistemática de todos ellos. Esto
constituye la esencia de Istio, un proyecto de código abierto que Google comenzó con Lyft
e IBM8 para hacer frente a los desafíos únicos de la administración de microservicios.

Administración de tráfico
Istio gestiona un grupo de proxy que combina los componentes de una malla de servicios.
Esta malla representa el conjunto de servicios dentro de una aplicación de mayor tamaño
orientada al usuario. Istio administra el tráfico de servicio a servicio (Este-Oeste) y depende
de los proxy que se encuentran en cada servicio. Esto permite el balanceo de cargas en el
lado del cliente, entre las instancias de servicio, además de capacidades de tráfico entrante,
como las pruebas A/B y las versiones para detección de fallos en servicios orientados al
usuario. Los proxy de malla también habilitan capacidades de tráfico saliente, como tiempos
de espera, reintentos e interruptores de circuito, y además mejoran la tolerancia a fallas al
enrutar a servicios web externos. Como cuestión crítica, Istio ofrece una administración
centralizada y sistemática de estos proxy y, por lo tanto, de las políticas que implementan.
Esto es probablemente el desacoplamiento más sobresaliente: las políticas desacopladas de
los servicios. En especial, permite que los desarrolladores eviten políticas de codificación
dentro de los servicios, lo que implica que pueden modificar las políticas sin tener que volver
a desplegar el servicio. De hecho, solo deben actualizar la configuración de los proxy
relevantes para cambiar las políticas. Al ser centralizada la administración, es fácil lograr una
coherencia entre todos los servicios, y es posible aplicar actualizaciones en una
implementación controlada, con el fin de mejorar la seguridad.

En un nivel superior, este modelo también permite desacoplar las operaciones del
desarrollo. Un problema frecuente en TI es que los equipos de operaciones quieren aplicar

8
https://cloud.google.com/blog/products/gcp/istio-modern-approach-to-developing-and

© 2019 Google Inc.

 11

políticas de forma uniforme, pero deben trabajar junto con los desarrolladores para asegurar
que todos los servicios funcionen de la manera correcta. Esto resulta en una costosa
coordinación, como el bloqueo de lanzamientos por revisión de políticas. En el modelo Istio,
es necesaria una menor coordinación, ya que las políticas residen fuera de los servicios. A su
vez, los equipos de desarrollo tienen una mayor velocidad, pueden lanzar diario (o con mayor
frecuencia) y suelen tener más autonomía y más moralidad. En términos generales,
queremos que los desarrolladores de servicios sean responsables de aquellos aspectos
operativos que se relacionan con la disponibilidad y las implementaciones, dejando la
definición y aplicación de políticas amplias a grupos más centralizados.

API del plano de control

Flujo de control durante

el procesamiento de
solicitudes
Datos de
descubrimiento y Certificados
configuración en proxy TLS a proxy
Verificacione
s de política,
telemetría

El tráfico es
interceptado de forma
transparente y asignado
al proxy. La app
desconoce la presencia
del proxy.
Servicio A Servicio B

Figura 2: Arquitectura de Istio

Istio toma estos proxy, como se muestran en la Figura 2, y los administra, lo que ofrece
distintos beneficios que permiten convertir servicios básicos en servicios avanzados con
propiedades y políticas coherentes.

Seguridad
Además de la administración de tráfico, Istio autentica los servicios entre sí, encripta el
tráfico entre servicios (TLS mutuo), ofrece control de acceso para servicios solicitantes, y
genera un registro de auditoría. Estas características se incorporan de forma transparente
sin necesidad de realizar cambios en la aplicación o una administración tediosa de

© 2019 Google Inc.

 12

certificados. La autenticación de Istio automatiza la identidad y autorización de servicios

para habilitar los controles granulares a nivel de la aplicación. Por ejemplo, sería perjudicial si
el proceso de un adversario pueda invocar al servicio de tarjetas de crédito y generar pagos
no deseados. Ver Seguridad en Istio para obtener más detalles.

Observabilidad
La visibilidad de los servicios es crucial para el objetivo de una ejecución segura en
producción, y comprender la telemetría en tiempo real es la pieza clave para construir una
plataforma segura. Istio automatiza la instrumentación de los servicios al generar y recopilar,
de forma automática, datos y registros sobre estos. Al instrumentar de esta manera, Istio
permite una recopilación coherente de datos entre diferentes servicios y backend9. Esto
facilita la generación de paneles y posibilita indicadores de nivel de servicio (SLI) comunes,
como distribuciones de latencia, throughput y tasas de error. A su vez, la consistencia de las
métricas simplifica las tareas de automatización, como el ajuste de escala automático y las
verificaciones de estado (ver ejemplos de telemetría de Istio).

Bases de datos y servicios con estado

Si bien la mayoría de las cargas de trabajo de Kubernetes hoy son cargas "sin estado",
Kubernetes acepta servicios con estado bajo el concepto de StatefulSets, donde cada pod
posee una identidad estable y un disco dedicado que se mantiene a lo largo de los reinicios.
Esto amplía la organización de contenedores a las bases de datos distribuidas,
canalizaciones de datos de transmisiones y otros servicios con estado. Aunque Kubernetes
hace hincapié en la organización de contenedores a gran escala, están surgiendo nuevos
modelos de programación para desarrollar aplicaciones y períodos de ejecución que
permitan administrar lógicas del negocio, la coherencia de datos y las cargas de trabajo cada
vez más distribuidas.

Tecnologías sin servidores y eventos

Los marcos de código abierto, como Knative, codifican las mejores prácticas en torno al
desarrollo de las aplicaciones nativas de la nube, a través de funciones impulsadas por el
origen y microservicios dinámicos e impulsados por eventos. Los encargados de la
producción pueden generar eventos y los consumidores pueden suscribirse a estos eventos
con anticipación, pagando solo por el uso activo del procesamiento impulsado por
solicitudes. El marco de servicios Knative está desarrollado sobre Kubernetes e Istio con
middleware que posibilita la implementación rápida de contenedores sin estado, además del

9 Los adaptadores de Istio Mixer habilitan backend conectables para datos como métricas y registros (https://istio.io/-
docs/reference/config/policy-and-telemetry/adapters/)

© 2019 Google Inc.

 13

ajuste de escala automático a cero, el enrutamiento inteligente e instantáneas de código y

ajustes implementados.

Seguridad confianza cero y modernización de la

garantía de la nube

Google fue pionero en el modelo confianza cero de seguridad de acceso, utilizando proxy
Norte-Sur para aplicar controles más detallados sin sacrificar la coherencia en la experiencia
de los usuarios (ver BeyondCorp: A New Approach to Enterprise Security10 y BeyondCorp:
The Access Proxy11). Al ser un componente clave de la arquitectura general de seguridad de
Google (más detalles en https://cloud.google.com/security/overview/whitepaper), este
modelo de acceso adaptable al contexto aplica la autenticación de servicios y usuarios,
además de controles dinámicos de acceso en todas las aplicaciones.

¿La ruta de red

es vulnerable? Procesamiento,
almacenamiento,
¿Se trata del ¿El dispositivo datos
¿Es correcto que el
usuario real? está en riesgo? usuario acceda a la
API/el servicio?

Empleado

Aplicaciones SaaS de
¿Es correcto que el Google y de terceros
Contratista usuario acceda a las
aplicaciones SaaS?

Figura 3: Modelo de confianza cero en usuarios, recursos y aplicaciones/servicios

Al insertar un gateway de capa de aplicación entre el usuario/navegador y los puntos finales

de servicio de backend, este enfoque hace frente a un desafío clave de los modelos
empresariales tradicionales, que todavía dependen de un rígido perímetro a nivel de red con
firewalls y redes privadas virtuales (VPN). Las aplicaciones móviles y de nube/SaaS
representan la mayoría de las cargas de trabajo empresariales, por lo que el acceso confiable

10
https://ai.google/research/pubs/pub43231
11
https://research.google.com/pubs/pub45728.html?hl=tr

© 2019 Google Inc.

 14

utiliza un contexto "en tiempo real" para aplicar, de manera adecuada, políticas de acceso
para puntos finales en la nube, además de minimizar las costosas violaciones de datos.

Además de asegurar transacciones, este enfoque de gateway basado en el proxy ayuda a

asegurar que los productores de servicio puedan, de manera eficiente, desarrollar,
desplegar y administrar las API que prestan servicios a cualquier backend en la nube.

La telemetría granular, la automatización del plano de control y la coherencia

técnica/operativa de las arquitecturas de nube abiertas permiten a las empresas evaluar
mejor sus activos, servicios y usuarios respecto de los controles en la nube que reflejen las
mejores prácticas de la gobernanza de la seguridad en la nube. También permite a las
empresas avanzar en su modelo de "responsabilidad compartida" para la nube, donde se
definen, de manera ascendente, controles personalizados de seguridad (vertical, región,
establecimiento de funciones, servicios administrados, etc.) para las políticas que controlan
la infraestructura (procesamiento, almacenamiento, redes), la plataforma (canalizaciones
automatizadas de integración y entrega continuas (CI/CD) y GitOps, período de ejecución
seguro, autenticación de servicios y administración del ciclo de vida, privilegios de identidad
y acceso de usuarios) y la capa de aplicaciones (lógica del negocio, experiencia del usuario).

La modernizada cadena de suministro de software seguro de extremo a extremo y el

comercio en la nube con principios de confianza cero aceleran el desarrollo y la compilación,
la entrega y el consumo de servicio y permite cumplir con los siguientes principios y
beneficios clave:

Todos los accesos de usuarios o servicios son verificados y otorgados a través de políticas
de acceso con privilegios mínimos:

• El acceso del usuario a los datos es autenticado, autorizado y registrado en función de

políticas claras basadas en funciones.
• Se aplica una administración centralizada de políticas y configuraciones para los recursos
en la nube, y también para los usuarios y servicios.
• Existe un sólido aislamiento de servicios, de modo tal que cualquier riesgo tenga un
impacto limitado sobre otros dominios.

Las políticas de aplicaciones y usuarios adaptables al contexto permiten proteger datos

© 2019 Google Inc.

 15

sensibles (identidades no reproducibles):

• Se utilizan múltiples factores (más allá del control de acceso basado en funciones
(RBAC), tokens) para autorizar usuarios, recursos y servicios.
• De manera predeterminada, los datos se encriptan en reposo y los datos en tránsito se
movilizan por conexiones encriptadas.
• La autorización binaria asegura que se firmen y se verifiquen las cargas de trabajo
portátiles (VM, contenedores) de forma adecuada.

Se aplica un monitoreo central y una administración continua sobre la postura de seguridad

respecto de recursos, usuarios y servicios:

• Telemetría coherente para los accesos a servicios detallados, no solo sobre registros y
monitoreo sobre IP e infraestructuras.
• Descubrimiento constante para localizar e indexar datos, y controles que permiten
analizar, clasificar y proteger datos.
• Todos los secretos y certificados son firmados a través de un certificado de raíz válido,
sujeto a la administración continua de certificados.
• Expertos confiables de la industria tienen a su cargo el mantenimiento de actualizaciones
de seguridad y parches automatizados.

Hoy más que nunca, las empresas están adoptando rápidamente marcos de software de
código abierto (Kubernetes, Istio, Knative) en sus entornos actuales empresariales y de TI.
Esta evolución en términos de arquitectura posibilita la portabilidad de cargas de trabajo, así
como las abstracciones de servicios en la nube independientes del proveedor y la
administración centralizada de políticas en entornos heterogéneos, lo que mejora el
control de costos y de seguridad y simplifica considerablemente las migraciones
futuras hacia la nube.

El modelo declarativo de configuración y Kubernetes

Hasta ahora hemos explicado el uso de contenedores y pods, además del uso de proxy
administrados para crear servicios avanzados con un buen nivel de desacoplamiento. La
pieza fundamental que resta agregar en nuestra plataforma de servicios en la nube es el
modelo de configuración.

© 2019 Google Inc.

 16

La configuración suele ser uno de los aspectos más complejos de las aplicaciones modernas
y, a lo largo de los años, Google ha creado y descartado una gran variedad de sistemas de
configuración, desde los más simples hasta los más complejos.

Ya que casi todos los aspectos de las aplicaciones y la infraestructura requieren

configuración, necesitamos un modelo que sea coherente y extensible, pero, a la vez, que
tenga una buena relación con la automatización. Idealmente, las herramientas de
configuración deberían también desacoplarse de los sistemas que se configuran.

El primer interrogante hace referencia a qué usar como lenguaje de configuración. Es muy
tentador, incluso para Google en ciertas ocasiones, emplear un lenguaje de para fines
generales, como Python o secuencias de comando de bash. Los lenguajes de este tipo son
muy potentes, ya que pueden resolver casi cualquier problema, pero dan lugar a sistemas
complejos, pueden no ser claros, y su interpretación durante el período de ejecución puede
llevar a comportamientos inesperados en producción.

La ejecución de código como parte de la configuración hace que la automatización sea

mucho más difícil, y esto es todo un desafío distinto. Por ejemplo, los bloques de
configuración suelen fallar durante su ejecución. Es posible que una persona interprete esa
falla y la corrija manualmente, pero un sistema automatizado, por lo general, no puede
hacerlo, ya que no es fácil conocer en qué estado está el sistema luego de una falla. Por
ejemplo: ¿sería adecuado simplemente volver a ejecutar el bloque de configuración? ¿La
ejecución se completó parcialmente y hay acciones que deben deshacerse en primer lugar?

Por el contrario, utilizamos un lenguaje restringido, YAML, que expresa el estado deseado de
un recurso, pero no lo procesa directamente. El objetivo es ser declarativo, esto es, el
lenguaje YAML debería manifestar (“declarar”) el estado deseado del sistema. YAML puede
usarse de forma directa o puede generarse fácilmente mediante herramientas; nosotros
podemos brindar herramientas inteligentes para combinar los cambios cuando existen
múltiples actores involucrados en la configuración (lo que resulta común en sistemas de
mayor tamaño).

Todavía queda por habilitar la automatización, pero en vez de usar código en la

configuración, recurrimos a los agentes en segundo plano ("controladores") para aplicar la
automatización según sea necesario. El enfoque básico se denomina conciliación, y la tarea

© 2019 Google Inc.

 17

del controlador consiste en realizar ajustes sobre el sistema de ejecución (como agregar un
nuevo pod), de modo tal que el estado actual se alinee ("se concilie") con el estado deseado.
Este es un método sólido de coherencia eventual: es posible que lleve algo de tiempo
completar la conciliación, pero cuando el estado real se desvía del estado deseado (sin
modificar) a causa de fallas, el mismo proceso vuelve a alinearlo.

Biblioteca
apiserver controladores
CLI

IU
etcd

Figure 4: Modelo de configuración de Kubernetes.

En conjunto el archivo YAML corresponde al estado previsto, y es administrado mediante una

interfaz RESTful hacia el servidor apiserver (como se muestra debajo). Diferentes formas de
IU, u otras herramientas, pueden impulsar el servidor apiserver, y este guarda el estado
deseado en un almacén duradero de claves/valores (actualmente basado en etcd). Los
controladores observan si existen cambios en el estado deseado y luego toman las medidas
que sean necesarias.

Una de las ventajas de este modelo declarativo es que funciona muy bien con sistemas
modernos de control de versiones, como git: los archivos de configuración son tratados
como código fuente y pueden (y deberían) ser administrados bajo las mismas nociones de
control de versiones, pruebas e implementación. Este sistema es muy general y muy
coherente; por ejemplo, existe un metadato común para los archivos de configuración,
además de una semántica bien definida para actualizaciones, validaciones y eliminación de
recursos. La lógica de negocio de los recursos reside dentro de los controladores, mientras
que el resto es bastante genérica y, por ende, reutilizable y ampliable.

Por ejemplo, los desarrolladores pueden crear "definiciones personalizadas de recursos"

(CRD) que establezcan el esquema de configuración para un nuevo recurso, y un controlador

© 2019 Google Inc.

 18

que implementa el comportamiento del recurso. Las máquinas de servidores API de

Kubernetes ahora pueden administrar nuevos recursos como puntos finales de servicio, sin
necesidad de modificación alguna.

Política como código

Este modelo declarativo y extensible permite la administración automatizada de
configuraciones para servicios que se ejecutan en Kubernetes y en la nube. Las
especificaciones de políticas de Istio (CRD basadas en YAML) pueden aplicarse a través de
controladores administrados que automatizan las actualizaciones de políticas en los proxy.

Las canalizaciones de “política como código” y de CI/CD automatizada garantiza las

implementaciones progresivas y una mejor gobernanza, como auditorías, tareas de
cumplimiento y controles de costos.

Las políticas declarativas ayudar a escalar diversos entornos de nube y garantizar la

coherencia. Los espacios de nombre ofrecen un límite lógico de aislamiento de servicios y
no están sujetos a implementaciones propietarias. Estos espacios también permiten que los
administradores de políticas establezcan una infraestructura de defensa básica y deleguen
políticas (locales) específicas de los usuarios. Asimismo, pueden agruparse de forma
jerárquica según la herencia y utilizarse con etiquetas de metadatos con el fin de aplicar
políticas de usuarios en la nube. Por último, los espacios de nombres admiten el método
"traiga su propio dispositivo" y la federación de identidades para la autenticación y
autorización de usuarios y servicios. A medida que las empresas adoptan modelos de acceso
de confianza cero para sus entornos de nube, los espacios de nombres ayudan a garantizar
controles coherentes de acceso programático y la aplicación dinámica de identidades de
usuarios y servicios a lo largo de entornos actuales y futuros. Con la política como código, la
aplicación de políticas propietarias de custodia de datos es un componente obligatorio de la
definición y activación de servicios.

Conclusiones

La clave para el desarrollo moderno consiste en desacoplar los equipos para que puedan ser
más productivos. El desacoplamiento se presenta de diversas formas, que, en conjunto,
llevan a una evolución más rápida y a mejores sistemas en menos tiempo, con un menor
esfuerzo. Hemos explicado las diferentes maneras que encontramos en el desacoplamiento:

© 2019 Google Inc.

 19

• Contenedores que permiten desacoplar aplicaciones y bibliotecas del SO subyacente y

a máquina.
• Servicios básicos en Kubernetes que permiten desacoplar los servicios de los pods, para
que cada uno de ellos evolucione de forma independiente.
• Los proxy de Istio ofrecen funcionalidades, como la seguridad y la telemetría, en todos los
servicios de una forma uniforme tal que se habilite el desacoplamiento de cada servicio
respecto de su código fuente.
• La implementación y aplicación de políticas habilitadas para proxy permiten desacoplar la
administración de políticas de los servicios específicos, de modo tal que las políticas
puedan evolucionar sin interrumpir los servicios y la postura de seguridad pueda mejorarse
sin cambios en la infraestructura (a través de la política como código).
• El uso de los servicios como unidad de despliegue que suele asignarse a los equipos
específicos permite que estos operen con mayor independencia. Si bien esto puede
derivar en cientos de servicios para una aplicación a gran escala, la infraestructura de
servicios de Istio y Kubernetes facilita su administración.

Al desacoplar la infraestructura, los servicios y los equipos, las empresas pueden mejorar la
agilidad de sus desarrolladores y acelerar la innovación sin poner en riesgo la eficiencia
operativa, la seguridad y la gobernanza.

© 2019 Google Inc.