¿Cuáles son algunos buenos libros sobre arquitectura de servidor web?

Bueno, depende de lo que entiendas por arquitectura de servidor web. La mayoría de las cosas que las personas hacen hoy están caídas, todavía locas. Personalmente, veo a cada persona llamada dev-ops como una declaración de fracaso total del departamento de desarrollo. Es un testimonio de que algo salió mal.

Esto es parcialmente cierto para la mayoría de las cosas de Docker que ocurren junto con los micro servicios. Totalmente loco. A menudo no tiene sentido y desacopla la operación del software y el desarrollo cuando el objetivo final del desarrollo del software es la operación automática sin interrupciones.

Básicamente, la arquitectura del servidor web puede verse como una arquitectura empresarial de un tipo especial. Aquí puede leer una lectura obligada para cada desarrollador de software: Fowler – Patrones de arquitectura de aplicaciones empresariales. Esto le da una comprensión real de lo que debería ser la arquitectura.

Ahora piense por qué un dev-ops es un desarrollador desperdiciado (además de algunos de los llamados dev-ops apenas califican como programadores pero solos como desarrolladores). He visto equipos donde necesitan la misma cantidad de operaciones de desarrollo para mantener las cosas en funcionamiento que la cantidad de personas responsables de esta situación.

Si tienes la oportunidad, únete a este habbit. Cada semana revisa el canal de las operaciones de desarrollo, revisa de qué están hablando o pregunta directamente a uno. Pregunta por los problemas que resuelven. Casi siempre puede encontrar una solución automática a lo que hicieron a mano o simplemente puede diseñar todo el aspecto del software.

Una cosa que pone a los desarrolladores en estado de shock y asombro es básicamente un pequeño proceso de inicio que inicia automáticamente toda la infraestructura requerida para la aplicación. Esto y, junto con la simple regla general, que una falla (potencial) desencadena instantáneamente un reinicio (en lugar de tratar de manejar un problema de forma inteligente) corta como el 90% de las cosas que un desarrollador tiene que lidiar a diario .

El resto del 10% se escapa utilizando un tablero de mensajes / canal para que todo el sistema se comunique (resolviendo el problema de membresía y reporte de errores de una manera legible para los humanos).