Master

Técnicas

Adoptar?

  • El patrón de expansión-contracción de APIs , a veces llamado cambios en paralelo (parallel change), será familiar para muchas personas, especialmente en relación a su uso con bases de datos o código; sin embargo, sólo vemos niveles bajos de adopción en las APIs. Específicamente, vemos el uso esquemas complejos de versionamiento y la introducción de cambios disruptivos en escenarios donde la simple expansión y posterior contracción del API sería suficiente. Por ejemplo, primero se añadiría un nuevo elemento a un API, para luego descontinuar un elemento existente, y posteriormente remover los elementos descontinuados, una vez que los consumidores se hayan cambiado al esquema más nuevo. Este enfoque requiere cierta coordinacion y visibilidad de los consumidores del API, tal vez a traves de técnicas como las pruebas de contratos dirigidos por consumidores.

    Historia
  • Vemos a la entrega continua para aprendizaje automático (CD4ML) como un buen punto de inicio predeterminado para cualquier solución de aprendizaje automático que se despliegue en producción. Muchas organizaciones dependen cada vez más de soluciones de aprendizaje automático tanto para las ofertas a sus clientes como para operaciones internas, así que tiene sentido comercial aplicar las lecciones y las buenas practicas capturadas por la entrega continua (CD) a las soluciones de aprendizaje automático.

    Historia
  • A medida que el desarrollo de aplicaciones se hace cada vez más dinámico y complejo, es un desafío ofrecer productos accesibles y utilizables con un estilo coherente. Esto es particularmente cierto en las organizaciones más grandes con varios equipos que trabajan en diferentes productos. Los sistemas de diseño definen una colección de patrones de diseño, bibliotecas de componentes y buenas prácticas de diseño e ingeniería que garantizan productos digitales consistentes. Basados en las guías de estilo corporativas del pasado, los sistemas de diseño ofrecen bibliotecas y documentos compartidos que son fáciles de encontrar y usar. Generalmente la guía se escribe como código y se mantiene bajo control de versiones para que sea menos ambigua y más fácil de mantener que los documentos simples. Los sistemas de diseño se han convertido en un enfoque estándar cuando se trabaja entre equipos y disciplinas en el desarrollo de productos porque permiten que los equipos se concentren. Pueden abordar desafíos estratégicos en torno al producto en sí sin reinventar la rueda cada vez que se necesita un nuevo componente visual.

    Historia
  • Como se mencionó en uno de los temas de esta edición, la industria está ganando cada vez más experiencia con los equipos de producto de ingeniería de plataforma que crean y dan soporte a plataformas internas. Estas son utilizadas por los equipos de toda la organización y aceleran el desarrollo de aplicaciones, reducen la complejidad operativa y mejoran el tiempo de comercialización. Con una adopción cada vez mayor, también tenemos más claros los patrones buenos y malos de este enfoque. Al crear una plataforma, es fundamental tener clientes y productos claramente definidos que se beneficiarán de ella en lugar de construir en el vacío. Advertimos en contra de los equipos de plataforma en capas, que conservan los silos de tecnología existentes pero se aplican la etiqueta de "equipo de plataforma", y también contra los modelos operativos de plataforma basados en tickets. Todavía somos partidarios de utilizar los conceptos de Team Topologies mientras pensamos en cómo organizar mejor a los equipos de plataforma. Consideramos que los equipos de producto de ingeniería de plataforma son un enfoque estándar y un habilitador significativo para lograr TI de alto rendimiento.

    Historia
  • Recomendamos encarecidamente a las organizaciones que, cuando realmente se necesite usar cuentas de servicios en la nube, roten las credenciales. La rotación es una de las tres R de la seguridad. Es muy fácil para las organizaciones perder de vista a estas cuentas hasta que ocurre un incidente. Esto da lugar a la existencia de cuentas con permisos innecesariamente amplios que se mantienen en uso por largos periodos de tiempo, además de la falta de planificación sobre como reemplazarlas o rotarlas. El aplicar regularmente una estrategia de rotación de cuentas de servicios en la nube también da la oportunidad de practicar el principio del menor privilegio.

    Historia

