Cloud Computing

Cloud Computing
En este documento vamos a explorar aspectos del paradigma Cloud Computing, vamos a
entender las necesidades a nivel tecnológico y cómo podemos comprender este concepto.
En el siguiente gráfico podemos observar de manera resumida, lo que vamos a navegar en
este documento.

Roadmap de inmersión

1. Entender la operatividad de los centro de datos.

2. Estrategias de migración a la nube (On-premise to Cloud).
3. Los aspectos de plataformas cloud.
4. Infraestructura global, división por capas, seguridad.
5. Arquitectura cloud y aspectos de calidad.
6. Distribución de los recursos.
7. Aspectos que componen Cloud Computing, dimensiones.
8. Modelo de servicio.
Presentation
Antes de entrar en el detalle quisiera hacer mi presentación, mi nombre es Raúl Ándres
Alzate, trabajo al rededor de la tecnología, soy Arquitecto de Soluciones Cloud y
apasionado por el desarrollo de software, desde el 2018 inicie mi camino como arquitecto
cloud y desde entonces he trabajado al frente de multiples proyectos, soy Certificado en
AWS Architect Associate, y profesional en Cloud Native. Mi lenguaje de cabecera es Java,
pero mis demás acercamiento son en NodeJS, C# (Dotnet) y Javascript.

Actualmente desempeño como Technical Coach, y fue el motivador para escribir este
documento, permitiendo compartir parte de mi conocimiento a las personas que entreno.
Soy de Colombia y trabajo en Medellín.

No siendo mas, espero que disfrutes este documento.

On-Premise (Data Center)
Un buen tratamiento de información hace que la operación sea efectiva, de esto se encarga
el área de Tecnología de Información (TI), que generalmente reporta al área administrativa.
Si vemos la perspectiva de la computación, observamos tres frentes, el centro de los
datos, las aplicaciones de negocio y la operación, tal como lo muestra el siguiente
diagrama:

Las necesidades puntuales son requeridas desde el frente de la operación (que a su ves
son requeridos por el área gerencial o administrativo), este lleva la necesidad tecnológica al
área de TI, donde el área resuelve la necesidad con aplicaciones de negocio. Estas
aplicaciones necesitan recursos para poder operar, los recursos estarían dentro de la
empresa o desde una perspectiva de servicios (Cloud Service). El centro de datos es el
enfoque moderno de la computación de la nube y es donde nos vamos a enfocar, pasando
desde un frente de aplicación, hasta redes y almacenamiento.

Todas las compañías dependen del Software y Hardware, en general una buena
administración de estos elementos, hace que una compañía u organización se sostenga
en el tiempo.

Ahora bien, lo que se busca es optimizar y economizar en mayor medida la

infraestructura de computación y la arquitectura de los componentes de
 software. Gracias a la computación en la nube, los centros de datos ayudan a
conseguir esos aspectos.

Si los centros de datos de la organización aun están en las instalaciones físicas, es decir,
en un lugar donde se deben soportar con algún equipo técnico, entonces se debe pensar en
una estrategia para migrar a la nube y llevar los requerimientos de la operación a una
plataforma cloud. Esto si se quiere tener los beneficios de Cloud Computing.
Migration to Cloud
Rehost

Es el modelo de migración a la nube más sencillo, pero también el que tiene más
probabilidades de causar problemas, incrementar los costes y alienar los stakeholders
clave. El rehosting (o también llamado “lift and shift”), consiste simplemente en replicar un
sistema existente en una infraestructura cloud.

Este enfoque tiene la ventaja de ser rápido y fácil, pero también que las ineficiencias y
fallos se migrarán igualmente a la nube. Muchas de las experiencias negativas en
proyectos de migración a la nube reportadas proceden de empresas que eligieron este
modelo de migración sin evaluar plenamente el impacto que supondría.

Re-platform

El re-platforming es un modelo que implica cierto grado de análisis de negocio para

identificar aquellos procesos y servicios que puedan ser eliminados de vuestras
operaciones. Si no se dispone de un equipo con experiencia en este tipo de proyecto, es
recomendable acudir a partners expertos que, además, nos ayudarán a aprovechar al
máximo las ventajas de las tecnologías que no se dominan.

Cambiar a servicios gestionados facilita una migración a la nube relativamente rápida sin
necesidad de rediseñar la arquitectura de la aplicación/workload. Por eso, a esta “R” a
veces se le llama “Lift and Tweak”.

Re-purchase

Como sugiere el nombre, se trata simplemente de recomprar la versión SaaS de una

aplicación que ya usáis. ¿Microsoft Exchange? Cambiad a Office 365 y obtendréis la
funcionalidad Exchange incluida. ¿Microsoft Dynamics ERP? Cambiad a Dynamics 365.

Inicialmente, es probable que la dirección financiera no esté muy dispuesta a comprar algo
que ya tenéis, pero hay buenas razones para convencerla de que es lo mejor. En primer
lugar, el SaaS normalmente se licencia por usuario al mes, por lo que pasáis del modelo de
gasto CapEx al modelo OpEx y nunca pagaréis por lo que no uséis. En segundo lugar, las
aplicaciones on-site son una fuente de gasto en recursos internos, pero si pasáis al SaaS la
responsabilidad del hosting y mantenimiento de la aplicación recae sobre el proveedor. En
otras palabras, podéis generar un ahorro considerable prescindiendo de los gastos en
gestión de infraestructura.

Refactor

El enfoque más avanzado, pero más costoso, a la hora de migrar es el refactoring, que
implica rearquitecturizar aplicaciones y procesos para aprovechar las tecnologías cloud.
En lugar de crear un servidor virtual para hospedar la aplicación, la contenerizas y/o la
conectas a servicios cloud nativos.

Sí, tenéis que volver a desarrollar la aplicación (a veces desde cero), pero este enfoque os
asegura minimizar el uso de recursos cloud, aportando un mayor control sobre la
facturación. También os permite escalar mejor los servicios de aplicación y soporte, así
como los data sets, sin gastos procedentes de gestionar una granja de servidores
virtualizados.

Retain

En algunos casos, no hay razón convincente alguna para migrar un sistema a la nube. Esto
puede pasar por las condiciones de licenciamiento existentes (como claves de licencia de
hardware) o la incompatibilidad general con las plataformas cloud.

En estos casos, se conserva la aplicación tal como está. No significa que vuestra
estrategia de migración sea un fracaso, sino entender que no todo encaja en la nube.
Siempre hay alguna mejora o ahorro que hacer en otros planos.

Retire

Quizás uno de los aspectos más satisfactorios de las migraciones al cloud. Con este
modelo finalmente apagáis algunos de los sistemas que han ido drenando el presupuesto
y los recursos porque ya no se necesitan.

Los sistemas re-comprados son los candidatos por excelencia a ser retirados.
Básicamente, cualquier cosa que ya no se usa puede ser apagada y desechada.
Toda la información anterior es extraída literalmente en la siguiente pagina:
https://www.claranet.es/blog/6-enfoques-para-afrontar-la-migracion-a-la-nube
Platforms on Cloud
"En informática, plataforma es un sistema que sirve como base para hacer funcionar
determinados módulos de hardware o de software con los que es compatible. Dicho
sistema está definido por un estándar alrededor del cual se determina una arquitectura
de hardware y una plataforma de software." Wikipedia

Quizá has escuchado superficialmente acerca de algunas plataformas cloud, actualmente

existen varias de estas plataformas, las más conocidas son AWS, GCP y Azure. Las
características que ofertan son muy similares en estructura y forma. Las gran diferencia es,
cómo se administra los recursos, cómo se organizan los costos por recursos y cómo se
gestionan las responsabilidades compartidas.

Todas las plataformas tienen diferentes maneras de efectuar el cobro para el

procesamiento del computo, ejemplo por uso (el tiempo que están usando el computo),
bajo demanda, por reserva del computo, por computo dedicado (aislado de las demás
máquinas) y existe un termino que es cobro por requerimiento puntual, que es
básicamente una instancia dada por un tiempo determinado.

