Master

Plataformas

Adoptar?

    Probar?

    • Muchos de nuestros equipos que ya están en AWS han encontrado que el kit de desarrollo en la nube de AWS (CDK de AWS) es una elección razonable predeterminada para permitir el aprovisionamiento de la infraestructura. En concreto, a los equipos les gusta el uso de lenguajes de programación de primera clase en lugar de archivos de configuración, lo que les permite utilizar herramientas, habilidades y enfoques de pruebas ya existentes. Al igual que otras herramientas similares, se debe tener cuidado para garantizar que los despliegues continúan siendo fáciles de entender y mantener. El CDK es actualmente compatible con TypeScript, JavaScript, Python, Java, C# y .NET. Se están añadiendo nuevos proveedores al núcleo del CDK. Hemos utilizado con éxito tanto el CDK de AWS como el kit de desarrollo en la nube para Terraform de HashiCorp para generar configuraciones de Terraform y permitir el aprovisionamiento exitoso en esta plataforma.

      Historia
    • Seguimos viendo interés en Backstage y crecimiento en su uso, además de la adopción de portales para desarrolladoras, dada por la necesidad de las organizaciones de brindar soporte y optimizar sus ambientes de desarrollo. A medida que crece el número de herramientas y tecnologías, también aumenta la importancia de lograr alguna forma de estandarización para conseguir algo de consistencia, de forma que los equipos de desarrollo puedan concentrarse en la innovación y el desarrollo de los productos en lugar de reinventar la rueda. Backstage es una plataforma de código abierto para levantar portales para desarrolladoras creada por Spotify; se basa en plantillas de software, y permite unificar las herramientas de infraestructura con documentación técnica consistente y centralizada. Su arquitectura para complementos permite extenderla y adaptarla a las necesidades del ecosistema de infraestructura de una organización.

      Historia
    • Delta Lake es una capa de almacenamiento de código abierto implementada por Databricks, que intenta llevar transacciones ACID al procesamiento de big data. En proyectos de lago de datos o de malla de datos con soporte de Databricks, nuestros equipos siguen prefiriendo usar el almacenamiento Delta Lake en lugar del uso directo de mecanismos de almacenamiento de archivos como S3 o ADLS. Por supuesto que esto se limita a proyectos que usan plataformas de almacenamiento que soportan Delta Lake cuando usan formatos de archivo Parquet. Delta Lake facilita casos de uso de lectura/escritura de datos concurrentes donde se requiere transaccionalidad a nivel de archivo. Encontramos de gran ayuda a la integración transparente de Delta Lake con las APIs de procesamiento en lotes o en micro lotes de Apache Spark, y particularmente, a funcionalidades como los viajes en el tiempo (acceder a los datos de un momento determinado o en la reversión de un commit) así como el soporte de evolución de esquema al momento de escritura, aunque hay algunas limitaciones en estas características.

      Historia
    • Materialize es una base de datos en streaming que permite realizar cálculos incrementales sin necesidad de pipelines de datos complicados. Se debe describir los cálculos mediante vistas SQL estándar y conectar Materialize al stream de datos. El motor de flujo de datos diferencial subyacente realiza cálculos incrementales para proporcionar resultados consistentes y correctos con mínima latencia. A diferencia de las bases de datos tradicionales, no hay restricciones para definir estas vistas y los cálculos se ejecutan en tiempo real. Nosotros hemos utilizado Materialize junto con Spring Cloud Stream y Kafka en un sistema de eventos distribuidos para hacer consultas sobre streams de eventos, y nos gustó esta configuración.

      Historia
    • Desde la última vez que presentamos a Snowflake en el Radar, hemos ganado algo más de experiencia con él, así como con las mallas de datos como alternativa a los almacenes de datos (data warehouses) y lagos de datos. Snowflake continua impresionándonos con funcionalidades como viajes en el tiempo, clonación de copia cero, intercambio de datos y con su tienda (marketplace). No hemos encontrado nada que no nos guste, lo que ha llevado a los equipos a preferirlo por sobre otras alternativas. Redshift se está enfocando en la separación del almacenamiento y del procesamiento, que ha sido un punto fuerte de Snowflake, pero, incluso con Redshift Spectrum, no es tan fácil y ni flexible de usar, en parte por sus lazos previos con Postgres (por cierto, todavía nos gusta Postgres). Las consultas federadas pueden ser una razón para usar Redshift, pero, cuando se trata de operaciones, Snowflake es mucho más fácil de usar. BigQuery, que es otra alternativa, es muy fácil de operar pero Snowflake lo supera en ambientes de múltiples nubes (multi-cloud). También podemos decir que hemos usado Snowflake con éxito en GCP, AWS y Azure.

      Historia
    • Las fuentes variables son una forma de evitar la necesidad de buscar e incluir archivos de fuentes distintos para diferentes pesos y estilos. Todo está en un solo archivo y puedes utilizar propiedades para seleccionar el tipo de estilo y el peso que se necesita. Si bien no es nuevo, aún vemos sitios y proyectos que se podrían beneficiar de este enfoque tan simple. Si tienes páginas que incluyen diferentes variaciones de la misma fuente, te sugerimos que pruebes fuentes variables.

      Historia

    Evaluar?

    • Apache Pinot es un almacén de datos distribuidos OLAP creado para ofrecer analíticas en tiempo real y con baja latencia. Puede alimentarse de fuentes de datos por lotes (como Hadoop HDFS, Amazon S3, Azure ADLS o Google Cloud Storage), así como de orígenes de datos en streams (como Apache Kafka). Si se necesita ofrecer al usuario análiticas de baja latencia, las soluciones de SQL-en-Hadoop no ofrecen la latencia que se necesita. Los motores OLAP modernos, como Apache Pinot (o Apache Druid y Clickhouse, entre otros), pueden lograr una latencia mucho menor y son particularmente adecuados en contextos donde se necesitan analíticas rápidas en tiempo real y con datos inmutables, como las agregaciones. Originalmente construido por LinkedIn, Apache Pinot ingresó a la incubadora de Apache a finales de 2018 y desde entonces ha obtenido una arquitectura de complementos y compatibilidad con SQL, entre otras capacidades clave. Apache Pinot puede ser bastante complejo de operar y tiene muchas partes móviles, pero recomendamos evaluarlo si los volúmenes de datos son lo suficientemente grandes y se necesita una capacidad de consulta de baja latencia.

      Historia
    • Bit.dev es una plataforma colaborativa alojada en la nube para componentes de interfaz de usuario extraídos, modularizados y reutilizados con Bit. Los componentes web han existido ya por un tiempo, pero nunca ha sido sencillo construir aplicaciones frontend modernas ensamblando componentes independientes y pequeños, extraídos de otros proyectos. Bit fue diseñada para hacer exactamente eso: extraer un componente de una biblioteca o proyecto existente. Tu puedes construir tu servicio propio para la colaboración de componentes o usar Bit.dev

      Historia
    • Desde que mencionamos al descubrimiento de datos por primera vez en el Radar, LinkedIn ha evolucionado WhereHows en DataHub, la plataforma de nueva generación que aborda la capacidad de descubrimiento de datos a través de un sistema extensible de metadatos. En lugar de rastrear y extraer metadatos, DataHub adopta un modelo basado en push en el que los componentes individuales del ecosistema de datos publican metadatos mediante un API o un stream hacia la plataforma central. Este modelo de integración traslada la propiedad de la entidad central a los equipos individuales, haciéndolos responsables de sus metadatos. A medida que más y más empresas intentan orientarse a los datos, es fundamental tener un sistema que ayude con el descubrimiento y la comprensión de la calidad y el linaje de los datos, por lo que recomendamos evaluar a DataHub en esa capacidad.

      Historia
    • Feature Store es una plataforma de datos específica para aprendizaje automático que resuelve algunos de los principales retos que encontramos hoy en la ingeniería de características con tres capacidades fundamentales: (1) usa pipelines de datos gestionados para eliminar conflictos con los pipelines cuando llegan nuevos datos; (2) cataloga y almacena datos de las características para fomentar su visibilidad y colaboración entre modelos; y (3) consistentemente provee datos de características durante el entrenamiento y la interferencia.

      Desde que Uber reveló su plataforma Michelangelo, muchas organizaciones y startups han construido sus propias versiones de almacenes de características, como Hopsworks, Feast y Tecton. Vemos potencial en Feature Store y recomendamos realizar un análisis cuidadoso.

      Historia
    • JuiceFS es un sistema de archivos POSIX distribuido, de codigo abierto, basado en Redis y, al mismo tiempo, un almacén de objetos. A la hora de crear nuevas aplicaciones, normalmente recomendamos interactuar directamente con el almacén de objetos, sin utilizar una capa de abstracción adicional. Sin embargo, JuiceFS podría ser una opción si se necesita migrar a la nube a aplicaciones legadas que dependen de sistemas de archivos POSIX tradicionales.

      Historia
    • A medida que más empresas recurren a los eventos como medio para compartir datos entre microservicios, recopilar analíticas o alimentar lagos de datos, Apache Kafka se ha convertido en la plataforma favorita para sostener una arquitectura basada en eventos. Aunque Kafka fue un concepto revolucionario en mensajería persistente y escalable, se requieren muchas partes móviles para que funcione, como ZooKeeper, brokers, particiones y réplicas. Si bien estos pueden ser particularmente difíciles de implementar y operar, ofrecen una gran flexibilidad y potencia cuando es necesario, especialmente a escala empresarial industrial. Debido a la alta barrera de entrada que presenta el ecosistema completo de Kafka, nos complace la reciente explosión de plataformas que ofrecen el API de Kafka sin Kafka. Entradas recientes como Kafka en Pulsar y Redpanda ofrecen arquitecturas alternativas y Azure Event Hubs para Kafka proporciona cierta compatibilidad con las APIs de producción y consumo de Kafka. Algunas características de Kafka, como la biblioteca cliente de streams, no son compatibles con estos brokers alternativos, por lo que todavía hay razones para elegir Kafka en su lugar. Sin embargo, queda por ver si las desarrolladoras realmente adoptan esta estrategia o si es simplemente un intento de los competidores para alejar a los usuarios de Kafka. En última instancia, quizás el impacto más duradero de Kafka podría ser su conveniente protocolo y el API que se brinda a los clientes.

      Historia
    • NATS es un sistema de cola de mensajería rápido y seguro con una gama inusualmente amplia de características y potenciales sistemas objeto de despliegue. En principio, pasaremos por alto el que uno se pregunte por qué el mundo necesita otro sistema de colas de mensajería. Estas han estado presentes en varias formas casi todo el tiempo desde que las empresas han usado computadoras y han experimentado años de refinamiento y optimización para diversas tareas. Sin embargo, NATS tiene características interesantes y es único por su capacidad para escalar desde controladores integrados hasta super clusters globales alojados en la nube. Nos intriga particularmente la intención de NATS de soportar flujos continuos de datos desde dispositivos móviles e IoT, y a través de una red de sistemas interconectados. Sin embargo, es necesario abordar algunos problemas delicados, uno de los cuales es garantizar que los consumidores solo vean los mensajes y tópicos a los que se les permite acceder, especialmente cuando la red atraviesa los límites de la organización. NATS 2.0 introdujo un esquema de seguridad y control de acceso que soporta clusters para múltiples propietarios (multitenant) donde las cuentas restringen el acceso de un usuario a las colas y a los tópicos. Escrito en Go, NATS ha sido adoptado principalmente por la comunidad de este lenguaje. Aunque existen clientes para casi todos los lenguajes de programación más comunes, el cliente Go es el más popular. Sin embargo, algunas de nuestras desarrolladoras han descubierto que todas las bibliotecas cliente tienden a reflejar sus orígenes en Go. El aumento del ancho de banda y la potencia de procesamiento de los dispositivos inalámbricos pequeños significa que el volumen de datos que las empresas deben consumir en tiempo real solo aumentará. Se puede evaluar a NATS como una posible plataforma para transmitir esos datos dentro y entre las empresas.

      Historia
    • Opstrace es una plataforma de código abierto de observabilidad, destinada para ser desplegada en la propia red del usuario. Si no usamos soluciones comerciales como Datadog (por temas de costo o de almacenamiento de datos, por ejemplo), la solución que nos queda sería construir nuestra propia plataforma compuesta de herramientas de código abierto. Esto puede suponer mucho esfuerzo, así que Opstrace está diseñado para cubrir esta brecha. Utiliza APIs e interfaces de código abierto, como Prometheus y Grafana, y agrega funcionalidades adicionales como TLS y autenticación. En el corazón de Opstrace se encuentra un clúster de Cortex para proporcionar el API escalable de Prometheus, así como un cluster de Loki para los logs. Como es una herramienta relativamente nueva, aún carece de ciertas funcionalidades si se compara con soluciones como Datadog o SignalFX. No obstante, es una opción prometedora que contribuye a este espacio y vale la pena tomarla en cuenta.

      Historia
    • Hemos visto un creciente pero lento interés en Pulumi. Esta utilidad llena una brecha en el mundo de la infraestructura como código, donde Terraform está muy afianzado. Si bien Terraform ha sido ampliamente usado y probado, su naturaleza declarativa presenta capacidades inadecuadas de abstracción y carece de la capacidad de ser probado. Terraform es adecuado cuando la infraestructura es completamente estática, pero para la definición de infraestructuras dinámicas se necesita un lenguaje de programación real. Pulumi se distingue por permitir que las configuraciones se escriban en TypeScript o JavaScript, Python y Go, sin ser necesario un lenguaje de marcado o de plantillas. Pulumi está altamente enfocado en arquitecturas nativas a la nube, incluyendo contenedores, funciones serverless y servicios de datos, proporcionando buen soporte para Kubernetes. Recientemente, el CDK de AWS se ha posicionado como contendor, pero Pulumi se mantiene como la única herramienta neutral del área, en lo que respecta a los proveedores. Anticipamos una amplia adopción de Pulumi en el futuro y esperamos la aparición de herramientas viables y de ecosistemas de conocimiento que le den soporte.

      Historia
    • Redpanda es una plataforma de streaming de datos que proporciona un API compatible con Kafka, lo que permite aprovechar el ecosistema de Kafka sin tener que lidiar con las complejidades de su instalación. Por ejemplo, operar Redpanda es sencillo porque se distribuye como un archivo ejecutable solo y no requiere de una dependencia externa como ZooKeeper. En su lugar, implementa el protocolo Raft y realiza pruebas integrales para validar si ha sido implementado correctamente. Una de las capacidades de RedPanda (solo para clientes empresariales) son las transformaciones WASM en línea, utilizando su motor WebAssembly (WASM) integrado. Esto permite a las desarrolladoras crear transformadores de eventos en su lenguaje preferido y compilarlos a WASM. También ofrece latencias de cola muy reducidas y mayor rendimiento debido a una serie de optimizaciones. Redpanda es una alternativa fascinante a Kafka y vale la pena probarla.

      Historia

    Resistir?

    • Ya hemos visto antes que los proveedores de la nube publican cada vez más y más servicios al mercado. También hemos documentado nuestras preocupaciones de que en ocasiones los servicios liberados al público no están del todo listos. Lamentablemente, en base a nuestra experiencia, Azure Machine Learning entra en esta última categoría. Como uno de los participantes más recientes en el campo de las plataformas delimitadas de poco código, Azure ML promete más facilidades para los científicos de datos. Sin embargo no cumple su promesa y, de hecho, nuestras científicas de datos sienten que sigue siendo más sencillo trabajar en Python. A pesar de algunos esfuerzos significativos, tuvimos dificultades para hacer escalar la solución y la falta de documentación adecuada demostró ser otro problema. Por estas razones la movemos al anillo "Resistir".

      Historia
    • Los productos respaldados por compañías o comunidades están en constante evolución, al menos aquellos que ganan tracción en la industria. De vez en cuando las organizaciones tienden a construir marcos de trabajo o abstracciones encima de productos externos existentes para cubrir necesidades muy específicas, pensando que sus adaptaciones traerán más beneficios que los productos por sí solos. Vemos a organizaciones intentando crear productos hechos en casa para infraestructura como código sobre tecnologías ya establecidas. Estas organizaciones subestiman el esfuerzo necesario para seguir evolucionando dichas soluciones al ritmo de sus necesidades, y tras un breve periodo de tiempo, se dan cuenta de que la versión original está en mucho mejor condición que la suya propia; incluso hay casos donde la abstracción encima del producto externo limita las funcionalidades originales. Aunque hemos visto casos de éxito de organizaciones construyendo soluciones hechas en casa, queremos advertir en contra de esta estrategia, ya que el esfuerzo que se requiere no es despreciable, y es necesario tener una visión de producto a largo plazo para conseguir las metas deseadas.

      Historia
    ¿No encuentras aquello que querías ver?

    Cada edición del Radar incluye blips que contienen la información encontrada durante los últimos seis meses. Es posible que ya hayamos incluido el tema que estás buscando en Radares anteriores. Hay veces que omitimos algunos temas debido a que hay demasiado de que hablar. O también, puede faltar algo debido a que en el Radar buscamos reflejar nuestra experiencia, no lo basamos en un análisis exhaustivo del mercado.

    Nuevo,Modificado,Ningún cambio