Una Guía Opinionada de Como Desarrollar Microservicios

9 min readAug 27, 2020

Las guías mas sencillas que encuentro sobre microservicios simplifican demasiado el desarrollo de microservicios y del otro extremo encuentro guías como la de Monolith to Microservices de O’reilly y NGINX que te promete que entenderás cómo migrar de un monolito a microservicios en 255 páginas.
Y entiendo de cierta manera esta brecha pues para cualquier problema de cualquier tema en desarrollo de dev siempre es el mismo: depende…, cual es tu meta?, es diferente en cada sistema…

Pero, ¿qué pasa cuando simplemente quiere hacer un desarrollo de Microservicios y aprender? Pero que no sabes ni cómo empezar ante tanta información y a la vez, tantos huecos en la información.

Y la respuesta a ese párrafo es esta entrada, aquí hago una Una Guía Opinionada de Como Desarrollar Microservicios tomando en cuenta como yo hubiera querido que me explicaran microservicios, cómo hacerlos y lo que involucran.

Esta guía asume que ya hiciste tu investigación de pros y cons de microservicios y que tomaste la decisión de crear una arquitectura de microservicios desde ceros, o de migrar un monolito a microservicios, sea por trabajo o simplemente por R&D.

El Mejor Resumen de Microservicios

Antes de cualquier desarrollo, de cualquier prueba unitaria, de cualquier diagrama de microservicios, ve esta presentación de Chris Richardson: Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability

En 84 slides explica:

La problemática que soluciona microservicios
Que no soluciona
Posibles problemáticas con microservicios
Mitos detrás de microservicios
Cultura necesaria para adoptar microservicios

La presentación será útil en cualquier organización o equipo de desarrollo que busca crear microservicios, tanto para personas técnicas como no técnicas.
Esta presentación es para mí el mejor primer paso que puedes tomar para adoptar el desarrollo de microservicios.

Como Desarrollar Microservicios

Más que pasarte un montón de links sin sentido, te escribo como idear microservicios desde 0s y que así vayas poco a poco encontrando el camino adecuado de acuerdo a tu expertise, techstack y necesidades de tu sistema, donde cada paso busca explicarte porque lo necesitas pero para que sepas porque está listado y continúes en contestarlo según tus necesidades y requerimientos.

Mi recomendación sería trabajar en este orden:

Bounded Context
Seguridad
Autenticación
Monitoreo & Logeo
Pipelines de CI & CD
Dockerization
Desarrollo
Infrastructure as Code

1. Bounded Contexts

La pregunta inicial con la cual debes iniciar es como debes partir el sistema y cómo, y para esto podemos tomar un concepto de Domain Driven Design: Bounded Contexts.

Para mi existen 2 caminos iniciales con los cuales te puedes familiarizar:

Lo haces a la manera que dice Domain Driven Design (te va a tomar un rato entender todos los conceptos detrás) que es por medio de Bounded Contexts, o mejor dicho, ¿cómo cortar la aplicación que haga sentido para todos?
Lo haces por medio del Strangler Fig, que es crear microservicios poco a poco alrededor de tu monolito.

La decisión está enteramente en las metas técnicas o qué problema se quiere atacar en el sistema, pues si el problema ya es por mantenimiento de monolito pero existen demasiadas complejidades técnicas, empieza con el #2.
Si aún están en pañales en DevOps, CI & CD, #2 también es tu mejor opción pues te permitirá no entrar en un mundo de complejidades técnicas.
Por otro lado, una reorganización técnica y organizacional de equipos de desarrollo, claro que amerita un #1.

2. Seguridad