La mayoría de plataformas se sostienen sobre un modelo de responsabilidad compartida,

entre mas este controlado/gestionado por la plataforma, la responsabilidad es de la
plataforma y entre mas ejerza control el cliente, la responsabilidad debe ser del cliente. Este
modelo de servicio lo veremos mas adelante, lo importante aquí es entender que, no
obstante del nivel de control, existe una corresponsabilidad a la hora de usar estas
plataformas.

Tendencias hasta el momento de GCP vs AWS vs Azure

Lo que vemos en la gráfica es una tendencia del uso de las plataformas a nivel
comparativo de las tres plataformas mas usadas, en la siguiente referencia podrán ver los
cuadrantes mágicos de Gartner del 2019, donde google se incluye como una de las
plataformas de liderazgo a nivel de infraestructura.

https://www.zdnet.com/article/google-cloud-gains-in-gartners-2019-cloud-infrastructure-
magic-quadrant/

A nivel practico hablaremos acerca de estas tres plataformas (AWS, GCP y Azure), los
ejemplos y los servicios estarán enfocados en dichas plataformas, para brindar un análisis
comparativo de las tres.

Otras plataformas

No obstante existen otras plataformas que podríamos resumir en este instante.

Heroku: es una plataforma como servicio de computación en la Nube que soporta

distintos lenguajes de programación. Heroku es propiedad de Salesforce.com
DigitalOcean: Es un proveedor estadounidense de infraestructura en la nube con sede
en la ciudad de Nueva York y centros de datos en todo el mundo. DigitalOcean ofrece a
los desarrolladores servicios en la nube que ayudan a implementar y escalar
aplicaciones que se ejecutan simultáneamente en varias computadoras.
IBM Cloud: Se refiere a una colección de tecnologías y servicios de clase empresarial
desarrollados para ayudar a los clientes a evaluar su preparación para la nube,
desarrollar estrategias de adopción e identificar puntos de entrada de negocios para un
entorno de nube.
Oracle Cloud: Es un servicio de computación en la nube ofrecido por Oracle
Corporation que proporciona servidores, almacenamiento, red, aplicaciones y servicios
a través de una red global de centros de datos administrados por Oracle Corporation.
La compañía permite que estos servicios se suministren a pedido a través de Internet.
VMWare Cloud: Es una infraestructura consistente donde las operaciones son
consistentes y permite administrar toda las aplicaciones en nubes públicas híbridas y
nativas.
Openshift: Es una nube híbrida que ofrece a las empresas un control total sobre sus
entornos Kubernetes, ya sea en las instalaciones o en la nube pública.
Global Infrastructure
Nivel de abstracción de las capas

Diseño de infraestructura orientadas a capas

El objetivo principal del diseño de infraestructura es, proteger siempre los datos, para cada
capa se debe considerar un diseño de mínimos privilegios y con la seguridad necesaria
para que las capas inferiores no tenga afectación de una capa superior.

La seguridad física siempre esta en el borde de la infraestructura de las

Plataformas Cloud. Las directivas y los perímetros son parametrizados y
configurados por el cliente.

Seguridad física: En esta capa se ubica en el borde de la plataforma, aquí se centra la

seguridad por parte de los proveedores de Cloud para entregar contenido y proteger él
mismo.
Directivas y acceso: En esta capa se ubican las especificaciones generales de acceso,
tanto para los privilegios de usuario como la ubicación de los recursos. Estas
 directivas se configuran para proteger los recursos a nivel de acceso.
Perímetros: El perímetro es la geolocalización de los recursos, las regiones y zonas
donde estarían ubicado los recursos, DNS, Balanceadores.
Redes: En esta capa tenemos las VPC, VPN, las Subnet, Firewall, etc.
Maquina virtual: El computo o maquinas virtuales con un sistema operativo dado, una
configuración de red especifica y una capacidad de computo dada.
Aplicaciones: Es la solución dada, el runtime y código fuente.
Datos: Nos referimos a los datos cómo la información almacenada, tato como
información sensible datos como objetos.

Algunos ataques comunes

En cada capa hay algunos ataques comunes de los que deseará protegerse. Esta lista no
es integral, pero puede darle una idea del tipo de ataque que puede recibir cada capa y qué
tipos de medidas de protección debería tener en cuenta.

Datos: La exposición de una clave de cifrado o el empleo de un cifrado sencillo pueden

hacer que los datos sean vulnerables en caso de acceso no autorizado.
Aplicaciones: La ejecución y la inserción de código malintencionado son las marcas
distintivas de los ataques de capa de aplicación. Algunos ataques comunes son los de
inyección de código SQL y de scripts de sitios (XSS).
Maquina virtual: El malware es un método habitual para atacar un entorno e implica
ejecutar código malintencionado para poner en peligro un sistema. Una vez que el
malware está presente en un sistema, pueden producirse otros ataques para exponer
las credenciales y desplazamientos laterales por todo el entorno.
Redes: Los puertos abiertos a Internet innecesariamente son una vía común de ataque.
Por ejemplo, dejar conexiones SSH o RDP abiertas a máquinas virtuales. Cuando están
abiertas, los atacantes intentan acceder mediante ataques por fuerza bruta.
Perímetros: En esta capa suelen producirse ataques por denegación de servicio (DoS).
Estos ataques intentan sobrecargar los recursos de red y obligarlos a desconectarse o
hacer que no sean capaces de responder a solicitudes legítimas.
Directivas y acceso: Aquí es donde se produce la autenticación de la aplicación. Puede
incluir protocolos de autenticación modernos como OpenID Connect, OAuth, o
autenticación basada en Kerberos, como Active Directory. La exposición de
credenciales supone un riesgo y es importante limitar los permisos de identidad.
También es deseable establecer una supervisión para detectar las cuentas en peligro,
por ejemplo, con inicios de sesión procedentes de ubicaciones inusuales.
Seguridad física: Aquí pueden verse accesos no autorizados a las instalaciones que
aprovechan las puertas abiertas y robos de distintivos de seguridad.
Cloud Architecture
Cuando pensamos en arquitectura pensamos en la estructura y la interconexiones entre los
elementos, la forma y los aspectos fundamentales para el diseño y la implementación.
Cuando un arquitecto cloud diseña la solución debe pensar en lo siguiente:

Diseño de arquitecturas resistentes

Definir el rendimiento de la arquitectura
Especificar aplicaciones y arquitecturas seguras
Diseñar arquitecturas optimizadas en costos
Definir arquitecturas operacionalmente excelentes

Le pregunto al lector, ¿será que hay que innovar en el pensamiento de arquitectura?

Esos aspectos son el enfoque de una buena arquitectura, cada descriptor orienta a una
solución idóneo, además de esos descriptores se debe considerar en una arquitectura
moderna:

Descomposición de componentes
El diseñado para un escalado elástico
La persistencia de Polyglot (combinación de tecnologías de almacenamiento)
El procesamiento asincrónico
El diseño para errores (MTTR)
Las pequeñas actualizaciones frecuentes
La administración automatizada
La infraestructura inmutable

Tener en cuenta: Límites de servicio, costee, acuerdo de nivel de servicio, disponibilidad

regional.

En la elaboración de arquitectura una de las principales preocupaciones en el

planteamiento es un diseño altamente acoplado a la plataforma. En lo posible
realizar diseño donde se tenga bajo acoplamiento de las prestaciones de los
servicios.
Veamos entonces los factores de una Arquitectura Cloud.
Cloud Architecture Factors
La arquitectura tiene que ver con el planeamiento, el diseño, la implementación y la mejora
continuos de un sistema de tecnología. La arquitectura en la nube debe contemplar los
requisitos del negocio con las funcionalidades técnicas necesarias para ejecutar esos
requisitos, riesgos, restricciones y costos. Además de interconectar las funcionalidades en
todo el sistema y sus componentes.

Los factores que orientan de manara correcta el diseño y la arquitectura de la computación

en la nube son; atributos de calidad del sistema, principios fundamentales y necesidades
de servicio. Estos factores se debe considerar en el planteamiento de la solución para un
enfoque de arquitectura sostenible.

