Menú

Técnicas

Adoptar?

  • Las funciones de aptitud introducidas por la arquitectura evolutiva, tomadas de la computación evolutiva, son funciones ejecutables que informan si las aplicaciones y la arquitectura se están alejando objetivamente de sus características deseadas. Básicamente, son pruebas que se pueden incorporar en los pipelines. Una de las principales características de una aplicación es la frescura de sus dependencias hacia bibliotecas, APIs o componentes del entorno que una función de aptitud de desfase de dependencias monitorea para marcar a aquellas que están obsoletas y que requieren de actualización. Con el incremento en cantidad y madurez de las herramientas que detectan desfases en las dependencias, como Dependabot o Snyk, podemos incorporar fácilmente funciones de aptitud de desfase de dependencias en el proceso de lanzamiento del software y así tomar las medidas más oportunas para mantener actualizadas las dependencias de nuestras aplicaciones.

    Historia
  • Automatizar la estimación, seguimiento y proyección del coste de ejecución de una infraestructura en la nube es necesario para las organizaciones de hoy. Los modelos inteligentes de precios de los proveedores de la nube, combinados con la proliferación de los parámetros de precios y la naturaleza dinámica de la arquitectura de hoy pueden llevar a costos de ejecución sorprendentemente altos. Por ejemplo, los precios de serverless basados en llamadas API, de soluciones de streaming de eventos enfocadas en el tráfico o de procesamientos de grupos de datos basados en tareas corridas, tienen una naturaleza dinámica que cambia a lo largo del tiempo a medida que la arquitectura evoluciona. Cuando nuestros equipos manejan infraestructura en la nube, implementar el coste de ejecución como función de la aptitud de arquitectura es una de sus primeras tareas. Esto quiere decir que nuestros equipos pueden observar el costo de ejecutar los servicios en comparación al valor entregado; cuando ven desviaciones respecto a lo que se espera o es aceptable, discutirán si es momento de evolucionar la arquitectura. La observación y cálculo del coste de ejecución se implementa como una función automatizada.

    Historia
  • A medida que el terreno de la tecnología se vuelve más complejo, áreas como la seguridad requieren de mayor automatización y prácticas de ingeniería. Cuando construimos sistemas, debemos considerar a las políticas de seguridad, aquellas reglas y procedimientos que protegen a los sistemas de peligros e interrupciones. Por ejemplo, las políticas de control de acceso definen e imponen quién puede acceder a cada servicio y recurso y bajo qué circunstancias; en contraste, las políticas de seguridad de redes pueden limitar dinámicamente el nivel de tráfico hacia un servicio en particular.

    Varios de nuestros equipos han tenido buenos resultados al tratar a las políticas de seguridad como código. Cuando decimos como código, no nos limitamos a escribir estas políticas en un archivo, si no que también aplicamos técnicas como mantener ese código versionado, introducir validaciones automatizadas en el pipeline, despliegues automatizados a ambientes así como observar y monitorear su funcionamiento. Basados en nuestra experiencia y en la madurez de las herramientas y plataformas existentes, como Open Policy Agent e Istio, que proveen mecanismos para definir e imponer políticas flexibles que soportan la práctica de políticas de seguridad como código, recomendamos mucho utilizar esta técnica en tu entorno.

    Historia
  • Desde la última vez que hablamos de las plantillas de servicio personalizadas , hemos visto una mayor adopción de este patrón para ayudar a allanar el camino de las organizaciones que se mueven a microservicios. Con los constantes avances en herramientas de observabilidad, orquestación de contenedores y sidecars de mallas de servicios, una plantilla proporciona definiciones predeterminadas para simplificar la creación de nuevos servicios, eliminando gran parte de la configuración necesaria para que el servicio funcione bien con la infraestructura circundante. Hemos tenido éxito aplicando los principios de gestión de productos a las plantillas, tratando a las personas desarrolladoras internas como clientes y facilitándoles llevar su código a producción y realizar su operación con apropiados niveles de observabilidad. Esto tiene el beneficio añadido de actuar como un mecanismo ligero de gobernanza para centralizar las decisiones técnicas por defecto.

    Historia

