¿La nube lo desafía? Enfréntela sin miedo

Los desafíos son parte de la vida y los desafíos en tecnología no son distintos

Por Eric Johnson

La realidad de la vida es que vivimos con desafíos. Esto es cierto en todo aspecto de nuestras vidas, tanto personal como profesional.

He dado muchas charlas acerca de cómo lidiar con desafíos en muchos grupos diferentes. No solo acerca de sobrevivir desafíos sino de superarlos y crecer. Creo de todo corazón en que superar los desafíos comienza con actitud y requiere del poder de la iteración.

Antes de que entremos en el tema, tal vez usted se pregunte: “¿Quién es este para darme consejos sobre desafíos?”. ¡Gran pregunta! En primer lugar, soy un humano, y con esa simple afirmación, tengo experiencia ante los desafíos. Pero eso podría no ser suficiente. He aquí un poco de mi historia como contexto.

Nací con un dedo en cada mano y un dedo en cada pie. En un cuarto saturado, salto a la vista ligeramente, pues soy aquel que come con ambas manos y señala mucho. Además de esto, cuatro de mis cinco hijos son como yo. Entiendo lo que significa tener una vida con desafíos. Sin embargo, quiero dejar algo en claro: no creo tener más desafíos que cualquier otra persona. De hecho, veo esto como una bendición, en lugar de una maldición. Como dije, actitud.

La segunda pregunta que podrían hacerse es “¿Por qué esto es un blog post técnico?”. Bueno, hasta ahora lo que hemos repasado es que soy un creador de rosquillas innato con una gran actitud. (Tal vez eso lo descubra un poco después). De cualquier manera, esa es otra gran pregunta, y he aquí mi respuesta:

Las lecciones de vida que le enseño a mi familia y de las que hablo en grupos son extremadamente aplicables al mundo de la tecnología, y, en particular, dentro del mundo de la nube. A lo largo del resto de este texto, aplicaré brevemente esas lecciones de vida a un problema técnico específico que enfrentamos en la industria de la tecnología.

Todos enfrentamos un desafío

La primera lección es que todos enfrentamos desafíos. En todo lo que hacemos, enfrentamos desafíos que debemos superar. Trabajar con tecnologías de la nube es lo mismo. Durante los últimos ocho años, he trabajado con tecnologías de nube y constantemente he peleado para mantenerme al día con ese conjunto de características siempre en evolución.

En 2015, Amazon Web Services añadió 722 características a su plataforma de nube. Eso equivale a dos características diarias. En 2016, AWS va camino a superar ese número. Como líderes en tecnología e implementadores, este es el desafío que enfrentamos. La nube crece a un ritmo drástico que aumenta el conjunto de características disponibles a la vez que disminuyen los conocimientos.

Sin excusas

La segunda lección que necesitamos aceptar es que ya no hay excusas. En mi familia, no permitimos que un “no puedo” nos gobierne. Les enseñamos a nuestros hijos el poder del “todavía”. “No puedes todavía.” No les permitimos decir: “No puedo hacer esto porque tengo un desafío físico.”

La misma mentalidad necesita utilizarse a cómo nos aproximamos a la tecnología. Dos de las excusas principales que escucho en el lugar de trabajo relacionadas con la nube son la excusa de arquitectura y la excusa de conocimiento.

La excusa de arquitectura

La excusa de arquitectura dice: Mis aplicaciones no tienen la flexibilidad para cambiar fácilmente”. Muchas veces nuestra capacidad de ir a la nube y permanecer relevantes queda truncada por una aplicación que no es iterativa. La aplicación es tan monolítica que es frágil y no puede hacérsele siquiera un cambio “pequeño”. Siguiendo la filosofía de “ni una excusa”, yo le digo… ARRÉGLELA. Sé que esto parece demasiado cruel, pero lo cierto es que este tipo de arquitectura lo limita sin importar si adopta o no la nube. Le invito a que analice tecnologías y patrones que le permitan llevar su aplicación a un estado iterativo. Algunos ejemplos serían:

  • Microservicios: Divida su backend en microservicios aislados que hagan solo una cosa pero que la hagan muy bien.
  • Redundancia: Incluya redundancia en su arquitectura. Quite los puntos de falla.
  • Interacción asíncrona: Separe sus servicios y permítales continuar incluso si otro servicio falla. Con frecuencia esto se logra con metodologías como Pub/Sub o colas.
  • Automatización: Asegúrese de que su aplicación pueda implementarse de manera segura y fácil a través del uso de automatización Continuous Integration and Continuous Delivery (CI/CD).
  • Cobertura de pruebas: Cubra su aplicación con pruebas. Esta es la red de protección del desarrollo. Estas pruebas deberán ser automatizadas y estar incluidas en el proceso CI/CD.