Arquitectura sostenible, no se refiere a qué la arquitectura sea la misma desde el

planteamiento, se refiere a que cumplan los principios y que se adapte a la solución.
Incorporando mejoras durante el proceso, buscando minimizar el impacto negativo.

Vemos entonces los tres factores fundamentales para la arquitectura cloud:

Atributos de Calidad del Sistema

Principios fundamentales
Necesidades del Servicio

Atributos de calidad del sistema

Los siguientes atributos se debe considerar a la hora de abordar el diseño de la

arquitectura en cloud. Desde el planteamiento se debe identificar y mantenerlos visible
durante el diseño.

Seguridad: facilitar la autenticación y la protección de la aplicación y los datos frente a

puntos vulnerables de la red. Ejemplos de tipos amenazas:
Credenciales expuestas
Malware
Ataques de red
 Suplantación de identidad
Vulnerabilidad de la aplicación
Rendimiento y escalabilidad: basada en la demanda que se tenga en la aplicación,
una cualidad del sistema debe ser capaz de escalar de forma automática,
garantizando el funcionamiento correcto de la aplicación todo tiempo. Ejemplo para
garantizar los atributos:
Capacidad de aprovisionamiento automatico
Demanda eficaz de los recurso
Verificaciones de estados
Disponibilidad y capacidad de recuperación: para garantizar los aspectos de
disponibilidad se debe anticipa a los errores en todos los niveles. La capacidad de
recuperarse dado un tiempo.
Plan de Recuperación de Desastres
El Recovery Point Objective (RPO)
Recovery Time Objective (RTO)
Eficiencia y operaciones: rentable y eficaz es la manera adecuada para abordar la
arquitectura cloud, los gasto en la nube pueden desfavorecer al negocio. Es preciso
tener visibilidad las siguientes características para cada recursos.
Alta Calidad
Alta Velocidad
Alta Eficiencia
Bajo Costo

Principios fundamentales

Veamos los principios fundamentales que rigen una buena arquitectura. Memorizar la
siguiente lista, es necesario saberlos y interpretarlos de forma correcta.

Habilitar la escalabilidad: Asegurar que la arquitectura puede escalar para manager el

incremento de la demanda.
Usa recursos desechables:Pensar en servidores y otros componentes como recursos
temporales.
Automatiza tu entorno: Removiendo procesos manuales para mejorar la estabilidad y
consistencia del sistema, y la eficiencia de la organización.
 Evitar un solo punto de falla: Implementar redundancia cuando sea posible así que
una única falla no afectaría todo el sistema
Optimizar para el costo: Asegurar que los recursos están en el tamaño apropiado, que
basados en la necesidad se escale dentro y fuera, y que se este pensando en las
ventajas de diferentes opciones de precios.
Usa el almacenamiento en caché: Use cache para minimizar las operaciones de
recuperación de datos redundantes.
Asegure su infraestructura en todas partes: Habilitar la seguridad en ambos dentro
del perímetro y entre los recursos.
Acopla libremente tu componente: Reducir interdependencias de manera que el
cambio o falla de un componente no afecte los otros componentes.
Servicios de diseño, sin servidores: Manejar las soluciones como servicios y modelos
de arquitectura sin servidor que pueda proveer gran fiabilidad y eficiencia de los
entornos.
Elija las soluciones de base de datos correctas: Coincidir la tecnología para la carga
de trabajo: seleccionar desde una colección de motores de base de datos, soluciones
NoSQL, opción data warehousing y search-optimized data stores.

Necesidades de servicio

El ultimo factor es la necesidades del servicio, nos acercamos a la promesa que debemos
generar a la hora de prestar un servicio adecuado en el diseño de la arquitectura.

Tolerancia a fallos: Es la propiedad que le permite a un sistema seguir funcionando

correctamente en caso de fallo de uno o varios de sus componentes.
Escalabilidad bajo demanda: A la capacidad de adaptación y respuesta de un sistema
con respecto al rendimiento del mismo a medida que aumentan de forma significativa
el número de usuarios del mismo.
Uso óptimo de recursos: La optimización de recursos es un conjunto de técnicas que
se aplican para llevar a cabo un mejor aprovechamiento de los recursos disponibles en
un proyecto cloud.
Descubrimiento automático para descubrir y comunicarse automáticamente entre sí:
Los sistemas deben ser capas de detectar los nuevos elementos que componen la
solución de forma automática, adaptarse de entre ellos de forma tal no afecte el
funcionamiento del mismo.
Accesibilidad desde el mundo exterior: Comunicación por fuera de la red interna de la
organización, accedidas de forma segura y segmentadas.
Actualizaciones/reversiones sin interrupciones sin ningún tiempo de inactividad:
Desde la perspectiva de entregas constantes se debe garantizar las actualización de
las aplicaciones sin afectar la disponibilidad del mismos.
Systemic qualities
Al momento de diseñar una solución de arquitectura se debe pensar fundamentalmente en
las cualidades que gobiernan el sistema, el enfoque de estas cualidades se debe respetar
en todo el ciclo de desarrollo. Algunos de las cualidades que se debe siempre considerar
son:

Disponibilidad y Resistencia
Eficiencia y Operaciones
Escalado y Optimización de Rendimiento

Veamos a continuación cada uno de ellas.

Availability and resistance
El diseño orientado a la capacidad de recuperación se centra en la recuperación tras una
pérdida de datos o un desastre a gran escala. La recuperación tras este tipo de incidentes a
menudo implica intervenir de manera activa, si bien los pasos de recuperación
automatizada pueden reducir el tiempo necesario para recuperar

Capacidad de recuperación

Se debe realizar un análisis de capacidad para determinar posible perdida de datos o

escenarios con tiempo de inactividad, se debe evaluar costos-beneficios en cada uno de
ellas. Los resultados deben incluir el objetivo de punto de recuperación (RPO) y el objetivo
de tiempo de recuperación (RTO) de la aplicación.

Objetivo de punto de recuperación: Duración máxima de pérdida de datos aceptable.

El RPO se mide en unidades de tiempo, no en volumen: "30 minutos de datos", "cuatro
horas de datos", etc. El RPO trata de la limitación y la recuperación de las pérdidas de
datos, no del robo de datos.
Objetivo de tiempo de recuperación: Duración máxima del tiempo de inactividad
aceptable, donde "tiempo de inactividad" se debe definir según sus propias
especificaciones. Por ejemplo, si la duración del tiempo de inactividad aceptable es de
ocho horas en caso de desastre, entonces el RTO es de ocho horas.

Con el RPO y el RTO definidos, puede diseñar las funcionalidades de copia de seguridad,
restauración, replicación y recuperación de la arquitectura para cumplir estos objetivos

Disponibilidad

El objetivo es agregar redundancia a los componentes de la arquitectura, para que sea

menos probable que experimente una interrupción del servicio. Parte de la estrategia es
incluir agrupación en clústeres y balanceadores de cargas en la soluciones. En relación con
la disponibilidad, identifique el Acuerdo de Nivel de Servicio (SLA) al que se ha
comprometido.
Efficiency and operations
Es necesario identificar los desperdicios para optimizar costos operativos. Veamos algunos
ejemplos de desperdicios que debemos identificar:

Una máquina virtual que tiene siempre un 90% de inactividad.

Pagar por una licencia incluida en una máquina virtual cuando ya se es propietario de
una licencia.
Conservar datos con acceso infrecuente en un medio de almacenamiento optimizado
para el acceso frecuente
Repetir manualmente la compilación de un entorno que no sea de producción.
Una asignación de tamaño incorrecto a las máquinas virtuales.

Con la implementación en la nube, paga por lo que usa, por lo que querrá asegurarse de
que no desperdiciar recursos. Para ayudar a garantizar la eficiencia, intente automatizar
tanto como sea posible, pasar los sistemas de IaaS a PaaS y diseñar las arquitecturas
teniendo en cuenta DevOps.

