Vivir al límite: cómo hemos llegado hasta aquí

Ken Arora

Los desarrolladores e ingenieros que acaban de llegar al mundo de la informática y las aplicaciones suelen ver el mundo a través del prisma de la tecnología más reciente, novedosa y reluciente del momento. Sin embargo, lo cierto es que, al igual que los amigos de la infancia de quienes ya somos veteranos curtidos del sector tecnológico, esos conceptos y otras implementaciones similares siempre han estado ahí. Simplemente cobran o pierden protagonismo con el tiempo, a medida que los requisitos empresariales y los factores económicos convergen o divergen en relación con las limitaciones y las infraestructuras de implementación subyacentes. De hecho, es el entorno empresarial en constante evolución el que impulsa las necesidades y los requisitos, lo que a su vez hace que determinadas estrategias tecnológicas se redescubran o se dejen de lado.

En esta línea, en la próxima serie de artículos hablaré de algunas de las tecnologías relacionadas con las aplicaciones que cobrarán impulso durante los próximos años, especialmente a medida que avancemos hacia una infraestructura de entrega de aplicaciones mucho más distribuida y el edge adquiera un papel cada vez más relevante. Pero antes conviene analizar por qué y cómo hemos llegado hasta donde estamos hoy.

Etapa 1: La era de los centros de datos

Comencemos nuestro recorrido remontándonos unos 20 años atrás, cuando la prestación digital de servicios empresariales (el término «aplicaciones» aún no formaba parte del vocabulario habitual) se realizaba desde centros de datos de propiedad y gestión privadas. Esta estrategia técnica era suficiente y adecuada para aquella época, en gran medida porque, por entonces, solo se «digitalizaban» las operaciones empresariales más críticas. Algunos ejemplos de operaciones empresariales digitales de aquella época eran:

• Un minorista en línea solo «digitalizaría» la experiencia de compra del cliente y, quizá, la gestión del inventario.
• Una aerolínea solo «digitalizaría» los sistemas de reservas y pagos.
• El gobierno se limitaría a «digitalizar» los flujos de trabajo transaccionales de alto valor, como el pago de impuestos.

Dado que solo un reducido número de flujos de trabajo empresariales —es decir, los más importantes— se prestaban digitalmente y se concebían en el contexto de una organización empresarial típica de aquel periodo (plantillas integradas verticalmente y ubicadas en un mismo lugar, con un control centralizado de la organización y de la infraestructura de TI), era lógico que esto se reflejara a nivel organizativo en un centro de datos de propiedad centralizada y gestionado por el departamento de TI, en el que se ejecutaban «aplicaciones» monolíticas desarrolladas en su mayor parte o en su totalidad internamente. La infraestructura, la seguridad y las aplicaciones (antes denominadas «servicios empresariales») constituían una única pila integrada verticalmente. Así pues, en un sentido muy real, la pila tecnológica —centralizada y monolítica— reproducía las estructuras organizativas y empresariales.

Etapa 2: La era de la nube

El siguiente paso en la evolución de las aplicaciones y su pila tecnológica vino impulsado por la expansión de la «digitalización» a los flujos de trabajo empresariales secundarios. Este nuevo paso amplió el conjunto de flujos de trabajo digitales para incluir no solo aquellos orientados al cliente —que, además, se convirtieron en productos básicos, como demuestra la proliferación de aplicaciones en las tiendas de aplicaciones—, sino también los flujos de trabajo operativos internos de la organización, a menudo englobados en la tendencia de transformación digital empresarial.

En consecuencia, las empresas se vieron obligadas a replantearse sus estrategias de organización empresarial. Una consecuencia concreta fue que se hizo mayor hincapié en la eficiencia de costes y la agilidad, ante el reto empresarial que suponían los rápidos cambios en la escala del negocio. Esto inclinó el modelo de pago hacia uno basado en el consumo, en el que se paga por lo que realmente se utiliza, en lugar de tener que pagar por adelantado y aprovisionar recursos para una carga superior que quizá se alcanzase. En términos financieros, el modelo de financiación de la infraestructura de las aplicaciones pasó cada vez más del modelo CapEx, basado en una inversión inicial, a la estrategia OpEx de pago por uso. Otra tendencia simultánea durante ese mismo periodo, también relacionada con la eficiencia de costes y la agilidad, fue la transición hacia una plantilla más distribuida geográficamente, lo que generó la necesidad de una conectividad permanente, más ubicua y fiable que en el pasado.

Las repercusiones de estos requisitos —la digitalización de un número mucho mayor de flujos de trabajo empresariales, el deseo de contar con la flexibilidad del modelo de costes OpEx y la necesidad de disponer de conectividad global las 24 horas del día, los 7 días de la semana— propiciaron de forma natural un entorno idóneo para la creación de una red global de centros de datos virtuales de gran tamaño y alta disponibilidad, cuyo uso se facturaba como un servicio público. Así nació la nube pública.