La excusa del conocimiento

La segunda excusa que escucho con frecuencia dice: “No sabemos cómo aprovechar esta nueva tecnología y no podemos darnos el lujo de aprender a usarla”. Esta pregunta tiene algo de verdad pues es la base del desafío que enfrentamos. ¡No sabemos cómo hacerlo! Sin embargo, en la segunda parte de la pregunta, yo cuestionaría: “¿Y NO puedes darte el tiempo para aprender?”. Déjeme enfatizar este punto con un caso práctico:

El Sr. Smith ejecuta una gran aplicación de WordPress que contiene millones de lectores. Para dar soporte a su aplicación en AWS de manera altamente disponible, ejecuta 10 instancias de MySQL en RDS, todas ellas MultiAZ. Esas son máquinas r3.8xlarge bastante grandes. Ejecutar esto le cuesta alrededor de 55,350 dólares al mes.

El Sr. Smith escucha que hay un producto llamado Amazon Aurora, una base de datos compatible con MySQL que funciona en RDS. Él se entera de que con Aurora ya no necesita especificar MultiAZ, pero sí necesita leer réplicas si quiere tolerancia ante fallas automática sin tiempo de recuperación. Por tanto, activa 10 instancias de Aurora pero las divide en cinco servidores primarios y cinco réplicas e lectura. Ahora su costo para bases de datos es alrededor de $33,969.

Esto le genera un ahorro de casi $22k mensuales. Pero, el ingenioso Sr. Smith rasca un poco más al fondo de Aurora y descubre que pruebas de AWS con SysBench en instancias r3.8xlarge muestran que Aurora entrega más de 500,000 SELECTs/seg y 100,000 actualizaciones/seg, que es cinco veces mayor que MySQL, ejecutándose con las mismas referencias y en el mismo hardware.

El Sr. Smith se da cuenta de que podría reducir su número de bases de datos a una quinta parte de lo que tiene actualmente. Teniendo en cuenta esto, reduce el número a una base de datos primaria y una réplica de lectura: dos servidores en total. El costo mensual total por sus bases de datos ahora es de $6,793. Eso implica un ahorro de $48,557 dólares mensuales. Así que usted dígame, ¿puede darse el lujo de no estar informado?

Resolver la excusa del conocimiento es fundamental para la supervivencia de su empresa. Sé que eso suena serio. Pero con la llegada de las tecnologías de nube, una compañía incipiente puede hacer lo mismo que usted por una fracción del costo. En resumen, el conocimiento es relevancia. Mi sugerencia para superar la barrera del conocimiento es ya sea crear un equipo interno dedicado a mantenerse informado o asociarse con un equipo externo como Rackspace, que se dedica a mantenerse informado. Con ahorros de $50k mensuales, el Sr. Smith no tiene problemas para pagar los costos.

El modelo

La tercera lección que le enseño a mi familia es que ellos son el modelo de otros. Les digo específicamente: “La manera en que tú enfrentes un desafío es el modelo con el que otros lo enfrentarán”. Lo mismo va para nosotros como líderes en nuestras compañías. La manera en que veamos el desafío de la nube es la manera en que nuestros equipos lo verán. ¿Ve la nube como una caja de herramientas en constante expansión que está a la espera de que la explore? ¿O usted permite que la nube le quite brillo a su tecnología?

A pesar de que este no es un blog de liderazgo, sería negligente de mi parte no dar una opinión acerca de cómo construir un equipo tecnológico efectivo. O tal vez solo es que quiero escuchar mi propia voz conforme lo escribo en la computadora. Sea como sea, aquí va.