¿Cómo harás para que cada microservicio sea seguro? ¿Estará en un cloud privado? ¿Requests solamente de IPs autorizados? ¿Cada microservicio tendrá su propio oAuth?
Aquí es donde performance, latencia y data transfers cross-region pueden entrar en consideración y la seguridad debe de ir arriba de cualquier desición técnica.
Mi opción inicial para adentrarte en microservicios es siempre contemplar seguridad en temas de red y que cada microservicio tenga un layer de seguridad en app-level.
Esto quiere decir que utilizes algo como AWS PrivateLink, IAM policies restringidas en AWS (o equivalentes en otros cloud platforms) a niveles de red, y en app-level busques un servicio de authentication.
Si apenas vas a entrar a microservicios y al ver esta lista notas conceptos que no has dominado o que no encuentras familiar, entonces mi recomendación es que te alejes de Kubernetes o Service Mesh, esto nomás dará dolores de cabeza adicionales para un equipo que lo más probable es que tenga necesidades muy básicas de desarrollo, pues incluso desde NGINX y por medio de cualquier plataforma de cloud puedes trabajar temas de seguridad.
Tip: Este ebook de Monolith to Microservices de O’reilly y NGINX está algo denso si no tienes contexto, pero la verdad es que es funcional y te da bastantes ideas y respuestas para principiantes (obviamente, promocionando NGINX para su uso).

3. Autenticación

Identifica los entry points a la arquitectura de microservicios, ¿cómo será? ¿oAuth? ¿JWT? ¿JWE? ¿SAML?
Lo recomendable es que un solo proceso de auth tenga como resultado un hash o encrypt que expira y que sea usable dentro de la red de microservicios, pero es solamente una de múltiples maneras de auth y que de acuerdo a tus necesidades propias de seguridad puedes incrementar por microservicio, por funcionalidad, por sistema, por bounded context, etc.
Eso si, no implementes cosas custom en procesos de authenticación, adhierete a patrones existentes de seguridad y de ser posible déjalo a third parties (como el link de Okta o Auth0 que pongo abajo) aunque esto es algo difícil en desarrollos customs o de ciertas compañias, en ocasiones he visto que esto es más seguro que desiciones técnicas tomadas por empresas que no priorizan la seguridad.

Algunas lecturas recomendadas:

4. Monitoreo & Logeo

Uno de los painpoints será el manejo de logs y data points de diferentes aplicaciones así como el monitoreo de cada instancia y a los cuales les debes de dar sentido a todos los datos…
Existen diferentes opciones pero Grafana y ELK stack (Logstash con Beats*) son mis opciones to-go.
Tienes que estandarizar los logs de todas las apps, de los procesos de CI & CD, así como seleccionar datos de todos los servidores para poder hacer sentido, pero sobre todo:

loguea todo lo que puedas, conforme vayas resolviendo bugs podrás ir quitando logs que consideres redundantes o que no aporten valor.

Mi motto en esto es: bugs are expensive, disk space is cheap.

Créeme que hacer esto suena más fácil de lo que es, así que pon atención al tema de monitoreo, logging y que prácticamente te dan la entrada a observability.
Solamente asegúrate que cada microservicio tenga un log rotation policy adecuado para el HDD que tengas.
Honeycomb tiene una buena intro a observability y tanto grafana como elastic (ELK) tienen buena documentación disponible:

5. Pipelines de CI & CD

Si no has amaestrado estos pasos previo a microservicios, solamente te dará dolores de cabeza adicionales una vez que crees tus microservicios.
Las herramientas sobran (Jenkins, Bamboo, TravisCI, etc) solamente escoge una que te funcione en la mayoría de los casos y listo. No le pienses mucho, en este paso buscas implementar CI & CD por microservicio, osease, quieres tener como meta poder empaquetar un microservicio estable, que haya pasado por diferentes pruebas (Unit Tests, Integration Tests, Acceptance Tests, etc) y estar deployeando en múltiples servidores (o en el mismo pero diferentes paths) sin hacer un overwrite, mandar al servidor equivocado o incluso deployear sin estar consciente de la calidad del sistema deployeado, esto requiere lo que se le conoce como tooling de parte de los devs/sysadmins/DevOps pues te preocuparás de cosas como:

Como guardo la configuración de cada microservicio? ¿config server? https://dzone.com/articles/microservices-and-spring-cloud-config-server)
¿Utilizo AWS Systems manager? ¿Me funcionará algo como HashiCorp Vault?
¿Hardcodeo los parámetros en Jenkins? Bamboo? TravisCI? (no recomendado)
¿Cuantos pipelines puedo correr al mismo tiempo de CI?
Si tengo 3 equipos de 5 devs cada uno, ¿tengo los pipelines correctos y pueden tener procesos asyncronos? ¿O CI & CD se convertirá en blockers?

