Imagínate que tienes el día libre: quieres relajarte viendo Hawkeye en Disney+, estás planeado comprar los regalos de Navidad para tus seres queridos desde la comodidad de tu sofá, vas a pedir una hamburguesa con papas para que te lo traigan porque no quieres cocinar, pero ninguna de estas aplicaciones funciona. Vas al enrutador, lo desconectas y vuelves a conectarlo; y aun así nada te funciona. Sabes que no es el Internet… ¿Entonces por qué no está sirviendo nada? Precisamente, este escenario fue lo sucedió a muchos usuarios el pasado 7 de diciembre cuando Amazon Web Services (AWS) se cayó; incidiendo que muchas plataformas como Netflix, Tinder, League of Legends, entre otras no estuvieran disponibles por unas horas.
Caídos por unas horas
¿Entonces qué pasó exactamente? Bueno, la plataforma de estado de servicios o Service Health Dashboard — que indica las alertas o sucesos de AWS que afectan a tu sitio, aplicación, etc.– dice que la raíz del problema fue identificada en las API (Application Programming Interface). Estos servicios están alojados en la región de US-EAST-1 localizada en Virginia, Estados Unidos. También cabe destacar que muchas “dependencias” de Amazon están almacenadas en este sector como empresas de Fortune 500 hasta el Gobierno de EE.UU. y como Amazon siendo la empresa de computación en la nube más grande del mundo, es gran problema en dónde sucedió el inconveniente.
Días después, Amazon sacó un comunicado diciendo que el problema fue desde su propio interno software que causó un error de escalado automatizado en la red principal de AWS. Provocando un “comportamiento inesperado” en una gran cantidad de sus clientes y en servicios fundamentales como el monitoreo, DNS interno y servicios de autorización.
Sin embargo, esta no es la primera vez que se cae AWS. En 2017, mientras un ingeniero estaba depurando un problema con el sistema de facturación en el servicio de almacenamiento en la nube S3, un mal comando redactado por parte de él causó una caída a los servidores por cuatro horas.
Entonces si piensan que estas fallas en los servidores, aplicaciones son poco comunes, están equivocados (o solo mire que pasó en octubre cuando los productos de Meta Inc. estuvieron caídas).
Caption: La revisión de un servidor requiere de paciencia, ahora imagínate varios servidores que almacenan información de las empresas más grandes del mundo.
Para dar más luces sobre lo comunes que son estos sucesos como la qué pasó con AWS, la firma de investigación Gartner Inc. explica que las plataformas en las nubes suelen tener caídas una vez por año.
Entonces no estamos diciendo que AWS es lo peor y que sí lo tienes deberías cambiar. Nada. Es simplemente darte luces que sea independientemente del servicio de almacenamiento en la nube que tengas y los servidores, se van a presentar estas fallas. Lo determinante –y lo explicaremos al final– es cómo puedes enfrentar estas situaciones de la manera más adecuada.
Ahora, ¿qué tiene que ver Kubernetes con AWS?
Antes que todo, quisiera remitirme a la definición de Kuberentes según Amazon: ”Kubernetes es un software de código abierto que le permite implementar y administrar aplicaciones en contenedores a escala. Kubernetes administra clústeres de instancias de informática de Amazon EC2 y ejecuta contenedores en ellas con procesos destinados a implementación, mantenimiento y escalado. Con Kubernetes puede ejecutar cualquier tipo de aplicación en contenedor mediante el uso del mismo conjunto de herramientas para entornos en las instalaciones y en la nube”.
Con base en lo anterior, Kubernetes (o K8s como también es conocido) “administra un clúster de instancias de informática y programa contenedores para que se ejecuten en el clúster en función de los recursos informáticos disponibles y de los requisitos de recursos de cada contenedor”, según Amazon.
Cuando los contenedores se agrupan con base a una lógica establecida, se denominan en pods en lo cual se pueden ejecutar y ajustar la escala de uno o más de estos contenedores dentro esta concentración. Es por esto quepor lo que el software de plano de control de Kubernetes determina cuándo y dónde se ejecutarán los pods, mientras que al mismo tiempo el usuario puede administrar. –Según unas indicaciones establecidas por este– el direccionamiento del tráfico y ajustar la escala de los pods en función del uso y de otras métricas. Aclaramos que los pods tienen su propiao dirección IP y un nombre de DNS único, y que Kubernetes los usa para conectar los servicios entre sí y con tráfico externo.
Caption: Como contenedores en un puerto, Kubernetes son ese transporte que lleva la información de un punto A a B digital en la nube..
Todo lo anterior, ¿no se te hace parecido que el uso de Kubernetes es lo mismo cuando un capitán navega su barco? En caso que sí, ahora entenderás por qué K8s tiene como un logo un timón.
Y bueno, regresando a la relación entre Kubernetes y Amazon, se da a través de Amazon Elastic Kubernetes Services (EKS) y otras asistencias integradas, y gracias a máquinas virtuales (VM) de escala, ayuda an ejecutar K8s, pods y contenedores en las nubes de AWS.
Entonces, AWS facilita la ejecución de Kubernetes. Vimos que con Amazon EKS, el usuario puede usar este servicio que es el plano de control de Kubernetes aprovisionado y administrado automatizado. Pero también a través de Amazon EC2, el usuario puede optar por administrar de “manera manual” la infraestructura de Kubernetes. Todo depende de las necesidades que tenga DevOps.
Si bien mencionamos la relación con Kubernetes, también cabe destacar que otros servicios de computación en la nube como Microsoft Azure y Google Cloud existen, y los K8s se comportan en estas plataformas de la misma forma como AWS.
¿Cómo se vio afectado Kubernetes con la caída de AWS?
Propondré varios escenarios de lo que pudo haber pasado ese día. De nuevo, cualquier parecido a la realidad es pura coincidencia.
Vamos con el primer escenario: DevOps. Desde los developers (desarrolladores), la seguridad es primordial en estas situaciones como la que sucedió. Están caídos todos los servidores, no se sabe cuánto tiempo estarán funcionando de nuevo y ni cuál fue la raíz del problema.
Aplicaciones que manejan datos personales y confidenciales como el nombre de uno, la dirección, tarjetas de crédito son las que más preocupan dado el caso que lo que pasó fuera un ataque cibernético; y algunas plataformas que se cayeron como son Disney+, Netflix requieren esta información para la suscripción. Entonces en este escenario, uno se verá afectado en pensar si las informaciones confidenciales dentro de los contenedores están: a) seguros y b) llegan al lugar qué debe ser.
Por otro lado, desde operaciones la preocupación está a partir de una mirada económica. Supongamos que en este otro ejemplo es un sitio web o aplicación que depende completamente de comercio electrónico. Como la información y los usos de los contenedores en esta tienda virtual no están llegando a su destino final en la nube, el usuario no puede finalizar o hacer sus compras que tenía pensado; ahí se dieron pérdidas financieras para la empresa.
Caption: Navegar Kubernetes durante en la caída de AWS es lo mismo que estar en un barco durante una tormenta en el mar.
No obstante, la caída de AWS no afecta solamente al sector informático y tecnológico. Surge otra pregunta: ¿cómo estuvieron los directores/shareholders de las empresas afectadas en este suceso? Especialmente los directores de marketing. En estas fechas debido a la cercanía temporal a las festividades navideñas, hay una necesidad de generar más ventas con respecto a los demás meses del año.
Sí, AWS estuvo caído un solo día por unas horas; pero quienes han trabajado o trabajan en el sector de ventas y mercadeo saben que cualquier oportunidad de venta en diciembre es oro. Y si por alguna razón externa interfiere con las transacciones (como el acontecimiento de AWS), un día que no se vende en estas fechas de manera adecuada puede perjudicarse en las ganancias del mes.
Pero no nos basemos solamente en los supuestos de venta que no se concretaron sino hay otra cuestión en juego ese día para estos directores de mercadeo en sus empresas: la reputación de marca.
¿Cuántos usuarios que no están enterados con lo que sucede cuando caen los servidores y pasarán por derecho, echando la culpa a la empresa por un mal usuario de experiencia? ¿Cuántas malas calificaciones tendrá el servicio en Google o App Store? Qué dirán la voz a voz entre los usuarios; o en un contexto digital, cómo serán los comentarios en las redes sociales del “pésimo servicio” que brindan ellos.
¿Ya ven cómo se ve afectado Kubernetes con este suceso? Sin poder usar de manera efectiva los servicios de Amazon como EC2 y EKS, no solamente es un problema que afecta al usuario ni DevOps; es un problema que va más allá como el simple hecho de la reputación del servicio y frente a los demás y pérdidas económicas.
Cuando los encargados de mercadeo e IT se reúnan a ver las métricas de ese día, verán datos así casi parecidos como la imagen, con una caída exponencial entre una hora y otra.
¿Cuemby cómo puede ser frente a estas situaciones cuando se caen estos servicios de almacenamiento en la nube?
No sé si están familiarizados con el término cloud agnostic (agnóstico en la nube). A lo que se refiere el término es que cualquier aplicación, plataformas o herramientas que son compatibles con cualquier infraestructura en la nube y se puede navegar entre cada servicio como AWS, Microsoft Azure o Google Cloud sin ningún problema.
Anteriormente les dije que cómo uno puede enfrentar estas situaciones que se caen los servidores, bueno, desde Cuemby tenemos el Cuemby Cloud Platform, una plataforma cloud agnostic, que permitirán que sus servicios naveguen entre AWS a Azure, Google Cloud y viceversa para que puedan funcionar sin ningún problema.
Incubado por
Miembros de
Hatchet Ventures 22 Cohort 1
Nuestras asociaciones y certificaciones
.png)
© Copyright | Cuemby® 2024