Probar?

  • Hace aproximadamente una década introdujimos la entrega continua, nuestra manera por defecto de entregar soluciones de software. Las soluciones actuales incluyen, cada vez más, modelos de aprendizaje automático y no los consideramos una excepción para la adopción de prácticas de entrega continua. Lo llamamos entrega continua para aprendizaje automático (CD4ML). A pesar de que los principios de la entrega continua siguen siendo los mismos, las herramientas y prácticas para implementar el proceso de principio a fin de entrenamiento, pruebas, despliegue y monitoreo de modelos requiere de algunas modificaciones. Por ejemplo: el control de versiones no solo incluye el código si no también los datos, los modelos y sus parámetros; la pirámide de pruebas se extiende para incluir análisis y validación de sesgos, de equidad, de datos y características; el proceso de despliegue debe considerar como promover y evaluar el rendimiento de los nuevos modelos contra los actuales modelos campeones. Mientras la industria está celebrando el nuevo término de moda, MLOps, creemos que CD4ML es la aproximación holística para implementar un proceso integral para entregar de forma fiable y mejorar continuamente los modelos de aprendizaje automático, desde la ideación hasta producción.

    Historia
  • La malla de datos marca el inicio de un cambio en los paradigmas arquitectónicos y organizacionales sobre cómo se gestionan los datos analíticos masivos. El paradigma se fundamenta en cuatro principios: (1) descentralización orientada al dominio de la propiedad de los datos y de su arquitectura; (2) datos orientados al dominio servidos como un producto; (3) auto servicio de infraestructura de datos como plataforma, para impulsar la autonomía de los equipos orientados al dominio; y (4) gobernanza federada para impulsar ecosistemas y la interoperabilidad. Si bien los principios son intuitivos y pretenden abordar muchos de los desafíos ya conocidos de la gestión centralizada de datos analiticos, estos trascienden las tecnologías actuales para datos analiticos. Luego de construir mallas de datos en muchos clientes con las herramientas existentes hemos aprendido dos cosas: (a) hay una gran brecha en las herramientas de código abierto o comerciales para acelerar la implementación de mallas de datos (por ejemplo, la implementación de un modelo de acceso universal a datos políglota basados en tiempo, que actualmente construimos a la medida para nuestros clientes) y (b) a pesar de la brecha, es factible usar tecnologías existentes como elementos básicos.

    Naturalmente, la idoneidad tecnológica es un componente importante en la implementación de una estrategia de datos de una organización basada en una malla de datos. Sin embargo, el éxito requiere de una reorganización estructural para separar al equipo de la plataforma de datos, crear el rol del product owner de datos para cada dominio e introducir las estructuras necesarias de incentivos para que los dominios se apropien y compartan los datos analíticos como productos.

    Historia
  • Muchos pipelines de datos se definen en un script largo, más o menos imperativo, escrito en Python o Scala. El script contiene tanto la lógica con los pasos individuales así como el código que enlaza los pasos entre sí. Cuando encontramos situaciones similares en pruebas de Selenium, los equipos de desarrollo descubrieron el patrón Objeto de Página (Page Object), y luego, varios frameworks para el desarrollo dirigido por comportamientos (BDD) implementaron una división entre las definiciones de pasos y su composición. Algunos equipos están aún experimentando para traer el mismo razonamiento a la ingeniería de datos. Una definición declarativa para pipelines de datos separada, escrita tal vez en YAML, contiene únicamente la declaración y la secuencia de pasos. En esta se declaran los conjuntos de datos de entrada y salida pero se recurre a los scripts si y cuando se requiere de lógica más compleja. A La Mode es una herramienta relativamente nueva que toma un enfoque de DSL para realizar la definición de pipelines, pero airflow-declarative, una herramienta que convierte directamente los grafos acíclicos en YAML en tareas programadas para Airflow, parece tener mayor impulso en este espacio.

    Historia
  • Estamos viendo más y más herramientas que te permiten crear diagramas como código para arquitectura de software y otros usos. Existen beneficios al utilizar estas herramientas en lugar de las alternativas más pesadas, como poder incluirlos fácilmente en el control de versiones y la habilidad de generar los DSLs desde varios orígenes. Entre las herramientas que nos gustan están Diagrams, Structurizr DSL, AsciiDoctor Diagram además de herramientas bien establecidas como WebSequenceDiagrams, PlantUML y el venerable Graphviz. También, como es bastante sencillo generar SVG hoy en día, no hay que descartar inmediatamente la opción de escribir una herramienta propia. Por ejemplo, uno de nuestros autores hizo un pequeño programa en Ruby para generar SVGs rápidamente.

    Historia
  • Cuando se construyen imágenes de Docker para las aplicaciones, usualmente nos preocupan dos cosas: la seguridad y su tamaño. Tradicionalmente hemos usado herramientas de escaneo de seguridad en contenedores para detectar y corregir vulnerabilidades y riesgos comunes y distribuciones pequeñas como Alpine Linux para resolver el tema del tamaño de la imagen y del rendimiento de la distribución. Hemos ganado más experiencia con imágenes Docker sin distribución y estamos listos para recomendar esta estrategia como otra importante medida de seguridad para aplicaciones contenerizadas. Este tipo de imágenes para Docker reducen el tamaño y las dependencias suprimiendo las distribuciones de sistemas operativos completos. Esta técnica reduce el ruido en los escaneos de seguridad y la superficie de ataque a la aplicación: hay menos vulnerabilidades que hay que corregir y, como extra, estas imágenes son más eficientes. Google ha publicado un conjunto de imágenes de contenedor sin distribución para diferentes lenguajes. Se pueden crear imágenes para aplicación sin distribución utilizando la herramienta de construcción Bazel de Google o utilizando simplemente Dockerfiles multistage. Hay que notar que los contenedores sin distribución no tienen un shell para depurar. Sin embargo es fácil encontrar en línea versiones de contenedores sin distribución habilitadas para la depuración que incluyen el shell BusyBox. Google ha sido pionero en esta técnica y, según nuestra experiencia, sigue estando confinada a imágenes generadas por Google. Esperamos que esta técnica se extienda por fuera de este ecosistema.

    Historia
  • A medida que más compañías están migrando sus sistemas legados, sentimos que vale la pena destacar una alternativa a la captura de cambios en los datos (CDC) como el mecanismo para obtener datos de estos sistemas. Martin Fowler describió la intercepción de eventos en 2004. En términos modernos, implica bifurcar las peticiones que ingresan a un sistema para que sea posible construir un reemplazo gradualmente. A menudo, esto es resultado de copiar eventos o mensajes, pero bifurcar peticiones HTTP es también válido. Algunos ejemplos son bifurcar eventos desde sistemas de puntos de venta antes de que se escriban en el sistema central y bifurcar transacciones de pago antes de que se escriban en los sistemas centrales de un banco. Ambos conducen al reemplazo gradual de las partes de los sistemas legados. Percibimos que la técnica de obtención de cambios del estado en su origen ha sido subestimada (ya que se ha preferido volver a crear estos eventos usando CDC, luego que los originales han sido procesados), por lo que la destacamos en esta edición del Radar.

    Historia
  • Reemplazar código legado en escala siempre es un esfuerzo complicado, el cual se beneficia a menudo de realizar una ejecución paralela con conciliación. En la práctica, esta técnica se fundamenta en ejecutar el mismo flujo en producción a través del código antiguo y nuevo, retornar la respuesta del código legado pero comparar los resultados para ganar mayor confianza en la nueva implementación. A pesar de ser una técnica antigua, en años recientes hemos visto implementaciones más robustas, basadas en prácticas de entrega continua como canary releases y feature toggles, y que se amplían añadiendo una capa extra de experimentación y análisis de datos para comparar los resultados en vivo. Incluso, hemos usado este enfoque para comparar resultados sobre aspectos no funcionales como el tiempo de respuesta. Aunque hemos utilizado esta técnica varias veces con herramientas hechas a la medida, sin duda le debemos un reconocimiento a la herramienta Scientist, de GitHub, que fue utilizada para actualizar una pieza crítica de su aplicación y que ahora ha sido portada a múltiples lenguajes de programación.

    Historia
  • Mientras la pandemia se extiende, parece que, por el momento, los equipos con una alta distribución serán parte de la “nueva normalidad”. En los últimos 6 meses hemos aprendido mucho acerca del trabajo remoto efectivo. En el lado positivo, las herramientas de visualización de colaboración y gestión de trabajo han simplificado más que nunca el trabajo remoto en conjunto entre colegas. Las personas desarrolladoras, por ejemplo, pueden apoyarse en Visual Studio Live Share y en GitHub Codespaces para facilitar el trabajo en equipo e incrementar la productividad. La mayor desventaja del trabajo remoto podría ser el agotamiento: demasiadas personas tienen video llamadas programadas consecutivamente durante todo el día, y esto ya está generando consecuencias. Mientras las herramientas visuales que tenemos en línea mejoran la posibilidad de colaborar, también es posible crear grandes y complejos diagramas que terminan siendo muy difíciles de usar, y los aspectos de seguridad por la proliferación de herramientas también debe ser administrado con mucho cuidado. Nuestro consejo es acordarse de dar un paso hacia atrás, hablar con los equipos, evaluar qué funciona y qué no y cambiar los procesos y herramientas según sea necesario.

    Historia
  • Mientras que la infraestructura computacional y de datos sigue cambiando en las empresas (de aplicaciones monolíticas a microservicios, de lagos de datos centralizados a mallas de datos, de alojamiento en servidores propios a usar las nubes de varios proveedores, con una proliferación creciente de dispositivos conectados), el enfoque para asegurar los activos empresariales sigue sin mayores cambios, con gran dependencia y confianza en el perímetro de la red: las organizaciones siguen haciendo grandes inversiones para asegurar sus activos fortaleciendo las perímetros virtuales de sus empresas, utilizando enlaces privados y configuraciones de cortafuegos, y reemplazando procesos de seguridad estáticos y engorrosos que ya no aplican en la realidad de hoy. Esta tendencia nos obliga a destacar nuevamente la arquitectura de confianza cero (ZTA).

    ZTA representa un cambio para los paradigmas de arquitectura y en las estrategias de seguridad. Se basa en el supuesto de que el perímetro de una red ya no representa un límite seguro y no se debe otorgar confianza implícita a los usuarios o servicios basándose únicamente en su ubicación física o de red. La cantidad de recursos, herramientas y plataformas disponibles para implementar aspectos de ZTA sigue creciendo e incluye: hacer cumplir políticas como código basadas en los principios de menor privilegio y de la mayor granularidad posible además del monitoreo continuo y la mitigación automatizada de amenazas; usar mallas de servicios para hacer cumplir los controles de seguridad de aplicación a servicio y de servicio a servicio; implementar certificación de los archivos binarios para verificar su origen; e incluir enclaves seguros además del cifrado tradicional para hacer cumplir los tres pilares de la seguridad de los datos: en tránsito, en reposo y en la memoria. Para obtener más información de este tema, consulta la publicación sobre ZTA del NIST y el artículo de Google sobre BeyondProd.

    Historia