En su libro Team of Teams: New Rules of Engagement for a Complex World, el general Stanley McChrystal hace la pregunta: ¿”Qué pasaría si usted pudiera combinar la adaptabilidad, agilidad y cohesión de un pequeño equipo con el poder y recursos de una organización gigante?” Su respuesta es crear un equipo de equipos que demuestre ser más rápido, más homogéneo y flexible.

Muchas compañías de tecnología han modelado este diseño. AWS le llama el “equipo de dos pizzas”, refiriéndose a que se deben crear equipos a los que puedas alimentar con dos pizzas y no más grandes que eso. Spotify les llama tribus y gremios. La idea es usar pequeños equipos que tienen un proyecto particular de principio a fin. Tienen poder, agilidad, son iterativos y comunicativos. Estos equipos tienen la libertad de fallar y aprender de esos fracasos.

La meta general de este enfoque de liderazgo es inculcar una actitud de iteración. Así como a mis hijos se los enseño, la idea es entender que el fracaso es simplemente un éxito que no ha ocurrido… todavía. El valor de “todavía” es que nos motiva a intentar de nuevo, a iterar. Su trabajo es guiar a su equipo a que sea iterativo.

Veo dos razones por las que los equipos no son iterativos. Una es que creen que triunfaron y su tecnología no necesita mejorar. A esto le llamo el síndrome de “la cabeza en las nubes”. La otra ocurre cuando nos abruma lo que implica convertirse en iterativos. A esto me refiero como el síndrome de “la cabeza en la arena”. Sin embargo, cuando su “cabeza está en el juego”, tiene una actitud de iteración y trabajas en un plan para hacer que su aplicación también sea iterativa.

Diviértase

La última lección que enseño es que en la vida hay que divertirse. Si tiene la fortuna (o mala fortuna) de ver nuestra sesión breakout en AWS Re:Invent 2016 acerca de este tema, escuchará historias mías o de mi estimado colega, James Cowe, que le dirán que en la vida nos gusta divertirnos. Puedo contar horas de historias acerca de hacer bromas sobre tener un solo dedo a la gente que no tendrían sentido si las intentara escribir. Sin embargo, esa misma filosofía sirve en la tecnología. Espero que como yo, usted entre a la tecnología para divertirse. La verdad es que usted es un geek. Y, para vergüenza de mi esposa, ¡también yo soy un geek!

La diversión en nuestro mundo es probar nuevas cosas y conquistar nuevas tecnologías. Sin embargo, cuando uno se queda atorado con una aplicación monolítica y con excusas de por qué se quedará así, la diversión parece difícil de encontrar. Por el otro lado, si tiene una aplicación que puede iterar fácilmente, es hora de divertirse. He aquí algunas ideas para abrir su apetito:

  • Lambda: Si tiene un app que utilice microservicios, piense en mudarlos a Lambda. A la larga, si puede mudar todos sus microservicios a Lambda, se olvidará de tener que usar servidores para ejecutar su API. ¡Bienvenido al mundo sin servidores!
  • Hospedaje S3: Eche un vistazo a su aplicación. ¿Su cliente web puede separarse de su backend? De ser así, usted puede hospedar un cliente web estático en S3 y disfrutar de escalabilidad, confiabilidad y seguridad ilimitadas por una fracción del costo.
  • RDS: ¿Qué tecnología de bases de datos utiliza? ¿Ejecuta sus bases de datos en servidores EC2 o en anaqueles locales? Es posible mudarlos a una instancia RDS que le quite el dolor de cabeza que es administrar su infraestructura sin perder la capacidad total de administrar sus bases de datos.

Podría seguir, pero creo que ya lo dejé en claro. Entender la nube, específicamente AWS, y lo que tiene que ofrecer, incluso a un nivel conceptual, puede incrementar la productividad y decrecer el costo. Lo reto a aceptar el desafío, olvidarse de las excusas, modelar un equipo iterativo y entonces… ¡a divertirse!

Asegúrese de asistir a las sesiones breakout mías y de James en AWS Re:Invent en Las Vegas. Más información aquí.

LEAVE A REPLY

Please enter your comment!
Please enter your name here