Video: Un ejemplo de microservicios #CafeConRivas (Noviembre 2024)
El panorama del software empresarial está plagado de tecnologías bulliciosas. Hemos escrito sobre muchos de ellos, ya sea blockchain, desarrollo de código bajo u otras tendencias emergentes que están cambiando la forma en que trabajamos. Una nueva palabra de moda que quizás no haya escuchado antes es "microservicios".
Eso es por diseño. Los microservicios son una forma diferente de diseñar software basado en un conjunto de componentes modulares entrelazados en lugar de la idea tradicional de un "monolito", una aplicación compuesta por una montaña de código cada vez mayor. Las aplicaciones basadas en microservicios no se ven diferentes del lado de la interfaz de usuario (UI), ya sea en una aplicación de centro de datos compleja o en una aplicación web o móvil alojada en una infraestructura de nube escalable.
La razón por la que las empresas deberían preocuparse por los microservicios es que, detrás de escena, la arquitectura puede ayudar a sus equipos de desarrollo y TI a trabajar e innovar más rápido, administrar la infraestructura y reducir el costo y la complejidad de agregar nuevas características y funcionalidades a una aplicación. Al Hilwa, director del programa de investigación de software de desarrollo de aplicaciones en IDC, explicó cómo ofrecería microservicios a un ejecutivo, teniendo en cuenta los desafíos culturales y tecnológicos.
"Al construir nuevos sistemas, probablemente el punto clave es reconocer que un pequeño equipo debe construir un microservicio único", dijo Hilwa. "En segundo lugar, la tolerancia de la diversidad en los lenguajes de programación y los flujos de trabajo de los desarrolladores a menudo está implícita en la naturaleza independiente de una cultura general de microservicios. El argumento principal para un ejecutivo es construir software de forma incremental usando equipos pequeños, cada uno con un módulo coherente con un publicado interfaz. La ventaja es que los módulos independientes pueden evolucionar a un ritmo mucho más rápido independientemente siempre que las API publicadas se gestionen de forma organizada ".
¿Qué son realmente los microservicios?
Hilwa escribió un informe de IDC de 2015 titulado "La aparición de microservicios como un nuevo enfoque arquitectónico para construir nuevos sistemas de software". En el informe, define los microservicios como una arquitectura de software granular donde los componentes de la aplicación se diseñan y evolucionan de forma independiente para cumplir con los requisitos de interoperabilidad definidos por la API (es decir, vinculados a la aplicación en su conjunto). Sin embargo, los microservicios no existen en el vacío. Una nueva arquitectura requiere un fuerte soporte organizacional y un cambio en la cultura de TI.
Los microservicios tampoco están definidos por ninguna tecnología específica, sino a medida que la evolución del concepto de arquitectura orientada a servicios (SOA) se ha incrementado por la llegada de contenedores y el aumento de la automatización a través de enfoques de desarrollo como la entrega continua (CD) y la integración continua (CI).
"Las organizaciones que usan microservicios en la actualidad están motivadas por el deseo de un ritmo más rápido de evolución del servicio", dijo Hilwa. "Por lo tanto, en la mayoría de estos casos, los microservicios están utilizando la automatización de CI / CD en gran medida. Sin embargo, el ritmo de implementación real puede ser diferente entre los servicios. Creo que la clave es echar un buen vistazo a la cultura interna y ser seguro de que está dispuesto a tolerar una mayor descentralización y diversidad en la pila de tecnología ".
Por "cultura interna", Hilwa se refiere en gran medida a DevOps, una filosofía que combina el desarrollo de software, las operaciones de TI y el control de calidad (QA) en un único flujo de trabajo colaborativo. El inicio del software DevOps HashiCorp y sus fundadores han sido durante mucho tiempo defensores de los microservicios. La compañía, que recientemente obtuvo una ronda de financiación de la Serie B de $ 24 millones, cuenta con compañías como Cisco, DigitalOcean, Mozilla y Stripe entre sus usuarios de código abierto y clientes empresariales.
Los microservicios son fundamentales para la forma en que HashiCorp aborda el desarrollo de la infraestructura de DevOps y los flujos de trabajo de las aplicaciones a través de sus populares herramientas de código abierto y el creciente conjunto de productos empresariales. Armon Dadgar, CTO y cofundador de HashiCorp, desglosó la diferencia entre monolitos y microservicios mediante una analogía simple: Amazon y eBay.
"Piense en Amazon y eBay como aplicaciones únicas. Desde la perspectiva del usuario final, se ven similares pero, detrás de escena, las compañías adoptaron enfoques opuestos en la forma en que construyeron y diseñaron sus aplicaciones", dijo Dadgar. "Amazon desde el principio ha sido un paquete de microservicios; actúa como una sola aplicación. Pero si toma la búsqueda, el catálogo de productos, el carrito de compras, las facturas, los flujos de pedidos y divide esas funciones, las dos aplicaciones se ejecutan en diferentes máquinas ".
La analogía de Amazon también se extiende a cómo Amazon está estructurado. Dadgar explica que los enfoques tecnológicos, como los microservicios, son herramientas para respaldar el movimiento más amplio del proceso hacia DevOps. La "Regla de dos pizzas" de Jeff Bezos funciona para que solo entre cinco y ocho personas formen parte de un equipo de Amazon. Si el equipo se hace más grande, se divide en dos.
La jerarquía organizacional de Amazon comienza a mapearse hacia lo que Dadgar describió como una "descomposición de la funcionalidad". Separados tanto a nivel de arquitectura organizacional como modular, cada equipo tiene la capacidad de desarrollar y experimentar más libremente, sin la necesidad de coordinar cada cambio, todo mientras funciona como parte de una sola aplicación cohesiva.
"eBay adoptó el enfoque monolítico; construyeron todo eBay como una larga línea de 50 millones de aplicaciones de código", dijo Dadgar. "El enfoque de microservicios es más doloroso al principio porque los problemas de modularidad e interoperabilidad son los que no existen en un monolito. Pero las cosas comienzan a romperse cuando la aplicación crece demasiado. En un monolito, no hay descomposición.
"Piense en cientos o miles de desarrolladores que colaboran en una única base de código e intentan coordinarse. Un equipo de control de calidad que agregue funcionalidad en un lado de la aplicación podría romper algo en el otro lado porque no hay una separación clara de roles y responsabilidades. si comienza a necesitar una coordinación cada vez mayor entre los gerentes de proyecto y un proceso de control de calidad que puede llevar semanas y el desarrollo de cuellos de botella, sin importar qué tan rápido trabaje ese equipo. Son demasiados cocineros en la cocina ".
Contenedores y microservicios en un mundo DevOps
La forma en que su empresa implementa una arquitectura de microservicios contribuirá en gran medida a determinar si la inversión vale o no. Los microservicios requieren mucho trabajo por adelantado, particularmente en la integración de API que se necesita para asegurarse de que todos los servicios se comuniquen entre sí. Hilwa explicó que es aún más complicado cuando se trata de integrar microservicios en un sistema existente; recomienda que las empresas creen nuevos sistemas siempre que sea posible en lugar de rediseñar una aplicación monolítica heredada para microservicios.
"Las arquitecturas de sistemas tradicionales generalmente involucran sistemas de registro de bases de datos grandes y complejos con esquemas normalizados elaborados", dijo Hilwa. "Factorizar dichos sistemas en componentes más pequeños con sus propios sistemas independientes requiere mucho trabajo de diseño de base de datos y reescribir de manera efectiva la mayor parte de la lógica de la aplicación central. Esto generalmente es prohibitivo en tiempo y costo en la mayoría de los casos".
Si vuelve a diseñar una aplicación heredada, Hilwa le aconseja que lo haga de forma gradual. Aunque es aún más importante que la integración API, los microservicios no funcionan sin la cultura DevOps detrás de esto. Dadgar de HashiCorp dijo que, cuando se trata del conjunto más amplio de DevOps, los microservicios se convierten en una herramienta para facilitar un cambio de proceso más amplio hacia cambios fundamentales en los flujos de trabajo mediante los cuales entregamos aplicaciones. Señaló el Tao de HashiCorp presentado cuando él y el cofundador Mitchell Hashimoto comenzaron la compañía: simple, modular y composable.
"DevOps en cierto sentido es un término aún más sobrecargado que microservicios", dijo Dadgar. "Pero un negocio está compuesto por personas con diferentes especialidades de conocimiento: desarrolladores, operadores, oficiales de seguridad. Y luego tienes el proceso, la forma en que organizas a esas personas. Luego tienes las herramientas para apoyar ese proceso, que es donde los microservicios y contenedores Adelante."
Los contenedores, popularizados por la explosión de código abierto de Docker, están lejos de ser la única herramienta que las empresas pueden usar para facilitar los microservicios. Hilwa de IDC dijo que los contenedores se usan en aplicaciones modernas como parte de los flujos de trabajo de CI / CD y, en algunos casos, mientras se implementan en producción. Pero dijo que los microservicios también pueden aprovechar las máquinas virtuales (VM), sin la necesidad de contenedores.
Dicho esto, cuando se trata de las formas en que las nubes empresariales están evolucionando, los contenedores y microservicios de Docker son una potente combinación de herramientas que está siendo adoptada por empresas de todas las formas y tamaños, desde nuevas empresas como HashiCorp hasta gigantes empresariales como Oracle. Dadgar de HashiCorp dijo que los contenedores son el medio conveniente por el cual Dev y Ops (y, por asociación, diferentes equipos y servicios) se comunican entre sí.
"¿Cuál es el artefacto que estamos pasando entre los desarrolladores y los operadores? ¿De qué estamos fluyendo y construyendo? Los contenedores son una unidad conveniente para pasar", dijo Dadgar. "Piense en un producto de envío empresarial global en todo el mundo. Ya sea un buque de carga, un tren de carga o un camión, es la misma unidad que fluye por todo el sistema".
DevOps y microservicios aún están lejos de la adopción generalizada de la empresa, pero el mercado solo está creciendo. Según el informe de IDC, la arquitectura de microservicios entrará en una fase de maduración en los próximos cinco años. Esta madurez se producirá inmediatamente después de que la cultura de DevOps llegue al 50 por ciento de las organizaciones para 2020, la evolución continua de las herramientas de automatización de software y el dominio de la infraestructura de nube económica y escalable proporcionada por Amazon Web Services (AWS) y Microsoft Azure.
Dadgar dijo que, incluso con la pequeña fracción de empresas que adoptan DevOps y microservicios en este momento, HashiCorp ya está muy suscrita. Alcanzó sus primeros ingresos de siete cifras después de solo nueve meses de ventas empresariales, además de una comunidad de código abierto en GitHub de varios millones de usuarios activos mensuales. Los microservicios son solo una parte del flujo de herramientas de la aplicación de flujo de trabajo de HashiCorp y una hoja de ruta de infraestructura DevOps más grande. Pero la modularidad y la interoperabilidad debajo de todo lo que construye la compañía ha impulsado el ascenso meteórico de una de las startups de software más populares en Silicon Valley.
"Hace cuatro años, cuando comenzamos, íbamos a reuniones y presentamos nuestra visión sobre cómo se administraría la infraestructura", dijo Dadgar. "No nos reímos exactamente de la sala; sabíamos que era temprano. Pero ahora nuestras herramientas como Terraform están en camino de convertirse en estándares de la industria. Lo que veremos es un efecto dominó de la presión competitiva y, en el A largo plazo, nuestro papel será trabajar con los CIO y CTO para comprender el cambio de proceso que deben tomar.
"Piensa en Toyota en el pasado", continuó Dadgar. "Tuviste un montón de compañías automotrices que fabricaban productos, pero el costo fue más alto de lo que debería ser. Toyota no reinventó lo que era un automóvil; simplemente fueron más rigurosos e incrementales sobre el proceso, y pasaron de la risa a la potencia, forzando El resto de la industria adoptará el mismo conjunto de prácticas para seguir siendo competitivos. En este momento, tenemos líderes de la industria que preguntan cómo pueden obtener una ventaja competitiva, y su respuesta es adoptar las prácticas de los Google y las Amazonas del mercado. punto, llegará a una masa crítica ".
