Como producto gerente, soy un verdadero creyente de que puede resolver cualquier problema con el producto y el proceso adecuados, incluso uno tan retorcido como la hidra de múltiples cabezas que es el microservicio por encima de la cabeza.
Trabajar para Vertex Ventures US este verano fue mi oportunidad de poner esto a prueba. Después de entrevistar a más de 30 expertos de la industria de un conjunto diverso de empresas (Facebook, Fannie Mae, Confluent, Salesforce y más) y organizar un seminario web con los cofundadores de PagerDuty, LaunchDarkly y OpsLevel, pudimos responder tres preguntas principales:
- ¿Cómo adoptan los equipos los microservicios?
- ¿Cuáles son los principales desafíos que enfrentan las organizaciones?
- ¿Qué estrategias, procesos y herramientas utilizan las empresas para superar estos desafíos?
¿Cómo adoptan los equipos los microservicios?
De las docenas de empresas con las que hablamos, solo dos aún no habían comenzado su viaje hacia los microservicios, pero ambas lo estaban considerando activamente. Las tendencias de la industria también reflejan esto. En una encuesta de O’Reilly a más de 1500 encuestados, más del 75% había comenzado a adoptar microservicios.
Es raro que las empresas comiencen a construir con microservicios desde cero. De las empresas con las que hablamos, solo una lo había hecho. Algunas startups, como LaunchDarkly, planean construir su infraestructura utilizando microservicios, pero se volvieron monolitos una vez que se dieron cuenta del alto costo de los gastos generales.
“Pasábamos más tiempo construyendo y operando de manera efectiva un sistema para sistemas distribuidos en lugar de construir nuestros propios servicios, por lo que retrocedimos mucho”, dijo John Kodumal, CTO y cofundador de LaunchDarkly.
“Como ejemplo, las cosas que estábamos tratando de hacer en la mesosfera eran imposibles”, dijo. “No pudimos hacer ningún registro. Las implementaciones sin tiempo de inactividad eran imposibles. Había tantos errores en la infraestructura y pasábamos tanto tiempo depurando las cosas básicas que no estábamos construyendo nuestro propio servicio “.
Como resultado, es más común que las empresas comiencen con un monolito y pasen a microservicios para escalar su infraestructura con su organización. Una vez que una empresa llega a ~ 30 desarrolladores, la mayoría comienza a descentralizar el control pasando a una arquitectura de microservicio.
Los equipos pueden tomar diferentes rutas para llegar a una arquitectura de microservicio, pero tienden a enfrentar un conjunto común de desafíos una vez que llegan allí.
Las grandes empresas con monolitos establecidos están deseosas de pasar a los microservicios, pero los costos son altos y la transición puede llevar años. De Atlassian La infraestructura de la plataforma está en microservicios, pero los monolitos heredados en Jira y Confluence persisten a pesar de los esfuerzos de descomposición en curso. Las grandes empresas a menudo se quedan estancadas en esta transición. Sin embargo, una combinación de una estrategia sólida de arriba hacia abajo combinada con el apoyo del equipo de desarrollo de abajo hacia arriba puede ayudar a empresas como Freddie Mac a lograr un progreso sustancial.
Algunas startups, como Instacart, primero cambiaron a un monolito modular que permite que el código resida en un solo repositorio mientras comienza el proceso de distribución de la propiedad de funciones de código discreto a los equipos relevantes. Esto les permite mitigar la sobrecarga asociada con una arquitectura de microservicio al equilibrar la visibilidad de tener un repositorio centralizado y una canalización de lanzamiento con la flexibilidad de la propiedad discreta sobre porciones de la base de código.
¿Qué desafíos enfrentan los equipos?
Los equipos pueden tomar diferentes rutas para llegar a una arquitectura de microservicio, pero tienden a enfrentar un conjunto común de desafíos una vez que llegan allí. John Laban, CEO y cofundador de OpsLevel, que ayuda a los equipos a construir y administrar microservicios, nos dijo que “con una arquitectura distribuida o basada en microservicios, sus equipos se benefician de poder moverse de forma independiente unos de otros, pero hay algunas trampas a tener en cuenta para.”
De hecho, el gráfico vinculado de O’Reilly muestra cómo los 10 principales desafíos que enfrentan las organizaciones al adoptar microservicios son compartidos por más del 25% de los encuestados. Si bien discutimos algunos de los bloqueadores de adopción anteriores, los comentarios de nuestras entrevistas destacaron problemas relacionados con la gestión de la complejidad.
La falta de una definición coherente de un servicio puede hacer que los equipos generen gastos generales innecesarios al crear demasiados servicios similares o difundir servicios relacionados entre diferentes grupos. Una empresa con la que hablamos tomó el camino de descomponer su monolito y lo llevó demasiado lejos. Sus definiciones de servicio eran demasiado limitadas y, cuando se completó la descomposición, les quedaban más de 4000 microservicios para administrar. Luego tuvieron que retroceder y consolidarse hasta un número más manejable.
La definición de demasiados servicios crea silos organizativos y técnicos innecesarios al tiempo que aumenta la complejidad y los gastos generales. El registro y la supervisión deben estar presentes en cada servicio, pero con la propiedad distribuida entre diferentes equipos, la falta de herramientas estandarizadas puede crear dolores de cabeza por la observabilidad. Es un desafío para los equipos obtener una vista de un solo panel de vidrio con demasiados sistemas y servicios interactivos diferentes que abarcan toda la arquitectura.
Source link