Además, una vez plantada la semilla de la nube pública, se creó un ciclo de retroalimentación positiva que se reforzaba a sí mismo. A medida que la nube pública maduraba como plataforma de aplicaciones, empezó a absorber gran parte de la infraestructura de red de bajo nivel que hasta entonces gestionaban los departamentos de TI empresariales tradicionales. En consecuencia, el ámbito de actuación de los equipos de Operaciones de Red se redujo en muchas empresas, que pasaron a centrarse en el Despliegue y la Entrega de Aplicaciones (también conocidos como «DevOps») y en la Seguridad de las Aplicaciones (también conocida como «SecOps»). Por supuesto, esto no ocurrió en todos los casos; los proveedores de servicios y las grandes empresas tenían la necesidad y la capacidad de gestionar internamente las operaciones de red (NetOps) para sus flujos de trabajo más críticos o sensibles.

Esta historia representó la primera fase de la era de la nube, en la que la nube pública podía considerarse una especie de centro de datos externalizado, con recursos y tiempo compartidos; en otras palabras, la abstracción de la nube pública correspondía al modelo de infraestructura como servicio (IaaS).

La siguiente fase de la era de la nube estuvo impulsada por dos nuevas perspectivas empresariales, ambas sustentadas necesariamente en el paradigma de la fase 1/IaaS. La primera de ellas surgió gracias a la posibilidad de separar la aportación de valor empresarial de la implementación que hacía posible el flujo de trabajo digital. Más concretamente, las empresas podían empezar a plantearse una estrategia de ejecución en la que los niveles inferiores de la infraestructura tecnológica —que ahora se gestionaban como un servicio prestado por la nube pública— pudieran desvincularse de las principales preocupaciones de los responsables empresariales, centradas en la propuesta de valor y las ventajas competitivas de la empresa.

La segunda observación empresarial fue que, a medida que más flujos de trabajo tradicionales se digitalizaban y automatizaban, los procesos empresariales de nivel superior podían ajustarse y optimizarse en plazos mucho más cortos. Otro artículo analiza este efecto con más detalle y explica cómo los flujos de trabajo digitales evolucionan desde la simple automatización de tareas, pasando por la optimización digital (también conocida como «expansión digital»), hasta llegar finalmente a las mejoras empresariales asistidas por IA. Como ejemplos de esta tendencia, flujos de trabajo tan diversos como el ajuste de precios, la planificación de los horarios de los empleados y la gestión de inventarios se beneficiaron de una rápida capacidad de adaptación, y se acuñó el término «agilidad empresarial».

Estas dos conclusiones propiciaron una revelación empresarial: las empresas se dieron cuenta de que, a menudo, resultaba más rentable externalizar las áreas que no formaban parte de sus competencias principales. Esto, a su vez, dio lugar a un acuerdo comercial beneficioso tanto para la empresa como para sus proveedores de servicios en la nube, ya que ambas partes estaban motivadas para seguir mejorando los servicios ofrecidos por la nube pública y liberar así a la empresa de más cargas tecnológicas. Posteriormente, la nube pública amplió este concepto para ofrecer funcionalidades de plataforma de nivel superior, como bases de datos, sistemas de archivos, puertas de enlace de API y plataformas de computación sin servidor, también como servicios en la nube pública. Además, los proveedores de nube pública ofrecieron integrar servicios adicionales, principalmente en los ámbitos de la gestión del rendimiento y la seguridad.

Como resultado, a medida que la era de la nube evolucionó más allá del modelo IaaS de la fase 1, dio paso a los paradigmas de la fase 2 de la nube: plataforma como servicio (PaaS) y software como servicio (SaaS). Con la fase 2 de la nube, la mayor parte de la infraestructura necesaria para dar soporte a una aplicación, si no toda, podía externalizarse desde la empresa a proveedores de servicios en la nube capaces de optimizarla a gran escala y de aportar un equipo más amplio de especialistas que se centrara en cualquier servicio de aplicaciones de uso generalizado. Aunque esto permitió a la empresa centrar su presupuesto tecnológico en la lógica de negocio principal, a menudo provocó el efecto secundario no deseado (desde la perspectiva de la empresa) de quedar «atrapada» con un proveedor de servicios en la nube concreto. Para mitigar este efecto, las empresas se esforzaron por definir y codificar la expresión del valor esencial de su negocio mediante tecnologías independientes del proveedor, especialmente en las áreas clave de las API y los modelos de computación. Para ello, utilizaron tecnologías de API REST y gRPC, respaldadas por un modelo de computación virtualizado y basado en contenedores: Kubernetes.

Etapa 3: Digitalización de objetos físicos y procesos

La tercera etapa, actualmente emergente, en la evolución de las «aplicaciones» está impulsada por la digitalización de actividades cotidianas que apenas consideramos flujos de trabajo. A diferencia de las etapas 1 y 2, en las que se trasladaron a Internet principalmente los procesos empresariales y un pequeño conjunto de flujos de trabajo transaccionales de los consumidores, esta etapa consiste en crear experiencias digitales omnipresentes e integradas de forma fluida en nuestras acciones cotidianas de la «vida humana». El conjunto completo de casos de uso aún está tomando forma, pero ya podemos vislumbrar el rico y polifacético camino que se abre ante nosotros en nuevos casos de uso que aprovechan tecnologías como la realidad aumentada, los sistemas automatizados de vigilancia doméstica y la gestión energética a escala de red. Estas soluciones interactúan de manera destacada con el mundo físico real, a menudo mediante dispositivos inteligentes: vehículos autónomos, asistentes digitales, cámaras y todo tipo de electrodomésticos inteligentes.

