Tabla de contenido
INTRODUCCIÓN
La definición del borde siempre ha estado entrelazada con la evolución de la arquitectura del centro de datos. La última década ha sido testigo de una rápida transformación en la arquitectura de la infraestructura empresarial, pasando de los centros de datos locales a las arquitecturas Distributed Cloud actuales. Reconocemos que Edge 2.0 es un cambio tecnológico que permitirá a las aplicaciones aprovechar una arquitectura Distributed Cloud.
Cada persona, organización o entidad tiene una interpretación diferente del borde. Algunos pueden considerar que el borde es una torre de telefonía móvil, otros pueden decir que su dispositivo móvil es el borde. Para los proveedores de servicios en la nube (CSP), el borde es una huella de infraestructura gestionada que se integra perfectamente en su back-end. Para las aplicaciones militares, el borde es el escenario de la batalla, ya sea por tierra, mar o aire. Cada vez que leemos sobre el borde, la interpretación se resume generalmente en las capacidades de computación, red y almacenamiento de la infraestructura o su ubicación.
Pero también consideramos que Edge 2.0 es la experiencia que ofrece a todas las partes interesadas del ecosistema, y no solamente al activo de la infraestructura o a su ubicación.
En este documento se describe cuál debe ser la funcionalidad de Edge 2.0, independientemente de su infraestructura física o virtual, o de su ubicación o instanciación. La intención no es explicar cómo construir una aplicación distribuida mejor, sino iluminar las capacidades que debe tener Edge 2.0 para apoyar la creación de las aplicaciones distribuidas más óptimas que se adapten a un requisito particular.
¿Qué es Edge 2.0?
Desde el punto de vista de una entidad que reside en esta Distributed Cloud, el borde está dondequiera que la entidad se encuentre actualmente. Así pues, proponemos una definición de Edge 2.0 centrada en la experiencia, no vinculada únicamente a la ubicación de la infraestructura, al tipo de infraestructura o a la entidad de control.
El objetivo de Edge 2.0 es mejorar las experiencias centradas en la aplicación, en las operaciones y en los desarrolladores. Edge 2.0 debe abordar las metapropiedades (como los SLA y los SLO) de la aplicación adaptándose a las necesidades cambiantes de esta. Edge 2.0 debe ser sencillo de manejar y liberar a los equipos de operaciones de la creación de nuevas automatizaciones para cada aplicación distribuida. Edge 2.0 debe reducir la fricción a la que se enfrentan los desarrolladores cuando desarrollan e implantan aplicaciones distribuidas a escala, apoyando sin problemas los objetivos de seguridad, gobernanza y nivel de servicio.
Como ejemplo, tomemos una aplicación bancaria. El objetivo de Edge 2.0 no es mejorar la lógica empresarial de la transacción. Se trata de hacerla más segura, más rápida, más privada, utilizable en todas las geografías (según sea necesario), y ampliable o reducible según sea necesario para apoyar los objetivos de negocio.
Conceptos y afirmaciones
A continuación se exponen los conceptos y afirmaciones clave de este documento:
- Borde centrado en la experiencia: establece una base para Edge 2.0 en torno a la experiencia que ofrece, en lugar de un activo o sus ubicaciones.
- Consideraciones de diseño: especifica las consideraciones de diseño clave para una implementación correcta de la arquitectura de Edge 2.0.
- Infraestructura heterogénea: destaca que diseñar para una Distributed Cloud significa considerar el control descentralizado de la infraestructura.
- La telemetría como base: hace hincapié en la telemetría como un elemento fundamental que debe ser apoyado en todas las capas de la infraestructura. Sin la telemetría, una estrategia que dé prioridad a los datos se diluye.
- Retos entre clústeres: destaca un desafío fundamental con Edge2.0 como interclúster en lugar de intraclúster.
- Interfaces adaptables: presenta las interfaces adaptables, lo que ofrece una clara comparación con las interfaces declarativas e imperativas.
- Plataforma de aplicaciones Edge 2.0 (EAP): presenta la EAP como marco para que Edge 2.0 se adapte a las necesidades de las aplicaciones.
Temas no tratados
Hay varios temas que aún no hemos abordado en este documento:
- Distribución de datos de aplicaciones: aquí hay muchos subtemas, como las redes de distribución de contenidos (CDN), la distribución de almacenamiento, la distribución de datos, el almacenamiento en caché, etc. También hay tecnologías emergentes como la de tipos de datos replicados sin conflictos (CRDT). Un marco de Edge 2.0 debería incluir compatibilidad con la distribución de datos de aplicaciones en su ámbito de aplicación.
- Distribución de funciones: el avance de la computación en el borde puede considerarse como funciones y lógica de la nube central, que se desplazan más cerca de la ubicación donde se genera el evento, o donde residen los datos. Debido a la importante cantidad de computación que está disponible en el borde, ahora debemos resolver problemas similares a los que suelen resolverse en las arquitecturas de nube heredadas si queremos aprovechar esa computación. Por ejemplo, las redes superpuestas, las cargas de trabajo de middleware y otros tipos de cargas de trabajo que se entrecruzan y son más complejas que los casos de uso ingenuos que hemos visto en el borde temprano, por ejemplo, los storlets, que son flujos simples sin estado que se ejecutan junto a los datos.
- Es probable que haya otras áreas que no se hayan debatido. El objetivo del marco es ser extensible, de manera que las responsabilidades puedan añadirse según sea necesario.
Evolución del borde
La figura 1 es la que mejor representa la coevolución de las arquitecturas Edge y de centro de datos. Edge 1.0 y 1.5 se basaban en la noción de un sitio de origen y el traslado de los datos y servicios desde el origen hasta el consumidor. Edge 1.0 era la implementación de la infraestructura de Internet centrada principalmente en la optimización del uso del ancho de banda con el almacenamiento en caché de contenidos distribuido, también conocido como redes de distribución de contenidos. Las CDN son un patrón de diseño fundamental, ya que el contenido agregado para transferir siempre será mayor que el ancho de banda disponible.
A medida que los costes de la CPU y la memoria bajaron, aparecieron las granjas de computación junto con los nodos CDN. Las aplicaciones se consumían como servicios a través de arquitecturas orientadas a servicios (SOA). De ahí la referencia a Edge 1.5 como red de distribución de servicios.
Una característica común de Edge 1.0 y Edge 1.5 es la idea de un sitio de origen. Antes del crecimiento del móvil, las personas, los dispositivos y las cosas descargaban principalmente contenidos o actuaban como consumidores del servicio. El sitio que originaba el servicio seguía siendo diferente al del consumidor.
En Edge 2.0, sin embargo, cualquier entidad puede actuar como sitio de origen o como consumidor. El flujo de tráfico ha cambiado. Las personas, los teléfonos y los dispositivos están produciendo activamente datos a medida que cargan contenidos o generan datos periódicos. Las aplicaciones se están convirtiendo en consumidores al depender de otras aplicaciones. Todas las entidades pueden actuar como productores o consumidores de un servicio (API, personas, dispositivos IoT, o aplicaciones web, de back-end y remotas). Desde su propio punto de vista, cada entidad de la infraestructura piensa que está en el borde.
Distributed Cloud es la última etapa de la evolución del centro de datos. La computación se ha convertido en algo verdaderamente ubicuo, desde los dispositivos móviles hasta la incorporación a los objetos cotidianos que se conectan a la red. Junto con ella, han evolucionado las arquitecturas de software para permitir aplicaciones distribuidas y escalables.
Consecuencias del borde: aumento de la complejidad
La abundancia e hiperdistribución de la computación y el almacenamiento en todas partes ha creado una oportunidad para la rápida transformación digital de la empresa. Pero esta rápida evolución tiene sus consecuencias.
La mayoría de las empresas suelen estar compuestas por infraestructuras heterogéneas, con entornos no uniformes. El escalado eficaz de estos entornos exige una organización y una automatización complejas de los sistemas implementados. Los cambios rápidos en las necesidades de la aplicación, como los cambios en los requisitos de CPU y ancho de banda, aumentan la complejidad de las operaciones en Distributed Cloud. Esto añade estrés a los equipos de operaciones, que pueden no estar bien equipados para responder eficazmente a las necesidades cambiantes de la aplicación o del cliente final.
Las consecuencias de estos problemas son la complejidad operativa, que neutraliza cualquier ganancia potencial para una empresa que pasa por la transformación digital.
A continuación se destacan algunos de los problemas y artefactos entrelazados que se derivan de la complejidad.
Las nubes híbridas generan una mayor superficie que puede verse comprometida debido a una variedad de vectores de ataque. Los diferentes casos de uso generan múltiples desafíos de seguridad y, a medida que la infraestructura evoluciona, estamos constantemente persiguiendo el objetivo. Por tanto, el problema que anticipamos es: ¿solo cambiarán con frecuencia las recomendaciones tecnológicas o también cambiarán los patrones de diseño para implementar la seguridad?
Estos son algunos de los problemas de los enfoques existentes:
- El perímetro definido por software (SDP) no se amplía fácilmente, ya que las soluciones más populares están basadas en agentes, lo que no se presta a implementaciones operativas simples.
- La implementación del acceso de red Zero Trust (ZTNA) es a menudo poco práctica, debido a que las soluciones ZTNA requieren una constelación de servicios de producción implementados, como la inspección de tráfico, la gestión centralizada de registros, la PKI global y la gestión de identidades, entre otros.
- El borde de servicio de acceso seguro (SASE) combina la red como servicio y la seguridad como servicio, una sopa de siglas de varias tecnologías que no se implementan con facilidad. Además, el enfoque de SASE tiende a estar centrado en la red de área amplia definida por software (SD-WAN), abordando un pequeño segmento de los casos de uso del borde de la red empresarial.
- La disparidad entre las infraestructuras de los distintos proveedores de nubes públicas y los ya complejos modelos de seguridad, por ejemplo, la gestión de identidades y acceso (IAM), suelen llevar a los equipos a un endurecimiento de los proveedores a base de parches y a engorrosas configuraciones multinube.
Uno de los principales retos de la hiperdistribución de la computación de baja potencia y bajo coste disponible en el borde es la capacidad de organizar y programar la infraestructura de manera uniforme. Los equipos de operaciones tienen dificultades para escalar y dar soporte a las aplicaciones que aprovechan Distributed Cloud, ya que estas aplicaciones suelen incluir tecnologías heterogéneas con diferentes requisitos de administración.
Aunque las plataformas de automatización como Terraform proporcionan un medio sofisticado para personalizar la automatización, los equipos de operaciones siguen necesitando mantener scripts para múltiples permutaciones: por ejemplo, cinco tipos diferentes de computación, cuatro tipos diferentes de cortafuegos y tres tipos de equilibradores de carga. El coste humano de tener que gestionar y mantener los scripts de automatización no es escalable.
Esto da lugar a que el cliente de la infraestructura siga interactuando con los equipos de operaciones a través de sistemas basados en tickets, que son una barrera para la automatización de los flujos de trabajo existentes. El servicio de atención al cliente se ve desbordado por los tickets y debe priorizar la seguridad y la estabilidad sobre la agilidad.
Las arquitecturas de microservicios ya se han convertido en el método de facto para construir nuevas aplicaciones con la evolución hacia la multinube. Las API se publican y se pueden crear instancias de ellas cuando y donde se necesiten, lo que da lugar a la expansión continua de las API. La detección, la conectividad y la gestión de estas API de forma autónoma se convierten en un gran reto.
Se necesita un cambio de paradigma para abordar la proliferación de API. Nuestros modelos internos demuestran que incluso suposiciones moderadas de parámetros, como la cantidad de desarrolladores de API globales, la cantidad de API desarrolladas por desarrollador por año y la vida útil de las API, dan como resultado cientos de millones (si no miles de millones) de API activas simultáneamente para 2030 (Figura 2). El informe API Sprawl de 2021 proporciona una visión integral de este tema emergente.
El aumento de la complejidad requiere que las empresas permitan una visibilidad detallada y significativa del sistema de extremo a extremo. En los entornos Distributed Cloud, las aplicaciones trascienden múltiples pilas de infraestructuras heterogéneas gestionadas por entidades independientes.
Además, ninguno de los operadores actuales está incentivado para exponer la telemetría nativa de su infraestructura a los clientes empresariales. Básicamente, las empresas trabajan a ciegas cuando implementan aplicaciones en Distributed Cloud y necesitan recurrir a múltiples herramientas con capacidad de observación. Para llenar estos vacíos de visibilidad, las herramientas suelen ser de diferentes empresas proveedoras que trabajan en diferentes puntos de la infraestructura o de las pilas de aplicaciones.
Las métricas de infraestructura no estándar se suman a los problemas dentro de una empresa. Normalmente, las métricas no están unificadas debido a los silos operativos y otros factores como la infraestructura no uniforme en diferentes entornos de infraestructura. Por ejemplo, las métricas de los proveedores de nubes públicas son diferentes y las tecnologías de los centros de datos locales tampoco siguen ninguna métrica estándar.
Resultado empresarial: disminución de la experiencia
Las cargas de trabajo que generan ingresos y los sistemas de misión crítica suelen utilizar la mayor parte de los recursos operativos y el presupuesto disponible en una empresa. Mientras tanto, los proyectos más pequeños, aunque de menor complejidad, tienden a constituir el volumen de las aplicaciones de la empresa. En la figura 3 se representa esto como una distribución de larga cola del número de proyectos que probablemente tenga una empresa en comparación con su complejidad operativa.
Aunque las aplicaciones más pequeñas pueden ser menos complejas desde el punto de vista operativo, los procesos y flujos de trabajo de la puesta en marcha siguen siendo en muchos casos manuales, y los tickets de servicio pueden tardar semanas en pasar por varios equipos operativos. Por ejemplo, la implementación de una aplicación que requiere recursos de red dedicados con políticas de seguridad granulares puede requerir primero que los equipos de seguridad globales resuelvan las aprobaciones de las políticas de seguridad. A continuación, el ticket de servicio puede ir al equipo de redes para planificar las configuraciones de subred y ruta que deben realizarse. Por último, otro equipo operativo responsable de la gestión del firewall puede requerir la validación de las reglas de este.
Ahora imaginemos que la complejidad anterior debe ser abordada para cada aplicación implementada en Distributed Cloud donde la empresa no posee ninguna parte de la infraestructura subyacente. El gran volumen de pequeños proyectos o aplicaciones que necesitan incorporarse o a los que hay que prestar soporte hace que no sea realista que los equipos de operaciones soporten cada proyecto, creando un problema de priorización y una oportunidad de autoservicio
Este problema de priorización es especialmente notable, ya que las inversiones de los equipos de infraestructura se centran en el soporte a los sistemas críticos y generadores de ingresos, dejando poco tiempo o presupuesto para los nuevos proyectos netos que implican su propio ciclo de vida de desarrollo, pruebas y organización antes de la producción. Esto se traduce en una disminución de las capacidades y de la inversión hacia la velocidad de las características, la personalización y la innovación que da soporte a los nuevos productos, lo que culmina en el estancamiento de la empresa y sus ofertas
Espacio de soluciones de borde
La evolución del ecosistema de borde amplía enormemente el espacio de soluciones al ofrecer la oportunidad de abordar estos retos con una plataforma de aplicaciones.
En la figura 4 se muestra el espacio de soluciones de Edge 2.0. Aquí afirmamos que todo lo que entra en una arquitectura Distributed Cloud es la totalidad del espacio de soluciones.
Así, en el contexto del espacio de soluciones, Edge 2.0 debe ofrecer la experiencia que todos los siguientes desean:
- Todas las entidades que residen en el ámbito de la solución (aplicaciones, personas y dispositivos que actúan como consumidores, o aplicaciones web, de back-end y remotas que conforman los servicios).
- Los equipos de SRE y los propietarios de las aplicaciones de estas aplicaciones, al mismo tiempo que preservan la seguridad y las medidas de protección normativas que se esperan de la infraestructura.
Edge 2.0 será operativamente sencillo, seguro, conforme y ofrecerá una experiencia de alta calidad a todas las entidades del ecosistema que participen en él.
Consideraciones sobre el diseño de Edge 2.0
Seguridad por defecto
Distributed Cloud amplifica este problema de seguridad a escala, ya que el número de puntos de conexión aumenta exponencialmente. Con una escala tan masiva, la complejidad de la implementación de una solución también escala. La postura de seguridad debe ser que la aplicación asuma que el entorno en el que está implementada ya está comprometido. Del mismo modo, la infraestructura no deberá confiar en ninguna aplicación que se ejecute en ella.
La base de estas ideas se recoge en los conceptos de la mentalidad Zero Trust, y el ejemplo de BeyondCorp1 demuestra estos conceptos para el caso de uso del acceso a las aplicaciones. De cara al futuro, Edge 2.0 amplía este modelo, basándose en los siguientes cinco principios básicos:
- La identidad es fundamental: en Edge 2.0 la identidad es profunda, ya que cada instancia de la entidad tiene su propia identidad única global, pero también su lugar en la jerarquía de la organización junto con su nivel de privilegio. La identidad debe ser una consideración clave no solo para el tráfico norte-sur, sino también internamente para el acceso este-oeste.
- Mínimo privilegio: las acciones permitidas por un actor deben ser restringidas a solo aquellas que dicho actor requiere para desempeñar su rol en el sistema. Un ejemplo es limitar el subconjunto de cargas de trabajo a las que se permite comunicarse con el servidor de la base de datos en función de la especificación del diseño.
- Autenticación continua: cualquier atestación que haga un actor del sistema debe tener un medio de verificación y debe ser explícitamente verificada cada vez que se produzca tal atestación. La autenticación no debe ser únicamente explícita a través de los secretos compartidos o la cadena de confianza, sino que también debe tener en cuenta los patrones implícitos de comportamiento y los metadatos contextuales.
- Supervisión y evaluación constantes: las acciones de todos los actores del sistema deben ser supervisadas, lo que refuerza el sol clave de las tecnologías de recopilación y almacenamiento de datos en una arquitectura Edge 2.0. Además, estas actividades se deben evaluar continuamente para detectar y mitigar los intentos de realizar acciones prohibidas o peligrosas. La evaluación debe ser casi en tiempo real, a escala, lo que implica un uso liberal de las técnicas de automatización y aprendizaje automático.
- Asumir la infracción: dados los recursos de que disponen los sofisticados adversarios de hoy en día, hay que asumir que cualquier sistema ha sido comprometido de alguna manera. En consecuencia, las políticas totalmente deterministas basadas en la carga de trabajo y las identidades de los usuarios, que imponen un acceso basado en privilegios representado por a y b, suelen ser insuficientes para evitar todos los ataques. Por lo tanto, un sistema Edge 2.0 totalmente maduro debe ser capaz de realizar evaluaciones de riesgo/recompensa en tiempo real basadas en la supervisión y evaluación continuas.
Proporciona capacidad de observación nativa
Edge 2.0 debe integrar la telemetría como un ciudadano de primera clase dentro de la pila de la infraestructura, proporcionar un medio simple y escalable para recopilar la telemetría de varias capas dentro de la infraestructura y mostrarla en una plataforma común. Esto ayuda a los equipos con capacidad de observación a cuestionar el “estado de la infraestructura” según sea necesario. De esta forma, los equipos de aplicaciones pueden centrarse en la lógica empresarial sin instrumentar explícitamente sus pilas de aplicaciones.
El estado actual de la tecnología de capacidad de observación ha sido, en gran medida, específico de un proveedor y propiedad de este. Esto ha llevado a que muchos agentes específicos de un proveedor recojan señales similares que se disputan la costosa memoria y la CPU.
El siguiente paso lógico es el uso de un recopilador de telemetría independiente del proveedor que permita transmitir los datos de la infraestructura y el tráfico a una plataforma de datos centralizada.
Muchos equipos de producto luchan por justificar la inversión en instrumentación, ya que el esfuerzo tiene que estar relacionado con una oportunidad de ingresos. La infraestructura debe ser instrumentada como cualquier otra función o proceso de negocio, porque el equipo necesita entender su comportamiento para optimizarlo para los objetivos del negocio. Por lo tanto, el debate debería centrarse más en lo que debería priorizarse para instrumentar que en su necesidad.
Para lograr mediciones detalladas y más precisas del comportamiento de la aplicación, prevemos que se apliquen prácticas “shift left” a la instrumentación invocándola en el momento de la codificación (figura 5).
Admite interfaces adaptables
En consonancia con Distributed Cloud, al descender un par de capas cada nube dentro de su ámbito (local o global) tiene su propio gestor, administrador, organizador, etc. Cada una se comporta de forma independiente, tomando sus propias decisiones, pero proporcionando interfaces para que otras entidades las utilicen según sea necesario.
Por tanto, la noción de Distributed Cloud, básicamente, es la administración y el control descentralizados. No se puede obviar este hecho, y es importante que lo reconozcamos para comprender mejor los matices de las interfaces adaptables frente a las declarativas e imperativas.
Para utilizar eficazmente la infraestructura Edge 2.0, las interfaces imperativas y declarativas no son suficientes, ya que siguen dependiendo de artefactos elaborados a mano que son esencialmente construcciones estáticas que no se adaptan con la suficiente rapidez a las condiciones que cambian rápidamente.
Tenemos que basarnos en los resultados y los sistemas deben ser lo suficientemente inteligentes como para ajustar las políticas en toda la infraestructura (de extremo a extremo) para alcanzar esos resultados. A esto lo llamamos interfaces adaptables.
Para ser claros, las interfaces imperativas, declarativas y adaptables no se excluyen mutuamente:
Imperativo: Se vuelve muy prescriptivo y define en detalle una serie de acciones para llegar al estado deseado. La configuración de un enrutador, por ejemplo, es una acción imperativa. En el escenario anterior, las acciones prescriptivas serán precisas: qué centro de datos, cuánta CPU/memoria, ancho de banda requerido, rutas específicas y más. La calidad de entrada del modelo de datos es muy alta y, por lo tanto, requiere un conocimiento y una experiencia más profundos sobre la infraestructura. Existe la expectativa de conocer tanto el modelo como la estructura de la infraestructura.
Declarativo: El matiz del declarativo es que se centra en describir el estado deseado, en oposición a las acciones que logran el estado deseado. La calidad de la entrada es menor, aunque todavía requiere que la aplicação conozca al menos la estructura de la infraestructura subyacente.
Adaptado: Se distingue del imperativo o declarativo. Una interfaz adaptativa se centra en el objetivo o meta deseada, en lugar del estado. El objetivo de la interfaz adaptativa es capturar el objetivo de la parte interesada que desea implementar la aplicação en lugar de centrarse en un conocimiento previo del sistema subyacente. La adaptación es diferente porque no tiene noción de cuáles son las capacidades de la infraestructura subyacente. No existen restricciones sobre cómo “hacer el trabajo” y, por lo tanto, se sostiene por sí solo.
Con la adaptación, la calidad de la entrada es baja y se aproxima al lenguaje natural. Los propietarios de las aplicaciones pueden enviar una solicitud para indicar al controlador de la infraestructura el resultado que esperan, en lugar de tener que declarar la capacidad requerida o configurar específicamente un recurso.
Resuelve el problema entre clústeres
Distributed Cloud, por definición, da cabida a todo tipo de arquitecturas de aplicaciones: monolíticas, de microservicios o sin servidor. Independientemente de la arquitectura, las aplicaciones utilizan APIs para ofrecer los servicios.
Los problemas de detección de API, conectividad y seguridad de la red se resuelven en gran medida utilizando una malla de servicios, pero una malla de servicios solo resuelve este problema dentro del clúster (intraclúster).
Por otro lado, las aplicaciones Edge 2.0 aprovechan las API en una infraestructura de nube hiperdistribuida, que básicamente es un entorno multiclúster. Las nuevas aplicaciones se escriben con API que cruzan los límites organizativos y geográficos. Algunas de las API pueden ser privadas o de socios detrás de múltiples capas de firewalls sin una ruta explícita entre ellas, aunque sean detectables. Este problema de clústeres heterogéneos (entre clústeres) carece de una solución elegante, ligera, escalable y segura que sea práctica.
| Escenario y propiedades | Imperativa | Declarativa | Adaptable |
|---|---|---|---|
| Definición | La interfaz imperativa define el flujo de control detallado basándose en las capacidades específicas del recurso subyacente. |
La interfaz declarativa define la lógica pero no el flujo de control. Desde el punto de vista de la programación, es el seudocódigo. |
La interfaz adaptable expresa el estado deseado como un requisito sin hacer ninguna suposición de las capacidades de los recursos subyacentes. Una interfaz adaptable es propiedad de la infraestructura y permite a esta responder dinámicamente a las necesidades cambiantes de la aplicación. |
Situación 1: El paquete debe ir de SFO a NYC |
Jane le dice a Mark: (a) Imprimir la etiqueta de envío, (b) Ir a la tienda de UPS, (c) Recoger la entrega en 72 horas, (d) Pagar por ella y enviarla Mark: Tiene que seguir una serie de pasos muy específicos |
Jane pide a Mark: (a) Por favor, envía este paquete a esta dirección, (b) El paquete debe llegar en 72 horas. Mark: Puede elegir cualquier empresa de mensajería (UPS, FedEx, DHL, etc.). |
Jane comenta a Mark: (a) Este paquete debe llegar a NYC para el sábado. Mark: Puede hacer lo que quiera. Potencialmente, incluso coger el paquete él mismo, volar a NYC y entregarlo en mano. |
Escenario 2: Ejemplo de equilibrador de carga |
El equilibrador de carga ya existe. Tarea: debe configurarse con esta política. Aquí la tarea es específica, entre otros, de la marca, el modelo, la versión del equilibrador de carga. |
No existe un balanceador de carga. Tarea: equilibrar la carga de la aplicação con una política abierta determinada. La tarea supone que existe una orquestación |
No hay suposiciones sobre la infraestructura subyacente. Asegúrese de que la aplicación se escala según sea necesario, con una latencia máxima de 10 ms. |
Propiedad |
Propiedad conjunta: aplicación e infraestructura |
Propiedad conjunta: aplicación e infraestructura |
Solo la infraestructura |
Calidad de la información |
Extremadamente alta. Requiere un profundo conocimiento del ámbito subyacente. Por ejemplo, necesita saber qué equilibrador de carga F5, qué versión de software, etc. Un CLI o NMS sería un ejemplo de interfaces imperativas. |
Alta: requiere el conocimiento de lo que la infraestructura es capaz de hacer. Por ejemplo, en el ejemplo anterior hay un conocimiento previo de la infraestructura que soporta un equilibrador de carga. |
Baja: no requiere ningún conocimiento de las capacidades de la infraestructura. La calidad de la entrada se aproxima a la del lenguaje natural. |
Nivel de habilidad (persona) |
Habilidades específicas de la función. Por ejemplo, administrador de la red, administrador de computación, administrador del almacenamiento. Cada aspecto de la infraestructura requiere que el usuario sea un experto en esa área. |
Habilidades de implementación de aplicaciones. El usuario conoce el tipo de función necesaria para implementar la aplicación. Como en el caso anterior, el gestor de la aplicación sabe que se necesita un equilibrador de carga y las políticas de alto nivel en las que debe configurarse dicho equilibrador para soportar el autoescalado. |
Ingeniero de aplicaciones. Puede indicar a la infraestructura cuáles son los requisitos no funcionales de la aplicación. En este caso, la rapidez con la que la aplicación debe responder a la solicitud de un cliente. Se pueden añadir otros factores, como la ubicación geográfica, el coste, etc., según sea necesario. |
Alcance |
Las interfaces imperativas tienen |
El ámbito declarativo es mayor. Por lo general, se asocia con un motor de organización que habla con múltiples interfaces imperativas para lograr el resultado requerido. |
Alcance muy amplio porque el resultado de |
Ejemplo |
- nombre: actualizar servidores web hosts: webservers usuario_remoto: root tareas: - nombre: asegurar que apache esté en la última versión yum: nombre: httpd estado: último - nombre: escribir el archivo de configuración de apache plantilla: src: /srv/httpd.j2 dest: /etc/httpd.conf |
servidor apache: version: “última” |
latencia de la aplicación: - lt: 10 ms coste de infraestructura: - lt: 200 $ - facturación: mensual |
En el informe2 de expansión continua de las API de 2021 hemos cubierto ampliamente las API y abordamos en él muchas cuestiones que pueden surgir. La figura 6 muestra la diferencia entre "interclúster" e "intraclúster".
Intra-Cluster: En una arquitectura monolítica, puede haber muy pocas API expuestas con comunicación interna entre módulos a través de otros métodos de comunicación entre procesos. Mientras que una arquitectura de microservicios se divide en docenas, si no cientos, de API.
Sea cual sea el caso, cada clúster de aplicación se desarrolla y gestiona de manera opinable. Por ejemplo, en los casos de arquitectura de microservicios, un equipo puede utilizar cualquier tipo de malla de servicios: Istio, Linkerd, Aspen Mesh u otros. Cada enfoque tiene sus propios medios para gestionar y controlar las API dentro de su clúster, es decir, "intraclúster".
Hay muchas soluciones aquí y el objetivo de Edge 2.0 no es reinventar las organizaciones o equipos de desarrollo ni obligarlos a adoptar otra nueva tecnología.
Entre clústeres: A medida que aumenta la cantidad de servicios entregados a través de API, se crean nuevas aplicações utilizando servicios ya desarrollados o adoptados por diferentes equipos de aplicação dentro de la empresa, ya que no hay necesidad de reinventar la rueda.
También se están construyendo nuevas aplicaciones a través de diferentes combinaciones de API públicas y privadas. Desde el punto de vista de la arquitectura, las aplicaciones modernas aprovechan los servicios proporcionados por otros clústeres. En Distributed Cloud, estos clústeres se implementan globalmente, por lo que pueden estar ubicados en cualquier bien inmueble que pueda alojar la aplicación o formar parte del clúster de aplicaciones.
Para reiterar, el ámbito de un clúster de aplicación no se limita solamente a una organización. Los clústeres pueden estar en dos redes, aplicaciones, silos organizacionales o incluso entre dos empresas cualesquiera.
El ámbito abarca toda la gama de todas las permutaciones y combinaciones, lo que aumenta exponencialmente la complejidad de las operaciones. En la figura 7 se muestran las permutaciones de tráfico dentro del ámbito de implementación de la aplicación.
Una empresa típica tendrá diferentes arquitecturas de aplicación. Puede haber diferentes tipos de malla de servicios, o una aplicación web 2.0 basada en la arquitectura orientada a servicios, o una implementación de software monolítica, dependiendo del equipo de desarrollo e implementación. De este modo, las API se encuentran dispersas por toda la empresa, ya sean API privadas o el uso de API públicas. Este problema aún no está resuelto. La comunicación de las API entre múltiples ubicaciones es crítica y un problema con una solución esquiva en empresas de cualquier tamaño.
Existen varias soluciones para gestionar las API dentro de un clúster (por ejemplo, el controlador de entrada, la pasarela de API, etc.), mientras que la comunicación de las API entre clústeres no está resuelta de forma práctica, escalable y segura. Por lo tanto, nos centramos en el ámbito del control y la gestión unificados de las API para abordar únicamente los problemas entre clústeres.
Ofrece autonomía
Un valor infravalorado de la nube es la autonomía que ofrece al “consumidor de la nube”. Las empresas y los emprendedores pueden crear instancias de sus propias infraestructuras bajo demando mientras experimentan una apariencia de control total.
El principio de diseño fundamental que debe seguir una plataforma Edge 2.0 es ofrecer una experiencia autónoma al cliente de la nube mientras se implementan las medidas de seguridad adecuadas. Dado que las entidades pueden aparecer en cualquier infraestructura (de confianza o no), las medidas de seguridad deben implementarse de tal manera que no supongan una carga para la BU o el equipo DevOps responsable de crear la aplicación.
El reto emergente con Edge 2.0 será el de la detección, la identidad, la confianza y la capacidad de observación entre varios servicios.
Incluso en las empresas medianas, el número de API producidas anualmente sería grande. ¿Cómo descubren los equipos estos servicios dentro de la empresa? O, para el caso, ¿cómo pueden saber si los servicios siguen siendo válidos y a quién pertenecen? ¿Pueden estar seguros de que se trata de un servicio validado y de confianza? El problema se agrava cuando los equipos quieren consumir servicios creados por clústeres que residen fuera de los límites de la empresa, por ejemplo, proveedores de SaaS o aplicaciones que se ejecutan en dispositivos de borde completamente fuera del control administrativo de los equipos de infraestructura empresarial.
Plataforma de aplicaciones Edge 2.0
Teniendo en cuenta los retos presentados en las secciones anteriores, tenemos que ver Distributed Cloud al completo como una plataforma. En un nivel superior articulamos el objetivo de la solución: detectar de forma autónoma (sin intervención humana), escalar y asegurar la aplicación distribuida a través de la infraestructura descentralizada.
Básicamente, podemos describir la responsabilidad de la plataforma de aplicaciones Edge 2.0 (EAP) de la siguiente manera:
- Detección, identidad y confianza de la API
- Programación y organización de la infraestructura
- Conectividad segura de aplicaciones
Ámbito de EAP
La infraestructura es la totalidad del espacio de la solución donde los elementos de dicha infraestructura pueden aparecer y desaparecer continuamente. La propiedad de la infraestructura y sus recursos frente a la administración y el control de estos son dos construcciones distintas. El propietario de una infraestructura puede asignar una infraestructura específica o una instancia de la misma a una organización diferente que la gestione y configure, o dicho propietario puede retomar el control según sea necesario. La organización que gestiona y configura los elementos puede además asignarlos a proyectos o aplicaciones individuales. Esta noción no es nueva; por ejemplo, los proveedores de servicios en la nube ofrecen un control administrativo jerárquico que puede ser utilizado por los equipos de TI de una empresa para ofrecer además infraestructura como servicio (IaaS) a unidades empresariales internas, equipos, etc. La principal preocupación de Edge 2.0 es cómo llevar a cabo esto de forma extensiva en una nube hiperdistribuida, que es el estado actual y futuro de la infraestructura de borde.
Aquí es donde entra en juego el ámbito de la EAP. En la figura 8 se muestra el ámbito de EAP en el contexto de diferentes tipos de interfaces. Cada EAP se organiza con su ámbito local utilizando interfaces declarativas e imperativas. En este caso:
- Declarativas o imperativas serían las API de AWS, las API de Azure, etc.
- Las interfaces adaptables serían una novedad neta que habría que definir caso por caso.
Para aprovechar las ventajas de Distributed Cloud, la EAP debe tener la capacidad de aprovechar todos los nodos y las entidades disponibles a través de Distributed Cloud. La visión es que la EAP individual se convierta en el equivalente al concepto de sistema autónomo3 en las redes IP, pero para la capa de aplicación.
Si lo juntamos (figura 9), podemos construir una visión de alto nivel de cómo se pueden implementar múltiples EAP en una infraestructura de nube descentralizada que interactúan entre sí de forma autónoma.
Las interfaces adaptables también facilitan la integración de CI/CD y otras aplicaciones del ciclo de vida de las aplicaciones con Distributed Cloud. Las plataformas CI/CD pueden interactuar directamente con la EAP con interfaces adaptables sencillas que solo indican el resultado deseado.
Es importante señalar que la comunicación entre EAP también puede lograrse utilizando interfaces adaptables.
El marco de EAP
El marco de EAP, como se muestra en la figura 10, organiza las responsabilidades en términos de capacidades de cada instancia de EAP. El rol de EAP es interactuar con los controladores de la infraestructura subyacente, ya sea la infraestructura como servicio (IaaS), la plataforma como servicio (PaaS) o el software como servicio (SaaS), y organizar y programar los recursos adecuados según sea necesario.
Control y gestión unificados de la API
El futuro será una economía impulsada por las API, en la que estas son algo más que un simple enfoque de arquitectura de software simplificado a través de la malla de servicios. Una API se convertirá en el medio principal por el que cualquier entidad que participe en Distributed Cloud preste su servicio.
Tal y como se ha establecido, en una década, el número global de API públicas y privadas que estarán disponibles será de cientos de millones, si no de miles de millones. Las API reconfigurarán nuestra economía y, por lo tanto, exigen un análisis más preciso de lo que la EAP debe implementar para dar soporte a esta economía.
La expansión continua de las API exige que cada API sea detectable dentro y fuera de la EAP. Con Distributed Cloud, las API pueden estar en cualquier lugar en varios clústeres.
El supuesto subyacente es que el problema de la detección de las API es realmente un problema interclúster. El ámbito de EAP puede abarcar muchos clústeres de aplicaciones que utilizan diferentes enfoques de software (de microservicios a monolíticos), cada uno de los cuales implementa su propia estrategia de pasarela de API. Una EAP proporciona un repositorio común para que todas las API se registren y se puedan detectar dentro de su ámbito, y no solo dentro del clúster. Esta distinción es clave para derivar las limitaciones de las estrategias de pasarela de API existentes, por ejemplo, como en la malla de servicios.
El reto para la EAP es permitir la detección de una API, proporcionar la documentación adecuada sobre su uso y gestionar el ciclo de vida de dicha API para garantizar la coherencia, la precisión y el control de versiones. La EAP implementa un medio para informar a las entidades que utilizan sus API sobre el estado actual de las API específicas que se están utilizando. Esto podría ser simplemente estableciendo fechas de caducidad o informando explícitamente a través de algún sistema de mensajería.
La postura de seguridad adoptada es aquella en la que una aplicación asume que la infraestructura en la que está implementada ya está comprometida.
El pilar clave para implementar esta postura de seguridad es la identidad. Cada punto de conexión de la API debe tener una identidad única desde el punto de vista global. Las políticas y los controles de seguridad se mantienen por separado en un repositorio central.
Las API deben marcarse como públicas o privadas, lo que activa los componentes de seguridad de la infraestructura subyacente para que se configuren automáticamente para la API específica.
Todas las conversaciones entre aplicaciones comienzan con una política mediante la que se deniega todo. Que una API sea visible no significa que otra aplicación pueda llamarla. Esto debe configurarse explícitamente dentro de la política de seguridad de la aplicación.
EAP debe garantizar que todas las APIs dentro de su ámbito sean de confianza y, al mismo tiempo, que todas las API externas utilizadas por los servicios dentro de su ámbito de aplicación también sean de confianza.
“No se puede probar la confianza, eso es lo que la hace «confiable»” – Traidores, Netflix
La confianza es, básicamente, “reputación en el tiempo” y hay que revalidar continuamente esa confianza para asegurarse de que no ha caído por debajo de un nivel aceptable. Esto se ha convertido en un enfoque cada vez más común en el modelado e implementación de la confianza en los sistemas, lo que requiere que la confianza se evalúe continuamente en lugar de darse por sentada en la ejecución inicial.
La fluidez de la confianza a lo largo del tiempo puede ser un reto para algunas empresas que no tienen el lujo de disponer de tiempo para establecer la reputación mutua entre sus sistemas y los de terceros. Tanto la infraestructura como las API pueden causar estragos si la reputación no se vigila de cerca.
Suponiendo que un servicio dentro del ámbito de la EAP acceda a una API externa, la plataforma debe implementar un mecanismo por el cual el servicio que llama pueda estar seguro de la exactitud de la respuesta recibida desde la API externa. El hecho de que la respuesta de la API parezca válida no significa que se pueda confiar en ella. O bien la respuesta podría ser inexacta debido a problemas de calidad, o bien las inexactitudes se podrían haber insertado explícitamente para hacer que la empresa sea menos competitiva. Tener esta capacidad de asignar un factor de confianza a cada API, interna o externa, es algo exclusivo de la construcción de la EAP.
Una estrategia para implementar la confianza es promediarla a lo largo de un “período de tiempo” más reciente en lugar de utilizar el historial completo del servicio. Esto es como mirar las “Reseñas más importantes” frente a las “Más recientes” para un producto en Amazon. El producto bien puede tener cuatro estrellas, pero si la mayoría de las calificaciones negativas corresponden a los últimos seis meses, esto indica una ruptura reciente de la confianza, mientras que una afluencia de comentarios positivos en los últimos seis meses indicaría una corrección o reconstrucción de la confianza.
El factor de la confianza no es solo específico de si una API es una fuente conocida de datos falsos o engañosos o no. La reputación de una EAP también dependerá de lo bien que gestione y actualice las API de su ámbito. Además, la “confianza” también es relativa. El Servicio A puede confiar en el Servicio C, pero el Servicio B puede tener una experiencia diferente con el Servicio C.
Gestor de infraestructura del borde
Dado que Distributed Cloud es la base de la infraestructura de Edge 2.0, se vuelve imperativo que los recursos dentro del ámbito de una EAP sean fáciles de detectar, asegurar e instrumentar. Lo siguiente puede leerse como un conjunto de recomendaciones requeridas de las capacidades del gestor de infraestructura del borde.
Dentro de una EAP, los recursos pueden programarse según las necesidades. Pueden llegar o salir nuevos recursos de forma dinámica debido a la movilidad. Una EAP también puede enviar o recibir solicitudes de otras EAP para detectar y programar recursos según sea necesario en su nombre.
Para reiterar la postura de seguridad: la infraestructura sobre la que se implementa la aplicación ya está comprometida. Por lo tanto, la EAP debe garantizar la seguridad de la aplicación implementada dentro de su ámbito.
Independientemente del nivel administrativo, el marco de la EAP debe tener en cuenta múltiples caras de la seguridad, como (pero sin limitarse a ellas):
Amenazas externas: Por ejemplo, ataques de denegación de servicio distribuido (DDoS) y amenazas persistentes avanzadas (APT). Estos pueden mitigarse utilizando las mejores prácticas existentes en seguridad, como prevención de DDoS, firewalls y más. La recomendación es que sea obligatorio para todo el tráfico.
El hombre en el medio: Todo el tráfico debe estar cifrado y no se puede dar por sentado que la capa de aplicação hará lo correcto. Esto garantiza la confidencialidad básica de los datos frente a cualquier dispositivo de espionaje del tráfico y protege la integridad de los datos frente a manipulaciones durante la transmisión.
Amenazas internas: El alcance de la capa de infraestructura debe estar limitado y dirigido principalmente a protegerse a sí misma. La recomendación es evitar que un recurso dentro de la infraestructura lance un ataque interno contra el administrador de la infraestructura.
Si Edge 2.0 se centra en la experiencia que ofrece y no en el activo o su ubicación, es lógico que la telemetría también se centre en la experiencia.
La pregunta es: ¿a la experiencia de quién o qué nos referimos? La experiencia es la de cualquier entidad que resida o utilice la infraestructura para producir o consumir un servicio: aplicaciones, dispositivos, personas, aplicaciones de back-end, bases de datos, etc. El punto de vista de la experiencia es, por tanto, el de la entidad. El servicio que una entidad produce o consume está directamente relacionado con los recursos de computación, almacenamiento y red que se le asignan.
Pero no hay que limitarse a medir la experiencia, sino que también hay que poner medios para remediarla.
Cualquier entidad que consuma o preste un servicio puede determinar si está obteniendo la experiencia que solicitó. Sin embargo, en los entornos Distributed Cloud, puede ser casi imposible explicar lo que ocurrió en la capa de infraestructura que condujo a la mala experiencia.
Las métricas de alto nivel, como las mediciones de utilización de la CPU, de la memoria, del ancho de banda y de la latencia, no son suficientes para determinar por qué una aplicación no está obteniendo la experiencia solicitada3. Las métricas deben ser detalladas en el tiempo y recopilarse en lo más profundo de la pila de aplicaciones y siempre que estén disponibles en las diferentes capas de la pila de infraestructura.
Una estrategia de telemetría y datos sólida, escalable y ampliable es fundamental para la EAP. De esta manera, las estrategias de aprendizaje automático (ML) e inteligencia artificial (IA) pueden aprovecharse para tomar la mejor decisión sobre la reserva de nuevos recursos o la optimización del uso de los existentes.
Conectividad de aplicaciones definida por software
Aunque se supone que la conectividad y la accesibilidad son problemas resueltos, muchos equipos de red siguen luchando por racionalizar su tejido de red con las necesidades dinámicas de la capa de aplicación. Una plataforma debe abordar también estos retos.
El problema con los enfoques existentes es que trasladamos las necesidades de conectividad de las aplicaciones a la conectividad WAN de la empresa, especialmente en Distributed Cloud. Los enfoques para abordar Distributed Cloud podrían utilizar diferentes estrategias de SDN o métodos basados puramente en el enrutamiento. Pero estas soluciones dependen en gran medida de la homogeneidad de la infraestructura y, por tanto, se quedan cortas a la hora de ofrecer un comportamiento coherente.
El único medio por el que podemos conseguir una red globalmente escalable, segura y estable para la aplicación es separar el plano de conectividad de la aplicación de la red subyacente, como se comenta a continuación.
En la evolución hacia una arquitectura de Distributed Cloud, el patrón emergente de SDN consiste en organizar tanto las redes subyacentes como las superpuestas y permitir la programabilidad de extremo a extremo de la ruta de aplicación.
Con Edge 2.0 necesitamos aportar esta apariencia de estabilidad incluso con la conexión de las redes empresariales. Proponemos que el plano de conectividad de la aplicación se separe de la conectividad de la red empresarial. El patrón de conectividad de la aplicación puede o no seguir la misma conectividad de SDN que se ve con la superposición del centro de datos (por ejemplo, VXLAN, NVGRE u otros), o los patrones SDN basados en BGP.
No todas las redes se han separado en superpuestas y subyacentes. Los equipos de red ven ahora la necesidad de esta programabilidad conjunta como un requisito importante para permitir la automatización de extremo a extremo, para lo cual es fundamental la separación de la red subyacente y la superpuesta.
Separar el plano de aplicación de la red subyacente y el transporte anula la necesidad de que los equipos de red respondan activamente a cada solicitud de aplicación. Su ámbito se limita a proporcionar rutas robustas, estables y bien definidas con un enfoque en la optimización del uso del ancho de banda agregado con las latencias más bajas.
Modelo de interfaz adaptable
El principio fundamental de una EAP es que es independiente, autónomo y gestiona un subconjunto del espacio de soluciones global. Pero las EAP necesitan un medio para comunicarse y ofrecer sus recursos o solicitar recursos a otras EAP. Este enfoque tiene varias ventajas.
Una interfaz basada en resultados anula la necesidad de que la EAP conozca los detalles de la otra infraestructura. Supongamos que hay dos EAP: A y B. Cada EAP tiene un ámbito local de su infraestructura para programar y reservar recursos. EAP-A no necesita conocer los recursos proporcionados por EAP-B. Si, por ejemplo, EAP-A no puede satisfacer las necesidades de la aplicación y requiere recursos de la infraestructura que están en el ámbito de EAP-B, entonces puede simplemente expresar su objetivo deseado a EAP-B. Entonces se convierte en responsabilidad de EAP-B invocar interfaces declarativas o imperativas para reservar, asignar y configurar desde su conjunto de recursos libres. EAP-B también es responsable de garantizar el cumplimiento de los SLO para ese servicio dentro de su infraestructura.
Mientras que una sintaxis común será útil para arrancar un conjunto inicial de API adaptables, la implementación se vuelve más sofisticada y madura con el tiempo con el uso del procesamiento del lenguaje natural y la IA para reducir la calidad requerida de la entrada.
Los diferentes patrones operativos también se vuelven sencillos cuando solo es necesario especificar el estado deseado. Los patrones de resistencia, por ejemplo, pueden basarse simplemente en un SLO previsto. Se convierte en la responsabilidad de la EAP que proporciona el servicio para garantizar que los recursos dentro de su ámbito se asignan para cumplir los objetivos de nivel de servicio. La EAP que llama no tiene por qué preocuparse, pero probablemente tendría que supervisar las métricas del servicio para saber si se están cumpliendo o no.
Características de EAP
- Multiinquilino: Si bien la malla de EAP que se muestra en la Figura 9 corresponde a una única implementación, son posibles varios EAP por nube. Otra aplicação podría comunicarse con un EAP diferente o con una malla de EAP.
- Diseñado para escalar: Cada malla es una malla peer-to-peer (P2P) y puede escalarse horizontalmente. Los EAP pares pueden realizar un seguimiento de forma independiente de qué EAP tienen qué tipo de recurso y cómo conectarse al recurso. La IA y el aprendizaje automático mejorarán aún más la forma en que cada EAP programa recursos dentro de su propio alcance o se comunica con otros EAP según sea necesario.
- Redes integradas: Para que las aplicações se conecten a través de la nube distribuida, el EAP debe ser compatible con redes integradas independientes de la infraestructura subyacente.
Todo en uno
En la figura 12 se visualiza el rol de las diferentes capas cuando se implementa una aplicación en Distributed Cloud.
Los aspectos más destacados de esta representación son:
- Cada EAP tiene un ámbito localizado y todas sus capacidades no están indicadas en la figura 10. La EAP debe admitir la función de detección y programación de recursos. Las EAP programan los recursos mediante la interfaz con el controlador de la infraestructura apropiado a través de API adaptables.
- La conectividad de las aplicaciones no es lo mismo que la conectividad de la red (como en el modelo sidecar de malla de servicios, los recursos para conectar las aplicaciones a través de la nube múltiple deben formar parte de la infraestructura de aplicaciones). Se podría argumentar que el plano de infraestructura también proporciona la conectividad de red de las aplicaciones, por lo que debería estar por debajo de la capa de red. Eso también sería técnicamente correcto, pero hemos optado por subsumirlo dentro del plano de “conectividad de aplicación”, ya que se trata principalmente de funciones de red.
- El plano de la infraestructura debe considerarse separado del plano de la aplicación.
- La conectividad de la red es diferente del transporte, ya que estamos hablando esencialmente de redes enrutables específicas que son independientes de la conectividad de la aplicación.
- El plano de transporte se puede considerar como redes troncales agregadas que se pueden aprovisionar, siempre que el proveedor de telecomunicaciones habilite procesos y API para conectar la capa de red superior.
resumen
Este libro blanco trata de profundizar un poco más en el manifiesto original de Edge 2.0. Hemos introducido algunos temas nuevos con el objetivo de informar a las diferentes partes interesadas dentro de las organizaciones internas y externamente al sector.
Edge 2.0 se basa en la noción de Distributed Cloud en la que cada entidad puede participar tanto como fuente como destino de los servicios. El tema principal es que Edge 2.0 se centrará en la experiencia y no en el activo o la ubicación.
La plataforma de aplicaciones de borde (EAP) se presenta como una pila de capacidades que permiten aplicar Edge 2.0 en Distributed Cloud.
Los detalles de implementación se han omitido deliberadamente para presentar una visión independiente del proveedor.
Recursos
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipedia - Un sistema autónomo (AS) es una colección de prefijos de enrutamiento de Protocolo de Internet (IP) conectados bajo el control de uno o más operadores de red en nombre de una única entidad administrativa o dominio que presenta una política de enrutamiento común y claramente definida a Internet.