Siempre que sea posible, le recomendamos que use servicios PaaS en lugar de IaaS. Los
servicios PaaS normalmente cuestan menos que los IaaS y, habitualmente también
generan menores costos operativos.
Scaling and performance optimization
Se trata de escalar los recursos, detectar y optimizar los posibles cuellos de botella, evitar el
mal uso de las herramientas y de las malas practicas de desarrollo de software.

Tipo de Escalado

El escalado horizontal consiste en incrementar la misma instancia la cantidad

necesaria.
Se podría escalar para siempre si tuviese más máquinas para agregar a la
arquitectura.
Este escalado se requiere un balanceador de cargas.
El escalado vertical consiste en incrementar las capacidades de computo de la
instancia.
Las máquinas virtuales están limitadas a la capacidad del host donde se ejecutan,
y los hosts mismos tienen limitaciones físicas.
Tendría limitantes de computo, que la plataforma no disponga de la cantidad
requerida.

Optimización de recursos

El almacenamiento y red se deben garantizar para lograr un optimo rendimiento. Ambos

pueden afectar al tiempo de respuesta de la aplicación. Además de esto es necesario
abordar buenas practicas de desarrollo de software, como también detectar los sistemas
externos que puedan afectar el rendimiento, ejemplo; servicios web.

Patrones

Creación de particiones de datos

Almacenamiento en caché
Escalado automático
Desacoplamiento de tareas que consumen muchos recursos como trabajos en
segundo plano
Uso de una capa de mensajería entre los servicios
Implementación de unidades de escalado
Supervisión del rendimiento
Resource distribution
distrubuyedistrubuye

La distribución de los recursos es clave para poder organizar la operación, a

nivel de seguridad y de respuesta temprana (latencia entre unidades de
computo).

La mínima agrupación de recursos para una implementación son las zonas. Por ejemplo,
cuando inicia una máquina virtual se ejecuta en la zona que usted especifica (a nivel
geográfico). Si bien los usuarios creen que una zona es como un centro de datos, no es del
todo correcto. Una zona no siempre corresponde a un solo edificio físico. Pero puede
visualizar la zona de esa manera. Las zonas se agrupan en regiones que son áreas
geográficas independientes, puede elegir en qué regiones estarán sus recursos. Todas las
zonas dentro de una región tienen una conexión de red rápida entre ellas llamada VPC.

Las ubicaciones en las regiones por lo general tienen latencias de red de ida y
vuelta de menos de cinco milisegundos.

Geolocalización de los recursos

Geolocalización y distribución de los recursos

La operación se distribuyen de tal forma garantice la cercanía de los recursos y la
disponibilidad del mismo. Se tiene el primer nivel, la generalidad del globo terrestre, donde
se distribuye todos los recursos al rededor del mundo (esta infraestructura global permite
proteger las plataformas y distribuir los contenidos). Después tenemos una agrupación de
regiones (multi-región), donde cada región es un punto dado georeferenciado (norte, sur,
oriente, etc...), por ultimo tenemos la zona donde se encuentran los centro de datos. En una
región se tendría mas de una zona para garantizar alta disponibilidad.

Saber dónde posicionar los recursos debe ser estratégico para evitar latencia en la
operación.

Content delivery network (CDN)

CDN es un tipo de infraestructura global en la que se entrelazan varios centros de

almacenamientos de forma distribuida, geográficamente ubicada en varios data centers.
Permite persistir contenido para luego de forma ágil obtener el contenido, esto se relaciona
mucho como un sistema de cache a nivel general de la plataforma.

Sus ventajas son que mejoran la disponibilidad del servidor (uptime, es el tiempo en el que
una máquina o servidor se mantiene activo durante un tiempo determinado), alivian la
carga de tráfico de este, son una barrera mas de seguridad contra ataques informáticos, y
además mejoran el rendimiento y los tiempos de carga.

Azure: Azure CDN

AWS: Amazon CloudFront
Google Cloud: Cloud CDN

Virtual Private Cloud (VPC)

Las redes de nube privada virtual que define tienen un alcance global. Pueden tener
subredes en cualquier región del mundo y las subredes pueden abarcar las zonas que
forman una región. Esta arquitectura le facilita definir su propio diseño de red con alcance
global. También puede tener recursos en diferentes zonas de la misma subred.
Puede aumentar el tamaño de una subred de forma dinámica en una red personalizada al
expandir el rango de las direcciones IP asignadas. Esto no afecta a las VM(Virtual
Machine) que ya están configuradas.

Configuración de una VPC divida en una región y dos zonas

Una VPC se ubica en una región (us-east1), dentro de ella se tiene dos zonas (us-east1-b y
us-east1-c) cada una con una VM con su propia IP asignada con el rango de IPs dada por
la subnet.

Azure: Azure Vistual Network

AWS: VPC
Google Cloud: Cloud Virtual Network

Firewall

Los firewall son componentes de red que se encargan de restringir el acceso a los recursos,
funcionan con reglas especifica donde se podrían priorizar para realizar filtros de
seguridad. El firewall se implementa en las plataformas a nivel virtual, esto quiere decir que
se puede configurar en caliente si necesidad de reiniciar o apagar las máquinas.
Existen dos tipos de firewall, los que son stateless y los que son stateful. Los firewalls sin
estado (stateless) están diseñados para proteger redes basadas en información estática,
como el origen y el destino. Mientras que los firewalls con estado (stateful) filtran los
paquetes según el contexto completo de una conexión de red determinada, los firewalls sin
estado filtran los paquetes según los paquetes individuales.

Balanceador de carga

Un balanceador distribuye la carga entre diferentes nodos de procesamiento de computo,

es un componente virtual que se implementa en un sistema cloud. Los balanceadores
pueden existir a nivel infraestructura global de la plataforma, a nivel de red o a nivel de
aplicación.

Los balanceadores descubren que nodo esta mas cargado y de esa forma distribuye la
carga al menos cargado. Las soluciones que están detrás de un balanceador generan mas
disponibilidad entre ellos.

Balanceador de cargas según la capacidad

Cada balanceador dispone de una IP que se conecta con las IPs de cada nodo, esta IP no
cambia, pero las IPs de los nodos si es posible que cambie, por esa razón el consumidor
siempre apunta a la IP del balance .
 Cada nodo debe ser una replica a nivel de capacidad, además de que la
aplicación que esta en el nodo no debe tener estados, es decir, debe ser
stateless.

Otra cosa importante son los escaladores automáticos, estos escaladores

ayudar a crear nodos en tiempo de ejecución permitiendo tener una flexibilidad
bajo demanda del procesamiento no esperado o no predecible.

Azure: Load Balancing for Azure

AWS: Elastic Load Balancing
Google Cloud: Cloud Load Balancing
Dimensions the Cloud Computing
Cloud Computing agrupa 8 elementos que compone la computación y la administración de
los recursos. Cada uno de estos elementos son dimensionados para operar en Internet a
través de alguna plataforma cloud.

Desde todas las dimensiones Cloud Computing debe cubrir los servicios necesarios para
operar las aplicaciones de negocio. Esto va desde el network hasta el origen de los datos.
Las Plataformas Cloud proveen estos servicios disponiendo los recursos a través de
Internet. No obstante este tiempo de plataformas se consideran publicas, de uso general,
para implantar una solución privada es necesario usar plataformas que se operen desde un
centro de datos local, una de esta es OpenShift. Los nubes privadas son generalmente
usadas para el caso que los datos no puedan salir del país, y este auditada por el gobierno
nacional, en otros casos para poder utilizar la infraestructura local.
 Llevar la operatividad a la nube, es una decisión de las compañías con pensamientos
modernos.

Tres elementos primarios

En este documento vamos a explorar 3 elementos de las dimensiones mencionadas

anteriormente en la gráfica y afianzar los fundamentos que engloban el resto de elementos.
Los tres elementos primarios son; Storage, Network y Vistualization. Las demás
dimensiones derivan de esos tres elementos.

Inicialmente vamos a entender los elementos claves para interiorizar todos estos
conceptos, además de definir aspectos importantes para abordar un buen diseño de
arquitectura y de implementación.

Cuando vimos las capas que componen la infraestructura global, observamos