Puedes llegar a tener microservicios con puro Continuous Integration y hacer deployments aún sin CD, pero claro, el punto es que puedas tener CI & CD detrás para realmente poder absorber el beneficio detrás de microservicios.

Esta es una buena guía introductoria al tema de CD:

How to implement Continuous Delivery for Microservices

6. Dockerization

Simple: si es microservicio es más fácil y puede en teoría tener mejor uso de recursos con Docker.
La realidad es que puedes hacerlo sin este, pero creo que a la larga terminarás aquí, así que sería mejor empezarle de una vez pero nuevamente, no es necesario.
Si se te complica el manejar los docker boxes a través de diferentes ambientes, crea 1 o 2 microservicios SIN docker y luego ya evalua poco a poco la introducción de docker en procesos o microservicios de docker.
Agarra cualquier tutorial de dockerizar una API y una parte que te debe de interesar es como sacar los logs de Docker a ELK (claro, después de que la app funcione en Docker):

https://logz.io/blog/docker-logging/#:~:text=To%20ship%20your%20Docker%20logs,outputted%20to%20a%20JSON%20file.

7. Desarrollo

Ahora si entrale a codear microservicios, pero en mi experiencia esto se convertirá en la última de tus preocupaciones.
Los pasos anteriores te los pongo para que te enfoques en infrastructura y resuelvas esos problemas ANTES de que tengas que resolver problemas de código, o que mientras desarrollas microservicios, otro equipo o persona esté a la par trabajando en estos puntos.

8. Infrastructure as Code

Algunos dirán que este paso tiene que estar mucho antes, puede ser, pero lo importante es que en algún momento te preocupes de como levantar y asegurarte que tus microservicios estén bien (ligado a monitoreo y observablity), pero la realidad es que puedes hacerla a la “cochina” en lo que agarras práctica y estabilizas lo demás.
Si estás utilizando AWS, yo recomiendo el CDK, pero la industria apunta mucho a Terraform en estos días (aquí no puedo recomendarlo de lleno pues no lo he utilizado).
Pero la realidad es que CDK, Ansible, Puppet o cualquier otra herramienta similar te dará resultados similares, habrá pequeños detalles y cambios que se irán más del lado de configuration management, otros de IaC, aquí dependerá bastante del control, experiencia propia y audits y lo que buscas detrás de todo esto (el clásico “depende…”).
Lo importante es que reconozcas que necesitarás una manera de “re-hacer” la arquitectura conpleta de tus microservicios y que si vas a grandes escalas (que si lo vas a hacer, no te recomiendo que estés leyendo este post) en algún momento necesitarás tener tu arquitectura mucho más resiliente y fácil de replicar.

Recomendación personal final: Serverless

Si lo de arriba te hace totalmente sentido y ya lo has trabajado previamente, te recomiendo ampliamente que evalúes un contexto de “Serverless” para tu arquitectura de microservicios, pues te quitará algunos de los puntos de encima de tu responsabilidad (pero claro, donde siempre dejas unas responsabilidades por adquirir otras).

AWS cuenta con una guía de microservicios con ECS, pero si no tienes nada de contexto de Microservicios, Serverless, AWS, CDK o Serverless apps en general, creo que puedes tener una curva de aprendizaje complicada, pero que por el lado positivo te quitaría de enfrente algunos temas de mantenimiento de servidores e IaC.
En resumen, ECS es prácticamente un servicio Serverless que deployea, corre tus docker boxes y los mantiene disponibles, tu solamente te encargas de configurarla y desarrollar tu microservicio.

Personalmiente siento que ECS o EKS son aún algo complejos para principiantes, pero es precisamente de lo que habló en este post: Qué es Serverless, una digerible pero extensa introducción a Serverless con AWS.

Conclusión

Nuevamente, esta es la guía opinionada que hubiera querido que alguien me explicará antes de entrar en microservicios.
No busco que la sigas al pie, simplemente busco dar una explicación rápida que no llegué a 255 páginas y que te permita iniciar las discusiones, investigaciones y requerimientos necesarios dentro de tu equipo de desarrollo que asumo no cuenta con experiencia en microservicios.

Y no puedo terminar la nota sin agradecer a Diego Tavera (@dtavera01) quien fue persona que con sus preguntas permitió que esta entrada fuera creada.

Imagen de portada creada por freepik