Como habrás notado este trimestre, estamos hablando de tendencias y palabras de moda para que sepas en qué enfocarte este año. Hoy discutiremos arquitectura de microservicios o los microservicios; su esencia, beneficios y estudios de casos prácticos.

 

¿Qué son los microservicios?

 

Los microservicios también se conocen como la arquitectura de microservicios. Es un estilo arquitectónico, un enfoque para el desarrollo de software en el que una gran aplicación se construye como un conjunto de servicios modulares; servicios centrados en el cliente, pequeños, con versiones independientes y escalables, con objetivos comerciales específicos, que se comunican entre sí a través de protocolos estándar con interfaces bien definidas. Como son de implementación independiente y escalables, cada servicio también proporciona un límite de módulo firme, incluso permitiendo que diferentes servicios se escriban en diferentes lenguajes de programación y también pueden ser administrados por diferentes equipos.

Los microservicios es una forma de dividir grandes proyectos de software en módulos más pequeños, independientes y poco compactos. Los módulos individuales son responsables de tareas discretas y altamente definidas y se comunican con otros módulos a través de API simples y universalmente accesibles. Es un método distintivo de desarrollo de sistemas de software que ha crecido en popularidad en los últimos años. Gracias a su escalabilidad, este método arquitectónico se considera particularmente ideal cuando tiene que habilitar el soporte para una gama de plataformas y dispositivos, por ejemplo, web, móvil, Internet of Things, wearables, etc. O simplemente cuando no está seguro qué tipo de dispositivos necesitará para respaldar en un futuro incierto.

La idea principal detrás de los microservicios es que algunos tipos de aplicaciones se vuelvan más fáciles de construir y mantener cuando se dividen en piezas más pequeñas y compostables que funcionan juntas. En otras palabras, cada componente se desarrolla por separado, y la aplicación es simplemente la suma de sus componentes constituyentes. En una arquitectura de microservicios, cada servicio ejecuta un proceso único y generalmente administra su propia base de datos. Esto no solo proporciona a los equipos de desarrollo un enfoque más descentralizado para la creación de software, sino que también permite que cada servicio se implemente, reconstruya, implemente de nuevo y se administre de manera independiente.

La filosofía de los microservicios: “Haz una cosa y hazla bien”. Los servicios pueden ejecutarse dentro del mismo proceso, pero deben ser implementables de forma independiente y fáciles de reemplazar. Se pueden implementar utilizando diferentes lenguajes de programación, bases de datos y entorno de software. Los servicios son pequeños, de grano fino para realizar una sola función. Adoptan la automatización de las pruebas y la implementación, el proceso de desarrollo de software de entrega continua y fallos, similar a los sistemas anti frágiles. Cada servicio es elástico, flexible, composable, mínimo y completo.

Además, probablemente tenga corazón acerca de Docker si está interesado en los microservicios. Y usted tiene el corazón de que Docker u otras tecnologías de contenedores es una especie de habilitador de una arquitectura de microservicios. Los contenedores están diseñados para reducirse a las piezas viables mínimas necesarias para ejecutar cualquier cosa para lo que esté diseñado el contenedor, en lugar de empaquetar múltiples funciones en la misma máquina. La facilidad de desarrollo que Docker proporciona ayuda permite un desarrollo y prueba rápidos.

El uso conjunto de contenedores y los microservicios mejora las capacidades de la nube. Los microservicios es escalable y reutilizable, mientras que los contenedores ofrecen recursos eficientes. Tanto los microservicios como los contenedores pueden funcionar de forma independiente, pero ha quedado claro que al fusionarlos se ha mejorado la frecuencia de tiempo de ejecución, las políticas de alojamiento en la nube y las herramientas en la nube.

 