como se localiza estos elementos dentro de cada capa. Generando un nivel de
seguridad para cada una de ellas.
Storage
Cuando hablamos de almacenamiento, nos estamos refiriendo a la información persistida
en el tiempo. La persistencia es donde se localiza los datos relacionado con el negocio,
donde en ocasiones se tiene grandes cantidades de información e inclusos información
donde se debe recuperar al instante.

El almacenamiento se integra con los sistemas de información logrando perpetuidad de la

información. Existe tres formas de conservar esta información, almacenamiento por
bloque, almacenamiento de archivos y almacenamiento de objetos. Cada uno tiene un
propósito especifico, para cada tipo de necesidad.

Cifrado de datos

Uno de los puntos importantes del almacenamiento es el cifrado de los datos, ayudando a
tener una protección en la información. Todos las plataformas cloud promueven
mecanismo de cifrado, donde se permite configurar para que los datos esten protegidos
por un cifrado manejado por el proveedor o por el cliente.

Critografia

Los documentos, archivos, entre otros, se puede lograr ecriptar. La encriptación tiene un
mecanismo de encriptación y desencriptación, a través de unos algoritmos y llaves que
permite encriptar la información.

Existe dos tipos de la criptografía simétrica y asimétrica. La información de cifrado

simétrico son aquellos que utilizan la misma clave para cifrar y descrifrar un documento.
El principal problema de seguridad reside en el intercambio de claves entre el emisor y el
receptor ya que ambos deben usar la misma clave. Por otro lado la información cifrado
asimétrica es un algoritmo que modifica los datos de un documento para alcanzar
algunas características de seguridad como autenticación. También conocidos como
algoritmos de llave pública.
Snapshot

Los snapshot son copias idénticas en un momento dado, es usa para restablecer
información o para generar backups de los grupos de datos. Un Snapshot ayuda a que la
información no se pierda, en el caso de un desastre donde el Data Center se vea afectado
por un desastre. Para lograr eso se debe buscar redundancia de datos me medio de las
replicas en diferentes regiones.

Backups

Los backups son respaldos almacenados para recuperar el sistema de cualquier falla. Son
estructuras idéndicas de datos en un punto dado de tiempo. También llamadas copias de
seguridad, se usa para respaldar mas que todo datos, información de base de datos o
archivos. El procedimiento de los backups se puede programar en periodos constantes, las
plataformas cloud tienen disponible una configuración para realizar estas copias a través
de reglas, configurando periodos de tiempo, ejemplo; mensual, cada 7 días e incluso cada
hora.

Si necesitamos almacenar mucha información en backup es necesario un volumen de

datos considerable, pero existe una forma de configuración que es la retención de los
datos, esto nos ayuda a indicar cuanto tiempo requiero que esa copia de seguridad este
disponible.

Ciclos de vida

Mucha de la información puede pasar por un ciclo de vida, esto nos ayuda a que el
documento, dato o volumen de persistencia este dentro de un ciclo de vida, y que al final de
el, ya no se persista mas, dejando disponible mas espacio para que información mas
reciente pueda estar disponible.

El ciclo de vida ayuda además a mitigar gastos, dado que, para los grupos de datos
cuando mas este redundante y con alta disponibilidad son mas costosos, entonces se
busca hacer una transición a deferentes tipos de almacenamiento, donde la clasificación
de la información se va almacenando en sistemas menos redundantes y con menos
disponibilidad pero menos costosos.
Block Storage
Cuando hablamos de este tipo de almacenamiento estamos refiriendonos a un volumen de
datos, donde normalmente esta asociado a un disco aislado de los damas. Los datos aquí
son de diferente forma, aunque es necesario montar el volumen para poder acceder a estos
datos, internamente puede existir todo un sistema de archivos.

El bloque de almacenamiento se usa mas que todo para alojar el Sistema Operativo,
aunque también son usados para almacenar datos de una Base de Datos.

El Snapshot, la encriptación y todo lo demás se maneja tal cual, solo que a nivel
de volumen de datos.

Los bloques una vez cifrados no se puede volver atrás. Se debe seleccionar
desde el inicio de la creación o después pero a partir de una Snapshot.

Los bloques como son volúmenes es necesario que estén atachados es decir que estén
conectados a través de un driver, esto indica que un volumen solo puede estar adjunto o
atachado con una instancia.

Azure: Azure Managed Storage

AWS: Amazon Elastic Block Storage
Google Cloud: Persistent Disk
File System
Cuando hablamos de un sistema de archivos, estaríamos hablamos de una estructura
orientada a carpetas, archivos y formatos de almacenamiento. Los sistemas de archivo
son como Bloques de Almacenamiento, pero en ves de guardar información altamente
transitadas como por ejemplo un Sistema Operativo o una Base de datos, este en cambio
es mas liviano y menos I/O.

Además de lo anterior tenemos que este tipo de almacenamiento se soporta por una
conexión y un protocolo de comunicación, permitiendo tener varias conexiones al tiempo,
es decir un sistema de archivo puede estar en varias instancias al tiempo.

Este tipo de almacenamiento es muy usado para cuando se quiera tener

archivos compartidos y colaborativos.

Muchas de las plataformas proporcionan un cliente para poder navegar el la

estructura de archivos, esto facilita la gestión de documentos.

Azure: Azure File Storage

AWS: Elastic File System
Google Cloud: Google Cloud Filestore
Object Storage
Tenemos por ultimo los Objetos, estos son archivos asociados a una única pieza de
información, donde la identidad del objeto esta compuesta pon una llave y un valor y
Metadata de información asociada al objeto.

Los objetos tiene una capa adicional de infraestructura que permite publicar el
recurso a Internet.

Los objetos tiene su ciclo de vida y versionamiento, tratados de forma singular. Son usados
para guardar archivos, paginas web, fotos y datos. No existe una estructura de archivo
orientadas a carpetas, cada unidad se representa por una llave, y el valor de la llave es la
composición del objeto.

La mayoría de plataformas genera alta disponibilidad para la persistencia de esta

información, realizando replicas en diferentes Data Center de una región especifica.

Cada objeto se puede representar por una URL donde el acceso al recursos se hace vía
HTTP.

Mucha de las plataformas proporcionan un repositorio para almacenar los

objetos, este repositorio se configura en una región especifica y con un nombre
único para generar el DNS de acceso publico.

Azure: Azure Blob Storage

AWS: Amazon Simple Storage
Google Cloud: Cloud Storage
Network
Parte de la configuración de nuestra solución es diseñar y configurar nuestra red privada
en la nube, hacer una configuración adecuada nos ayuda a proteger la información y a
segmentar nuestro recursos.

Un VN (Redes de Conexión- Virtual Network) son configuraciones virtuales que se hacen a

través de la plataforma cloud. Cada VN se configura en una región dada, y no es necesaria
mas VN por regiones, es ciertamente limitada a un numero mínimo por regiones.

Una VN dispone de una cantidad de IPs definidas en la creación, utilizando

diferente tipos de mascaras o de bloques para definir el rango de IPs que puede
tener.

Azure: Azure Vistual Network

AWS: VPC
Google Cloud: Cloud Virtual Network

Subnet

Una subnet es una red segmentada con un rango de IPs (configurando el enrutamiento de
dominio - CIDR) limitada por la VN. Existir dos tipos de subnets; una privada y otra
publica. Cada subnet se relaciona con una zona dada, generado una distribución adecuada
de los recursos, este proceso se llama subneting.

Las redes privadas son para alojar aplicaciones que no estén expuestas a Internet, como
por ejemplo una base de datos. Una base de datos debe estar creada dentro de una subnet
privada (y normalmente localizada en una zona geográfica cercana a los recursos que la
usan).

Las redes publicas son las instancias que están expuestas a Internet, y son usadas para
comunicarse del exterior al interior.
 Classless Inter-Domain Routing o CIDR se introdujo en 1993 por IETF y
representa la última mejora en el modo de interpretar las direcciones IP. Su
introducción permitió una mayor flexibilidad al dividir rangos de direcciones IP
en redes separadas. Wikipedia

