freshidea - Fotolia

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

La realidad de la adopción de microservicios y los límites de su monolito

En esta entrevista, Randy Shoup de Stitch Fix habla sobre la ‘realidad’ de la adopción de microservicios y comparte tres señales reveladoras de que su monolito ha alcanzado su límite.

Pasar a una arquitectura distribuida, particularmente una arquitectura de microservicios, es cada vez más el furor entre las organizaciones que buscan hacer una transformación digital. Sin embargo, mientras que grandes jugadores como Amazon y eBay han dirigido el avance de romper monolitos en pedacitos, la mayoría de las empresas todavía están descubriendo lo que significa una arquitectura de microservicios para ellos.

En esta entrevista, Randy Shoup de Stitch Fix, un servicio de estilo personal en línea, habla sobre la definición más simple de microservicios, la "realidad" de la adopción de microservicios, y las señales reveladoras de que su monolito llegó al final de su vida.

¿Cuál es su definición más simple de microservicios?

Randy Shoup: El 'micro' en microservicios es más sobre el alcance de la interfaz y no sobre la cantidad de líneas de código, o cuánto tiempo se tarda en escribirlo. Por lo tanto, pienso en ello como en un servicio que tiene una interfaz simple y bien definida. [También debe poder ser] compuesta, lo que significa que es lo suficientemente general que puedo utilizar el mismo, por ejemplo, microservicio de 'facturación' con muchos clientes diferentes para componerlo de muchas maneras diferentes.

Randy Shoup

Son todas las ideas que tenemos en el software sobre la construcción de buenas clases, excepto en un nivel ligeramente superior de granularidad. Construimos una clase que está encapsulada; los datos están dentro de ella. Tiene una interfaz sencilla, es fácil de usar y es fácil de entender. [Son] esos principios de diseño que se aplican a nivel de un proceso o un servicio.

¿Cuál es la ‘realidad’ cuando se trata de la adopción de microservicios? ¿Cuántos están todavía, tanto como ellos dicen que están intentando alejarse, atados al monolito?

Shoup: Lo primero que diría es que hay un montón de empresas de las que todos hemos oído hablar –eBay, Amazon, Netflix, Twitter– que han comenzado tan monolíticas como usted puede imaginar. Toda esa gente que mencioné, por cierto, son ahora lo que llamaríamos arquitectura de microservicios.

Así pues, [hay] dos puntos. Primero, ninguno de ellos empezó de esa manera; todos ellos comenzaron como un monolito. En segundo lugar, han evolucionado su arquitectura con el tiempo... en el caso de eBay, cinco generaciones. Twitter ha pasado por esa evolución, Amazon ha pasado por ella y Netflix ha pasado por ella.

Por lo tanto, nadie comenzó con microservicios cuando eran pequeños, porque si hemos oído hablar de ellos, pasaron su tiempo construyendo su negocio y no construyendo tecnología. La broma que me gusta decir es: Podría haber habido un competidor de eBay en 1995 que gastó todo su tiempo construyendo un sistema distribuido, y hay una razón por la que no hemos oído hablar de ellos; gastaron todo su tiempo haciendo eso.

OK, ¿así que cuál es la realidad? Debido a que es un proceso evolutivo, hay muchas empresas diferentes que están en diferentes puntos a lo largo de ese espectro. Por lo tanto, la gente que empezó muy temprano –esas personas de las que hablé– están todas hechas. Amazon es totalmente una arquitectura de microservicios, y sigue evolucionando creando nuevos servicios.

[Pero en] Stitch Fix, donde trabajo ahora, estamos en medio de romper nuestro monolito particular y pasar a microservicios. Por lo tanto, tenemos un pie en cada lado... hay un monolito en un extremo, y [es] completamente microservicios en el otro extremo. Estamos un poco en el medio de un espectro, y creo que muchas empresas están aquí.

¿Cuáles son los signos de que su monolito ha llegado al final de su usabilidad y que es hora de considerar una adopción de microservicios?

Shoup: [Una razón es] que su equipo no puede escalar. Así que, a medida que añado más gente a mi equipo, todo el mundo se está pisando los dedos en el monolito, y solo están frenando a todo el mundo.

También puede llegar a un cuello de botella de [rendimiento] en la escala. Twitter se estaba cayendo todo el tiempo en sus primeros días... era muy popular, pero simplemente moría todo el tiempo, en gran parte porque su monolito simplemente no podía soportar la carga. Y así eso obligó a Twitter a romper su arquitectura en pedazos más pequeños.

Y luego, el tercero es el ciclo de vida del despliegue. Puede haber diferentes partes de su sistema que necesitan moverse más rápido o más lentamente. Podría ser que tengo que desplegar la interfaz web todos los días porque tiene que cambiar. Y eso es un gran problema si tengo que desplegar todo sobre mi sistema solo para modificar algo en el HTML.

Un monolito no es un término peyorativo. Es una solución completamente legítima para [una cierta] clase de problema. Y cuando estás más allá de esa clase de problemas, ya sea por el número de usuarios, por el tamaño de tu equipo o por las características del ciclo de vida del despliegue, debes hacer algo más parecido a los microservicios.

Este artículo se actualizó por última vez en agosto 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close