Esta es una breve digresión en la serie actual de artículos sobre cómo evitar la introducción de servicios para varias entidades. Una conversación interesante en la cena me llevó a pensar que decidí escribir.

Ley de Amdahl

En 1967, Gene Amdahl argumentó en contra de la computación paralela. Argumentó que el crecimiento de la productividad es limitado porque solo una parte de la tarea puede ser paralela. El tamaño del resto de la "parte secuencial" difiere en diferentes tareas, pero siempre está ahí. Este argumento se conoció como la ley de Amdal.

Si crea un gráfico de "aceleración" de la tarea en función del número de procesadores paralelos asignados a ella, verá lo siguiente:


Este es un gráfico asintótico para un fragmento que no puede ser paralelo (la "parte secuencial"), por lo tanto, existe un límite superior para la aceleración máxima

De Amdal a USL

Lo interesante de la ley de Amdal es que en 1969 había muy pocos sistemas multiprocesadores. La fórmula se basa en otro principio: si la parte secuencial de la tarea es igual a cero, entonces esta no es una tarea, sino varias.

Neil Gunther amplió la ley de Amdahl sobre la base de observaciones de las mediciones de rendimiento de muchas máquinas y desarrolló la Ley de Escalabilidad Universal (USL). Utiliza dos parámetros: uno para "competencia" (que es similar a la parte secuencial), y el segundo para "inconsistencia" (incoherencia). La inconsistencia está relacionada con el tiempo dedicado a restaurar la consistencia, es decir, una visión general del mundo de los diferentes procesadores.

En una CPU, la sobrecarga de negociación se produce debido al almacenamiento en caché. Cuando un núcleo modifica una línea de caché, le dice a los otros núcleos que recuperen esta línea de la caché. Si todos necesitan la misma línea, pasan tiempo cargándola desde la memoria principal. (Esta es una descripción ligeramente simplificada ... pero en una redacción más precisa, todavía existe el costo de la negociación).

Todos los nodos de la base de datos incurren en costos de coordinación debido a algoritmos coincidentes y al guardar la secuencia de datos. La multa se paga al cambiar datos (como en el caso de bases de datos transaccionales) o al leer datos en el caso de repositorios finalmente acordados.

Efecto USL

Si crea un gráfico de USL según la cantidad de procesadores, aparecerá una línea verde:


La línea púrpura indica que la ley de Amdahl predeciría

Observe que la línea verde alcanza un pico y luego disminuye. Esto significa que hay un cierto número de nodos en los que el rendimiento máximo. Agregue más procesadores y el rendimiento se reduce . Vi esto en pruebas de estrés real.

La gente a menudo quiere aumentar el número de procesadores y aumentar la productividad. Hay dos formas de hacer esto:

1. Reduce la parte secuencial
2. Reduce los costos de aprobación

USL en grupos humanos?

Probemos la analogía. Si la "tarea" computacional es un proyecto, entonces podemos representar el número de personas en el proyecto como el número de "procesadores" que realizan el trabajo.

En este caso, la parte secuencial es un trabajo que solo se puede hacer secuencialmente, paso a paso. Este puede ser un tema para un artículo futuro, pero ahora no estamos interesados ​​en la esencia de la parte secuencial.

Parece que vemos una analogía directa con los costos de la reconciliación. Independientemente del tiempo que los miembros del equipo dediquen a restaurar una visión común del mundo, los costos de la alineación están presentes.

Para cinco personas en una habitación, estos costos son mínimos. Dibujo de cinco minutos con un marcador en la pizarra una vez por semana más o menos.

Para un equipo grande en varias zonas horarias, la multa puede crecer y formalizarse. Documentos y tutoriales. Presentaciones para el equipo, etc.

En algunas arquitecturas, la alineación no es tan importante. Imagine un equipo con empleados en tres continentes, pero cada uno está trabajando en un servicio que utiliza datos en un formato estrictamente definido y crea datos en un formato estrictamente definido. No necesitan coherencia con respecto a los cambios en los procesos, pero sí necesitan coherencia con respecto a cualquier cambio en los formatos.

A veces, las herramientas y los idiomas pueden cambiar los costos de la reconciliación. Uno de los argumentos a favor de la escritura estática es que ayuda a interactuar en un equipo. En esencia, los tipos de código son un mecanismo para traducir los cambios en un modelo del mundo. En un lenguaje de tipo dinámico, necesitamos artefactos secundarios (pruebas unitarias o mensajes de chat), o necesitamos crear límites donde algunos departamentos rara vez restablecen la coherencia con otros.

Todos estos métodos están destinados a reducir los costos de coordinación. Recuerde que el escalado excesivo causa una disminución en el rendimiento. Entonces, si tiene altos costos de coordinación y demasiada gente, entonces el equipo en su conjunto trabaja más lentamente. Vi equipos donde parecía que podíamos cortar a la mitad de la gente y trabajar el doble de rápido. Los costos de USL y de reconciliación ahora ayudan a entender por qué sucede esto: es más que solo eliminar basura. Se trata de reducir la sobrecarga de intercambiar modelos mentales.

En The Loop of Fear, me referí a las bases de código donde los desarrolladores sabían sobre la necesidad de cambios a gran escala, pero tenían miedo de hacer daño accidentalmente. Esto significa que el equipo sobreinflado aún no ha alcanzado un consenso. Parece muy difícil conciliar después de la pérdida. Esto significa que es imposible ignorar los costos de coordinación.

USL y microservicios

En mi opinión, USL explica el interés en los microservicios. Al dividir un sistema grande en partes cada vez más pequeñas que se implementan de forma independiente, se reduce la parte secuencial del trabajo. En un sistema grande con una gran cantidad de participantes, la parte secuencial depende de la cantidad de esfuerzo para integrar, probar e implementar. La ventaja de los microservicios es que no necesitan trabajo de integración, pruebas de integración o retraso en la implementación sincronizada.

Pero el costo de igualar significa que es posible que no obtenga la aceleración deseada. Quizás la analogía es un poco tensa aquí, pero creo que es posible considerar los cambios de interfaz entre microservicios que requieren la reconciliación entre los equipos. Si esto es demasiado, no obtendrá los beneficios deseados de los microservicios.

¿Qué hacer al respecto?

Mi sugerencia: mire la arquitectura, el lenguaje, las herramientas y el equipo utilizado. Piense en dónde se pierde tiempo para la reconciliación cuando las personas realizan cambios en el modelo sistémico del mundo.

Busca huecos . Brechas entre los límites internos del sistema y divisiones dentro del equipo.

Use el entorno para comunicar los cambios, de modo que el proceso de reconciliación tenga lugar para todos, no individualmente.

Mira las comunicaciones de tu equipo. ¿Cuánto tiempo y esfuerzo se necesita para garantizar la coherencia? ¿Quizás hacer pequeños cambios y reducir la necesidad de hacerlo?