Desde una perspectiva empresarial, esta próxima transición pondrá mucho más énfasis en la experiencia de usuario del consumidor digital. Este enfoque en la experiencia de usuario, unido a la constatación de que los dispositivos, y no las personas, constituirán la mayoría de los clientes directos de los procesos digitales, implica que los requisitos de experiencia de usuario del consumidor digital serán mucho más diversos que en las etapas anteriores de la evolución digital. Esta próxima transición, de la etapa 2 a la etapa 3, será diferente de la anterior (de la etapa 1 a la etapa 2). En concreto, este siguiente paso no consistirá en una simple progresión extrapolada de las métricas habituales de la experiencia digital (es decir, «hacerla más rápida y reducir la latencia»), sino en proporcionar a la «aplicación» un abanico mucho más amplio de opciones para decidir qué aspectos priorizar en la prestación de la aplicación, lo que permitirá adaptar la experiencia a los requisitos del consumidor digital en el contexto del caso de uso en cuestión.

Desde la perspectiva de un tecnólogo, los requisitos empresariales implican que la creciente diversidad de requisitos de la experiencia de consumo hará necesario crear un mecanismo igualmente flexible y adaptable que permita equilibrar, especificar y optimizar las métricas habituales de entrega de aplicaciones: latencia, ancho de banda, fiabilidad y disponibilidad. Por ejemplo, un sistema de realidad aumentada puede requerir una latencia muy baja y un gran ancho de banda, pero tolerar mejor la pérdida de una pequeña parte del tráfico de red. Por el contrario, una cámara doméstica utilizada en un sistema de alarma puede requerir un gran ancho de banda, pero tolerar una latencia (relativamente) mayor, del orden de varios segundos. Un contador inteligente puede tolerar tanto una latencia elevada como un ancho de banda reducido, pero requerir altos niveles de fiabilidad final, aunque no necesariamente inmediata, para que quede registrado todo el consumo energético.

El diseño y la arquitectura de un sistema lo suficientemente flexible y adaptable como para satisfacer las necesidades de esta próxima etapa de «digitalización» requerirán un mecanismo que permita distribuir fácilmente los numerosos componentes que intervienen en la prestación de una experiencia digital y trasladarlos, cuando sea necesario, entre distintas ubicaciones de la ruta de entrega de la aplicación. La distribución de estos componentes deberá adaptarse a las necesidades de entrega —latencia, ancho de banda y fiabilidad— determinadas por los requisitos de la experiencia de usuario, y los sistemas deberán ajustarse continuamente a medida que cambien el entorno y la carga. Por último, pero no por ello menos importante, los aspectos de seguridad de la aplicación —gestión de identidades, protección contra software malicioso y detección de brechas— deberán acompañar de forma fluida a los componentes de la aplicación a medida que estos se desplacen por la ruta de entrega.

Avanzando con decisión hacia el futuro

Así pues, en términos más concretos, ¿qué significa esto con respecto a nuestra situación actual? Significa lo siguiente:

• En primer lugar, dado que la mayoría de los consumidores de experiencias digitales serán otras aplicaciones y servicios digitales, las API y su gestión adquirirán un protagonismo aún mayor.
• En segundo lugar, el conjunto de ubicaciones de entrega de aplicaciones de las que disponemos actualmente —el centro de datos, la nube y los servicios prestados desde la nube— no será suficiente para satisfacer las necesidades del futuro. Más concretamente, para ofrecer experiencias de cliente más completas, tendremos que poder acercar al usuario final determinados aspectos de la experiencia de las aplicaciones digitales mediante tecnologías como el perímetro inteligente, los servicios de contenido y computación en la ruta de entrega y SD-WAN en dicha ruta. Puede que incluso tengamos que ampliar la ruta de entrega de aplicaciones para utilizar tecnologías de entorno aislado en el lado del cliente.
• En tercer lugar, el edge será cada vez más el punto de «entrada» para la prestación de la experiencia digital y, por tanto, cobrará mayor importancia como punto clave de orquestación de dicha prestación.
• Por último, en lo que respecta a la seguridad, esta no solo debe ser intrínseca y omnipresente, sino también independiente de cómo estén distribuidos los componentes de la aplicación a lo largo de la ruta de entrega de aplicaciones.

Estos tres últimos temas centrarán los próximos artículos de esta serie, en los que hablaremos del «edge» y de hacia dónde se dirige, y, posteriormente, de cómo es una visión de la seguridad verdaderamente independiente de la ubicación.

Sobre el autor

Ken Arora

Más artículos de Ken Arora