1. Velocidad vs. uniformidad

El primer obstáculo con el que las grandes empresas se topan con frecuencia al adoptar microservicios es equilibrar la independencia con el control. Hay una tendencia a decir: “Haz lo que es correcto para ti”, y luego haz un seguimiento preguntando “¿Cuántos proveedores y habilidades deberíamos administrar?” Esto puede suceder porque las organizaciones grandes tienden a ser preceptivas por defecto. Si bien esto no es necesariamente algo malo, relega a los microservicios verdaderos al ámbito de la discusión teórica.

En última instancia, no hay una bala de plata. Pero cuando hay dudas, a menudo es beneficioso favorecer la velocidad sobre la uniformidad, dentro de límites. (¿Realmente necesita tres bases de datos NoSQL? No es probable). Si sus microservicios están envueltos con API limpias (consulte el tercer punto, a continuación), una mejor uniformidad siempre puede venir más tarde. Después de todo, con API limpias, las implementaciones pueden cambiar.

2. El temido requisito de DevOps

Otro desafío organizacional que las grandes empresas a menudo tienen que superar es la resistencia a las habilidades y deberes adicionales que los microservicios imponen a los equipos, a saber, el temido requisito de DevOps.

Si el Equipo A construye un microservicio, entonces es realmente su trabajo mantenerlo en funcionamiento. Desafortunadamente, DevOps no es una habilidad adquirida. Ni siquiera es una habilidad aprendida, por así decirlo. A diferencia de los lenguajes de programación, por ejemplo, DevOps es una habilidad de “experiencia”, una que solo viene con el paso del tiempo.

Dos principios prácticos de diseño pueden ayudarlo a prevalecer: (a) invertir en herramientas que simplifiquen las operaciones, y (b) para cosas realmente difíciles (como administrar una base de datos NoSQL como Cassandra), tener un equipo separado que pueda enfocarse en esas habilidades específicamente .

3. Contratos caóticos

Un tercer problema común se relaciona con la implementación. Diseñar y mantener un contrato con los equipos descendentes es muy diferente a acercarse al otro equipo y analizar las características especiales que necesitan.

En el primer escenario, tiene un contrato bien elegido (que se manifiesta en una API bien documentada) que no se esfuerza hacia los intereses especiales del equipo downstream “más fuerte”. El contrato es por lo tanto 1: N, y con N equipos, hay O (N) contratos. En el segundo, terminas recibiendo extensiones que son personalizadas y frágiles. El contrato es 1: 1, y por lo tanto, con N equipos, obtenemos O (N ^ 2) contratos. Para una organización con 1,000 servicios, ¡esa es una diferencia entre 1,000 y 1,000,000 de interfaces!

Si bien la teoría es perfectamente clara (“menos es mejor”), la dinámica organizacional puede evitar su aplicación. Las empresas que enfrentan este problema deberían explorar un enfoque “abierto a todos” para las API.

Todas las API y su documentación deben publicarse, y todas las interacciones entre microservicios deben pasar por un proceso de registro. Siempre que no haya contratos paralelos, tener demasiadas API no debería ser un problema; la poda periódica basada en la observación del uso puede evitar que cualquier problema que surja se salga de control. La apertura con revisiones periódicas debe ser todo lo que necesita.