Beneficios de la arquitectura basada en los microservicios

 

  • El software creado como microservicios se puede dividir en servicios de componentes múltiples. Para que cada uno de estos servicios se pueda implementar y luego implementar de forma independiente sin comprometer la integridad de una aplicación. Eso significa que la arquitectura de microservicios brinda a los desarrolladores la libertad de desarrollar e implementar servicios de manera independiente
  • Mejor aislamiento de fallos. Si un microservicio falla, el otro continuará funcionando
  • El código para diferentes servicios se puede escribir en diferentes idiomas
  • Fácil integración e implementación automática; utilizando herramientas de integración continua de código abierto como Jenkins, etc.
  • Los microservicios permite la entrega continua
  • Fácil de entender ya que representan una pequeña funcionalidad y son fáciles de modificar para los desarrolladores, por lo tanto, pueden ayudar a un nuevo miembro del equipo a ser productivo rápidamente.
  • El código está organizado en torno a las capacidades empresariales
  • Escalabilidad y reutilización, así como también eficiencia. Fácil de escalar e integrar con servicios de terceros 
  • Los componentes se pueden distribuir en varios servidores o incluso en varios centros de datos
  • Trabaja muy bien con contenedores, como Docker
  • Complementar las actividades en la nube
  • Los microservicios simplifica la supervisión de seguridad porque las diversas partes de una aplicación están aisladas. Un problema de seguridad podría ocurrir en una sección sin afectar otras áreas del proyecto
  • Aumento de la autonomía de los equipos de desarrollo dentro de una organización, ya que las ideas pueden implementarse y desplegarse sin tener que coordinarse con una función de entrega de IT más amplia.

 

Casos de éxito y ejemplos de implementación de los microservicios

 

Netflix, eBay, Amazon, el Servicio Digital del Gobierno del Reino Unido, Twitter, PayPal, The Guardian y muchos otros sitios web y aplicaciones a gran escala han evolucionado desde la arquitectura monolítica a la de microservicios. Veamos algunas de los casos de éxito y el resultado.

 

Walmart revitalizó su arquitectura defectuosa con los microservicios

 

Este es un buen ejemplo de lo que se debe hacer cuando la arquitectura antigua comienza a afectar negativamente a las empresas. Esta es la pregunta multimillonaria que el Departamento de IT de Walmart Canadá tuvo que abordar después de que fallaran en Black Fridays durante dos años seguidos.

El problema era que no podía manejar 6 millones de páginas vistas por minuto e imposibilitaba el mantenimiento de cualquier tipo de experiencia positiva para el usuario. Antes de aceptar los microservicios, Walmart tenía una arquitectura para internet de 2005, diseñada en computadoras de escritorio, computadoras portátiles y monolitos. La compañía decidió replatformizar su viejo sistema heredado en 2012, ya que no podía escalar para 6 millones de páginas vistas por minuto y estuvo inactivo la mayor parte del día durante los momentos pico. Querían prepararse para el mundo de 2020, con 4 mil millones de personas conectadas, más de 25 millones de aplicaciones disponibles. Entonces, Walmart replatformó a una arquitectura de microservicios con la intención de lograr cerca del 100% de disponibilidad con costes razonables.

La migración a microservicios realmente trajo resultados notables:

  • Las conversiones aumentaron un 20%, literalmente, durante la noche
  • Los pedidos móviles aumentaron un 98% al instante
  • Sin tiempo de inactividad en Black Friday o Boxing Day
  • Los ahorros operativos también fueron significativos desde que la compañía se mudó de los costes hardware al hardware básico.
  • Ahorraron el 40% de la potencia de computación y experimentaron entre un 20 y un 50% de ahorro de costes generales

 

Spotify crea una experiencia de usuario excepcional con los microservicios

 

Kevin Goldsmith, vicepresidente de ingeniería de Spotify, sabe por su experiencia que una empresa que intenta moverse rápido y mantenerse innovadora en un mercado altamente competitivo requiere una arquitectura que pueda escalar.

Spotify brinda servicios a más de 75 millones de usuarios activos por mes, con una duración promedio de sesión de 23 minutos, mientras ejecuta roles empresariales increíblemente complejos entre bastidores.

Por lo tanto, Spotify llegó a la conclusión de que si le preocupa el escalado a cientos de millones de usuarios, construye su sistema de manera que escale los componentes de forma independiente. Y Spotify construyó una arquitectura de microservicio con equipos autónomos de pila completa a cargo para evitar el infierno de sincronización dentro de la organización. Estos equipos son autónomos y su misión no se superpone con la misión de otros equipos.