Gateway

Los Gateway son mecanismos que sirven para enlazar redes entres si, se usan con
diferentes propósito. Para el caso de una red publica es necesario un Gateway que se
conecte a Internet, porque por naturaleza, al crear una subnet no esta vinculada a un
gateway y por ende son privadas dentro de la Virtual Network.

Existe otras Gateway para vincular redes internas o incluso conexiones entre VNs, esto es
conexión como Endpoint.

Otro mecanismo es generar una puerta de enlace para conectar un centro de datos local
(on-premise) a una plataforma, a través de un Gateway tipo Storage.

VPN

Las VPN (Redes privadas vistuales - Virtual Private Network) son mecanismo de
configuración que permite conectar de forma segura dos redes distintas e incluso fuera del
rango de IPs que estarían asociadas. Las VPN es conocen también como Site-to-Site, punta
a punta. Donde conecta dos segmentos de red, permitiendo convivir con un grupo de redes.

Virtual Network Peering

Es otra formar de conectar dos Virtual Network pero en este caso debe ser dentro del
ámbito de Cloud, aquí se debe tener en cuenta con el overlapping, eso pasa cuando las IPs
están en un mismo segmento de Red, es decir la configuración del CIDR debe estar
segmentada con diferente bloque de IPs.

Route Table

Estas tablas son configuradas para enlazar la subnet con el gateway, son mapeadas
directamente con el nombre de la subnet y la configuración del gateway. Así se administra
en un mismo punto las interconexiones con la interfaz de la red mas la interfaz del
gateway.
Virtualization
Cada máquina virtual tiene su propia instancia de un sistema operativo, a su elección, y
puede construir y ejecutar aplicaciones en ella con acceso a memoria, sistemas de
archivos, interfaces de red y otros atributos que las computadoras físicas también tienen.
Pero la flexibilidad tiene un costo. En un entorno como este, la unidad de cómputo más
pequeña es una máquina virtual junto con su aplicación. El sistema operativo invitado, que
es el sistema operativo, puede ser grande, incluso de gigabytes de tamaño. Puede llevar
minutos arrancar. A menudo vale la pena. La máquina virtual es altamente configurable y
puede instalar y ejecutar sus herramientas de elección.

Vistualizaciones de sistemas operativos

Una hipervisor o monitor de máquina virtual es una plataforma que permite

aplicar diversas técnicas de control de virtualización para utilizar, al mismo
tiempo, diferentes sistemas operativos en una misma computadora.

Se puede configurar los recursos del sistema subyacentes, como discos y redes, y puede
instalar su propia base de datos del servidor web o un middleware. Pero supongamos que
su aplicación es un gran éxito. A medida que aumenta la demanda, debe escalar en
unidades de una máquina virtual completa con un sistema operativo invitado para cada
una. Eso puede significar que su consumo de recursos crece más rápido de lo que desea.
 Azure: Virtual Machine
AWS: Elastic Compute Cloud
Google Cloud: Compute Engine

Entorno IaaS

Ahora, hagamos un contraste con un entorno IaaS. Desde la perspectiva de alguien que
implementa una AppWeb, se siente muy diferente. En lugar de obtener una máquina virtual
en blanco, obtiene acceso a una familia de servicios que las aplicaciones necesitan.

Entonces, todo lo que debe hacer es escribir su código y las cargas de trabajo
independientes que utilizan estos servicios e incluyen las bibliotecas dependientes. A
medida que aumenta la demanda de su aplicación, la plataforma escala sus aplicaciones
de manera transparente e independiente por carga de trabajo e infraestructura.

Esto se escala rápidamente, pero renuncia al control de la arquitectura del servidor

subyacente. Ahí es donde entran los contenedores.

Entorno PaaS
La idea de un contenedor es brindarle la escalabilidad independiente de las cargas de
trabajo como las que obtiene en un entorno PaaS, y una capa de abstracción del sistema
operativo y el hardware, como lo hace en un entorno de infraestructura como servicio.

¿Qué obtienes como un cuadro invisible alrededor de tu código y sus dependencias con
acceso limitado a su propia partición del sistema de archivos y hardware? Recuerde que en
Windows, Linux y otros sistemas operativos, un proceso es una instancia de un programa
en ejecución.

Los contenedores vienen a salvarnos, ya no solo funciona en mi laptop sino que también
debe funcionar en el servidor.

Un entorno PaaS muy conocido es OpenShift, que es una nube privada que se
instala en en la máquina privada o en una nube publica como son los
proveedores cloud. Este entorno trabaja con Kubernetes como parte de su core
de operación.
Contenedores

Cada contenedor tratados como una aplicación independiente.

Un contenedor comienza tan rápido como un nuevo proceso, comparador con el tiempo
que lleva iniciar una instancia completamente nueva de un sistema operativo. Todo lo que
necesita en cada host es un sistema operativo que admita contenedores y un runtime de
contenedores. En esencia, se virtualiza el sistema operativo en lugar del hardware.

El entorno se escala como PaaS pero le brinda casi la misma flexibilidad que
Infraestructura como servicio.

Las interfaces están dentro del O/S y los contenedores lo implementa.

La abstracción del contenedor hace que su código sea muy portátil. Puede tratar el sistema
operativo y el hardware como una caja negra. Por lo tanto, puede mover su código desde el
desarrollo, la puesta en escena, a producción o desde su computadora portátil a la nube sin
cambiar ni reconstruir nada.
Si fue a escalar, por ejemplo, un servidor web, puede hacerlo en segundos e implementar
docenas o cientos de ellos dependiendo del tamaño de su carga de trabajo en un solo host.

Consideremos un caso más complicado. Es probable que desee crear sus aplicaciones
utilizando muchos contenedores, cada uno realizando su propia función, por ejemplo,
utilizando el estilo de arquitectura orientado a microservicios.

Contenedores orientados a microservicios

Las unidades de código que se ejecutan en estos contenedores pueden comunicarse entre
sí a través de una estructura de red. Si construye de esta manera, puede hacer que las
aplicaciones sean modulares. Lo implementan fácilmente y escalan de forma
independiente en un grupo de hosts. El host puede escalar hacia arriba y hacia abajo, e
iniciar y detener contenedores a medida que cambia la demanda de su aplicación, o
incluso cuando los hosts fallan y son reemplazados.

Azure: Azure Container Service

AWS: Elastic Container Service
Google Cloud: Container Engine
Docker
Docker es para empaquetar y distribuir una solución desde la vista de infraestructura. Esta
orientado paras las aplicaciones o servicios, su principal ventaja es la transportabilidad y la
interoperabilidad.

Docker permite limitar los recursos de la solución, permitiendo compartir

recursos de una maquina (maquina anfitriona — VM), y de igual forma aislar los
fallos por medio de la configuración de los contenedores. Separa las
preocupaciones de Network, Compute y Storage.

¿Cómo funciona?

De forma muy general, docker interactua por medio de capas, la capa principal consiste en
un microkernel de un sistema operativo (normalmente Linux). Cada capa se genera
especificaciones de configuración particulares para el uso especifico de la aplicación. Por
ultimo se tiene la capa de solución donde se pueden hacer cambios y modificar su
comportamiento, las capas superiores son
Desde la capa de la App, es donde construiremos nuestra imagen, propia de la solución
implementada. Una imagen es el resultado final de la solución, podemos extender una
imagen y heredar toda su configuración. — Esto lo veremos más adelante con un ejemplo.
—

Otro punto importante es lo que se considera como contenedor para docker.

Un contenedor es una representación de implementación dada por una imagen compilada.

Es decir, el contenedor es la forma de cómo se gestiona y se ejecuta una imagen en
particular. Varios contenedores pueden usar una imagen en particular.
Las imágenes se almacenan de forma local (en tu maquina) al momento de compilar una
solución y a nivel remoto por medio de un Container Registry, que es un repositorio de
imágenes (ejemplo docker-hub). Los contenedores corren gracias a un demon o un Runner
Container para ejecutar la imagen.

Cada contenedor se configura para se aislado, a nivel de red se usan los