Probar?

  • Dado que la nube se está convirtiendo cada vez más en un producto básico y que la posibilidad de crear sandboxes en la nube es mucho más sencillo y está disponible a gran escala, nuestros equipos prefieren entornos de desarrollo en la nube (en lugar de locales) para reducir la complejidad del mantenimiento. Estamos viendo que las herramientas para hacer una simulación local de los servicios nativos de la nube limitan la confianza en los ciclos de construcción y prueba de los desarrolladores; por lo tanto, estamos buscando centrarnos en estandarizar los ambientes sandbox en la nube, en lugar de ejecutar los componentes nativos de la nube en una máquina del desarrollador. Esto impulsará las buenas prácticas de infraestructura como código como medida obligatoria y los buenos procesos de incorporación para proveer de ambientes sandboxes a los nuevos desarrolladores. Existen riesgos asociados a esta transición, ya que supone que los desarrolladores tendrán una dependencia absoluta de la disponibilidad del entorno en la nube, y puede ralentizar el ciclo de retroalimentación. Recomendamos encarecidamente adoptar algunas prácticas de gobernanza lean en relación con la estandarización de estos entornos de sandboxes, especialmente en lo que respecta a la seguridad, la administración de identidades (IAM por sus siglas en inglés) y los despliegues regionales.

    Historia
  • Contextual bandits es un tipo de aprendizaje por refuerzo muy adecuado para problemas que requieren un equilibrio entre exploración y explotación ("Exploration-Exploitation Trade-off"). Con un nombre que hace honor a las máquinas tragamonedas de los casinos (en inglés, "bandits" o "one-armed bandits"), el algoritmo explora diferentes opciones para aprender más sobre los resultados esperados y los equilibra explotando aquellas que se desempeñan bien. Hemos usado esta técnica exitosamente en escenarios donde se ha tenido muy poca información para entrenar y desplegar otros modelos de aprendizaje automático. El hecho de que es posible agregar contexto a este equilibrio entre exploración y explotación lo hace apropiado para una amplia variedad de casos de uso, como pruebas A/B, recomendaciones y optimizaciones de diseño, etc.

    Historia
  • Cuando se construyen imágenes 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. Pero con el aumento de las amenazas de seguridad, eliminar todos los posibles vectores de ataque es más importante que nunca. Es por esto que las imágenes Docker sin distribución se están convirtiendo en la opción predeterminada para contenedores para despliegue. Este tipo de imágenes 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 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 usando la herramienta de construcción Bazel de Google o simplemente usando Dockerfiles multistage. Hay que tener en cuenta que los contenedores sin distribución no tienen un intérprete de comandos (shell) para depurar. Sin embargo es fácil encontrar en línea versiones de contenedores sin distribución habilitados para la depuración que incluyen a BusyBox como intérprete de comandos. Google ha sido pionero en esta técnica y, en nuestra experiencia, sigue limitada en gran medida a las imágenes generadas por ellos. Nos sentiríamos mejor si existiera más de un proveedor para elegir. Además, se debe tener precaución al correr Trivy o escáneres de vulnerabilidades similares, ya que solamente sus versiones más recientes son compatibles con este tipo de contenedores.

    Historia
  • El grupo que está detrás de Ethical OS (Omidyar Network, una empresa autodenominada de cambio social creada por el fundador de eBay, Pierre Omidyar) ha liberado un nueva iteración llamada Ethical Explorer. Este nuevo paquete se basa en las lecciones aprendidas con el uso de Ethical OS y agrega más preguntas para que los equipos de producto las tengan en cuenta. El kit, que puede descargarse de forma gratuita y doblarse en tarjetas para iniciar una conversación, tiene preguntas abiertas para varias "zonas de riesgo" técnicas, incluida la vigilancia ("¿puede alguien utilizar nuestro producto o servicio para rastrear o identificar a otros usuarios?"), la desinformación, la exclusión, el sesgo algorítmico, la adicción, el control de datos, los malos actores y el poder desmesurado. La guía que se incluye tiene actividades y talleres, ideas para iniciar conversaciones y consejos para lograr la aceptación de la organización. Si bien tenemos un largo camino por recorrer como industria para representar mejor los factores externos éticos de nuestra sociedad digital, hemos tenido algunas conversaciones fructíferas sobre productos utilizando Ethical Explorer y nos alienta la creciente conciencia de la importancia de las decisiones sobre los productos para abordar los problemas sociales.

    Historia
  • A menudo nos piden que renovemos, actualicemos o reparemos sistemas legados que originalmente no hemos construido. En ocasiones, debemos atender problemas técnicos como mejorar el desempeño y la fiabilidad del sistema. Un enfoque común para abordar estos asuntos es crear "historias técnicas" usando el mismo formato que una historia de usuario, pero con un resultado técnico en vez de uno de negocio. Sin embargo, estas tareas técnicas a menudo son difíciles de estimar, llevan más tiempo del que se anticipa, o no terminan produciendo el resultado deseado. Un método alternativo y más exitoso es aplicar la renovación de legados guiada por hipótesis. En lugar de trabajar con un banco (backlog) estándar de historias de usuario, el equipo se apropia de un resultado técnico cuantificable y establece colectivamente un conjunto de hipótesis sobre el problema. Luego llevan a cabo experimentos en iteraciones de tiempo establecidas para verificar o refutar cada hipótesis en orden de prioridad. El flujo de trabajo resultante está optimizado para reducir la incertidumbre en lugar de seguir un plan hacia un resultado predecible.

    Historia
  • A medida que las organizaciones se mueven hacia arquitecturas evolutivas, es importante llevar un registro de las decisiones de diseño, arquitectura, técnicas y formas de trabajar de los equipos. El proceso de recolectar y consolidar la retroalimentación que conduce a esas decisiones comienza con las Solicitudes de Comentarios (Request for Comments, RFCs). Las RFCs son una técnica para recoger contexto, ideas de diseño y de arquitectura y colaborar con los equipos para finalmente llegar a tomar decisiones junto con su contexto y consecuencias. Nosotros recomendamos que las organizaciones tomen un enfoque ligero respecto a las RFCs , usando una plantilla estandarizada entre los equipos además de control de versiones para recoger las RFCs.

    Es importante agregar estas decisiones en un registro de auditoría, para beneficiar a los miembros futuros de los equipos y así documentar la evolución técnica y de negocio de una organización. Las organizaciones maduras han usado los RFCs en equipos autónomos para impulsar mejoras en la comunicación y la colaboración, especialmente cuando se trata de tomar decisiones importantes entre equipos.

    Historia
  • Todos los proveedores grandes de la nube ofrecen una gama deslumbrante de soluciones de aprendizaje automático. Estas poderosas herramientas pueden proveer mucho valor, aunque tienen costos asociados. Existe el costo puro por la ejecución de estos servicios, cobrado por el proveedor de la nube. Además, hay una especie de impuesto a su operación. Estas herramientas complejas necesitan ser entendidas y operadas, y con cada nueva herramienta que se agrega a la arquitectura, esta carga impositiva se incrementa. En nuestra experiencia, muchas veces los equipos eligen herramientas complejas porque menosprecian el poder de herramientas más sencillas como la regresión lineal. Muchos de los problemas de aprendizaje automático no necesitan de una GPU ni de redes neuronales. Por esta razón recomendamos utilizar el aprendizaje automático más simple posible , aprovechando herramientas y modelos sencillos, algunos cientos de líneas de código Python, en la plataforma de cómputo que esté más a la mano. Se debe dejar las herramientas complejas solo para cuando se pueda demostrar su necesidad.

    Historia
  • El patrón de estrangulamiento es a menudo la primera estrategia que viene a la mente para modernizar sistemas legados, donde el nuevo código envuelve al antiguo y absorbe lentamente la capacidad de manejar toda la funcionalidad necesaria. Este tipo de enfoque "de afuera hacia adentro" funciona bien para algunos sistemas legados, sin embargo, ahora que hemos tenido suficiente experiencia con aplicaciones de página única (SPA), y dado que estas aplicaciones se están volviendo sistemas legados en sí, notamos que el enfoque opuesto, "de adentro hacia afuera", se está usando para reemplazarlas. En vez de envolver al sistema legado, se agrega las bases de la nueva SPA en el documento HTML que contiene a la anterior y dejamos que se expanda lentamente en funcionalidad. Los marcos de trabajo de SPA ni siquiera necesitan ser los mismos, siempre que los usuarios puedan tolerar el impacto causado al rendimiento por el aumento del tamaño de la página (por ejemplo, al incrustar una nueva aplicación React dentro de una antigua en AngularJS). La inyección de SPA permite eliminar iterativamente la aplicación antigua hasta que la nueva tome su lugar por completo. Mientras que la metáfora del árbol estrangulador puede verse como un tipo de parásito que usa la superficie externa, estable, del árbol huésped para sostenerse hasta echar raíces, mientras el huésped muere; este enfoque es más como inyectar un agente externo en el huésped, apoyándose en la funcionalidad de la SPA original hasta poder reemplazarla por completo.

    Historia
  • La arquitectura de un sistema replica la estructura de la organización y sus patrones de comunicación. No es nada nuevo que debemos ser intencionales sobre cómo interactúan los equipos (véase, por ejemplo, la Maniobra Invertida de Conway). La interacción de un equipo es una de las variables que definen cuán rápido y cuán fácil les resulta entregar valor a sus clientes. Estamos contentos de haber encontrado una forma de medir esas interacciones: usamos la evaluación que proponen las autoras de Team Topologies, que proporciona una forma de entender cuán fácil o difícil le resulta a los equipos construir, probar y mantener sus servicios. Midiendo la carga cognitiva del equipo , podríamos aconsejar mejor a nuestros clientes sobre cómo cambiar la estructura de sus equipos y evolucionar sus interacciones.

    Historia
  • Muchas de nuestras personas que desarrollan para iOS con Xcode a menudo sufren por culpa de los cambios en el archivo Xcodeproj cada vez que cambia el proyecto. El formato de este archivo no es legible para las personas, por lo que intentar manejar conflictos es bastante complicado y puede conducir a una pérdida de productividad con el riesgo de estropear el proyecto entero (si algo malo pasa con el archivo, Xcode no funcionará bien y las desarrolladoras quedarán bloqueadas). En lugar de intentar fusionar los cambios y arreglar el archivo manualmente o versionarlo, recomendamos un enfoque llamado Xcodeproj administrado por herramientas : la configuración del proyecto Xcode se define en YAML (XcodeGen, Struct), Ruby (Xcake) o Swift (Tuist) y estas herramientas generan el archivo Xcodeproj a partir del archivo de configuración y la estructura del proyecto. Como resultado, los conflictos al fusionar cambios en el archivo Xcodeproj serán una cosa del pasado y, cuando ocurran en el archivo de configuración, son mucho más fáciles de resolver.

    Historia
  • Con TypeScript convirtiéndose en un lenguaje común para el desarrollo de front-end, y Node.js siendo una de las tecnologías preferidas para el desarrollo de BFFs, percibimos un incremento en el uso de tipos compartidos entre la UI y el BFF. En esta técnica, un único conjunto de definiciones de tipos de datos es utilizado para definir tanto los objetos de datos devueltos por las consultas del front-end, como los datos entregados desde el servidor de back-end para satisfacer esas consultas. Normalmente, seríamos cautelosos con esta práctica debido al acoplamiento innecesario que crea a través de los límites de los procesos; pero, muchos equipos están encontrando que los beneficios de este enfoque superan cualquier riesgo de alto acoplamiento. Dado que el patrón BFF funciona mejor cuando el código de la interfaz de usuario y el del BFF son propiedad del mismo equipo, y considerando que ambos componentes conviven en el mismo repositorio con frecuencia, el par UI-BFF puede verse como un único sistema cohesionado. Cuando el BFF ofrece consultas de datos fuertemente tipados, los resultados se pueden adaptar a las necesidades específicas del front-end, en lugar de utilizar una única entidad de propósito general que deba satisfacer las necesidades de muchos consumidores y contener más campos de los que realmente son necesarios. Esto reduce el riesgo de exponer accidentalmente datos que el usuario no debería ver, previene la interpretación incorrecta del objeto de datos devuelto y hace que la consulta sea más expresiva. Esta práctica es particularmente útil cuando se implementa con io-ts para hacer cumplir la seguridad de los tipos en tiempo de ejecución.

    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
  • 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
  • Un radiador del desfase de los despliegues hace visible las discrepancias entre las versiones del software desplegado en múltiples ambientes. Las organizaciones que utilizan despliegues automáticos suelen tener flujos de aprobación manual para los ambientes cercanos a producción, y con frecuencia, el código en estos ambientes está varias versiones por detrás del código en desarrollo actual. Esta técnica muestra esta diferencia entre las versiones de cada componente en cada ambiente mediante un tablero simple. Esto ayuda a destacar el costo de oportunidad del código terminado que aún no está en producción y puede señalar posibles riesgos, como parches de seguridad aún no liberados.

    Historia
  • El cifrado homomórfico (homomorphic encryption, HE) total se refiere a una clase de métodos de cifrado que permiten que los cálculos (como la búsqueda y la aritmética) se realicen directamente sobre datos cifrados. El resultado de los cálculos permanece encriptado, y se puede desencriptar y revelar posteriormente. Aunque el problema de la HE se propuso por primera vez en 1978, no se construyó una solución sino hasta 2009. Con los avances en el poder computacional y la disponibilidad de bibliotecas de código abierto fáciles de usar, como SEAL, Lattigo, HElib y el cifrado homomórfico parcial en Python, HE se está volviendo factible en aplicaciones del mundo real. Los escenarios motivadores incluyen casos de uso con preservación de la privacidad, donde la computación se puede subcontratar a un grupo que no es de confianza, por ejemplo, para ejecutar cálculos sobre datos cifrados en la nube, o para permitir que un tercero agregue resultados intermedios cifrados homomórficamente de aprendizaje automático federado. Además, la mayoría de los esquemas de HE se consideran seguros frente a las computadoras cuánticas y se están realizando esfuerzos para estandarizar la HE. A pesar de sus limitaciones actuales, rendimiento y viabilidad de los tipos de cálculos, HE es digno de atención.

    Historia
  • Hotwire (HTML over the wire) es una técnica para construir aplicaciones web. Las páginas se construyen a partir de componentes, pero a diferencia de las SPA modernas, el HTML de los componentes se genera en el lado del servidor y luego se envía por el cable "over the wire" al navegador. La aplicación sólo tiene una pequeña cantidad de código JavaScript en el navegador para unir los fragmentos de HTML. Nuestros equipos, y sin duda otros también, utilizaron esta técnica después de que las peticiones web asíncronas fueran soportadas por los navegadores, allá por el año 2005, pero por diversas razones esta técnica nunca ganó mucha fama.

    En la actualidad, Hotwire utiliza tanto las capacidades modernas de los navegadores web como las capacidades de HTTP para lograr la velocidad, capacidad de respuesta y la naturaleza dinámica de las aplicaciones de una sola página (SPA, por sus siglas en inglés). Esta técnica adopta un diseño de aplicación web más sencillo, localizando la lógica en el servidor y manteniendo simple el código del lado del cliente. El equipo de Basecamp ha lanzado algunos marcos de trabajo de Hotwire que potencian su propia aplicación, incluyendo Turbo y Stimulus. Turbo incluye un conjunto de técnicas y marcos de trabajo para acelerar la capacidad de respuesta de la aplicación evitando la recarga de la página completa, la previsualización de la página desde la caché y la descomposición de la página en fragmentos con mejoras progresivas bajo demanda. Stimulus está diseñado para mejorar el HTML estático en el navegador conectando objetos JavaScript a los elementos de la página en el HTML.

    Historia
  • Cuando se compone una aplicación con varios micro frontends, algunas partes del sistema necesitan decidir qué micro frontend cargar y de dónde hacerlo. Hasta ahora, o bien construíamos una solución a medida, o bien dependíamos de un marco de trabajo más amplio como single-spa. Ahora existe un nuevo estándar denominado import-maps que ayuda en ambos casos. Nuestras primeras experiencias muestran que usar importmaps para micro frontends permite conseguir una separación limpia de responsabilidades. El código JavaScript indica qué importar y una etiqueta script al inicio de la respuesta HTML inicial especifica de dónde hay que importar el front-end. Ese HTML está generado obviamente en el lado servidor, lo que hace posible usar alguna configuración dinámica durante la renderización. En muchos casos esta técnica nos recuerda a las rutas del enlazador/cargador (linker/loader) para bibliotecas dinámicas Unix. Por ahora los importmaps solo están soportados por Chrome, pero con el polyfill SystemJS están listos para un uso más amplio.

    Historia
  • El Open Application Model (OAM) es un intento para crear algunos estándares alrededor del modelamiento de plataformas de infraestructura como productos. Usando abstracciones para los componentes, las configuraciones de aplicaciones, sus ámbitos (scopes) y atributos (traits), los equipos de desarrollo pueden describir sus aplicaciones de forma agnóstica a la plataforma; mientras que el equipo que la implemente, lo puede hacer en términos de carga de trabajo, atributos y ámbitos. Desde la última vez que hablamos sobre OAM, hemos seguido con interés una de sus primeras implementaciones: KubeVela. KubeVela está cerca de publicar su versión 1.0 y tenemos curiosidad de ver si este tipo de implementaciones pueden sustentar la promesa de la idea de OAM.

    Historia
  • La analítica web centrada en la privacidad es una técnica para recopilar datos analíticos web sin comprometer la privacidad del usuario final, manteniéndolos verdaderamente anónimos. Una consecuencia inesperada del cumplimiento de la Regulación General de Protección de Datos (RGPD o, GDPR en inglés) es la decisión tomada por varias organizaciones de degradar la experiencia del usuario con complejos procesos para aceptar cookies, especialmente cuando el usuario no acepta inmediatamente la configuración por defecto de "todas las cookies". La analítica web centrada en la privacidad tiene el doble beneficio de respetar el espíritu y la letra de la RGPD a la vez que evita la necesidad de introducir formularios intrusivos de consentimiento de cookies. Una implementación de esta técnica es Plausible.

    Historia
  • La programación en grupo (mob programming) es una de esas técnicas que nuestros equipos han visto que son capaces de ejecutar más fácilmente de forma remota. La programación en grupo remota permite a los equipos agruparse alrededor de una tarea o una sección de código sin las limitantes físicas de solo poder ubicar un número limitado de personas en una estación de trabajo. Los equipos pueden colaborar rápidamente sin tener que conectar una gran pantalla, reservar una sala de reuniones física o encontrar una pizarra.

    Historia
  • La computación segura entre múltiples partes (secure multiparty computing, MPC) soluciona el problema de computación colaborativa protegiendo la privacidad entre partes que no confían entre sí. Su objetivo es calcular de forma segura un problema acordado sin un tercero de confianza, mientras cada participante es requerido de formar parte del cálculo de un resultado, que no puede ser obtenido por las otras entidades. Un ejemplo simple de MCP es el problema de los millonarios: dos millonarios quieren conocer quién es más rico, pero ninguno quiere revelar el valor de su patrimonio al otro ni tampoco a un tercero. Los enfoques de implementación de MPC varían: los escenarios pueden incluir el intercambio de secretos, transferencia inconsciente, circuitos confusos o cifrado homomórfico. Algunas soluciones comerciales de MPC que han aparecido recientemente, como Antchain Morse, afirman que ayudan a resolver los problemas del intercambio de secretos y el aprendizaje automático seguro en escenarios como la investigación crediticia conformada por múltiples partes y el intercambio de datos de registros médicos. Aunque estas plataformas son atractivas desde una perspectiva de mercadotecnia, todavía tenemos que ver si son realmente útiles.

    Historia

