Ideas de sistemas que casi no funcionan

Ideas de sistemas casi no funcionales

• "Solo hagámoslo pluggable"

  • La idea es que, cuando una implementación no funciona, los desarrolladores puedan agregar una nueva implementación fácilmente. Pero en la mayoría de los casos, las capacidades que ofrece una API no funcionan tan bien como se espera. Para lograr una verdadera capacidad pluggable, la segunda implementación debe diseñarse desde el inicio junto con la primera.

• "Solo agreguemos APIs"

  • Es común agregar APIs para construir una plataforma y atraer desarrolladores. Pero proporcionar APIs requiere un esfuerzo continuo de compatibilidad e interoperabilidad, y ofrecer APIs no significa que automáticamente aparezcan usuarios. Construir una plataforma es un negocio serio, y solo ofrecer APIs difícilmente crea una base económica.

• "Añadamos una abstracción más"

  • En ciencia de la computación se dice que, al agregar otro nivel de indirección, se puede resolver un problema. Pero abstraer demasiado temprano puede traer dificultades para el mantenimiento, la seguridad y la optimización del rendimiento. Una abstracción agregada sin planificación puede hacer que el mantenimiento del código sea más difícil.

• "Hagamos todo asíncrono"

  • La asincronía ha sido durante mucho tiempo un tema de investigación en ciencia de la computación. Los frameworks web la abstraen bien, pero si se intenta gestionar la asincronía directamente fuera de un framework, hay más probabilidades de que aparezcan bugs impredecibles.

• "Agreguemos el control de acceso después"

  • La seguridad de un sistema debe considerarse desde el principio, pero a menudo se agrega después por la velocidad del lanzamiento al mercado. Desde la perspectiva del cliente y del atacante, si el control de acceso no se considera desde el inicio, es probable que el producto deba ser rediseñado.

• "Sincronizemos los datos"

  • La sincronización de datos es un problema muy difícil que plantea muchos retos resolvibles únicamente con experiencia. Construir soluciones basadas en la sincronización de datos es casi siempre indeseable.

• "Hagamos que sea multiplataforma"

  • Hacer algo multiplataforma es similar a construir un sistema operativo, un proveedor de nube o un navegador. Puede funcionar cuando la plataforma es nueva o la aplicación es sencilla, pero con el tiempo se vuelve cada vez más complicado.

• "Permitemos salir a nativo"

  • Cuando lo multiplataforma es limitado, suele hacerse común que se pueda salir a funcionalidades nativas. Sin embargo, este enfoque puede entrar en conflicto con el estado que mantiene el framework y suele fallar en 9 de cada 10 casos.

• Conclusión

  • Estas aproximaciones no fallan siempre, pero en la mayoría de los casos existe una forma mejor. Es importante resolver los problemas de acuerdo con principios básicos y evitar patrones de software con alta probabilidad de fallo.

[ndrgrd]

En el caso de los plugins, lo más importante es diseñar la interfaz filtrando al máximo solo las acciones esenciales.
Si solo tomas la estructura general del código actual para crear la interfaz, inevitablemente se convierte en una interfaz innecesaria atada a esa implementación; y lamentablemente, eso sucede más de lo que debería...

[GN⁺]

Comentarios de Hacker News

• Las DSL y las API suelen funcionar bien. Incluso un motor de inferencia como TensorFlow puede verse como una DSL o como una API que envuelve una DSL

  • SQL, lenguajes de shader y BPF también pueden verse como ejemplos similares
  • El enfoque de "solo agregar una API" puede no tener éxito. Hay que abordarlo con el mismo cuidado y minuciosidad que cuando se implementa una UI

• Las DSL a veces funcionan muy bien. Se puede consultar jOOQ.org

• Elastic Load Balancer es un bucle de control que responde a la carga de trabajo. Es una especie de commodity

• La escasez de recursos es generalizada en la mayoría de las industrias. Puedes ver erikbern.com y "Goal: Process of Ongoing Improvement"

• La detección de anomalías no es un problema de los sistemas distribuidos. Pero quienes la padecen pueden sentirse convencidos de que la necesitan

  • El algoritmo Isolation Forest a veces parece milagroso. En 2018, usando embeddings basados en CNN sobre texto se obtuvieron buenos resultados

• Aquí, el término "casi" no funciona bien. Es simple pesimismo y cinismo

• Muchas personas buscan una función de decisión sutil para las excepciones. Pero en la práctica es simple: si lo hago yo, funciona; si lo hizo la persona anterior, no funciona

• El "Domain Driven Design" es una receta para el desastre

  • Esto puede no ser un problema en un negocio pequeño, pero en uno que ya es exitoso o está creciendo puede convertirse rápidamente en una mala decisión
  • En cambio, diseña alrededor de capas funcionales y conserva la lógica de negocio tanto como sea posible en filas de base de datos y flujos de usuario

• Un bucle de control de respuesta a carga es un componente básico y necesario. Se utiliza en muchos sistemas

• He trabajado en proyectos que usan múltiples DSL, caché P2P y paralelismo híbrido, y la mayoría fueron exitosos

  • El caché P2P no funcionó tan bien porque no era necesario
  • Es complejo, pero esa complejidad ofrece capacidades difíciles de lograr de otra manera

• El enfoque de "simplemente sincronizar datos" puede causar problemas

  • Muchos sistemas se diseñan para "internet-scale", pero en la práctica están por debajo de esa escala
  • Esos equipos son ingenuos, o en el peor de los casos gastan dinero con gerentes que no son ingenieros para resolver el problema

• He ejecutado varias ideas con éxito. Por eso suena un poco raro