Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Plataformas

Adoptar ?

Probar ?

  • Debido a que el ecosistema Azure DevOps sigue creciendo, nuestros equipos lo utilizan con éxito cada vez más. Estos servicios contienen un conjunto de servicios administrados, que incluyen repositorios Git alojados, pipelines de compilación y despliegue, herramientas de pruebas automatizadas, utilidades de administración de tareas pendientes y repositorio de artefactos. Hemos visto a nuestros equipos adquirir experiencia en esta plataforma con muy buenos resultados, lo que significa que Azure DevOps está madurando. Particularmente nos gusta su flexibilidad; permitiéndonos usar los servicios que uno desea incluso si estos son de diferentes proveedores. Por ejemplo, es posible usar un repositorio Git externo al mismo tiempo que los servicios de pipelines de Azure DevOps. Nuestros equipos están especialmente entusiasmados con Azure DevOps Pipelines. A medida que el ecosistema madura, vemos un aumento en la incorporación de equipos que ya se encuentran utilizando Azure, ya que se integra fácilmente con el resto del mundo de Microsoft.

  • Las plantillas de Azure Pipelines te permiten eliminar la duplicidad cuando defines tus Azure Pipelines, a través de dos mecanismos. Con “incluir” plantillas, puedes hacer referencia a una plantilla, de tal forma que se expandirá en línea como una macro parametrizado de C++, permitiendo así una forma sencilla de reutilizar una configuración común en todas las etapas, trabajos y pasos. Con “extender” plantilla, puedes definir una capa exterior con la configuración común de la pipeline y con la aprobación requerida de la plantilla, puedes hacer que la compilación falle si la pipeline no extiende de ciertas plantillas, previniendo ataques maliciosos contra la propia configuración de la pipeline. Junto con [CircleCI]((/es/radar/platforms/circleci), Orbs y el todavía más reciente GitHub Actions Reusable Workflows, las plantillas de Azure Pipeline son parte de la tendencia sobre la creación de modularidad en el diseño de las pipelines a lo largo de múltiples plataformas y varios de nuestros equipos han estado contentos utilizándolo.

  • Muchos de nuestros equipos eligen CircleCI para sus necesidades de integración continua y aprecian su capacidad para ejecutar pipelines complejas de manera eficiente. Los desarrolladores de CircleCI continúan agregando nuevas funcionalidades con CircleCI, ahora en la versión 3.0. Orbs y executors fueron llamados por nuestros equipos como particularmente útiles. Los Orbs son fragmentos de código reutilizables que automatizan procesos repetidos, aceleran la configuración de proyectos y facilitan la integración con herramientas de terceros. La amplia variedad de tipos de ejecutores brinda flexibilidad para configurar trabajos en máquinas virtuales en Docker, Linux, macOS o Windows.

  • Cuando cubrimos Couchbase originalmente en 2013, se consideraba principalmente un caché persistente que evolucionó de una fusión entre Membase y CouchDB. Desde ese entonces, ha mejorado constantemente y un ecosistema de herramientas relacionadas y oferta comercial se ha desarrollado en torno a él. Entre las novedades de la suite del producto está Couchbase Mobile y el Couchbase Sync Gateway. Estas funcionalidades trabajan juntas para mantener actualizados los datos persistentes en dispositivos periféricos, incluso cuando el dispositivo está fuera de red por periodos extendidos de tiempo debido a conectividad intermitente. A medida que estos dispositivos proliferan, vemos una necesidad más grande de persistencia embebida que continúa funcionando esté el dispositivo conectado o no. Recientemente, uno de nuestros equipos valoró Couchbase por su capacidad de sincronización offline, y descubrió que esta capacidad existente les ahorró considerable esfuerzo que de otra manera lo habrían tenido que invertir en tiempo propio.

  • Desde hace varios años, el kernel de Linux incluye el filtro de paquetes Berkeley extendido (eBPF), una máquina virtual que ofrece la posibilidad de adjuntar filtros a determinados sockets. Pero eBPF va mucho más allá del filtrado de paquetes y permite activar scripts personalizados en varios puntos del kernel con muy poca sobrecarga. Aunque esta tecnología no es nueva, está cobrando importancia con el creciente uso de microservicios desplegados como contenedores orquestados. Los Kubernetes y la tecnología de malla de servicios (Services Mesh) como Istio se utilizan habitualmente, y emplean sidecars para implementar la funcionalidad de control. Con las nuevas herramientas, - Bumblebee en particular, hace que la construcción, ejecución y distribución de programas eBPF sea mucho más fácil - eBPF puede ser visto como una alternativa al sidecar tradicional. Un mantenedor de Cilium, una herramienta en este espacio, ha llegado a proclamar la desaparición del sidecar. Un enfoque basado en eBPF reduce parte de la sobrecarga de rendimiento y operación que conllevan los sidecars, pero no da soporte a funciones comunes como la terminación SSL.

  • GitHub Actions ha crecido considerablemente el año pasado. Ha demostrado que puede asumir flujos de trabajo más complejos y llamar a otras acciones en acciones compuestas, entre otras cosas. Sin embargo, todavía tiene algunas deficiencias, como su incapacidad para volver a activar un solo trabajo de un flujo de trabajo. Aunque el ecosistema en el GitHub Marketplace tiene sus ventajas obvias, al dar acceso a las Acciones de GitHub de terceros a tu pipeline de construcción se corre el riesgo de compartir secretos de forma insegura (recomendamos seguir los consejos de GitHub sobre security hardening). Sin embargo, la comodidad de crear tu flujo de trabajo de compilación directamente en GitHub junto a tu código fuente, combinada con la capacidad de ejecutar las Acciones de GitHub localmente utilizando herramientas de código abierto como act es una opción convincente que ha facilitado la configuración y la incorporación de nuestros equipos.

  • Si estás usando GitLab para administrar la entrega de software, también deberías darle un vistazo a GitLab CI/CD para tus necesidades de integración y entrega continua. Hemos comprobado que es especialmente útil cuando se utiliza con GitLab con ejecutores en servidores OnPremise y auto-hospedados, ya que esta combinación evita los dolores de cabeza de autorización que suelen producirse al utilizar una solución basada en la nube. Los ejecutores auto-hospedados pueden configurarse completamente para tus propósitos con el sistema operativo y las dependencias correctas instaladas y, como resultado, los pipelines pueden ejecutarse mucho más rápido que cuando se utiliza un ejecutor hospedado en la nube que necesita configurarse cada vez.

    Además de las operaciones básicas de compilación, pruebas y despliegue de pipelines, este producto de GitLab soporta el uso de Services, Auto Devops y ChatOps, entre otras características avanzadas. Los Services son útiles al ejecutar servicios Docker como Postgres o Testcontainer vinculados a un job para integración y pruebas de extremo a extremo. Auto Devops crea pipelines que no requieren configuraciones, lo que es muy útil para los equipos que son nuevos en la entrega contínua o para las organizaciones con muchos repositorios que de otro modo tendrían que crear muchos pipelines manualmente.

  • Desde la última vez que hablamos sobre Google BigQuery ML, se han agregado modelos más sofisticados, como Redes Neuronales Profundas y de Tablas con Autoaprendizaje, al conectar BigQuery ML con TensorFlow y Vertex AI como backend. BigQuery también ha introducido soporte para previsión de series temporales. Una de nuestra preocupaciones anteriormente era explicabilidad. A principios de este año fue anunciado BigQuery Explainable AI, dando un paso para abordar esto. También podemos exportar modelos de BigQuery ML a Cloud Storage como Tensorflow SavedModel y usarlos para predicción online. Aún quedan cosas pendientes como la dificultad de “entrega continua para aprendizaje automático” pero con su facilidad de uso, BigQuery ML sigue siendo una opción atractiva, sobre todo si la información ya está en BigQuery.

  • Google Cloud Dataflow es un servicio de procesamiento de datos basado en la nube para aplicaciones de transmisión de datos en tiempo real y por lotes. Nuestros equipos usan Dataflow para crear flujos de procesamiento para integrar, preparar y analizar grandes conjuntos de datos, con el modelo de programación unificado de Apache Beam para facilitar su administración. Presentamos Dataflow por primera vez en 2018, y su estabilidad, rendimiento y conjunto completo de funciones nos dan confianza para moverlo a la sección Trial en esta edición del Radar.

  • Hemos visto un creciente interés en GitHub Actions desde que se hizo blip por primera vez hace dos Radars. Con el lanzamiento de los flujos de trabajo reutilizables, GitHub ha continuado evolucionando el producto de forma que aborda algunas de sus limitaciones iniciales. Los flujos de trabajo reutilizables en GitHub Actions aportan modularidad al diseño de pipeline, permitiendo la reutilización parametrizada incluso a través de repositorios (siempre y cuando el repositorio de flujo de trabajo sea público). Soportan el paso explícito de valores confidenciales en forma de secretos, y el resultado es devuelto al proceso que lo ha llamado. Con unas cuantas lineas de YAML, Github Actions ahora aporta el tipo de flexibilidad que se ve en CircleCI Orbs o Azure Pipeline Templates, pero sin tener que dejar la plataforma GitHub.

  • Kubernetes soporta de manera nativa un objeto valor-clave (key-value en inglés) como secretos (secrets en inglés). Sin embargo, por defecto los secret en Kubernetes no son realmente secretos. Estos son manipulados separadamente de otros datos key-value con precauciones o con controles de acceso que pueda ser aplicados de manera separada. Existe soporte para encriptar secrets antes de que sean guardados en etcd, pero estos empiezan como campos de texto plano en archivos de configuración.

    Secretos sellados (Sealed Secrets en inglés) es una combinación entre el operador y la utilidad de la línea de comando que usa claves asimétricas para encriptar secrets de manera que solo pueden ser descifrados por un controlador del clúster. Este proceso asegura que los secrets no serán comprometidos mientras se encuentren en los archivos de configuración que definen el deployment en Kubernetes. Una vez encriptados, estos archivos pueden ser compartidos o almacenados de manera segura junto a otros artefactos del deployment.

  • VerneMQ es un broker MQTT de código abierto, de alto rendimiento y distribuído. En el pasado hemos analizado otros brokers MQTT como Mosquitto y EMQ. Al igual que EMQ y RabbitMQ, VerneMQ está también basado en Erlang/OTP, lo que lo convierte en altamente escalable. Escala tanto horizontalmente como verticalmente sobre hardware estándar para soportar un gran número de productores y consumidores, manteniendo una baja latencia y tolerancia a fallos. En nuestros bancos de pruebas internos, hemos sido capaces de alcanzar algunos millones de conexiones concurrentes en un único clúster. Aunque no es nuevo, llevamos utilizándolo ya en producción durante algún tiempo y nos ha funcionado bien.

Evaluar ?

  • actions-runner-controller es un controlador que opera runners auto hospedados para GitHub Actions en tu clúster de Kubernetes. Con esta herramienta creas un recurso runner en Kubernetes, que ejecutará y operará el runner auto hospedado. Los runners auto hospedados son de mucha ayuda en escenarios dónde el trabajo o job que tu GitHub Actions ejecuta necesita acceder a recursos a los que los runners en la nube de GitHub no pueden acceder o tienen requerimientos específicos para un sistema operativo y entorno que difieren de los que provee GitHub. En esos casos dónde tienes un clúster de Kubernetes, puedes ejecutar tus runners auto hospedados como un pod de Kubernetes, con la capacidad de escalar conectándose con los eventos de los webhooks de GitHub.

  • Apache Iceberg Es un formato de tabla abierta para conjuntos de datos analíticos muy grandes. Iceberg admite operaciones de datos analíticos modernos, como la inserción, actualización y eliminación a nivel de registro, time-travel queries, transacciones ACID, partición oculta y evolución completa del esquema. Soporta múltiples formatos de almacenamiento de archivos subyacentes como Apache Parquet, Apache ORC y Apache Avro. Muchos motores de procesamiento de datos soportan Apache Iceberg, incluyendo motores SQL como Dremio y Trino, así como motores de streaming (estructurado) como Apache Spark y Apache Flink.

    Apache Iceberg está en la misma categoría que Delta Lake y Apache Hudi. Todos ellos soportan más o menos características similares, pero cada uno difiere en las implementaciones subyacentes y en las listas de características detalladas. Iceberg es un formato independiente y no es nativo de ningún motor de procesamiento específico, por lo que es soportado por un número creciente de plataformas, incluyendo AWS Athena y Snowflake. Por la misma razón, Apache Iceberg, a diferencia de los formatos nativos como Delta Lake, puede no beneficiarse de las optimizaciones cuando se utiliza con Spark.

  • Blueboat es una plataforma multiplataforma para aplicaciones web sin servidor. Aprovecha el popular motor JavaScript V8 e implementa bibliotecas de aplicaciones web de uso común de forma nativa en Rust para seguridad y rendimiento. Se puede pensar en Blueboat como una alternativa a CloudFlare Workers o Deno Deploy pero con una distinción importante — debe operar y administrar la infraestructura subyacente. Dicho esto, le recomendamos que evalúe cuidadosamente Blueboat para sus necesidades locales sin servidor.

  • Cuando los Cloudflare Workers fueron liberados, los destacamos como una temprana función como servicio (FaaS) para cómputo de borde con una implementación interesante. La liberación de las Cloudflare Pages del pasado Abril no se sintió como digna de mención, debido a que Pages es solo una en una clase de muchas soluciones respaldadas por Git y de alojamiento de sitios. Tenía vistas previas continuas, una función útil que no se encuentra en la mayoría de las alternativas. Ahora, sin embargo, Cloudfare tiene unos Workers y Pages integrados más enfocados, creando una solución totalmente integrada Jamstack corriendo sobre el CDN. La inclusión de un almacenamiento de clave-valor y una coordinación primitiva fuerte y consistente mejoran aún más el atractivo de la nueva versión de Cloudflare Pages.

  • Colima se está convirtiendo en una popular alternativa abierta para Docker de Escritorio. Provee el tiempo de ejecución del contenedor Docker en una máquina virtual (VM) Lima, configura la interfaz de línea de comando (CLI) en macOS y se encarga del port-forwarding y montaje de volúmenes. Colima utiliza containerd como tiempo de ejecución, que es el más común en la mayoría de servicios Kubernetes (lo cual mejora la relación dev-prod). Con Colima se puede utilizar y probar fácilmente las últimas características de containerd, tal como lazy loading para imágenes en contenedores. Por su buen desempeño, vemos a Colima como una alternativa de software abierto con un gran potencial frente a Docker para Escritorio.

  • En el ambiente cada vez más concurrido del mercado corporativo de catálogos de data, nuestros equipos han disfrutado al trabajar con Collibra. Les ha gustado la flexibilidad en el despliegue sea de un SaaS o de una instancia self-hosted, la gran amplitud de funcionalidad incluida out of the box, tales como gobernanza de datos, linaje, calidad y observabilidad. Los usuarios también tienen la opción de utilizar un pequeño subconjunto de capacidades requeridas desde una aproximación más descentralizada como por ejemplo un data mesh. El verdadero punto extra se lo lleva su servicio al cliente muchas veces pasado por alto, quienes se han mostrado colaborativos y de gran soporte. Por supuesto, existe tensión entre catálogos de data simples y plataformas corporativas con mayores funcionalidades, pero hasta ahora los equipos se encuentran muy contentos en cómo Collibra ha soportado sus necesidades.

  • CycloneDX es un estándar para describir una Lista de materiales de software (SBOM) legible por una máquina. A medida que las estructuras del software y la computación crecen en complejidad, el software se vuelve más difícil de definir. Originario de OWASP, CycloneDX mejora el antiguo estándar SPDX con una definición más amplia que se extiende más allá de las dependencias de la máquina local para incluir dependencias de servicio en tiempo de ejecución. También encontrarás implementaciones en varios lenguajes, un ecosistema de soporte de integraciones y una herramienta de línea de comando CLI que te permite analizar y cambiar SBOMs con la firma y verificación correspondientes.

  • Embeddinghub es una base de datos vectorial para embeddings de machine learning, bastante similar a Milvus. Sin embargo, dado que tiene soporte disponible para operaciones de vecino más cercano (NN) aproximado, particionamiento, control de versiones y control de accesos, recomendamos evaluar Embeddinghub para sus casos de embedding vectorial.

  • Temporal es una plataforma para desarrollar flujos de trabajo de larga duración, particularmente para arquitecturas de microservicios. Es una variante del anterior proyecto de OSS Cadence de Uber, tiene un modelo de aprovisionamiento de eventos para flujos de trabajo de larga duración para que puedan sobrepasar caídas de procesos o infraestructura. A pesar de que no recomendamos el uso de transacciones distribuidas en arquitectura de microservicios, si realmente necesitas implementarlas o larga duración Sagas, puedes considerar darle un vistazo a Temporal.

Resistir ?

 
  • platforms quadrant with radar rings Adoptar Probar Evaluar Resistir Adoptar Probar Evaluar Resistir
  • Nuevo
  • Modificado
  • Ningún cambio

¿No encontraste algo que esperabas ver?

 

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que busca en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

¿No encontraste algo que esperabas ver?

 

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que busca en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

Radar

Descargar Radar Tecnológico Volumen 26

 

English | Español | Português | 中文

Radar

Mantente informada sobre tecnología

 

Suscríbete ahora

Visita nuestro archivo para leer los volúmenes anteriores