Vivir al límite: Cómo llegamos aquí

Los desarrolladores e ingenieros que han llegado recientemente al mundo de la informática y las aplicações a menudo ven el mundo a través de la lente de la tecnología más reciente, más nueva y más brillante del mercado. Pero lo más frecuente es que, al igual que los amigos de la infancia de los veteranos de la industria tecnológica, esos conceptos e implementaciones análogas siempre hayan existido. Simplemente avanzan o retroceden con el tiempo, a medida que los requisitos del negocio y la economía convergen y divergen, en relación con las limitaciones de implementación e infraestructuras subyacentes. De hecho, es el entorno empresarial en constante evolución el que impulsa las necesidades y los requisitos, lo que luego da lugar a que se redescubran o dejen de lado estrategias tecnológicas específicas.

En ese sentido, en el próximo conjunto de artículos hablaré sobre algunas de las tecnologías relacionadas con las aplicaciones cuyo auge llegará en los próximos años, especialmente a medida que evolucionamos hacia una estructura de distribución de aplicação más dispersa y el papel emergente del borde. Pero primero, es útil examinar por qué y cómo llegamos donde estamos hoy.

Etapa 1: La era del centro de datos

Comencemos nuestro viaje hace unos 20 años, en un momento en el que la entrega digital de servicios empresariales (el término "aplicações" no se usaba en ese momento) se realizaba desde centros de datos operados y de propiedad privada. Esta estrategia técnica fue suficiente y apropiada para esa época, en gran medida porque en ese período, solo las operaciones comerciales más críticas eran las que se "digitalizaban".  Algunos ejemplos de operaciones comerciales digitales en esa era fueron:

• Un minorista en línea sólo “digitalizaría” la experiencia de compra del cliente y quizás la gestión del inventario. 
• Una aerolínea sólo “digitalizaría” los sistemas de reserva y pago. 
• El gobierno “digitalizaría” flujos de trabajo transaccionales de alto valor, como el pago de impuestos.

Teniendo en cuenta que solo una pequeña cantidad de flujos de trabajo empresariales (es decir, los más importantes) se entregaban digitalmente y se consideraban en el contexto de una organización empresarial típica en ese período (fuerzas de trabajo integradas verticalmente y ubicadas geográficamente con control centralizado de la organización y la infraestructura de TI), era natural que esto se reflejara organizacionalmente en un centro de datos de propiedad central y administrado por TI, que ejecutaba "aplicações" monolíticas que se desarrollaban mayoritariamente o en su totalidad de manera interna. Infraestructura, seguridad y aplicações (antes "servicios empresariales") eran una única pila integrada verticalmente. Así, en un sentido muy real, la pila de tecnología (centralizada y monolítica) imitaba las estructuras organizacionales y comerciales.

Etapa 2: La era de la nube

El siguiente paso en la evolución de las aplicações y su pila tecnológica fue impulsado por la expansión de la "digitalización" a los flujos de trabajo comerciales secundarios. Este siguiente paso amplió el conjunto de flujos de trabajo digitales para incluir no solo los flujos de trabajo orientados al cliente (que además se convirtieron en productos básicos, como lo demuestra la proliferación de aplicaciones en las tiendas de aplicaciones), sino que también amplió el alcance para incluir flujos de trabajo operativos internos de la organización, a menudo denominados parte de la tendencia de transformación digital empresarial.

Como consecuencia, las empresas se vieron obligadas a repensar sus estrategias de organización empresarial. Una implicación específica fue que se puso mayor énfasis en la eficiencia de costos y la agilidad, dado el problema empresarial de cambiar rápidamente la escala empresarial. Esto inclinó el modelo de pago hacia un modelo de precios de servicios públicos, pagando por lo que realmente se usa, en lugar de tener que pagar por adelantado y prever una posible carga mayor. Utilizando la terminología financiera, el modelo para financiar la infraestructura de aplicaciones migró cada vez más del modelo de CapEx por adelantado a la estrategia de OpEx de pago por uso. Otra tendencia concurrente en el mismo período, también relacionada con la eficiencia de costos y la agilidad, fue el movimiento hacia una fuerza laboral más distribuida geográficamente, lo que impulsó la necesidad de una conectividad ubicua y confiable las 24 horas del día, los 7 días de la semana, que la que se necesitaba 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 flexibilidad en el modelo de costos OpEx y el requisito de conectividad global 24 horas al día, 7 días a la semana) naturalmente llevaron a un entorno propicio para la creación de una red global de centros de datos virtuales muy grandes y de alta disponibilidad, cuyo uso se cotizaba como un servicio público. Y así nació la nube pública. 