puertos, a nivel de capacidad de computo y a nivel de almacenamiento a través
de volúmenes. También los contenedores son efímero, esto quiere decir que un
contenedor es mortal, no persisten en el tiempo, si se elimina no se volverá a
recuperar, pero si se puede regenerar de nuevo, a través del build de Dockerfile.
— Una mala practica es ejecutar comandos dentro del contenedor como parte
de la solución, para eso se debe incluir en el archivo Dockerfile que veremos
mas adelante. —

Ejemplo de un Dockerfile
 Java

1 FROM fabric8/java-alpine-openjdk8-jre
2 WORKDIR /opt/microservicio
3 COPY spring-boot/build/libs/spring-boot*.jar app.jar
4 EXPOSE 8080
5
6 RUN mkdir -p /opt/microservicio/external
7 VOLUME /opt/microservicio/external
8
9 CMD ["java","-jar","app.jar"]

C#

1 FROM mcr.microsoft.com/dotnet/core/aspnet:2.2
2
3 WORKDIR /opt/microservicio
4 ADD out /opt/microservicio
5 EXPOSE 8080
6
7 RUN mkdir -p /opt/microservicio/external
8
9 ENTRYPOINT ["dotnet", "app.dll"]

El archivo Dockerfile agrega las capas necesarias para la construcción de la imagen, se

basa de una imagen principal usando la definición FROM. Podemos usar WORKDIR para
crear una dirección de carpeta y posicionarnos en ella. Lo que es la ADD y COPY es una
capa sincrona donde intercambia archivos desde tu local a la imagen. EXPOSE expone el
puerto dentro del la solución. Tenemos otra capa que es RUN esta sirve para ejecutar batch
o comandos particulares del OS. Por ultimo tenemos ENTRYPOINT o CMD, son usadas
para ejecutar la solución como una orden interna del contenedor.
Kubernetes
Kubernetes es un marco de orquestación para contenedores de software. Los contenedores
son una forma de empaquetar y ejecutar código que es más eficiente que las máquinas
virtuales. Kubernetes proporciona las herramientas que necesita para ejecutar aplicaciones
en contenedores en producción y a escala.

Kubernetes desde diferentes dimensiones

Automatiza la implementación, el escalado, el equilibrio de carga, el registro, monitoreo y

otras características de gestión de contenedores aplicaciones. Estas son las características
de soluciones típicas de PaaS.

Kubernetes también facilita las características de IaaS, como permitir una amplia gama de
usuarios preferencias y flexibilidad de configuración.

Kubernetes es una herramienta donde engloba los aspectos generales de Cloud-Native,

donde es ideal para un modelo de servicio cloud tipo Hybrid.

Características

Soporte de aplicaciones stateful y stateless

Auto-escalado
Limitación de recursos
Extensibilidad
Portabilidad
 Interfaces de Aplicación
Balanceador de Carga

Kubernete maneja el modo de escalado scale in y scale out para las

aplicaciones contenerizadas.

Solución de arquitectura

Uno de los estilos de arquitectura más usado en las soluciones empresariales, son las
arquitecturas orientadas a microservicios.

Un microservicio es una unidad de software con una responsabilidad de dominio bien

definida y de forma independiente. Cada contenedor representa un host de forma
independiente. Como el siguiente ejemplo:

Contenedor orientado a microservicios con host independientes

Ahora bien, para administrar esos hosts es necesario un orquestador, aquí es donde
Kubernetes tiene sentido para este estilo de arquitectura.
 Contenedor orientado a microservicios con un kubernetes

Kubernetes facilita la orquestación de muchos contenedores en muchos hosts. Permitiendo

el escalado, el despliegue de nuevas versiones, el rollback de versión anterior, entre otros.

Implementación

Kubernetes requiere un Container Runtime para correr los contenedores, uno de ellos es
Docker. Esta tecnología la vimos en la pagina anterior.

En nuestra solución tendríamos el archivo Dockerfile con las indicaciones para construir la
imagen en nuestro sistema local. En el siguiente ejemplo veremos cómo construir, etiquetar
y empujar nuestra imagen a un Imagen Register (un ejemplo seria docker-hub).
 Java

1 export COMPONENT_NAME=spring-boot
2 export URL_REPO=[URL OF THE CONTAINER REGISTER]
3
4 echo "Building object [$COMPONENT_NAME]..."
5 ./gradlew :spring-boot:build build
6
7 echo "Building image [$COMPONENT_NAME]..."
8 docker build -t $COMPONENT_NAME .
9 docker tag $COMPONENT_NAME:latest $URL_REPO/$COMPONENT_NAME:latest
10
11 echo "Pushing image [$COMPONENT_NAME]..."
12 docker push $URL_REPO/$COMPONENT_NAME:latest

C#

1 export COMPONENT_NAME=dotnet
2 export URL_REPO=[URL OF THE CONTAINER REGISTER]
3
4 echo "Building object [$COMPONENT_NAME]..."
5 dotnet restore
6 dotnet build
7 dotnet publish -c Release -o out
8
9 echo "Building image [$COMPONENT_NAME]..."
10 docker build -t $COMPONENT_NAME .
11 docker tag $COMPONENT_NAME:latest $URL_REPO/$COMPONENT_NAME:latest
12
13 echo "Pushing image [$COMPONENT_NAME]..."
14 docker push $URL_REPO/$COMPONENT_NAME:latest

Estas instrucciones también crean el Contenedor y lo almacena en el sistema local como

una imagen ejecutable.

Docker es la tecnología de contenedores más popular pero también existe más como;
containerd, rkt, CRI-O.
El paso a seguir es usar la imagen con una implementación de Kubertentes usando la
siguiente linea de comandos (o se podría usar un archivo yaml).

kubectl run $COMPONENT_NAME --image=$COMPONENT_NAME:latest

Lo anterior ilustra un poco cómo son los aspectos a tener en cuenta para poner
en marcha una implementación en Kubernetes, se esta asumiendo una etapa
anterior de configuración.

¿Cómo trabajar Kubernetes?

El trabajo de Kubernetes es hacer que el sistema implementado se ajuste a su estado

deseado y mantenerlo allí a pesar de las fallas. La configuración declarativa le ahorra
trabajo, permitiendo mantener la configuración a través de archivos (el manifest en
formato yaml), también existe la configuración imperativa donde se puede puedes cambiar
el el sistema por medio de comandos en linea.

Arquitectura

Kubenertes necesita de las maquinas virtuales, estas VM son nombradas como nodos,
mínimamente se necesita una maquina que sirve de orquestación (master) o otras
maquinas que alojan la soluciones contenerizadas. Todo el trafico interactua por medio del
master dónde se podría configurar para que este dentro de una red publica o una red
privada. El computo siempre estaría en una infraestructura subyacente.
Esta arquitectura permite manejar un cluster de VM, donde la flaxibilidad del computo se ve
reflejado en las unidades de nodos que se puede asignar el cluster.

Kubernetes tiene toda una arquitectura donde controla y supervisar los

contenedores, este es conocido como Kubernetes Control Plane.

Interfaz de comando

Para utilizar kubernetes es necesario una interfaz de comando llamada kubectl (kube-
control), esta interfaz de comando (CLI) nos ayuda a interactuar con el Control Plane de
Kubernetes, donde por medio de ordenes podemos crear, administrar, monitorear y
gestionar el orquestador, pero no los nodos.

La administración de los nodos se encarga el proveedor, la plataforma o la

herramienta para administrar el cluster.
Veamos un ejemplo de cómo implementar una solución de forma imperativa.

1 echo "esto crea un Deployment de un solo pod que contiene el contenedor "
2 kubectl run $COMPONENT_NAME --image=$COMPONENT_NAME:latest
3
4 echo "expone el deployment a internet"
5 kubectl expose deployment $COMPONENT_NAME --port 8080 --type LoadBalancer
6
7 echo "escala el contenedor de la implementación con 3 replicas"
8 kubectl scale deployment $COMPONENT_NAME --replicas 3
9
10 echo "Se actualiza los nuevo pods con las repicas"
11 kubectl get pods
12 kubectl get services

