Colaborador de Madison Friedman
Como gerente de producto, creo firmemente que puede resolver cualquier problema con el producto y el proceso correctos, incluso uno tan retorcido como la hidra de múltiples cabezas que es la sobrecarga de microservicio.
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 retos a los que se 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 un O’Reilly encuesta de más de 1500 encuestadosmá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 nuevas empresas, como LaunchDarkly, planean construir su infraestructura utilizando microservicios, pero recurrieron a un monolito una vez que se dieron cuenta del alto costo de los gastos generales.
“Pasábamos más tiempo construyendo y operando un sistema para sistemas distribuidos de manera efectiva en lugar de construir nuestros propios servicios, por lo que retrocedimos con fuerza”, 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 dedicábamos tanto tiempo a depurar las cosas básicas que no estábamos creando nuestro propio servicio”.
Como resultado, es más común que las empresas comiencen con un monolito y pasen a los 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 moviéndose a una arquitectura de microservicio.
Los equipos pueden tomar diferentes rutas para llegar a una arquitectura de microservicio, pero tienden a enfrentar una serie de desafíos comunes una vez que llegan allí.
Las grandes empresas con monolitos establecidos están ansiosas por pasar a los microservicios, pero los costos son altos y la transición puede llevar años. La infraestructura de la plataforma de Atlassian 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 atrapadas en esta transición. Sin embargo, una combinación de una estrategia sólida y de arriba hacia abajo combinada con el soporte del equipo de desarrollo de abajo hacia arriba puede ayudar a las empresas, como Freddie Mac, a lograr un progreso sustancial.
Algunas empresas emergentes, como Instacart, primero cambiaron a un monolito modular que permite que el código resida en un solo repositorio mientras comienzan el proceso de distribución de la propiedad de las funciones de código discreto a los equipos relevantes. Esto les permite mitigar los gastos generales asociados con una arquitectura de microservicio al equilibrar la visibilidad de tener un repositorio centralizado y una canalización de versiones con la flexibilidad de la propiedad discreta sobre partes del código base.
¿Qué desafíos enfrentan los equipos?
Los equipos pueden tomar diferentes rutas para llegar a una arquitectura de microservicio, pero tienden a enfrentar una serie de desafíos comunes una vez que llegan allí. John Laban, director ejecutivo y cofundador de OpsLevel, que ayuda a los equipos a crear y administrar microservicios, nos dijo que “con una arquitectura distribuida o basada en microservicios, sus equipos se benefician de poder moverse independientemente unos de otros, pero hay algunas trampas a tener en cuenta”. por.”
De hecho, el vinculado Carta 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 para un servicio puede hacer que los equipos generen gastos generales innecesarios al crear demasiados servicios similares o distribuir 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 estrechas y, cuando se completó la descomposición, les quedaban más de 4000 microservicios para administrar. Luego tuvieron que retroceder y consolidarse en un número más manejable.
Definir 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 repartida entre diferentes equipos, la falta de herramientas estandarizadas puede crear dolores de cabeza de observabilidad. Es un desafío para los equipos obtener una vista de panel único con demasiados sistemas y servicios que interactúan diferentes que abarcan toda la arquitectura.
Source link