Defendiendo una arquitectura simple (2022)

• Wave es una empresa valuada en $1.7B (2.3 billones de wones) con 70 ingenieros (ofrece servicios de banca móvil para África)
• Tiene una arquitectura estándar de app CRUD monolítica en Python basada en Postgres
• Al comenzar con una arquitectura simple y resolver problemas minimizando la complejidad, los ingenieros pudieron enfocarse en el trabajo que aporta valor a los usuarios
• Stackoverflow creció con éxito escalando un monolito hasta ser adquirida por 1.8 mil millones de dólares

A pesar de la eficiencia de una arquitectura simple, a la mayoría de los medios les gustan las arquitecturas complejas

• En las conferencias técnicas hay muchas charlas sobre arquitecturas complejas basadas en microservicios, pero ninguna sobre monolitos simples
• Muchas empresas imitan tecnologías complejas aunque sus aplicaciones sean pequeñas, y con eso ganan popularidad en conferencias y en HN
• La arquitectura que usamos es tan simple que ni siquiera hace falta dibujar un diagrama de arquitectura

Cómo mantener la simplicidad

• Wave usa Python síncrono, lo que significa que el proceso del servidor se bloquea mientras espera I/O
• Probaron frameworks asíncronos como Eventlet, pero tenía demasiados bugs y concluyeron que el costo no valía el dolor operativo
• En lugar de aumentar la complejidad, separan en colas los trabajos de larga duración
• Para cumplir con regulaciones de residencia de datos, en algunos países deben operar centros de datos on-premise
  • Senegal/Costa de Marfil estaban en la nube, pero Uganda y otros países requieren on-premise por regulación
  • En esos casos, una arquitectura simple es mucho más sencilla que una compleja

Construir en vez de comprar

• Como el equipo era pequeño, al principio preferían comprar software, pero cuando no podían resolver bugs críticos desarrollaban sus propias herramientas
• Construir herramientas internas es una complejidad que no quieren asumir, pero en algunas categorías de producto no encontraron proveedores adecuados incluso tras una investigación bastante amplia
• A veces es necesario desarrollar herramientas propias y mantener expertise interna incluso fuera de la competencia principal

Decisiones que están reconsiderando

• Están reconsiderando elecciones tecnológicas como RabbitMQ, Celery, SQLAlchemy y Python, porque aumentan la complejidad o la carga de mantenimiento
• Si iniciaran un nuevo codebase, evaluarían estas decisiones con mucho cuidado

Decisiones con las que están satisfechos

• Están satisfechos con decisiones como GraphQL, protocolos de transporte personalizados y Kubernetes
• GraphQL tiene ventajas como autodocumentación, generación de código y el explorador interactivo GraphiQL
• Consideran que, al usar GraphQL, las ventajas superan las desventajas
  • Ventajas
    • Autodocumentación sobre los tipos exactos de retorno
    • Los clientes son más seguros gracias a la generación de código con tipos de retorno exactos
    • Mayor productividad con el explorador interactivo GraphiQL
    • Varias apps (app de usuario, app de soporte, app de agentes de Wave, etc.) pueden compartir en gran medida una sola API, reduciendo la complejidad
    • Con un lenguaje de consultas componible, los clientes pueden obtener exactamente los datos necesarios en un solo viaje de ida y vuelta del paquete sin tener que construir muchos endpoints de propósito específico
    • Elimina el bikeshedding sobre lo que debería considerarse una API RESTful
  • Desventajas
    • Las librerías de GraphQL no eran muy buenas cuando adoptaron GraphQL
    • La codificación GQL por defecto es redundante, y como muchos clientes usan poco ancho de banda, prestan mucha atención a las limitaciones de tamaño
• Kubernetes se usa para cumplir con los requisitos de operar centros de datos por país

Conclusión

• Al mantener la arquitectura de la aplicación lo más simple posible, pueden gastar el presupuesto de complejidad (y de personal) en los lugares donde esa complejidad sí ayuda al negocio
• La idea de hacer las cosas tan simples como sea posible salvo que exista una razón poderosa para agregar complejidad les permitió construir un negocio bastante grande con pocos ingenieros, a pesar de operar en el negocio financiero africano, que por lo general se considera difícil

[secret3056]

"comprar en vez de construir" me parece que en realidad debería ser "construir en vez de comprar".

Another area is with software we’ve had to build (instead of buy).