Ahora, Spotify tiene alrededor de 90 equipos, 600 desarrolladores y 5 oficinas de desarrollo en 2 continentes construyendo el mismo producto, por lo que necesitan minimizar estas dependencias tanto como sea posible.

Lo que a Spotify realmente le gusta de los microservicios es que no tienen grandes fallos; los grandes servicios fallan, los servicios pequeños fallan en menor implicación. La construcción de una arquitectura de microservicios permite a Spotify tener una gran cantidad de servicios al mismo tiempo sin que los usuarios lo noten. Han construido su sistema suponiendo que los servicios pueden fallar todo el tiempo, por lo que los servicios individuales que podrían estar fallando no tienen demasiada implicación total, por lo que no pueden arruinar la experiencia de usar Spotify.

 

Amazon adoptó la filosofía DevOps con los microservicios

 

Amazon también ha migrado a microservicios. Reciben innumerables llamadas desde una variedad de aplicaciones, incluidas aplicaciones que administran la API del servicio web, así como el sitio web en sí, lo que habría sido simplemente imposible de manejar en su antigua arquitectura de dos niveles.

En 2001, el sitio web minorista de Amazon.com era un gran monolito arquitectónico. Estaba estructurado en varios niveles, y esos niveles tenían muchos componentes en ellos, pero estaban muy juntos y se comportaban como un gran monolito. Tenían una gran cantidad de desarrolladores trabajando en un gran sitio web monolítico, y aunque cada uno de estos desarrolladores solo trabajaba en una parte muy pequeña de esa aplicación, aún necesitaban ocuparse de coordinar sus cambios con todos los demás que también trabajaban en el mismo proyecto. Cuando agregaban una nueva función o realizaban una corrección de errores, tenían que asegurarse de que el cambio no rompería ninguna otra cosa en ese proyecto. Si querían actualizar una biblioteca compartida para aprovechar una nueva característica, necesitaban convencer a todos los demás en ese proyecto de que actualizaran a la nueva biblioteca compartida al mismo tiempo. Si querían hacer una solución rápida para enviarla rápidamente a sus clientes, no podían hacerlo en su propio calendario, tenían que coordinar eso con todos los demás desarrolladores que habían procesado los cambios al mismo tiempo. A principios de los 2000, Amazon incluso tenía un grupo de ingeniería cuyo único trabajo era tomar nuevas versiones de la aplicación y empujarla manualmente a través del entorno de producción de Amazon.
Fue, literalmente, un proceso muy largo y complejo, fue un infierno. Frustrante para los ingenieros de software, y lo más importante, fue la desaceleración del ciclo de vida del desarrollo de software, la capacidad de innovar, por lo que hicieron cambios arquitectónicos y organizativos.

Estos grandes cambios comenzaron en un nivel arquitectónico: Amazon pasó por su aplicación monolítica en una arquitectura orientada a servicios. Amazon también implementó cambios en cómo operaba su organización. Desglosaron su único equipo de desarrollo de productos jerárquico y central en pequeños “equipos de dos pizzas”. Querían equipos tan pequeños que pudieran alimentarlos con solo dos pizzas. En realidad, ahora hay entre 6 y 8 desarrolladores por equipo “.
Cada uno de estos equipos recibió la propiedad total de uno o unos pocos microservicios. Así que definieron su propia hoja de ruta de características, diseñaron sus características, implementaron sus características, luego las probaron, implementaron y operaron.

Después de todos estos cambios, Amazon mejoró dramáticamente su ciclo de vida de desarrollo front-end. Ahora los equipos de productos pueden tomar decisiones rápidamente y generar nuevas características para sus microservicios. Ahora la compañía realiza 50 millones de implementaciones al año, gracias a la arquitectura de microservicio y sus procesos de entrega continua.

 

Si este artículo sobre los microservicios te gustó, te puede interesar: 

 

La Deuda Técnica 

Simular respuestas del servidor con Nodejs

Principio de responsabilidad única 

Por qué Kotlin ?

Patrón MVP en iOS

Arquitectura de microservicios  

F-bound en Scala: traits genéricos con higher-kinded types

Scala Generics I : Clases genéricas y Type bounds

Scala Generics II: covarianza y contravarianza