Además, una vez que las semillas de la nube pública estuvieron presentes, se creó un ciclo de retroalimentación positiva que se reforzaba a sí mismo. A medida que la nube pública maduró como plataforma de aplicação , comenzó a absorber gran parte de la infraestructura de red de nivel inferior que anteriormente había sido administrada por la TI empresarial tradicional. En consecuencia, el alcance de los equipos de Operaciones de red disminuyó en muchas empresas y, en cambio, las empresas enfocaron su atención en la Implementación y entrega de aplicação (también conocidas como "DevOps") y la Seguridad de aplicação (también conocidas como "SecOps"). Por supuesto, esto no era universal; los proveedores de servicios y las grandes empresas tenían la necesidad y la capacidad de realizar NetOps internamente 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 verse como una forma de centro de datos subcontratado y compartido en el tiempo y los recursos; en otras palabras, la abstracción de la nube pública era una de Infraestructura como Servicio (IaaS).

La siguiente fase de la Era de la Nube fue impulsada por dos perspectivas comerciales emergentes diferentes, las cuales requerían el paradigma de Fase 1/IaaS como requisito previo. La primera de estas realizaciones comerciales fue posible gracias a la capacidad de aislar la entrega de valor comercial de la implementación que generó el flujo de trabajo digital. Más específicamente, las empresas ahora podían comenzar a imaginar una estrategia de ejecución donde los niveles inferiores de la infraestructura tecnológica, que ahora se administraban como un servicio proporcionado por la nube pública, podían desacoplarse de las preocupaciones principales de los líderes empresariales, que giraban en torno a la propuesta de valor de la empresa y los diferenciadores competitivos. 

La segunda observación empresarial fue que, a medida que más flujos de trabajo tradicionales se digitalizaron y se automatizaron, los procesos empresariales de nivel superior pudieron ajustarse y optimizarse en escalas de tiempo mucho más cortas. Un artículo aparte analiza este efecto con más detalle y explica cómo los flujos de trabajo digitales evolucionan desde la simple automatización de tareas hasta la optimización digital (también conocida como "expansión digital") y terminan en ampliaciones comerciales asistidas por IA. Como ejemplos de esta tendencia, flujos de trabajo tan diversos como el ajuste de precios, la programación del tiempo de los empleados y la gestión de inventario se beneficiaron de una rápida adaptabilidad, y se acuñó el término "agilidad empresarial". 

Estas dos ideas dieron lugar a una epifanía empresarial, ya que las empresas se dieron cuenta de que a menudo era más rentable externalizar áreas que no eran las competencias básicas del negocio. Esto, a su vez, condujo a un acuerdo comercial beneficioso para ambas partes, la empresa y sus socios proveedor de nube, donde ambas partes se vieron motivadas a mejorar aún más los servicios ofrecidos por la nube pública, descargando así la sobrecarga tecnológica adicional de la empresa. Este concepto fue luego ampliado a la nube pública para poner a disposición capacidades de plataforma de nivel superior, como bases de datos, sistemas de archivos, puertas de enlace de API y plataformas informáticas sin servidor, nuevamente como servicios en la nube pública. Además, los proveedores de nube pública también ofrecieron integrar servicios over-the-top, más comúnmente en las áreas de gestión del rendimiento y seguridad.

El resultado fue que, a medida que la era de la nube maduró más allá del modelo IaaS de la Fase 1, marcó el comienzo de los paradigmas de la Fase 2 de la nube de Plataforma como Servicio (PaaS) y Software como Servicio (SaaS). Con Cloud Phase 2, la mayor parte, si no toda, de la infraestructura necesaria para dar soporte a una aplicação podría subcontratarse desde la empresa a proveedores de la nube que podrían optimizar la infraestructura a escala y traer un equipo más grande de especialistas para centrarse en cualquier servicio de aplicação ampliamente requerido. Si bien esto liberó a la empresa para concentrar su presupuesto tecnológico en la lógica central del negocio, a menudo causó un efecto secundario indeseable (desde la perspectiva de la empresa) de "bloqueo" a un proveedor de nube en particular. Para mitigar este efecto, las empresas se esforzaron por definir y codificar la expresión de su valor comercial principal utilizando tecnologías independientes del proveedor, especialmente en las áreas clave de API y modelos de cómputo, y se implementaron utilizando tecnología de API REST y gRPC, respaldada por un modelo de cómputo virtualizado y en contenedores: Kubernetes. 

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

La tercera etapa, actualmente emergente, en la progresión de las "aplicações" está siendo impulsada por la digitalización de las actividades cotidianas que difícilmente consideramos como flujos de trabajo. A diferencia de las Etapas 1 y 2, donde se pusieron en línea principalmente procesos de negocios y un pequeño conjunto de flujos de trabajo transaccionales de consumidores, esta etapa trata de crear experiencias digitales que sean ubicuas y se integren perfectamente en nuestras acciones cotidianas de "vida humana". El conjunto completo de casos de uso aún se está desarrollando, pero ya vemos destellos del rico y multifacético camino por delante en casos de uso emergentes que aprovechan tecnologías como la realidad aumentada, los sistemas de vigilancia automatizada del hogar y la gestión de energía a nivel de red. Las soluciones interactúan notablemente con el mundo físico real, a menudo utilizando dispositivos inteligentes: vehículos autónomos, asistentes digitales, cámaras y todo tipo de electrodomésticos inteligentes. 

