Los Ingress han sido, desde las primeras versiones de Kubernetes, la forma más habitual de exponer aplicaciones al exterior. Aunque su diseño inicial era sencillo y elegante, el éxito de Kubernetes y la creciente complejidad de los casos de uso han convertido al Ingress en una pieza problemática: limitado, inconsistente entre vendors y difícil de gobernar en entornos empresariales.
En este artículo analizamos por qué los Ingress se han convertido en una fuente constante de fricción, cómo han influido los distintos Ingress Controllers en esta situación y por qué cada vez más organizaciones están considerando alternativas como Gateway API.
Qué son los Ingress y por qué fueron diseñados así
El ecosistema de Ingress gira en torno a dos recursos principales:
🏷️ IngressClass
Define qué controlador gestionará los Ingress asociados. Su alcance es global al clúster, por lo que suele ser administrado por el equipo de plataforma.
🌐 Ingress
Es el recurso que los desarrolladores usan para exponer un servicio. Permite definir rutas, dominios, certificados TLS y poco más.
Su especificación es mínima por diseño, lo que permitió una adopción rápida, pero también sembró las bases de los problemas actuales.
El problema: un estándar demasiado simple para necesidades complejas
A medida que Kubernetes se convirtió en estándar empresarial, los usuarios querían replicar configuraciones avanzadas de proxies tradicionales: re-escrituras, timeouts, cabeceras personalizadas, CORS, etc. Pero Ingress no daba soporte nativo a todo esto.
Los vendors reaccionaron… y ahí nació el caos.
Anotaciones vs CRDs: dos caminos incompatibles
Los distintos Ingress Controllers han tomado caminos muy diferentes para añadir capacidades avanzadas:
📝 Anotaciones (NGINX, HAProxy…)
Ventajas:
Flexibles y fáciles de usar
Directamente en el recurso Ingress
Desventajas:
Cientos de anotaciones propietarias
Documentación fragmentada
Configuraciones no portables entre vendors
📦 CRDs personalizados (Traefik, Kong…)
Ventajas:
Más estructurado y potente
Mejor validación y control
Desventajas:
Añade nuevos objetos no estándar
Requiere instalarlos y gestionarlos
Menor interoperabilidad
¿Resultado? Infraestructuras profundamente acopladas a un vendor, lo que complica migraciones, auditorías y automatización.
La complejidad para los equipos de desarrollo
El diseño de Ingress implica dos responsabilidades muy diferenciadas:
Plataforma: define IngressClass
Aplicación: define Ingress
Pero la realidad es que el desarrollador acaba tomando decisiones que deberían ser responsabilidad del área de plataforma:
Certificados
Políticas de seguridad
Reglas de reescritura
CORS
Timeouts
Prácticas corporativas de naming
Esto provoca:
Configuraciones inconsistentes
Cuellos de botella en revisiones
Dependencia constante entre equipos
Falta de estandarización efectiva
En empresas grandes, donde la seguridad y la gobernanza son críticas, esto es especialmente problemático.
NGINX Ingress: la descomisión que reavivó el debate
La reciente descontinuación del NGINX Ingress Controller ha puesto en evidencia lo frágil del ecosistema:
Miles de clústeres dependen de él
Múltiples proyectos usan sus anotaciones
Migrar implica reescribir configuraciones enteras
Esto ha reactivado la conversación sobre la necesidad de un estándar real… y ahí aparece Gateway API.
Gateway API: una alternativa prometedora (pero no perfecta)
Gateway API nace para resolver muchas de las limitaciones de Ingress:
Separación clara entre responsabilidades (infraestructura vs aplicación)
Extensibilidad estandarizada
Más tipos de rutas (HTTPRoute, TCPRoute…)
Mayor expresividad sin depender de anotaciones propietarias
Pero también trae desafíos:
Requiere adopción gradual
No todos los vendors implementan lo mismo
La migración no es trivial
Aun así, se perfila como el futuro de la gestión de tráfico en Kubernetes.
Conclusión
Los Ingress han sido fundamentales para el éxito de Kubernetes, pero su propia simplicidad los ha llevado a convertirse en un cuello de botella. La falta de interoperabilidad, las diferencias entre vendors y la compleja gobernanza en entornos empresariales hacen evidente que es momento de adoptar modelos más maduros.
Gateway API no es perfecto, pero avanza en la dirección correcta. Las organizaciones que quieran estabilidad a futuro deberían empezar a planificar su transición.
En los últimos dos años, todos están hablando de Microservicios y quieren aplicarlos en cualquier lugar.
Es la misma historia con los contenedores y docker (y antes lo fue con el Enfoque en la Nube e incluso antes con SOA, BPM, EDA…).
Cualquier cosa que tenga suficiente ruido de la comunidad, resulta en que todos los clientes (y «todo tipo» de clientes) intentan aplicar la «nueva moda» sin importar qué. Debido a eso, todos los Integradores de Sistemas intentan buscar un lugar donde encaje (o incluso si no encaja…) para aplicar esta «nueva cosa» porque es «lo que tenemos que hacer ahora». Es como el negocio de la moda. ¿Qué está de moda hoy? ¿Eso? Ok, hagámoslo.
No me malinterpreten, esta publicación no va a estar en contra de los microservicios porque me encanta el concepto y me encantan las ventajas que trae consigo y lo bueno que es ir hacia este tipo de modelo.
Pero, me gustaría hablar sobre algunos aspectos específicos que no estaban en la charla común y la experiencia con este tipo de tecnología. Este patrón, modelo o paradigma, es genial y es un éxito comprobado.
Puedes ver cualquier charla de Adrian Cockcroft sobre su experiencia en Netflix para estar seguro de que esto no es solo una palabra de moda (#NoSoloUnaPalabraDeModa) pero, ¿es capaz de usarse en todos los casos?
Cuando usualmente vemos una charla sobre microservicios, siempre es la misma historia: microservicios vs aplicación monolítica, especialmente aplicaciones web siguiendo algún tipo de patrón cliente-servidor o incluso un patrón MVC o algo similar. Y para ese tipo de aplicaciones es genial, simple y claro.
Pero, ¿qué pasa con las Aplicaciones Empresariales donde en las últimas décadas seguimos un Enfoque SOA: ¿Es aplicable aquí?
Por supuesto, hay muchas diferencias entre el Enfoque de Microservicios (el puro, el que Martin Fowler usó en su artículo) y el Paradigma SOA. No comparten los mismos principios, pero al final están más cerca que los concursantes habituales que ves en todas las charlas (aplicación web monolítica vs microservicios).
Los microservicios hablan de romper el monolito y eso es fácil para una aplicación web, pero ¿qué pasa con una Arquitectura SOA? En este caso, ni siquiera es posible seguir ese camino.
Si alguna vez has trabajado en Integración Empresarial, has visto algunos silos y es obligatorio no tocarlos y mantenerlos de esa manera. Es algo que no está abierto a discusión.
Existen diferentes razones para esa decisión: Podría ser porque son tan antiguos que nadie sabe sobre ellos, sobre cómo hacen lo que hacen, o podría ser porque son tan críticos que nadie va a seguir ese camino o solo porque no hay un caso de negocio para justificar reemplazar este tipo de silos.
Entonces, ¿qué pasa ahora? ¿Podemos seguir el camino de los Microservicios o deberíamos quedarnos con el enfoque SOA? Los microservicios no solo se tratan de romper los silos, pero es algo muy importante, así que no, no podemos seguir el camino de los Microservicios para Integraciones Empresariales, pero podemos reunir todas las otras ventajas que incluyen los Microservicios e intentar aplicarlas a nuestra capa de integración (ahora, no estaríamos hablando de Arquitectura SOA porque la mayoría de estas ventajas están en contra de algunos de los principios de SOA).
La Ola de Microservicios también se trata de Ágil y DevOps, de ser más rápido, de estar automatizado, de ser mejor, de reducir tu tiempo de comercialización. Se trata de la nube (no en el término de nube pública, sino en el término de no estar atado a tu infraestructura). Se trata de todas esas cosas también.
Entonces, los Microservicios se tratan de tantas cosas que podríamos aplicar incluso si no pudiéramos ir al 100% sobre esto. Hay varios nombres para este enfoque como Arquitectura Basada en Servicios, pero me gusta mucho más el enfoque de micro-servicios (con guion en el medio, hablando de servicios que son micro) porque creo que explica mejor el enfoque.
Así que, nos gustaría hacer servicios más pequeños para ser más flexibles, para poder aplicar todas estas cosas de DevOps, y allí podemos aplicar todas las otras cosas relacionadas con la Ola de Microservicios.
Y eso no es algo nuevo, eso no es algo que esté comenzando ahora o en los últimos años.
Es algo que he visto desde el principio en mi carrera (hace una década) cuando comencé a trabajar con TIBCO AMX BusinessWorks que te da la oportunidad de decidir tú mismo el alcance de tus servicios y dependiendo de las necesidades podrías crear «Aplicaciones Empresariales» o podrías optar por «Servicios Empresariales» o «Servicios Pequeños» que trabajaban juntos para hacer el trabajo.
Y ese camino ha sido seguido no solo por TIBCO sino por algunas otras compañías también, con la evolución del concepto ESB para adaptarse a la nueva era, que eran más como PaaS donde te permitían ejecutar tus servicios en un mundo «algo» containerizado.
Por ejemplo, la Plataforma TIBCO AMX (desde 2006) podías desarrollar tus servicios y aplicaciones usando varios tipos de lenguajes y opciones como el Editor Gráfico para Mediaciones o Java, C/C++, .NET, Spring y así sucesivamente usando el estándar SCA y ejecutándose en una plataforma elástica basada en OSGI donde puedes gestionarlos a todos de la misma manera (suena similar, ¿verdad? 🙂 )
¿Qué pasa con la reutilización? El paradigma SOA tiene estándares muy altos para asegurar la reutilización de los servicios y el registro y repositorio empresarial… y el microservicio está (al principio) en contra de la reutilización, deberías duplicar en lugar de reutilizar para poder ser autónomo y más libre. Pero, los últimos avances en Microservicios incluyen una capa de Orquestación, cosas como Conductor que están siguiendo el camino de la reutilización y la orquestación. Así que, podemos encontrar un lugar intermedio, cuando necesitas reutilizar si es posible pero no detener tu agilidad para asegurar el 100% de reutilización de las oportunidades disponibles. El tiempo de comercialización es el factor crítico aquí para todos ahora, y todos los «principios» tienen que adaptarse a eso.
¿Qué pasa con DevOps y la Nube? No hay problema, aquí podrías incluir las mismas técnicas para este caso como lo estabas haciendo anteriormente. Infraestructura como Código, Contenedores, Integración y Despliegue Continuo, etc.
¿Qué pasa con los estándares ágiles REST/JSON y demás? Tampoco hay problemas aquí.
En resumen, puedes adoptar e implementar la mayoría de los sabores y componentes del movimiento de Microservicios, pero también necesitas comprometerte con otros, y no vas a usar «Microservicios puros», vas a usar otra cosa, y eso no es malo. Siempre tienes que adaptar cualquier paradigma a tu caso de uso específico.
Apache Kafka parece ser la solución estándar en la arquitectura actual, pero deberíamos centrarnos en si es la elección correcta para nuestras necesidades.
Hoy en día, estamos en una nueva era de Arquitectura Orientada a Eventos, y esta no es la primera vez que vivimos eso. Antes de los microservicios y la nube, EDA era la nueva normalidad en la integración empresarial. Basado en diferentes tipos de estándares, había protocolos como JMS o AMQP utilizados en productos basados en brokers como TIBCO EMS, Active MQ o IBM Websphere MQ, por lo que este enfoque no es algo nuevo.
Con el auge de las arquitecturas de microservicios y el enfoque liderado por API, parecía que habíamos olvidado la importancia de los sistemas de mensajería, y tuvimos que pasar por los mismos desafíos que vimos en el pasado para llegar a una nueva solución de mensajería para resolver ese problema. Así que estamos volviendo a la Arquitectura EDA, mecanismo pub-sub, para ayudarnos a desacoplar los consumidores y productores, moviéndonos de la orquestación a la coreografía, y todos estos conceptos encajan mejor en los mundos actuales con componentes cada vez más independientes que necesitan cooperación e integración.
Durante este esfuerzo, comenzamos a mirar nuevas tecnologías para ayudarnos a implementar eso nuevamente. Sin embargo, con la nueva realidad, olvidamos los protocolos y estándares pesados como JMS y comenzamos a pensar en otras opciones. Y debemos admitir que sentimos que hay un nuevo rey en esta área, y este es uno de los componentes críticos que parece ser, sin importar qué, en la arquitectura de hoy: Apache Kafka.
Y no me malinterpretes. Apache Kafka es fantástico, y ha sido probado durante mucho tiempo, una solución lista para producción, de alto rendimiento, con capacidades impresionantes para la reproducción y una API poderosa para facilitar la integración. Apache Kafka tiene algunos desafíos en este mundo nativo de la nube porque no se lleva tan bien con algunas de sus reglas.
Si has usado Apache Kafka durante algún tiempo, eres consciente de que hay desafíos particulares con él. Apache Kafka tiene una arquitectura que proviene de sus días en LinkedIn en 2011, donde Kubernetes o incluso Docker y las tecnologías de contenedores no eran una cosa, lo que hace que ejecutar Apache Kafka (servicio puramente con estado) de manera contenedorizada sea bastante complicado. Hay mejoras usando gráficos de helm y operadores para facilitar el viaje, pero aún así, no se siente como si las piezas pudieran integrarse bien de esa manera. Otra cosa es la geo-replicación que incluso con componentes como MirrorMaker, no es algo que se use, funcione sin problemas y se sienta integrado.
Otras tecnologías están tratando de proporcionar una solución para esas capacidades, y una de ellas es también otro proyecto de la Fundación Apache que ha sido donado por Yahoo! y se llama Apache Pulsar.
No me malinterpretes; esto no se trata de encontrar una nueva verdad, esa única solución de mensajería que es perfecta para las arquitecturas de hoy: no existe. En el mundo actual, con tantos requisitos y variables diferentes para los diferentes tipos de aplicaciones, una talla única ya no es cierta. Así que deberías dejar de pensar en cuál solución de mensajería es la mejor, y pensar más en cuál sirve mejor a tu arquitectura y cumple con los requisitos tanto técnicos como comerciales.
Hemos cubierto diferentes formas de comunicación general, con varias soluciones específicas para la comunicación sincrónica (tecnologías de malla de servicios y protocolos como REST, GraphQL o gRPC) y diferentes para la comunicación asincrónica. Necesitamos profundizar en la comunicación asincrónica para encontrar lo que funciona mejor para ti. Pero primero, hablemos un poco más sobre Apache Pulsar.
Apache Pulsar
Apache Pulsar, como se mencionó anteriormente, ha sido desarrollado internamente por Yahoo! y donado a la Fundación Apache. Como se indica en su sitio web oficial, hay varios puntos clave a mencionar al comenzar a explorar esta opción:
Funciones de Pulsar: Despliega fácilmente lógica de cómputo ligera usando APIs amigables para desarrolladores sin necesidad de ejecutar tu motor de procesamiento de flujos
Probado en producción: Apache Pulsar ha funcionado en producción a escala Yahoo durante más de tres años, con millones de mensajes por segundo a través de millones de temas
Baja latencia con durabilidad: Diseñado para baja latencia de publicación (< 5ms) a escala con fuertes garantías de durabilidad
Geo-replicación: Diseñado para replicación configurable entre centros de datos en múltiples regiones geográficas
Multi-tenencia: Construido desde cero como un sistema multi-tenant. Soporta Aislamiento, Autenticación, Autorización y Cuotas
Almacenamiento persistente: Almacenamiento persistente de mensajes basado en Apache BookKeeper. Proporciona aislamiento a nivel de IO entre operaciones de escritura y lectura
Bibliotecas de clientes: Modelos de mensajería flexibles con APIs de alto nivel para Java, C++, Python y GO
Operabilidad: API de administración REST para aprovisionamiento, administración, herramientas y monitoreo. Despliega en metal desnudo o Kubernetes.
Como podemos ver, en su diseño, Apache Pulsar está abordando algunas de las principales debilidades de Apache Kafka como la Geo-replicación y su enfoque nativo de la nube.
Apache Pulsar proporciona soporte para el patrón pub/sub, pero también ofrece muchas capacidades que también lo colocan como un sistema de mensajería de cola tradicional con su concepto de temas exclusivos donde solo uno de los suscriptores recibirá el mensaje. También proporciona conceptos y características interesantes utilizados en otros sistemas de mensajería:
Temas de Carta Muerta: Para mensajes que no pudieron ser procesados por el consumidor.
Temas Persistentes y No Persistentes: Para decidir si deseas persistir tus mensajes o no durante la transición.
Espacios de Nombres: Para tener una distribución lógica de tus temas, de modo que una aplicación pueda agruparse en espacios de nombres como lo hacemos, por ejemplo, en Kubernetes para poder aislar algunas aplicaciones de las otras.
Failover: Similar a exclusivo, pero cuando el consumidor adjunto falla al procesar, otro toma la oportunidad de procesar los mensajes.
Compartido: Para poder proporcionar un enfoque de round-robin similar al sistema de mensajería de cola tradicional donde todos los suscriptores estarán adjuntos al tema, pero solo uno recibirá el mensaje, y distribuirá la carga entre todos ellos.
Suscripciones Multi-tema: Para poder suscribirse a varios temas usando una expresión regular (similar al enfoque de Subject de TIBCO Rendezvous, por ejemplo, en los años 90) que ha sido tan poderoso y popular.
Pero también, si requieres características de Apache Kafka, aún tendrás conceptos similares como temas particionados, temas compartidos por clave, y así sucesivamente. Así que tienes todo a tu disposición para elegir qué tipo de configuración funciona mejor para ti y tus casos de uso específicos, también tienes la opción de mezclar y combinar.
Arquitectura de Apache Pulsar
La Arquitectura de Apache Pulsar es similar a otros sistemas de mensajería comparables hoy en día. Como puedes ver en la imagen a continuación del sitio web de Apache Pulsar, estos son los componentes principales de la arquitectura:
Brokers: Uno o más brokers manejan mensajes entrantes de productores, despachan mensajes a consumidores
Así que puedes ver que esta arquitectura también es bastante similar a la de Apache Kafka nuevamente con la adición de un nuevo concepto del Cluster de BookKeeper.
El Broker en Apache Pulsar son componentes sin estado que principalmente ejecutarán dos piezas
Servidor HTTP que expone una API REST para gestión y es utilizado por consumidores y productores para búsqueda de temas.
Servidor TCP usando un protocolo binario llamado dispatcher que se utiliza para todas las transferencias de datos. Por lo general, los mensajes se despachan desde un caché de libro mayor gestionado por razones de rendimiento. Pero también si este caché crece demasiado, interactuará con el cluster de BookKeeper por razones de persistencia.
Para soportar la Replicación Global (Geo-Replicación), los Brokers gestionan replicadores que siguen las entradas publicadas en la región local y las republican en las regiones remotas.
El Cluster de Apache BookKeeper se utiliza como almacenamiento persistente de mensajes. Apache BookKeeper es un sistema de registro de escritura anticipada (WAL) distribuido que gestiona cuándo los mensajes deben ser persistidos. También soporta escalado horizontal basado en la carga y soporte multi-log. No solo los mensajes son persistentes sino también los cursores que son la posición del consumidor para un tema específico (similar al offset en la terminología de Apache Kafka)
Finalmente, el Cluster de Zookeeper se utiliza en el mismo rol que Apache Kafka como un cluster de almacenamiento de configuración de metadatos para todo el sistema.
Hola Mundo usando Apache Pulsar
Veamos cómo podemos crear un caso rápido de «Hola Mundo» usando Apache Pulsar como protocolo, y para hacer eso, vamos a intentar implementarlo de manera nativa en la nube. Así que haremos un cluster de un solo nodo de Apache Pulsar en una instalación de Kubernetes y desplegaremos una aplicación productora usando la tecnología Flogo y una aplicación consumidora usando Go. Algo similar a lo que puedes ver en el diagrama a continuación:
Diagrama sobre el caso de prueba que estamos haciendo
Y vamos a intentar mantenerlo simple, así que solo usaremos docker puro esta vez. Así que, primero que nada, solo inicia el servidor de Apache Pulsar y para hacer eso usaremos el siguiente comando:
Ahora, necesitamos crear aplicaciones simples, y para eso, se utilizarán Flogo y Go.
Comencemos con el productor, y en este caso, usaremos la versión de código abierto para crear una aplicación rápida.
Primero que nada, solo usaremos la interfaz web (dockerizada) para hacer eso. Ejecuta el comando:
docker run -it -p 3303:3303 flogo/flogo-docker eula-accept
E instalamos una nueva contribución para habilitar la actividad del publicador de Pulsar. Para hacer eso, haremos clic en el botón «Instalar nueva contribución» y proporcionaremos la siguiente URL:
// Recibe mensajes del canal. El canal devuelve una estructura que contiene el mensaje y el consumidor de donde
// se recibió el mensaje. No es necesario aquí ya que tenemos un solo consumidor, pero el canal podría ser
// compartido entre múltiples consumidores también
for cm := range channel {
msg := cm.Message
fmt.Printf(“Mensaje recibido msgId: %v — contenido: ‘%s’n”,
msg.ID(), string(msg.Payload()))
consumer.Ack(msg)
}
}
Y después de ejecutar ambos programas, puedes ver la siguiente salida como puedes ver, pudimos comunicar ambas aplicaciones en un flujo sin esfuerzo.
Este artículo es solo un punto de partida, y continuaremos hablando sobre cómo usar Apache Pulsar en tus arquitecturas. Si deseas echar un vistazo al código que hemos utilizado en este ejemplo, puedes encontrarlo aquí:
“Que vivas en tiempos interesantes” es la traducción al inglés de la maldición china, y esto no podría ser más cierto como descripción de los tiempos en los que vivimos en cuanto a nuestra arquitectura de aplicaciones y desarrollo de aplicaciones.
Todos los cambios del enfoque nativo de la nube, incluyendo todas las nuevas tecnologías que vienen con él, como contenedores, microservicios, API, DevOps, etc., han transformado completamente la situación para cualquier arquitectura, desarrollador o administración de sistemas.
Es algo similar si te fuiste a la cama en 2003 y te despiertas en 2020, todos los cambios, todas las nuevas filosofías, pero también todos los desafíos únicos que vienen con los cambios y nuevas capacidades son cosas con las que necesitamos lidiar hoy.
Creo que todos podemos estar de acuerdo en que el presente es políglota en términos de desarrollo de aplicaciones. Hoy no se espera que ninguna gran empresa o corporación encuentre una tecnología disponible, un lenguaje disponible para soportar todos sus productos internos. Hoy todos seguimos y estamos de acuerdo con el principio de “la herramienta adecuada para el trabajo adecuado” para intentar crear nuestro conjunto de herramientas de tecnologías que vamos a usar para resolver diferentes casos de uso o patrones que necesitas enfrentar.
Pero ese acuerdo y movimiento también vienen con su desafío respecto a cosas en las que usualmente no pensamos, como el rastreo y la observabilidad en general.
Cuando usamos una sola tecnología, todo es más sencillo. Definir una estrategia común para rastrear tus flujos de extremo a extremo es fácil; solo necesitas incrustar la lógica en tu marco de desarrollo común o biblioteca que todos tus desarrollos están usando. Probablemente definir una arquitectura de encabezado típica con todos los datos que necesitas para poder rastrear efectivamente todas las solicitudes y definir un protocolo estándar para enviar todos esos rastros a un sistema estándar que pueda almacenarlos y correlacionarlos todos y explicar el flujo de extremo a extremo. Pero intenta mover eso a un ecosistema políglota: ¿Debería escribir mi marco o biblioteca para cada lenguaje o tecnología que necesitaría usar, o también puedo usar en el futuro? ¿Tiene sentido eso?
Pero no solo eso, ¿debería ralentizar la adopción de una nueva tecnología que puede ayudar rápidamente al negocio porque necesito proporcionar desde un equipo compartido este tipo de componentes estándar? Ese es el mejor caso en el que tengo suficiente gente que sabe cómo funcionan los internos de mi marco y tiene las habilidades en todos los lenguajes que estamos adoptando para poder hacerlo rápidamente y de manera eficiente. Parece poco probable, ¿verdad?
Entonces, a nuevos desafíos también nuevas soluciones. Ya he estado hablando sobre Service Mesh respecto a las capacidades que proporciona desde una perspectiva de comunicación, y si no lo recuerdas, puedes echar un vistazo a esas publicaciones:
Pero también proporciona capacidades desde otras perspectivas y el rastreo y la observabilidad es una de ellas. Porque cuando no podemos incluir esas características en cualquier tecnología que necesitemos usar, podemos hacerlo en una tecnología general que sea compatible con todas ellas, y ese es el caso con Service Mesh.
Como Service Mesh es la forma estándar de comunicar sincrónicamente tus microservicios en una comunicación de este a oeste cubriendo la comunicación de servicio a servicio. Entonces, si puedes incluir en ese componente también la capacidad de rastreo, puedes tener un rastreo de extremo a extremo sin necesidad de implementar nada en cada una de las diferentes tecnologías que puedes usar para implementar la lógica que necesitas, así que, has cambiado de la Figura A a la Figura B en la imagen a continuación:
Implementación de lógica de rastreo en la aplicación vs. Soporte de rastreo de Service Mesh
Y eso es lo que la mayoría de las tecnologías de Service Mesh están haciendo. Por ejemplo, Istio, como una de las opciones predeterminadas cuando se trata de Service Mesh, incluye una implementación del estándar OpenTracing que permite la integración con cualquier herramienta que soporte el estándar para poder recopilar toda la información de rastreo para cualquier tecnología que se use para comunicarse a través de la malla.
Entonces, ese cambio de mentalidad nos permite integrar fácilmente diferentes tecnologías sin necesidad de ningún soporte excepcional de esos estándares para cualquier tecnología específica. ¿Significa eso que la implementación de esos estándares para esas tecnologías no es necesaria? En absoluto, eso sigue siendo relevante, porque las que también soportan esos estándares pueden proporcionar aún más información. Después de todo, el Service Mesh solo conoce parte de la información que es el flujo que está sucediendo fuera de cada tecnología. Es algo similar a un enfoque de caja negra. Pero también agregar el soporte para cada tecnología al mismo estándar proporciona un enfoque adicional de caja blanca como puedes ver gráficamente en la imagen a continuación:
Combinación de datos de rastreo de caja blanca y datos de rastreo de caja negra
Ya hablamos sobre el cumplimiento de algunas tecnologías con el estándar OpenTracing como TIBCO BusinessWorks Container Edition que puedes recordar aquí:
Entonces, también, el soporte de estas tecnologías de los estándares de la industria es necesario e incluso una ventaja competitiva porque sin necesidad de desarrollar tu marco de rastreo, puedes lograr un enfoque de Datos de Rastreo Completo adicional a lo que ya proporciona el nivel de Service Mesh en sí mismo.
La gestión de registros no parece un tema muy fantástico. No es el tema que ves y dices: “¡Oh! ¡Increíble! Esto es con lo que he soñado toda mi vida”. No, soy consciente de que esto no es muy atractivo, pero eso no lo hace menos crítico que otras capacidades que tu arquitectura necesita tener.
Desde el principio de los tiempos, hemos usado archivos de registro como la única fuente de datos confiable cuando se trataba de solucionar problemas de tus aplicaciones o saber qué falló en tu implementación o cualquier otra acción relacionada con una computadora.
El procedimiento era fácil:
Lanzar “algo”
“Algo” falló.
Revisar los registros
Cambiar algo
Repetir
Y lo hemos estado haciendo de esa manera durante mucho, mucho tiempo. Incluso con otros enfoques más robustos de manejo y gestión de errores como el Sistema de Auditoría, también volvemos a los registros cuando necesitamos obtener el detalle minucioso sobre el error. Buscar una traza de pila allí, más detalle sobre el error que se insertó en el Sistema de Auditoría o más datos que solo el código de error y la descripción que proporcionó una API REST.
Los sistemas comenzaron a crecer, la arquitectura se volvió más complicada, pero incluso con eso, terminamos con el mismo método una y otra vez. Estás al tanto de arquitecturas de agregación de registros como la pila ELK o soluciones comerciales como Splunk o incluso ofertas SaaS como Loggly, pero simplemente piensas que no son para ti.
Son caras de comprar o caras de configurar, y conoces muy bien tu ecosistema, y es más fácil simplemente entrar en una máquina y seguir el archivo de registro. Probablemente también tengas tu caja de herramientas de scripts para hacer esto tan rápido como cualquiera puede abrir Kibana e intentar buscar algo como el ID de instancia allí para ver el error de una transacción específica.
Ok, necesito decirte algo: Es hora de cambiar, y te voy a explicar por qué.
Las cosas están cambiando, y TI y todos los nuevos paradigmas se basan en algunos fundamentos comunes:
Vas a tener más componentes que van a funcionar aislados con sus archivos de registro y datos.
Las implementaciones serán más regulares en tu entorno de producción, y eso significa que las cosas van a estar mal más a menudo (de una manera controlada, pero más a menudo)
Las tecnologías van a coexistir, por lo que los registros van a ser muy diferentes en términos de patrones y diseños, y necesitas estar preparado para eso.
Así que, discutamos estos tres argumentos que espero te hagan pensar de una manera diferente sobre las arquitecturas y enfoques de Gestión de Registros.
1.- Tu enfoque simplemente no escalable
Tu enfoque es excelente para sistemas tradicionales. ¿Cuántas máquinas gestionas? ¿30? ¿50? ¿100? Y puedes hacerlo bastante bien. Imagina ahora una plataforma basada en contenedores para una empresa típica. Creo que un número promedio podría ser alrededor de 1000 contenedores solo para propósitos comerciales, sin hablar de arquitectura o servicios básicos. ¿Eres capaz de estar listo para ir contenedor por contenedor para verificar 1000 flujos de registros para conocer el error?
Incluso si eso es posible, ¿vas a ser el cuello de botella para el crecimiento de tu empresa? ¿Cuántos registros de contenedores puedes seguir? ¿2000? Como decía al principio, eso simplemente no es escalable.
2.- Los registros no están allí para siempre
Y ahora, lees el primer tema y probablemente solo estás diciendo a la pantalla que estás usando para leer esto. ¡Vamos! Ya sé que los registros no están allí, se están rotando, se pierden, y así sucesivamente.
Sí, eso es cierto, esto es aún más importante en el enfoque nativo de la nube. Con plataformas basadas en contenedores, los registros son efímeros, y además, si seguimos el manifiesto de la aplicación de 12 factores, no hay archivo con el registro. Todas las trazas de registro deben imprimirse en la salida estándar, y eso es todo.
¿Y dónde se eliminan los registros? Cuando el contenedor falla… ¿y cuáles son los registros que más necesitas? Los que han fallado.
Así que, si no haces nada, las trazas de registro que más necesitas son las que vas a perder.
3.- Necesitas poder predecir cuándo las cosas van a fallar
Pero los registros no solo son válidos cuando algo sale mal, son adecuados para detectar cuándo algo va a estar mal, sino para predecir cuándo las cosas van a fallar. Y necesitas poder agregar esos datos para poder generar información y conocimientos a partir de ellos. Para poder ejecutar modelos de ML para detectar si algo va como se espera o si algo diferente está sucediendo que podría llevar a algún problema antes de que ocurra.
Resumen
Espero que estos argumentos te hayan hecho pensar que incluso para tu empresa de pequeño tamaño o incluso para tu sistema, necesitas poder configurar una técnica de Agregación de Registros ahora y no esperar a otro momento cuando probablemente sea demasiado tarde.
Serverless es un tema apasionante para muchas personas, y es algo que ha evolucionado mucho desde su concepción. Comenzó siendo un enfoque para deshacerse de los servidores, no en el lado técnico (obviamente) sino en el lado de la gestión.
La idea detrás de esto es hacer que los desarrolladores, y las personas de TI en general, se concentren en crear código y desplegarlo en algún tipo de infraestructura gestionada. La contraposición habitual era contra plataformas basadas en contenedores. Con servicios de Kubernetes gestionados, como EKS o AKS, todavía eres responsable de los trabajadores que están ejecutando tu carga. No necesitas preocuparte por el componente de administración. Pero, de nuevo, necesitas manejar y gestionar algunas partes de la infraestructura.
Este enfoque también se incorporó en otros sistemas, como iPaaS y ofertas puras de SaaS en cuanto a low code o no code. E incluimos el concepto de función como servicio para marcar la diferencia en este enfoque. Entonces, la primera pregunta es: ¿Cuál es la principal diferencia entre una función que despliegas en tu proveedor sin servidor y una aplicación que puedes usar en tu iPaaS?
Depende de la perspectiva que quieras analizar.
Voy a omitir los detalles técnicos sobre capacidades de escalar a cero, técnicas de calentamiento, etc., y me centraré en la perspectiva del usuario. La principal diferencia es cómo estos servicios te van a cobrar en función de tu uso.
iPaaS u ofertas similares de SaaS te van a cobrar en función de la instancia de la aplicación o algo similar. Pero la plataforma sin servidor/función como servicio te va a costar en función del uso que hagas de esa función. Eso significa que te van a cobrar en función del número de solicitudes que reciba tu función.
Eso es un cambio de juego. Proporciona la implementación más precisa de las operaciones optimizadas y el enfoque de elasticidad. En este caso, es directo y claro que solo vas a pagar por el uso de tu plataforma. La economía es excelente. Echa un vistazo a la oferta de AWS Lambda hoy:
El nivel de uso gratuito de AWS Lambda incluye 1 millón de solicitudes gratuitas por mes y 400,000 GB-segundos de tiempo de cómputo por mes.
Y después de ese primer millón de solicitudes, te van a cobrar 0.20 $ por cada millón de solicitudes adicionales.
Al leer las oraciones anteriores, probablemente estés pensando: «Eso es perfecto. ¡Voy a migrar todo a ese enfoque!»
No tan rápido. Este estilo de arquitectura no es válido para todos los servicios que puedas tener. Aunque la economía es excelente, estos servicios vienen con limitaciones y anti-patrones que significan que deberías evitar esta opción.
Primero, comencemos con las restricciones que la mayoría de los proveedores de la nube definen para este tipo de servicios:
Tiempo de ejecución: Esto suele estar limitado por tu proveedor de la nube a un número máximo de segundos de ejecución. Eso es justo. Si te van a cobrar por solicitud, y puedes hacer todo el trabajo en una sola solicitud que tarda 10 horas en completarse utilizando los recursos del proveedor, ¡probablemente eso no sea justo para el proveedor!
Recursos de memoria: También limitados, por las mismas razones.
Carga útil de la interfaz: Algunos proveedores también limitan la carga útil que puedes recibir o enviar como parte de una función, algo a tener en cuenta cuando estás definiendo el estilo de arquitectura para tu carga de trabajo.
En un momento, veremos los anti-patrones o cuándo deberías evitar usar esta arquitectura y enfoque
Pero primero, una breve introducción a cómo funciona esto a nivel técnico. Esta solución puede ser muy económica porque el tiempo que tu función no está procesando ninguna solicitud no está cargado en sus sistemas. Por lo tanto, no está utilizando ningún recurso en absoluto (solo una pequeña parte de almacenamiento, pero esto es algo ridículo) y generando cualquier costo para el proveedor de la nube. Pero eso también significa que cuando alguien necesita ejecutar tu función, el sistema necesita recuperarla, lanzarla y procesar la solicitud. Eso generalmente se llama el «tiempo de calentamiento», y su duración depende de la tecnología que uses.
Servicios de baja latencia y Servicios con tiempo de respuesta crítico: Si tu servicio necesita baja latencia o el tiempo de respuesta debe ser agresivo, este enfoque probablemente no va a funcionar para ti debido al tiempo de calentamiento. Sí, hay soluciones alternativas para resolver esto, pero requieren solicitudes ficticias al servicio para mantenerlo cargado y generan costos adicionales.
Proceso por lotes o programado: Esto es para API sin estado para el mundo nativo de la nube. Si tienes un proceso por lotes que podría llevar tiempo, tal vez porque está programado por las noches o los fines de semana, podría no ser la mejor idea ejecutar este tipo de carga de trabajo.
Servicios masivos: Si pagas por solicitud, es importante evaluar el número de solicitudes que tu servicio va a recibir para asegurarte de que los números todavía estén a tu favor. Si tienes un servicio con millones de solicitudes por segundo, probablemente este no sea el mejor enfoque para tu presupuesto de TI.
Al final, serverless/función como servicio es tan genial por su simplicidad y lo económico que es. Al mismo tiempo, no es una bala de plata para cubrir todas tus cargas de trabajo.
Necesitas equilibrarlo con otros enfoques arquitectónicos y plataformas basadas en contenedores, o ofertas de iPaaS y SaaS, para mantener tu caja de herramientas llena de opciones para encontrar la mejor solución para cada patrón de carga de trabajo que tenga tu empresa.
Cómo lograr verdaderamente la agilidad en su organización enfocándose en lo que importa para su negocio y multiplicar la productividad de su equipo de desarrollo
La moda es cíclica y lo mismo ocurre en la Ingeniería de Software. Vivimos en un mundo donde cada innovación parece similar a una del pasado; avanzamos hace algún tiempo. Eso se debe a que lo que estamos haciendo es simplemente refinar una y otra vez soluciones para los mismos problemas.
Hemos vivido en los últimos años un auge de «el desarrollador es el nuevo negro», donde cualquier cosa relacionada con escribir código es excelente. Incluso los desarrolladores ahora son vistos como un personaje genial como los de Silicon Valley (el programa de HBO) en lugar de ser objeto de burla como en The I.T Crowd.
Pero, ahora, parece que estamos volviendo a un nuevo auge de lo que se llama Aplicaciones de Bajo Código (o Sin Código).
Una Aplicación de Bajo Código es un software que te ayuda a generar tus aplicaciones o servicios sin necesidad de escribir código en ningún lenguaje de programación, en lugar de hacer eso, puedes arrastrar y soltar algunas cajas que representan lo que te gustaría hacer en lugar de escribirlo tú mismo.
Eso ha proporcionado ventajas que ahora están nuevamente sobre la mesa. Echemos un vistazo a esas ventajas con más detalle.
1.- Proporciona más agilidad
Eso está claro. No importa cuán alto sea el nivel de tu lenguaje de programación, no importa cuántos arquetipos tengas para generar el esqueleto de tu proyecto o el marco y las bibliotecas que uses. Escribir siempre es más lento que arrastrar algunas cajas sobre el lienzo blanco y conectarlas con algunos enlaces.
Y soy una persona que es un tipo de terminal y usuario avanzado de VI, y me doy cuenta del poder del teclado, pero seamos honestos y hagamos una pregunta:
¿Cuántas de las palabras clave que escribes en tu código están proporcionando valor al negocio y cuántas son necesarias solo por razones técnicas?
No solo cosas como el manejo de excepciones, auditoría, registro, descubrimiento de servicios, gestión de configuración, sino cosas como la estructura de bucles, definición de firmas de funciones, definición de variables, definición de clases, y así sucesivamente…
Puedes enfocarte verdaderamente en el valor comercial que estás tratando de proporcionar a tu negocio en lugar de pasar tiempo en cómo gestionar cualquier capacidad técnica.
2.- Más fácil de mantener
Un mes después de la producción solo el desarrollador y dios saben lo que hace el código. Después de un año, solo dios sabe…
Codificar es increíble, pero al mismo tiempo es complejo de mantener. Principalmente en las empresas cuando los desarrolladores están cambiando de un proyecto a otro, de algunos departamentos a otros, y nuevas personas se están incorporando todo el tiempo para mantener y evolucionar algunos códigos.
Y los que han estado en la industria por algún tiempo, conocen por ejemplo la situación cuando la gente dice: “Prefiero no tocar eso porque no sabemos qué está haciendo”, “No podemos migrar esta aplicación de Mainframe porque no sabemos si podrá capturar toda la funcionalidad que están proporcionando.”
Y eso es malo por varias razones. En primer lugar, es costoso de mantener, más complejo de hacerlo, pero en segundo lugar también te impide evolucionar al ritmo que deseas hacerlo.
3.- Más seguro y rentable
No me malinterpretes sobre esto: Programar puede ser tan seguro como cualquier aplicación de bajo código. Eso está claro porque, al final, cualquier aplicación de bajo código termina generando el mismo binario o bytecode para ser ejecutado.
El problema es que esto va a depender de las habilidades del programador. Vivimos en una situación que, incluso programar y los desarrolladores son algo genial, ya que necesitas un gran número de desarrolladores en tu equipo, lo que implica que no todos ellos son tan experimentados y hábiles como quisieras que fueran.
La realidad es mucho más compleja y también necesitas lidiar con la realidad de tu presupuesto y encontrar la manera de obtener lo mejor de tu equipo.
Usando una aplicación de bajo código, tienes garantizada la calidad de los componentes base que son verificados por una empresa y que han mejorado con equipos dedicados incorporando comentarios de clientes de todo el mundo, lo que la hace más segura.
4.- Tan lista como una solución basada en código para necesidades específicas
Uno de los mitos que se dicen contra el Bajo Código es que es adecuado para cargas de trabajo y casos de uso genéricos, pero no es capaz de adaptarse y optimizarse para tus necesidades.
Con respecto a esta resistencia habitual, en primer lugar, necesitamos trabajar en la idea errónea del nivel de especificación que necesita nuestro software. Al final, las veces que necesitas hacer algo tan específico que no está cubierto por las opciones disponibles de inmediato son tan pocas que es complejo justificarlo. ¿Vas a hacer más lento el 99% de tu desarrollo solo para poder hacerlo más rápido en un 1%? ¿Cuánto de tus cargas de trabajo no son similares a lo que otras empresas están haciendo en la misma industria?
Pero incluso por el bien de la discusión, asumamos que eso es cierto, y necesitas una sola pieza de lógica que una aplicación de bajo código no proporciona de inmediato. Ok, Bajo Código significa que no necesitas escribir código, no que no puedas hacerlo.
La mayoría de las plataformas admiten la opción de agregar código si es necesario como una opción para cubrir estos casos. Entonces, incluso en esos casos, todavía tienes las mismas herramientas para hacerlo específico sin perder todas las ventajas de tus actividades diarias.
Resumen
Las aplicaciones de bajo código son una de las soluciones que tienes a tu disposición para mejorar tu agilidad y tu productividad en tus desarrollos para seguir el ritmo de los cambios en tu negocio.
Las soluciones que trabajan en ese espacio no son nuevas, pero han sido renovadas para adaptarse a los paradigmas modernos de los desarrolladores (microservicios, basados en contenedores, dirigidos por API, impulsados por eventos…) por lo que no vas a perder nada, sino a ganar más tiempo para proporcionar aún más valor a tu negocio.
El mundo cambia rápido, y en TI, cambia aún más rápido. Todos sabemos eso, lo que generalmente significa que necesitamos enfrentar nuevos desafíos y encontrar nuevas soluciones. Ejemplos de ese enfoque son las tendencias que hemos visto en los últimos años: Contenedores, DevSecOps, Microservicios, GitOps, Service Mesh…
Pero al mismo tiempo, sabemos que TI es un ciclo en términos de que los desafíos que enfrentamos hoy son diferentes evoluciones de desafíos que se han abordado en el pasado. El objetivo principal es evitar reinventar la rueda y evitar cometer los mismos errores que las personas antes que nosotros.
Por lo tanto, creo que vale la pena revisar los principios que las Arquitecturas Orientadas a Servicios (SOA) nos proporcionaron en las últimas décadas y ver cuáles son relevantes hoy en día.
Definición de Principios
Utilizaré los principios del libro de Thomas Erl SOA Principles of Service Design y las definiciones que podemos encontrar en el artículo de Wikipedia:
1.- Abstracción de Servicio
Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios para que la información publicada en un contrato de servicio se limite a lo que se requiere para utilizar efectivamente el servicio.
El objetivo principal detrás de estos principios es que un consumidor de servicios no debe ser consciente del componente particular. La principal ventaja de ese enfoque es que necesitamos cambiar el proveedor de servicios actual. Podemos hacerlo sin afectar a esos consumidores. Esto sigue siendo totalmente relevante hoy en día por diferentes razones:
Comunicación de servicio a servicio: Los Service Meshes y proyectos similares proporcionan capacidades de registro y descubrimiento de servicios basadas en los mismos principios para evitar conocer el pod que proporciona la funcionalidad.
Modo de protección SaaS habilitado: Algunos sistemas backend todavía están aquí para quedarse, incluso si tienen formas más modernas de configurarse como plataformas SaaS. Esa flexibilidad también proporciona una manera más fácil de alejarse o cambiar la aplicación SaaS que proporciona la funcionalidad. Pero toda esa flexibilidad no es real si tienes esa aplicación SaaS totalmente acoplada con el resto de los microservicios y la aplicación nativa de la nube en tu espacio.
2.- Autonomía del Servicio
Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para proporcionar servicios con mayor independencia de sus entornos de ejecución.
Todos conocemos la importancia del aislamiento de servicios que los patrones de desarrollo nativos de la nube proporcionan basados en las capacidades de los contenedores para proporcionar independencia entre entornos de ejecución.
Cada servicio debe tener su propio contexto de ejecución aislado tanto como sea posible del contexto de ejecución de los otros servicios para evitar cualquier interferencia entre ellos.
Por lo tanto, eso sigue siendo relevante hoy en día, pero alentado por los paradigmas actuales como la nueva forma normal de hacer las cosas debido a los beneficios mostrados.
3.- Ausencia de Estado del Servicio
Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para diseñar servicios escalables separándolos de sus datos de estado siempre que sea posible.
Los microservicios sin estado no mantienen su propio estado dentro de los servicios a través de las llamadas. Los servicios reciben una solicitud, la manejan y responden al cliente que solicita esa información. Si es necesario almacenar alguna información de estado, esto debe hacerse externamente a los microservicios utilizando un almacén de datos externo como una base de datos relacional, una base de datos NoSQL o cualquier otra forma de almacenar información fuera del microservicio.
4.- Composibilidad del Servicio
Diseño de servicios que pueden ser reutilizados en múltiples soluciones que están compuestas por servicios compuestos. La capacidad de recomponer el servicio es idealmente independiente del tamaño y la complejidad de la composición del servicio.
Todos sabemos que la reutilización no es uno de los principios detrás de los microservicios porque argumentan que la reutilización va en contra de la agilidad; cuando tenemos un servicio compartido entre muchas partes, no tenemos una manera fácil de evolucionarlo.
Pero esto se trata más de aprovechar los servicios existentes para crear nuevos que son el mismo enfoque que seguimos con el paradigma de Orquestación y Coreografía de API y la agilidad que proporciona aprovechar los existentes para crear servicios compuestos que cumplan con los objetivos de innovación del negocio.
Resumen
Los paradigmas de desarrollo de aplicaciones nativas de la nube son una evolución suave de los principios existentes. Debemos aprovechar los que aún son relevantes y proporcionar una visión actualizada de ellos y actualizar los que se necesiten.
Al final, en esta industria, lo que hacemos cada día es dar un nuevo paso en el largo viaje que es la historia de la industria, y aprovechamos todo el trabajo que se ha hecho en el pasado, y aprendemos de ello.
Transmisión de Eventos, API y Datos son los tres mosqueteros que cubren todos los aspectos de dominar la integración en la nube.
Foto de Simon Rae en Unsplash
La Integración de Aplicaciones Empresariales ha sido uno de los temas más desafiantes en el panorama de TI desde el principio de los tiempos. Tan pronto como el número de sistemas y aplicaciones en grandes corporaciones comenzó a crecer, esto se convirtió en un problema que debíamos abordar. La eficiencia de este proceso también definirá qué empresas tendrán éxito y cuáles fracasarán, ya que la cooperación entre aplicaciones se vuelve crítica para responder al ritmo que el negocio demanda.
Usualmente me gusta usar la «analogía de la carretera» para definir esto:
No importa si tienes los autos más rápidos, si no tienes carreteras adecuadas no llegarás a ninguna parte
Esta situación genera muchas inversiones por parte de las empresas. Además, se lanzaron muchos proveedores y productos para apoyar esa situación. Algunas soluciones están comenzando a emerger: EAI, ESB, SOA, Middleware, Plataformas de Integración Distribuida, solución Nativa de la Nube e iPaaS.
Cada uno de los enfoques proporciona una solución para los desafíos existentes. A medida que el resto de la industria evolucionaba, las soluciones cambiaron para adaptarse a la nueva realidad (contenedores, microservicios, DevOps, API-led, Event-Driven..)
Entonces, ¿cuál es la situación hoy? Hoy en día está extendida la idea errónea de que la integración es lo mismo que API y también que API es HTTP asincrónico basado en (REST, gRPC, GraphQL) API. Pero es mucho más que esto.
API-led es clave para la solución de integración, especialmente enfocándose en el enfoque filosófico detrás de ella. Cada componente que creamos hoy se crea con la colaboración en mente para trabajar con componentes existentes y futuros para beneficiar al negocio de una manera fácil y ágil. Esto trasciende completamente la discusión del protocolo.
API cubre todo tipo de soluciones desde API REST existentes hasta AsyncAPI para cubrir la API basada en eventos.
2.- Transmisión de Eventos
La comunicación asincrónica es necesaria porque los patrones y los requisitos cuando se habla de grandes empresas y diferentes aplicaciones hacen que esto sea esencial. Requisitos como el enfoque pub-sub para aumentar la independencia entre servicios y aplicaciones, control de flujo para gestionar la ejecución de flujos de alta demanda que pueden exceder la limitación para aplicaciones, especialmente cuando se habla de soluciones SaaS.
Entonces, puedes pensar que esta es una visión muy opinada, pero al mismo tiempo, esto es algo que la mayoría de los proveedores en este espacio han realizado basándose en sus acciones:
AWS lanza SNS/SQS, su primer sistema de mensajería, como su única solución.
Nov 2017 AWS lanza Amazon MQ, otro sistema de mensajería en cola para cubrir los escenarios que SQS no puede cubrir.
May 2019 AWS lanza Amazon MSK, un servicio gestionado para soluciones Kafka para proporcionar capacidades de distribución y procesamiento de datos en streaming.
Y esa situación es porque cuando nos alejamos de aplicaciones más pequeñas, cuando estamos migrando de un enfoque monolítico a una aplicación de microservicios, se necesitan más patrones y más requisitos, y aquí es donde las soluciones de integración han demostrado en el pasado que esto es crítico para las soluciones de integración.
3.- Integración de Datos
Usualmente, cuando hablamos de integración, hablamos de Integración de Aplicaciones Empresariales porque tenemos este sesgo del pasado. Incluso yo uso este término para cubrir este tema, EAI, porque usualmente nos referimos a estas soluciones. Pero desde los últimos años, estamos más enfocados en la distribución de datos en la empresa en lugar de cómo las aplicaciones se integran porque lo que realmente importa son los datos que están intercambiando y cómo podemos transformar estos datos en bruto en conocimientos que podamos usar para conocer mejor a nuestros clientes u optimizar nuestros procesos o descubrir nuevas oportunidades basadas en eso.
Hasta hace poco, esta parte se manejaba aparte de las soluciones de integración. Probablemente dependías de un ETL (Extract-Transform-Load) enfocado que ayuda a mover los datos de una base de datos a otra o a un tipo diferente de almacenamiento como un Data Warehouse para que tus Científicos de Datos puedan trabajar con ellos.
Pero nuevamente, la agilidad ha hecho que esto necesite cambiar, y todos los principios de integración en términos de proporcionar más agilidad al negocio también se aplican a cómo intercambiamos datos. Tratamos de evitar el movimiento técnico de los datos y tratamos de facilitar el acceso y la organización adecuada de estos datos. La Virtualización de Datos y la Transmisión de Datos son las capacidades centrales que abordan y manejan esos desafíos proporcionando una solución optimizada para cómo se distribuyen los datos.
Resumen
Mi principal expectativa con este artículo es hacerte consciente de que cuando piensas en integrar tu aplicación, esto es mucho más que la API REST que estás exponiendo, tal vez usando algún API Gateway, y las necesidades pueden ser muy diferentes. Cuanto más fuerte sea tu plataforma de integración, más fuerte será tu negocio.
Una de las grandes cosas sobre los desarrollos basados en contenedores es definir espacios de aislamiento donde tienes recursos garantizados como CPU y memoria. Esto también se extiende en entornos basados en Kubernetes a nivel de namespace, por lo que puedes tener diferentes entornos virtuales que no pueden exceder el uso de recursos a un nivel especificado.
Una cuota de recursos, definida por un objeto ResourceQuota, proporciona restricciones que limitan el consumo agregado de recursos por namespace. Puede limitar la cantidad de objetos que se pueden crear en un namespace por tipo, así como la cantidad total de recursos de cómputo que pueden ser consumidos por recursos en ese namespace.
Tienes varias opciones para definir el uso de estas Cuotas de Recursos, pero nos centraremos en este artículo en las principales de la siguiente manera:
limits.cpu: En todos los pods en un estado no terminal, la suma de los límites de CPU no puede exceder este valor.
limits.memory: En todos los pods en un estado no terminal, la suma de los límites de memoria no puede exceder este valor.
requests.cpu: En todos los pods en un estado no terminal, la suma de las solicitudes de CPU no puede exceder este valor.
requests.memory: En todos los pods en un estado no terminal, la suma de las solicitudes de memoria no puede exceder este valor.
Así que puedes pensar que esta es una gran opción para definir una cuota de limit.cpu y limit.memory, para asegurarte de que no excederás esa cantidad de uso por ningún medio. Pero necesitas tener cuidado con lo que esto significa, y para ilustrarlo usaré un ejemplo.
Tengo una sola carga de trabajo con un solo pod con la siguiente limitación de recursos:
requests.cpu: 500m
limits.cpu: 1
requests.memory: 500Mi
limits.memory: 1 GB
Tu aplicación es una aplicación basada en Java que expone un Servicio REST y ha configurado una regla de Escalador Horizontal de Pods para escalar cuando la cantidad de CPU excede su 50%.
Entonces, comenzamos en la situación primaria: con una sola instancia que requiere ejecutar 150 m de vCPU y 200 RAM, un poco menos del 50% para evitar el escalador. Pero tenemos una Cuota de Recursos sobre los límites del pod (1 vCPU y 1 GB) por lo que hemos bloqueado eso. Tenemos más solicitudes y necesitamos escalar a dos instancias. Para simplificar los cálculos, asumiremos que usaremos la misma cantidad de recursos para cada una de las instancias, y continuaremos de esa manera hasta llegar a 8 instancias. Así que veamos cómo cambian los límites definidos (el que limitará la cantidad de objetos que puedo crear en mi namespace) y la cantidad real de recursos que estoy usando:
Entonces, para una cantidad de recursos usados de 1.6 vCPU he bloqueado 8 vCPU, y en caso de que ese fuera mi Límite de Recursos, no puedo crear más instancias, aunque tengo 6.4 vCPU no usados que he permitido desplegar debido a este tipo de limitación no puedo hacerlo.
Sí, puedo asegurar el principio de que nunca usaré más de 8 vCPU, pero me he bloqueado muy temprano en esa tendencia afectando el comportamiento y la escalabilidad de mis cargas de trabajo.
Debido a eso, necesitas ser muy cuidadoso cuando estás definiendo este tipo de límites y asegurarte de lo que estás tratando de lograr porque al resolver un problema puedes estar generando otro.
Espero que esto pueda ayudarte a prevenir que este problema ocurra en tu trabajo diario o al menos tenerlo en cuenta cuando te enfrentes a escenarios similares.