Evaluar?

  • Una de las decisiones más complejas a las que se enfrentan las compañías en este momento es la adopción de plataformas de poco o ningún código, es decir, plataformas que resuelven problemas muy específicos en dominios bastante limitados. Muchos proveedores están presionando agresivamente hacia este espacio. Los problemas que vemos con estas plataformas se relacionan típicamente con la imposibilidad de aplicar buenas prácticas de ingeniería como el versionamiento. Además, realizar pruebas es generalmente muy difícil. Sin embargo, hemos notados la existencia de algunos nuevos e interesantes participantes en el mercado, como Amazon Honeycode que facilita la creación de aplicaciones simples de gestión de tareas o eventos y Parabola para flujos de trabajo en la nube similares a los de IFTTT, por lo que estamos incluyendo a las plataformas delimitadas de poco código en esta edición del Radar. No obstante, seguimos siendo profundamente escépticos acerca de su mayor aplicabilidad, ya que estas herramientas tienen el poder de escapar de sus límites y enredarlo todo, como lo hace la maleza. Es por eso que seguimos aconsejando tener mucho cuidado en su adopción.

    Historia
  • Los polyfills son muy útiles para ayudar a la evolución de la web ya que proveen implementaciones alternativas para funcionalidades modernas en navegadores que aún no las soportan. Sin embargo, muy a menudo, las aplicaciones web envían polyfills a navegadores que no los necesitan, provocando descargas innecesarias y gasto de recursos al procesarlos. Esta situación se ha hecho más notoria ahora que quedan pocos motores de renderizado y la mayoría de los polyfills apuntan solo a uno de ellos: el motor Trident de IE11. Además, la cuota de mercado de IE11 está decreciendo a medida que se acerca el fin de su soporte, en menos de un año. Por lo tanto, sugerimos que se utilicen polyfills adaptados al navegador , que entreguen solo los polyfills que en realidad se necesitan para cada navegador. Esta técnica se podría implementar como un servicio con Polyfill.io.

    Historia
  • En 2016, Christopher Allen, uno de los contribuyentes principales a SSL/TLS, nos inspiró con una introducción de 10 principios que apuntaban a una nueva forma de identidad digital así como una forma de llegar a ella: el camino hacia la auto-identidad soberana. La auto-identidad soberana, también conocida como la identidad descentralizada , es una “identidad portable y para toda la vida de una persona, organización o cosa que no depende de una autoridad centralizada y que nunca se puede confiscar”, de acuerdo al estandar Trust over IP. La adopción e implementación de identidades descentralizadas está ganando impulso y convirtiéndose en algo asequible. Vemos que se está adoptando en aplicaciones médicas, infraestructura sanitaria pública e identidad empresarial legal que respetan la privacidad. Si quieres comenzar pronto con la identidad descentralizada, puedes evaluar proyectos de código abierto como Sovrin Network, Hyperledger Aries e Indy, así como los estándares de identificadores descentralizados y de credenciales verificables. Estamos muy pendientes de lo que sucede en este campo mientras ayudamos a nuestros clientes con su posicionamiento estratégico en la nueva era de confianza digital.

    Historia
  • Los proveedores de la nube han comenzado lentamente a dar soporte a APIs del estilo de Kubernetes, mediante definiciones de recursos personalizados (CRDs) para gestionar sus servicios en la nube. En la mayoría de los casos, estos servicios en la nube son una parte central de la infraestructura y hemos visto a equipos utilizar herramientas como Terraform o Pulumi para provisionarlos. Con estos nuevos CRDs (ACK para AWS, Azure Service Operator para Azure y Config Connectors para GCP) puedes utilizar Kubernetes para provisionar y gestionar estos servicios en la nube. Una de las ventajas de estos servicios en la nube gestionados por Kubernetes es que puedes utilizar el mismo nivel de control de Kubernetes para garantizar el estado declarativo tanto de tu aplicación como de su infraestructura. El inconveniente es que acopla estrechamente el clúster de Kubernetes con la infraestructura, por lo que lo estamos evaluando cuidadosamente y pensamos que deberías hacerlo igual.

    Historia
  • Hemos hablado mucho sobre los beneficios de crear equipos de producto de ingeniería de plataformas para dar soporte a los demás equipos de producto, pero en realidad es difícil hacerlo. Parece que la industria aún está buscando la abstracción correcta en el mundo de la infraestructura como código. Aunque herramientas como Terraform y Helm son pasos en la dirección correcta, el enfoque sigue estando en la gestión de la infraestructura en lugar del desarrollo de aplicaciones. También hay cambios hacia el concepto de infraestructura como software con la aparición de nuevas herramientas como Pulumi y CDK. El Modelo Abierto de Aplicaciones (OAM) es un intento de traer alguna estandarización a este espacio. Utilizando las abstracciones de componentes, configuraciones de aplicaciones, ámbitos o contextos (scopes) y aspectos o atributos (traits), las personas desarrolladoras pueden describir sus aplicaciones independientemente de la plataforma, mientras que las personas implementadoras de plataforma definen su plataforma en términos de cargas de trabajo, aspectos o atributos (traits) y ámbitos o contextos (scopes). Queda por ver si el OAM será ampliamente adoptado, pero recomendamos estar atento a esta idea interesante y necesaria.

    Historia
  • Los enclaves seguros , también conocidos como entornos de ejecución confiable (trusted execution environments, TEE), hacen referencia a una técnica que aisla un entorno (procesador, memoria y almacenamiento) con un mayor nivel de seguridad y limita el intercambio de información con otros contextos no fiables. Por ejemplo, un enclave seguro a nivel de hardware y sistema operativo podría crear y almacenar claves privadas y realizar operaciones con ellas como el cifrado de información o verificación de firmas sin permitir que las claves privadas salgan del enclave seguro o que sean cargadas en memoria de algún proceso no fiable. Un enclave seguro provee un conjunto limitado de instrucciones para ejecutar operaciones confiables, de manera aislada a un contexto de aplicación no fiable.

    La técnica ha sido ampliamente soportada por muchos proveedores de hardware y proveedores de sistemas operativos (incluído Apple) y las personas desarrolladoras lo han usado en la Internet de las Cosas y para edge applications. Sin embargo, sólo recientemente ha ganado atención tanto en aplicaciones empresariales como en aplicaciones en la nube. Los proveedores de la nube han empezado a introducir funcionalidades de computación confidencial en la forma de enclaves seguros basados en hardware: La infraestructura de computación confidencial de Azure promete máquinas virtuales con entornos de ejecución confiables y accesibles mediante el Open Enclave SDK, que es una biblioteca de código abierto para ejecutar operaciones confiables. De igual manera, GCP Confidential VMs and Compute Engine, que todavía está en beta, permite el uso de máquinas virtuales con cifrado de datos en memoria y AWS Nitro Enclaves está siguiendo esa tendencia en su siguiente entrega. Con la introducción de enclaves seguros basados en la nube y la computación confidencial, podemos añadir un tercer pilar a la protección de datos: en reposo, en transmisión y ahora en la memoria.

    Si bien nos encontramos todavía en los primeros días de los enclaves seguros para aplicaciones empresariales, animamos a considerar esta técnica teniendo en cuenta las posibles vulnerabilidadades que pueden comprometer el enclave seguro de los proveedores de hardware usados.

    Historia
  • Los experimentos controlados usando pruebas A/B son una gran manera de contextualizar decisiones alrededor del desarrollo de productos. Pero no funcionan muy bien cuando no podemos establecer independencia entre los dos grupos involucrados en la prueba A/B, por ejemplo, al añadir alguien al grupo "A" impacta al grupo "B" y viceversa. Una técnica para resolver este tipo de problema es la experimentación de avance y retroceso. El concepto central en esto es cambiar entre los modos "A" y "B" continuamente en ciertas regiones en periodos de tiempos alternativos en vez de correr ambos modos durante el mismo periodo de tiempo. Entonces comparamos la experiencia de la clientela y otras métricas clave entre los dos periodos de tiempo. Hemos probado esta técnica con buenos resultados en algunos de nuestros proyectos y creemos que es una buena herramienta para incluir en nuestra caja de herramientas de experimentación.

    Historia
  • Las credenciales están en todas partes en nuestras vidas e incluyen pasaportes, licencias de conducir y certificados académicos. Sin embargo, la mayoría de las credenciales digitales actuales son registros de datos simples en sistemas de información que son fáciles de modificar y falsificar, y que a menudo, exponen información innecesaria. En los últimos años, hemos visto cómo la madurez continuada de Credenciales verificables resuelve este problema. El estándar de la W3C lo define de una manera que es criptográficamente segura, respetuosa de la privacidad y verificable por máquina. El modelo coloca a los titulares de las credenciales en el centro, que es similar a nuestra experiencia cuando usamos credenciales físicas: los usuarios pueden poner sus credenciales verificables en sus propias billeteras digitales y mostrarlas a cualquier persona en cualquier momento sin el permiso del emisor de las credenciales. Este enfoque descentralizado también permite a los usuarios administrar mejor su propia información y revelar selectivamente cierta información y mejora en gran medida la protección de la privacidad de los datos. Por ejemplo, debido a la tecnología de prueba de conocimiento cero, se puede construir una credencial verificable para demostrar que uno es un adulto sin revelar su fecha de nacimiento. La comunidad ha desarrollado muchos casos de uso en torno a credenciales verificables. Hemos implementado nuestra propia certificación de salud COVID con referencia a la Iniciativa de Credenciales para COVID-19 (CCI). Aunque las credenciales verificables no dependen de la tecnología blockchain o identidad descentralizada, esta técnica a menudo funciona con DID en la práctica y utiliza blockchain como registro de datos comprobables. Muchos frameworks de identidad descentralizada también están integrados con credenciales verificables.

    Historia