Desde la perspectiva empresarial, esta próxima transición pondrá un énfasis mucho mayor en la experiencia del usuario del consumidor digital. Este enfoque en la experiencia del usuario, junto con la observación de que los dispositivos, no los humanos, comprenderán la mayoría de los clientes directos del proceso digital, significa que los requisitos de experiencia del 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 a la anterior (Etapa 1 a Etapa 2). En concreto, este próximo paso no será una simple progresión extrapolada de las métricas de experiencia digital habituales (es decir, "hacerlo más rápido y con menor latencia"), sino que consistirá en dar a la "aplicação" un conjunto mucho más amplio de opciones sobre cómo realizar concesiones en la entrega de aplicação , lo que permitirá adaptar la experiencia a los requisitos del consumidor digital en el contexto del caso de uso que se esté abordando.

Desde la perspectiva de un tecnólogo, la implicación de los requisitos comerciales es que la mayor diversidad de requisitos de experiencia de consumo generará la necesidad de construir un medio correspondientemente flexible y adaptable para equilibrar, especificar y optimizar las métricas de entrega de aplicação comunes: latencia, ancho de banda, confiabilidad y disponibilidad. Por ejemplo, un sistema de experiencia de realidad aumentada puede requerir una latencia muy baja y un alto ancho de banda, pero ser más tolerante a la pérdida de una pequeña fracción del tráfico de la red. Por el contrario, una cámara doméstica utilizada para un sistema de alarma puede requerir un gran ancho de banda, pero tolerar una latencia (relativamente) más larga, del orden de segundos. Un medidor inteligente puede tolerar tanto una latencia larga como un ancho de banda bajo, pero puede requerir altos niveles de confiabilidad eventual, si no oportuna, de modo que se registre todo el uso de energía.

El diseño y la arquitectura de un sistema que sea lo suficientemente flexible y adaptable para satisfacer las necesidades de esta próxima etapa de "digitalización" requerirá un mecanismo donde los muchos componentes que comprenden la entrega de una experiencia digital puedan dispersarse fácilmente y migrarse cuando sea necesario, a través de una variedad de ubicaciones en la ruta de entrega de la aplicação . La distribución de estos componentes de aplicação deberá adaptarse a las necesidades de entrega (latencia, ancho de banda, confiabilidad) impulsadas por los requisitos de experiencia del usuario, y los sistemas deberán adaptarse continuamente a medida que cambien el entorno y la carga. Por último, pero no menos importante, las preocupaciones de seguridad de la aplicação(gestión de identidad, protección contra malware, detección de violaciones) deberán seguir sin problemas los componentes de la aplicação a medida que cambian en la ruta de distribución de la aplicação .

Inclinándose hacia el camino por delante

Entonces, más concretamente, ¿qué significa esto en relación a dónde estamos hoy?  Lo que significa es esto:

• En primer lugar, debido a que la mayoría de los consumidores de experiencias digitales serán otras aplicações y servicios digitales, el papel de las API y la gestión de API ocupará un lugar aún más central.
• En segundo lugar, el conjunto de ubicaciones de distribución de aplicação que tenemos hoy (el centro de datos, la nube y los servicios entregados desde la nube) no será suficiente para satisfacer las necesidades del futuro. Más específicamente, para brindar experiencias de cliente más ricas, necesitaremos poder entregar aspectos de la experiencia de la aplicação digital más cerca del usuario final, utilizando tecnologías como el borde inteligente, el contenido de la ruta de entrega y los servicios computacionales, y SDWAN en la ruta de entrega. Es posible que incluso necesitemos ampliar la ruta de entrega de aplicação para utilizar tecnologías de espacio aislado del lado del cliente.  
• En tercer lugar, el borde será cada vez más el punto de "ingreso" a la entrega de experiencia digital y, por lo tanto, adquirirá más importancia como punto clave de orquestación de la entrega.
• Por último, cuando se trata de seguridad, no solo debe ser innata y generalizada, sino que también debe ser independiente de cómo se dispersan los componentes de la aplicação a lo largo de la ruta de entrega de la aplicação .

Estos últimos tres temas serán el foco de los próximos artículos de esta serie, en los que hablaremos sobre "Edge" y hacia dónde se dirige y, a partir de ahí, cómo es una visión de la seguridad verdaderamente independiente de la ubicación.