[xguru]

Ah, al intentar enfatizarlo, el título terminó quedando raro. Ya lo corregí. Gracias.

[savvykang]

¿Será que las modas cambian según el ciclo económico? Independientemente de las tendencias, empezar con un monolito es más conveniente para reducir costos fijos y facilitar el mantenimiento.

[aer0700]

Una arquitectura fácil de entender también es fácil de mantener.

[mhj5730]

En mi opinión, para cualquier servicio conviene empezar con un monolito. Si desde el principio te metes con MSA, es desperdiciar dinero.

[dhlee0305]

"A medida que aumenta la complejidad, también aumentan los costos (dinero, personas, tiempo...)."
"No intentes resolver con una arquitectura compleja un problema que puede resolverse con una arquitectura simple."

[xguru]

Opiniones en Hacker News

• Consejos de ingeniería sobre microservicios

  • Los microservicios no son una estrategia para mejorar el rendimiento, sino una estrategia potencial para reducir costos y coordinar la ingeniería.
  • No hay una gran diferencia entre una aplicación monolítica escalable horizontalmente y los microservicios, excepto cuando se quiere reducir solo una función específica.
  • En una app monolítica, no es posible reducir solo una parte de la aplicación.
  • El ahorro de costos empieza a gran escala y requiere al menos 3 réplicas.
  • En la mayoría de las empresas, el beneficio real está en la coordinación de ingeniería.
  • En un monolito con un solo repositorio, un equipo puede ser dueño y administrarlo, pero en un monolito compartido nadie es realmente dueño y se vuelve difícil de gestionar.

• Charlas sobre microservicios

  • En conferencias técnicas generales hubo varias presentaciones sobre la complejidad y los efectos secundarios de la arquitectura de microservicios, pero no hubo charlas sobre construir monolitos simples.
  • Fue especialmente memorable una charla de David Schmitz sobre consejos para fracasar con microservicios, y su estilo humorístico de presentación resulta muy atractivo.

• Sesgo cognitivo y simplicidad

  • La gente suele enfocarse en agregar cosas y pasa por alto soluciones simples.
  • Un estudio mostró que, en estructuras de LEGO, resolver un problema quitando piezas en vez de agregarlas puede ser una mejor solución.

• Sobreingeniería y falta de experiencia

  • La arquitectura debe ser "lo suficientemente simple y tan compleja como sea necesario", pero lograr eso requiere experiencia.
  • La industria de TI tiende a carecer de experiencia, y la experiencia toma tiempo.
  • Ingenieros y gerentes con poca experiencia suelen usar tecnologías o métricas innecesarias.

• Empresas que valoran el equilibrio entre trabajo y vida personal

  • Se busca una empresa donde uno pueda enfocarse en mejorar el producto y dedicar el resto del tiempo a la vida personal.

• Experiencia personal con Dan Luu

  • Dan Luu es generoso al interactuar con fans de su blog y tiene experiencia en la frontera entre software y hardware.
  • Comparte sus ideas y conocimientos con mucha generosidad, y aprender de él es una experiencia muy agradable.

• Importancia de una arquitectura simple

  • En la mayoría de los casos, la arquitectura necesaria consiste en componentes básicos como un balanceador de carga con soporte SSL, varios servidores de aplicaciones, una base de datos con sharding y una cola de mensajes.

• Arquitectura y estructura social del equipo de ingeniería

  • La arquitectura debe reflejar la estructura social del equipo de ingeniería; si no se toma esto en cuenta, pueden surgir confusión e ineficiencias.
  • Los repositorios monolíticos a gran escala y una arquitectura simple pueden ser difíciles de gestionar, y empresas como Google y Meta también desarrollan muchas herramientas internamente.
  • La arquitectura puede apoyar o entorpecer la colaboración entre equipos, por lo que el liderazgo técnico debe tomarlo en cuenta.

• Preferencia por una arquitectura simple

  • Una arquitectura simple y un monolito suelen ser adecuados en la mayoría de los casos, pero hay que cuidar que no aparezcan problemas por IO sincrónico.
  • Los bugs de integridad de datos son un problema importante que debe evitarse en sistemas financieros.

[dangyup]

¿Podrían compartir el enlace de la charla sobre los consejos de David Schmitz acerca de los fracasos de los microservicios?

[xguru]

Es https://www.youtube.com/watch?v=r8mtXJh3hzM