Resistir?

  • Sugerimos usar GitOps con cierto grado de cuidado, especialmente con lo que respecta a las estrategias de ramificación en repositorios de código. GitOps se puede ver como una forma de implementar infrastructura como código que implica la sincronización y aplicación continua de código de infraestructura desde Git en varios ambientes. Cuando se usa con una estrategia de "rama por ambiente", los cambios se promueven de un ambiente al siguiente mediante la combinación (merge) del código. Si bien tratar el código como única fuente de la verdad es un enfoque sólido, vemos que la estrategia de "rama por entorno" típicamente da pie a que aparezcan diferencias entre ambientes y que configuraciones específicas se propaguen a medida que las operaciones de combinación del código (merge) se vuelven problemáticas o se dejan de hacer. Esto es muy similar a lo que advertimos en el pasado respecto a las ramas de larga duración con GitFlow.

    Historia
  • La explosión de interés en torno a las plataformas de software ha creado mucho valor para las organizaciones, pero el camino hacia la construcción de un modelo de entrega basado en plataformas está plagado de posibles callejones sin salida. Por la emoción que traen los nuevos paradigmas, es común ver un resurgimiento de técnicas antiguas marcadas con la nueva lengua vernácula, lo que hace que sea fácil perder de vista las razones por las que superamos esas técnicas en primer lugar. Para ver un ejemplo de este cambio de marca, revisa nuestro blip sobre los ESBs disfrazados de API Gateways en la edición anterior del Radar. Otro ejemplo que estamos viendo es repetir el enfoque de dividir a los equipos por capa de tecnología, pero llamándolos plataformas. En el contexto de la construcción de una aplicación, era común tener un equipo de front-end separado del equipo que se encarga de la lógica empresarial, separado del equipo de datos, y vemos análogos a ese modelo cuando las organizaciones segregan las capacidades de la plataforma entre los equipos dedicados a una capa de negocio o de datos. Gracias a la Ley de Conway, sabemos que organizar equipos de capacidades de plataforma en torno a capacidades comerciales es un modelo más eficaz, que permite al equipo empoderarse de la capacidad completamente, incluyendo los datos. Esto ayuda a evitar los dolores de cabeza de la gestión de dependencias de equipos de plataforma en capas , con el equipo de front-end esperando al equipo de la lógica de negocio, esperando al equipo de datos para hacer cualquier cosa.

    Historia
  • En la actualidad, las políticas de contraseñas son un estándar por defecto para muchas organizaciones. Sin embargo, seguimos viendo que hay organizaciones que solicitan que las contraseñas incluyan una variedad de símbolos, números, letras mayúsculas y minúsculas, e incluso caracteres especiales. Estos son requisitos ingenuos de complejidad de contraseñas y provocan una falsa sensación de seguridad, ya que los usuarios optarán por contraseñas más inseguras porque cualquier otra cosa es difícil de recordar y escribir. De acuerdo a las recomendaciones del NIST, el factor principal en la fuerza de una contraseña es su longitud, y por lo tanto, los usuarios deberían elegir frases de contraseña largas con un requisito máximo de 64 caracteres (incluyendo espacios). Estas frases de contraseña son más seguras y fáciles de recordar.

    Historia
  • Parece que ciertas organizaciones consideran que la revisión por pares es equivalente a un pull request : creen que la única manera de lograr una revisión por pares del código es a través de un pull request. Hemos visto que este enfoque crea importantes embotellamientos en el equipo y además degrada significativamente la calidad de la retroalimentación cuando los revisores, sobrecargados, comienzan a rechazar las solicitudes casi sin mirar. Aunque se podría argumentar que esta es una forma de demostrar el "cumplimiento normativo" de la revisión de código, en uno de nuestros clientes se dijo que esto era inválido, ya que no había evidencia de que el código había sido leído por alguien antes de su aceptación. Los pull requests son solo una forma de administrar el flujo de trabajo de revisión de código por lo que instamos a las personas a considerar otros enfoques, especialmente cuando es necesario capacitar y transmitir retroalimentación con cuidado.

    Historia
  • Nuestro posicionamiento respecto a "ser ágil antes de hacer ágil" y nuestras opiniones sobre este tema no deberían causar sorpresa; pero desde que SAFe™ (Scaled Agile Framework®), según el informe de Gartner de Mayo de 2019, es el marco de referencia ágil empresarial más considerado y utilizado, y dado que vemos a más y más empresas emprender cambios organizacionales, hemos pensado que es el momento de volver a crear conciencia sobre este tema. Nos hemos encontrado con organizaciones luchando con los procesos sobre-estandarizados y de fases que tiene SAFe. Esos procesos crean fricción en la estructura organizacional y su modelo operativo. También, puede promover la creación de silos en la organización, impidiendo que las plataformas se conviertan en auténticas habilitadoras de las capacidades del negocio. El control "de arriba hacia abajo" genera desperdicio en la cadena de valor y desalienta la creatividad del talento de ingeniería, al tiempo que limita la autonomía y la experimentación en los equipos. En vez de medir el esfuerzo y focalizarse en ceremonias estandarizadas, recomendamos una aproximación y gobernanza más ligeras y enfocadas en la entrega de valor, para así ayudar a eliminar la fricción organizativa, como EDGE, y evaluar la carga cognitiva de los equipos para identificar sus tipos y determinar como deben interactuar mejor entre sí.

    Scaled Agile Framework® y SAFe™ son marcas registradas de Scaled Agile, Inc.

    Historia
  • Idealmente, el pipeline de despliegue y el código que se despliega deben ser propiedad del mismo equipo, especialmente cuando los equipos practican DevOps. Desafortunadamente, todavía vemos organizaciones donde existe una propiedad separada del código y del pipeline , donde este último pertenece al equipo de infraestructura. Esto se traduce en lentitud para aplicar cambios, en la existencia de barreras para las mejoras y en una falta de apropiación por parte del equipo de desarrollo, con menor involucramiento en los despliegues. Una causa de esto puede ser claramente el tener equipos separados; otra puede ser el deseo de conservar procesos y roles que funcionen como controladores y guardianes. Aunque puede haber razones legítimas para usar este enfoque (por ejemplo, por control regulatorio), en general encontramos que es doloroso e inútil.

    Historia
  • Uno de los objetivos finales de una plataforma debe ser reducir los procesos basados en tickets a un mínimo absoluto ya que crean colas en el flujo de valor. Lamentablemente, todavía vemos organizaciones que no presionan con la suficiente fuerza para conseguir esa meta, lo que resulta en modelos operativos de plataforma basados en tickets. Esto es particularmente frustrante cuando los procesos basados en tickets se colocan en frente de plataformas de los proveedores de la nube que tienen características de autoservicio y orientadas a las APIs. Es difícil pero no necesario lograr el autoservicio con muy pocos tickets desde el comienzo, pero debe ser el objetivo.

    La dependencia excesiva en la burocracia y la falta de confianza son las causas de esta resistencia a alejarse de los procesos basados en tickets. Incorporar más verificaciones y alertas automáticas dentro de la plataforma ayuda a cortar el cordón de los procesos de aprobación con tickets. Por ejemplo, se puede dar visibilidad de los costos de ejecución a los equipos y colocar límites automáticos para evitar una explosión accidental de los costos. Recomendamos implementar políticas de seguridad como código y utilizar escáneres de configuración o analizadores como Recommender para ayudar a los equipos a hacer lo correcto.

    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