Resistir?

  • Cuando hablamos por primera vez de GraphQL en el Radar, advertimos que su mal uso podria llevar a situaciones que tienen mas desventajas que beneficios en el largo plazo. No obstante, hemos visto un aumento en el interés en GraphQL entre nuestros equipos por su habilidad de agregar información provista por diferentes recursos. Esta vez queremos advertir sobre el uso de Apollo Federation y su soporte sólido para un grafo de datos único y unificado para tu compañía. Si bien, a primera vista, la idea de tener conceptos ubicuos para toda la organización es tentadora, debemos tener en cuenta intentos similares ya propuestos en la industria, como MDM y modelos de datos canónicos, entre otros, que han expuesto las dificultades de este enfoque. Los retos pueden ser significativos, especialmente cuando el dominio en el que nos encontramos es lo suficientemente complejo como para crear un modelo único y unificado.

    Historia
  • Hace tiempo que advertimos en contra de los ESB centralizados y definimos que los "endpoints inteligentes y canales (pipes) tontos" eran una de las características base para las arquitecturas de microservicios. Desafortunadamente, estamos viendo como los ESBs tradicionales están cambiando su imagen y creando ESBs disfrazados de API Gateways , que naturalmente incentivan a crear API Gateways demasiado ambiciosos. Hay que evitar el engaño de la publicidad: independientemente de como se llamen, poner la lógica de negocio (incluyendo la orquestación y transformación) en una herramienta centralizada crea acoplamiento en la arquitectura, reduce la transparencia e incrementa la dependencia en un proveedor sin añadir ventajas. Los API gateways pueden servir como una abstracción útil para aplicar características horizontales (crosscutting concerns), pero estamos convencidos que la inteligencia debe estar en las propias APIs.

    Historia
  • Hace varios años, surgió una nueva generación de plataformas de agregación de registros (logs) que eran capaces de almacenar y buscar en grandes cantidades de datos para descubrir tendencias y conocimientos sobre datos operativos. Splunk fue el más destacado pero de ninguna manera el único ejemplo de estas herramientas. Debido a que estas plataformas proporcionan una amplia visibilidad operativa y de seguridad en todo el conjunto de aplicaciones, los administradores y desarrolladores se han vuelto cada vez más dependientes de ellas. Este entusiasmo se extendió cuando las partes interesadas descubrieron que podían usar la agregación de registros (logs) para análisis de negocios. Sin embargo, las necesidades comerciales pueden superar rápidamente la flexibilidad y la facilidad de uso de estas herramientas. Los registros destinados a la observación técnica a menudo son inadecuados para inferir una comprensión profunda del cliente. Preferimos usar herramientas y métricas diseñadas específicamente para el análisis de los clientes o adoptar un enfoque de observabilidad más orientado a eventos, donde los eventos comerciales y operativos se recopilan y almacenan de manera que puedan reproducirse y procesarse con herramientas especialmente diseñadas para ese propósito.

    Historia
  • Desde que introdujimos originalmente el término en 2016, los micro-frontends han ganado popularidad y han sido aceptados de forma generalizada. Pero como suele ocurrir con cualquier nueva técnica con un nombre fácil de recordar, en ocasiones ha sido mal utilizada o de forma abusiva. Es especialmente preocupante la tendencia a utilizar esta arquitectura como una excusa para mezclar una variedad de tecnologías, herramientas o frameworks competidores en la misma página, dando lugar a la anarquía de los micro-frontends. Una forma particularmente escandalosa de este síndrome consiste en el uso de múltiples frameworks de frontend, como React.js y Angular, en la misma aplicación de página única. Si bien esto puede ser técnicamente posible, no es en absoluto aconsejable, excepto cuando forma parte de una estrategia de transición deliberada. Otras propiedades que deberían ser consistentes entre equipos incluyen la técnica de aplicación de estilos (por ejemplo, CSS-en-JS o CSS modules) y los métodos utilizados para integrar los componentes individuales (por ejemplo, iFrames o web components). Además, las organizaciones deberían decidir si estandarizar usando enfoques consistentes o dejar a sus equipos decidir sobre cómo gestionar el estado, el acceso a los datos, las herramientas de construcción, las analíticas y una serie de otras opciones en una aplicación micro-frontend.

    Historia
  • En las últimas décadas, los notebooks computacionales, mostrados por primera vez por Wolfram Mathematica, han evolucionado para dar soporte a los flujos de trabajo de investigación científica, exploración y educación. De forma natural, al soportar flujos de trabajo de ciencia de datos y mediante herramientas como Jupyter notebooks y Databricks notebooks, se han convertido en un gran complemento al proporcionar un entorno interactivo de computación simple e intuitivo para combinar código que analiza datos junto con texto enriquecido y visualización para contar una historia de datos. Los notebooks se diseñaron para ser el mejor medio para la comunicación y la innovación científica moderna. Sin embargo, en los últimos años, hemos visto una tendencia a utilizar los notebooks como medio para la ejecución de código de calidad de producción utilizado generalmente para guiar operaciones empresariales. Hemos visto a proveedores de plataformas de notebooks publicitando el uso de notebooks exploratorios en producción. Este es un caso de buenas intenciones, por intentar democratizar la programación para científicas de datos, con una implementación incorrecta y a cambio de escalabilidad, mantenibilidad, adaptabilidad y otras cualidades que un código de producción longevo necesita proporcionar. Por ello, no recomendamos llevar notebooks a producción y, en su lugar, animamos a empoderar a las personas científicas de datos para que construyan código de calidad para producción con los frameworks de programación adecuados, y así simplificar el uso de herramientas de entrega continua y abstraer la complejidad a través de plataformas de aprendizaje automático de punta a punta.

    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