Para los que nos toca andar en la calle, en “campo”, es de mucho valor estar con ustedes los clientes, y futuros clientes.

Nos ayuda a entender mucho de las dinámicas a las que se enfrentan día con día. La realidad local. Si bien existen firmas de analistas que realizan o comercializan reportes, o estudios que se llevan a cabo a nivel global o LATAM -con suerte- la historia en corto es muy reveladora.

Lo que nos platican la mayoría de ustedes, siempre lleva color, un entorno y detalles que no salen a relucir en algunos gráficos.

Parte de esto es lo que podemos dar cuenta en los últimos meses, ya que hay un par de tópicos que siempre salen en las conversiones con ustedes:

• La experiencia del usuario como lo más importante para el negocio.
• La estrategia multicloud. Un elemento que ocupa y preocupa.

¡El primero me gusta mucho! Me entusiasma ver que, en las áreas de Telecom, por ejemplo, los objetivos estratégicos han cambiado apuntando a entregar valor al usuario. Están quedando atrás los tiempos donde las presentaciones internas, describen al objetivo del área algo así como: Eficientizar el uso de las tecnologías de la información para alinear los procesos de tal forma que permitan ser un elemento disruptivo bla bla bla. Completen con lo que ustedes gusten. Algún profile de linkedin les puede dar buenas ideas.

El cambio de mindset de un área, hacia la búsqueda de exportar el valor de sus actividades, procesos y tecnologías a cargo, en pos de la mejora de la experiencia del usuario, no es ser revolucionario sino pragmático. ¿Qué habrá cambiado eso? Puede ser el protagonismo que han alcanzados las aplicaciones o APIs en los últimos años. Pueden ser también los niveles de exigencia del usuario. Yo creo que las dos.

Algunos -me incluyo- cuando piden un servicio de ride, y después de minutos no confirma este alguna unidad, simplemente se cambian de Aplicación. Muchas veces funciona y son servidos. Por otro lado, la Aplicación (proveedor/empresa), no quiere que pase esto. En sus mesas internas de análisis se preguntarán: ¿Por qué tardamos en entregar el servicio?,¿no había socios disponibles?, ¿hubo problemas con la infraestructura?, ¿hubo problemas en la red (pun intended!)?

Es una tarea enorme, hacer arquitecturas resilientes que permitan reducir latencias, que protejan de forma integral los datos suyos y de sus usuarios, que entreguen trazabilidad y observabilidad que al final permitan resolver problemas rápido, pero también tomar decisiones de negocio con información precisa.

Hoy la dinámica es así. El usuario o consumidor se va si su Aplicación no responde. Se va tan rápido como lo que el usuario tarda en abrir la Aplicación de la competencia en su móvil. Ya se lo hemos dicho en los últimos años: Las Aplicaciones son el gateway hacia sus datos. Ahora le complemento: La Aplicación es su cara hacia el cliente. El API es su cara hacia el Partner (hacia el usuario también pero no tienen por qué saberlo ellos).

Por eso todo lo que la rodea debe ser resiliente, seguro. Para evitar interrupciones. Para evitar que su cliente se vaya con los de “enfrente”.

Es aquí donde hablamos del siguiente punto: La estrategia multicloud.

Cuando platicamos de forma ocasional con ustedes o hablando meramente de negocios, multicloud es un tema que siempre está ahí. A veces explicita al hablar de “prender” una segunda nube, la preocupación del arquitecto o estratega de TI, es cómo disponibilizar las aplicaciones o APIs, más allá de un solo proveedor de nube. Pero ¿por qué? En México tenemos una frase que ronda en el argot de TI, que reza más o menos: “Los fierros no perdonan” (sic). Hacemos alusión a que no podemos confiar 100% en los sistemas electrónicos. ¿Por qué menciono al hardware cuando hablo de nube? Porque las nubes, ya sea para ejecución de funciones, para manejo de containers en formato PaaS, para ETL, para CI/CD, todo, todo, se ejecuta en hardware. Sólo que no es de usted, es de un tercero.

Hemos notado en los últimos años cómo esos grandes proveedores de nube tienen caídas. A veces por un problema de DNS, o de ruteo, o por un proveedor de ellos se caen regiones completas en Internet, inclusive cuando alguien golpeó un equipo en un rack. La nube es la última abstracción del hardware.

Por esta realidad de fallos, a los que nadie está exento, es que hoy en día, correr sus aplicaciones en una sola nube representa tener un punto único de falla. ¡Sí! Aunque esta Aplicación o API viva en diferentes regiones o zonas de disponibilidad. Vamos a algo más clásico: ¿usted tiene sus varios enlaces a internet con el mismo ISP? Si la respuesta es sí creo conoce bien el tema de la falta de disponibilidad.

El componente de fallo de cualquier proveedor de nube de ser tomado en cuenta al realizar la arquitectura de sus aplicaciones. Y esto es lo que estamos notando cada vez que platicamos con ustedes, es un tópico que tiene mucha tracción. Algunos de ustedes, según su feedback, han perdido dinero por tener una Aplicación o API, en una nube que se cayó por varias horas.

Es claro el momentum de multicloud. Las aplicaciones y APIs necesitan de esto para sobrevivir y seguir entregando servicios y valor a los usuarios finales, en cualquier momento, en cualquier lugar.

Es importante notar que la adopción que tiene LATAM en ambientes contenerizados indica que muchos de ustedes, ya cuentan cargas productivas en Kubernetes. Esto es medular en una estrategia multicloud. La descomposición de una Aplicación en microservicios y su portabilidad, le permite adoptar estrategias mucho más rápido, que puedan sostener una Aplicación de misión crítica para su negocio.

Así, una Aplicación o API, con una arquitectura sólida en cuanto a disponibilidad basada en diferentes nubes, y obviamente seguridad, le va a permitir entregar una experiencia digital extraordinaria para sus clientes.

Claro, luego vienen temas relacionados a la simplificación de conectividad entre la nubes, la distribución de esas aplicaciones, y su colocación más cerca del usuario, la seguridad de esas aplicaciones y APIs, su protección contra amenazas y fraude modernos, pero estemos tranquilos, de eso se encarga F5.

(*) Héctor Heredia: Sr Solutions Engineer F5.