# El camino de Shoprocket hacia los microservicios, parte 1: lo que hice mal al romper el monolito

> Artículo del equipo de ingeniería de los primeros años de Shoprocket sobre el primer intento de extraer un servicio de un monolito en PHP. Por qué elegí mal el primer servicio, qué me enseñó el acoplamiento fuerte y el consejo de Newman que debí seguir antes.

Winston Berty  - 17 de marzo de 2016 - 5 min de lectura

Unos meses después de entrar en Shoprocket, empecé a frustrarme. Teníamos una aplicación en PHP en la que trabajaba un pequeño equipo de desarrolladores brillantes repartidos por todo el mundo, y a mí me parecía que los arreglos de errores generaban más errores, que integrar funciones nuevas no era tan sencillo como debería y que los despliegues eran poco frecuentes y estresantes. El motivo: código muy acoplado.

Teníamos una aplicación monolítica, casi toda en un único repositorio de GitHub. Las actualizaciones o correcciones de una función a menudo requerían cambios en varios sitios. Para las pruebas, teníamos un proceso de revisión por pares en el que al menos otros dos desarrolladores debían dar el visto bueno a una rama antes de fusionarla en master y desplegarla. Todo esto significaba que, cuando se colaba un error, a menudo era difícil localizar el cambio que lo causaba. Una vez que lo encontrábamos, la corrección pasaba por el mismo proceso y había que volver a desplegar toda la aplicación.

Como joven desarrollador entusiasta siempre a la caza de lo nuevo, cuando descubrí los microservicios pensé que iban a resolver todos nuestros problemas.

## Lo que yo creía que eran los microservicios

No hay una definición formal de microservicios, pero de mi investigación saqué que la arquitectura de microservicios es una forma de diseñar aplicaciones de software como sistemas distribuidos de servicios independientes, cada uno muy especializado y con su propio ciclo de vida. Para una introducción detallada, el [artículo](https://martinfowler.com/articles/microservices.html) de Martin Fowler es excelente.

Dos aspectos me engancharon. Primero, la idea de dividir la aplicación en servicios con fronteras estrictas. Esto reduce la probabilidad de que la lógica propia de un contexto de negocio se filtre entre componentes, porque las interfaces entre fronteras tienen que planificarse con cuidado. No es tan simple como hacer llamadas a funciones locales. Segundo, cada componente puede tener su propio ciclo de vida independiente. Los equipos pueden ser dueños de su código y usar la pila que mejor encaje con el servicio, y los cambios pueden desplegarse servicio a servicio y revertirse sin afectar al resto.

Me convencieron. Shoprocket iba a romper el monolito. Esta es la parte 1 de una serie breve que sigue ese camino. Espero que quienes planeen o estén atravesando una transición parecida aprendan de nuestros aciertos y errores.

## El primer reto fue humano, no técnico

Tuve que vender la idea al resto del equipo. Sentían curiosidad pero no compartían mi entusiasmo, y eran reacios a ceder horas de desarrollo en esta etapa tan temprana del producto. Por suerte, el CTO quería que estudiara nuestra gestión de sesiones, así que aproveché el momento: lo convencí de que podía separar un servicio de sesiones.

En retrospectiva, fue una mala elección de primer servicio. Nuestro producto incluye un widget de JavaScript que [permite el ecommerce en cualquier sitio web](https://v3.shoprocket.io/es/funciones/vender-en-cualquier-sitio-web.md). Tratamos las sesiones como un recurso y guardamos la información de sesión en la base de datos para analizar el abandono de carrito y otros KPIs. Pero este recurso no es tan tangible como los pedidos o las líneas de pedido, y usábamos las sesiones en casi todos los cambios del estado de la aplicación. Eso significaba que el servicio iba a ser inevitablemente muy conversador con el resto de la aplicación, algo que no preví y que hizo mi tarea más difícil.

## Lo que aprendí construyéndolo de verdad

Intensifiqué la investigación. Junto a Fowler, **Building Microservices**, de Sam Newman, resultó ser un recurso imprescindible.

El consejo de Newman, en retrospectiva, era el que debí seguir: primero reestructura la aplicación existente en módulos que reflejen los contextos delimitados del dominio. Cuando los desarrolladores estén contentos con las fronteras, *entonces* separa los módulos en sus propios servicios. La razón es que es mucho más fácil descomponer y reescribir módulos con malas fronteras que descomponer y reescribir servicios enteros con todo su código de conexión adicional y sus recursos persistentes.

No seguí ese consejo. Con ganas de construir un componente propio, seguí adelante con el servicio de sesiones.

Elegí una pila apenas distinta de la del monolito y empecé a construir. El servicio en sí salió rápido: unas pocas semanas para producir una aplicación independiente con una API REST. Ahí no estaba lo difícil. Lo difícil fue lograr que el servicio hablara con el monolito.

La gestión de sesiones resultó estar muy acoplada al resto del código. Sustituir llamadas a funciones por llamadas a API fue un trabajo lento. Como el servicio de sesiones y el monolito tenían esquemas de base de datos separados, tuve que reescribir toda la lógica del monolito que usaba recursos de sesión de la base de datos antigua, reestructurando los datos en la frontera de la aplicación para mantener la compatibilidad de clientes como nuestro widget de JavaScript.

Integrar llevó más tiempo que construir. Y eso sin contar la mayor parte de la sobrecarga que suelen traer los microservicios: descubrimiento de servicios, registro, monitorización, trazado distribuido. Peor aún, el acoplamiento fuerte hacía que los cambios se extendieran por muchas áreas del código. Como el equipo había estado trabajando en paralelo durante ese tiempo, fusionar y llevar el servicio de sesiones a producción habría exigido bastante más coordinación de la que había estimado.

## La valoración sincera

Puede que el servicio pronto llegue a producción. Pero ahora siento que debí seguir el consejo de Newman y dedicar mis esfuerzos a modularizar primero la aplicación existente. El beneficio de tener un servicio viviendo por su cuenta es marginal. El beneficio real viene de dividirlo todo, al menos en servicios de grano grueso que hablen lo menos posible entre sí. Eso requiere fronteras de componentes bien pensadas, y aún no estábamos ahí.

Sigo convencido de los microservicios como idea. Veo mi intento como un experimento útil. Aprendí muchísimo sobre arquitectura de aplicaciones, modelado de dominio y principios REST, y esas lecciones tuvieron efectos en cadena en otras partes de nuestro código.

Para quien esté pensando en una transición parecida, mis recomendaciones sinceras:

- Lee todo lo que puedas sobre el tema antes de comprometerte
- Aplaza el trabajo hasta que tengas verdadera confianza con tu código actual y tu modelo de dominio
- Recuerda que hay otras formas de dar estabilidad y resiliencia a un monolito. Las pruebas unitarias y funcionales automatizadas ayudan enormemente. El desarrollo guiado por pruebas reduce las regresiones. El escalado horizontal hace los despliegues menos dolorosos
- Empieza modularizando tu monolito antes de extraer servicios

Shoprocket seguirá su camino. La parte 2 es donde la cosa se pone más interesante.

---

*Publicado originalmente como el primero de una serie breve que documenta la migración temprana de Shoprocket lejos de un monolito en PHP. El camino completo, incluidos los errores corregidos en iteraciones posteriores, ha continuado a lo largo de cada gran reescritura de la plataforma desde entonces.*

---

- HTML version: https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito
- Language: Español (es)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)