En el ejemplo anterior se ejecuta la imagen publicada en el Imagen Register, luego se

expone el contenedor para que sea accedido desde una IP Externa, se configura el número
de replicas y por ultimo revisamos los pods y los servicios.

AWS: Elastic Kubernetes Service

Azure: Azure Kubernetes Services
Google Cloud: Google Kubernetes Engine
Service Model

Los centros de datos virtualizados (el computo de bajo nivel) ofrecen infraestructura como
servicio (IaaS) y plataforma como servicio (PaaS). Las ofertas como Software como
servicio (SaaS) proporcionan infraestructura elemental para computación,
almacenamiento y red organizada de forma que la administración del mismo este al lado
de la plataforma.

Entre más bajo sea el nivel, más se tendrá que administrar por el cliente,
teniendo la responsabilidad de escalado, balanceo, red y configuraciones.

Por otro lado, las ofertas de PaaS vinculan el código de aplicación que usted escribe a
bibliotecas que dan acceso a la infraestructura que necesita su aplicación. Así, pueden
enfocarse en la lógica de sus aplicaciones, esto hace que la plataforma administre cierta
parte de la solución, que en comparación con IaaS este debe ser configurado por usted.
Tipo de Modelos
Vamos a explorar cuatro modelos fundamentales para entender los aspectos de cloud
computing, cada modelo lo estaríamos detallando más adelante.

Modelo Serverless

La computación sin servidor (o serverless para abreviar) es un modelo de ejecución en el

que el proveedor en la nube (AWS, Azure o Google Cloud) es responsable de ejecutar un
fragmento de código mediante la asignación dinámica de los recursos. Y cobrando solo
por la cantidad de recursos utilizados para ejecutar el código.

El código, generalmente, se ejecuta dentro de contenedores sin estados, que pueden ser
activados por una variedad de eventos que incluyen solicitudes HTTP, eventos de base de
datos, servicios de colas, alertas de monitoreo, carga de archivos, eventos programados
(trabajos cron), etc. El código que se envía al proveedor en la nube para la ejecución, es
generalmente una función. Por lo tanto, serverless a veces se denomina “Funciones como
servicio” o “FaaS”. Las siguientes son las ofertas de FaaS de los principales proveedores en
la nube:

AWS: AWS Lambda

Microsoft Azure: Azure Functions
Google Cloud: Cloud Functions

Mientras que serverless abstrae la infraestructura subyacente al desarrollador, los

servidores aún participan en la ejecución de nuestras funciones.

Modelo PaaS

PaaS incluye infraestructura como; servidores, almacenamiento, redes, y entre otros

servicios administrados de la plataforma. PaaS está diseñado para sustentar el ciclo de
vida completo de las aplicaciones web: compilación, pruebas, implementación,
administración y actualización. Ademas de la administración de licencias de software y
otras aspectos complejos de la infraestructura.

La característica fundamenta es que en este modelo no es requeridos los aspectos del

sistema operativo, la intenciones es solo enfocarse en el runtime de la aplicación, los
aspectos de seguridad y redes son subyacentes a la solución.

Azure: Web Apps

AWS: Elastic Beanstalk
Google Cloud: App Engine

Modelo IaaS

En este modelo nos debemos de preocupar por la infraestructura del mismo, nos daría el
control pero también la responsabilidad del mismo.

Cuando hablamos de la estrategias de migración, podemos pensar inicialmente en

pasarnos a un IaaS. Como una transición al modelo de servicio.

En el modelo IaaS, paga por lo que asigna. En el modelo PaaS, paga por lo que usa. Ambos
superan a la manera antigua en la que se compraba todo por adelantado. Con la evolución
de la computación en la nube la atención cambió hacia la infraestructura administrada y
los servicios administrados. Las plataformas clouds ofrece muchos servicios con los que
no necesitan preocuparse del aprovisionamiento de recursos.

Los proveedores de cloud ofertan este servicio como virtualización con diferentes tipos de
computo, variando así económicos, de especialización y de disponibilidad:

AWS: Elastic Compute Cloud (EC2)

Microsoft Azure: Azure Virtual Machines
Google Cloud: Compute Engine

Modelo Hybrid
Cloud-native es un enfoque para crear y ejecutar aplicaciones que explota las ventajas del
modelo de entrega de computación en la nube. Lo más importante es la capacidad de
ofrecer una potencia informática casi ilimitada, bajo demanda, junto con servicios
modernos de datos y aplicaciones para desarrolladores.

Cuando hablamos de Cloud Native hablamos de portabilidad, independencia de

la plataforma, escalabilidad, predecible, independiente, rollback y entregas
constantes.

Cloud-native trata sobre cómo se crean y despliegan las aplicaciones, no dónde.

Las abstracción del sistema operativo

Una arquitectura de aplicación nativa de la nube permite a los desarrolladores usar una
plataforma como un medio para abstraerse de las dependencias de infraestructura
subyacentes. En lugar de configurar, parchar y mantener los sistemas operativos, los
equipos se centran en su software. El medio de abstracción más eficiente es una
plataforma formalizada, por ejemplo, Google Cloud Platform (GCP), Microsoft Azure o
Amazon Web Services (AWS).

Kubernetes as a Service

Kubernetes es una herramienta open-source que nos permite automatizar la

implementación, el escalado y la administración de aplicaciones en contenedores, con
kubernetes podemos trabajar con Cloud-Native. Las siguientes son las ofertas de Cloud
Native usando Kubernetes como servicio:

AWS: EKS( Elastic Kubernetes Service)

Microsoft Azure: AKS (Azure Kubernetes Services)
Google Cloud: GKE (Google Kubernetes Engine)
Correlación de los Modelo de Servicio
Entendiendo los tipos de modelos, podemos resumir lo siguiente de acuerdo a lo que vimos
anteriormente:

Interpretación del modelo administrado y dinámico

En la anterior imagen podemos interpretar con respecto a las preocupaciones de la

infraestructura, si nos acercamos a un modelo IaaS debemos pensar más en los aspectos
de la infraestructura (redes, balanceo, escalado, seguridad), pero si nos alejamos de el, las
preocupaciones se van alejando, hasta volverla de forma dinámica donde las
preocupaciones se disminuyen.

Un modelo PaaS o Hybrid (Cloud Native) en ocaciones es atractivo porqué tenemos

control del mismo y ademas de no preocuparnos por esos factores técnicos nos daría
más capacidad para hacer innovación.

Serverless vs Hybrid

En ambos modelos podemos innovar rapidamente, podemos llegar a soluciones

tempranas, pero en generar los modelos serverless están mas orientados a desarrollo con
una necesidad de cambios mas constante, donde el modelo pay-as-you-go (es un método
de pago para la computación en la nube que cobra según el uso) es la premisa.

el modelo hybrid es muy atractivo dado que no generamos un vinculo fuerte con la
plataforma, si pensamos además en algún momento cambiar de proveedor o usar los
recursos on-premise. El modelo de pago es on-demand, pagamos bajo en consumo.
Describo estos dos modelos porque mas me atraen y más pongo en practica, aunque en
soluciones intermedias pienso también en un modelo PaaS.
Gratitude
En este espacio quiero agradecer a las siguientes fuentes de información que me
proporcionarón la inspiración para poder abordar este documento:

https://es.coursera.org/learn/google-kubernetes-engine
https://azure.microsoft.com/es/
https://aws.amazon.com/es/
https://kubernetes.io/es/

Muchas de la información suministrada en este documento se puede consultar en las

referencias anteriores.

Los gráficos y demás recortes pueden hacer uso de ellos en el siguiente enlace:

https://drive.google.com/file/d/1mznkg4
cloud-computing RMmgA1IKZLH2nFgYoqbOlsTRdW/view?
usp=sharing

Y agradecerte a ti por leer este documento y esperar que pueda servirte

de mucha ayudar, si quieres contáctarme y conversar al respecto puede
seguirme en el twitter en siguiente enlace:

Raul A. Alzate (@2a_raul) | Twitter https://twitter.com/2a_raul