El software se parece mucho a los negocios, porque un negocio comienza con una persona haciéndolo todo. Como EDteam que comenzó conmigo haciendo el sitio web, el marketing, dictando el curso, editándolo, cobrando y atendiendo a los clientes.

Pero tener un negocio es una cosa, mientras que hacerlo crecer es otra muy diferente. Para crecer, un emprendedor necesita que las funciones dejen de concentrarse en una sola persona y se distribuyan en un equipo, donde cada persona haga lo que mejor sabe hacer (así creció EDteam).

Igual es en el software. Una aplicación pequeña se puede construir con una sola tecnología, base de datos y servidor. Es un solo paquete fácil de mantener y de desplegar, donde todas las responsabilidades están concentradas en un solo lugar.

Pero, si la aplicación crece y le toca soportar mucha demanda, empezará a ponerse lenta y a caerse (como nos pasó en EDteam). Entonces, nos toca dejar de concentrar la responsabilidad en un solo punto y distribuir la app en muchas mini apps (o microservicios) con responsabilidades únicas y que se comuniquen entre sí.

En este blog vas a aprender qué son los microservicios y por qué debes dominarlos para subir tu nivel como programador.

Porque estás en EDteam y tú sabes que en español, #NadieExplicaMejor.

1. ¿Qué es una arquitectura?

Para entender a los microservicios primero debemos repasar qué es la arquitectura de software. Este es un tema muy amplio, pero para simplificar podemos decir que es la forma en que se organizan y se comunican los componentes de un software y las responsabilidades que cumple cada uno.

Más fácil, si cada componente de la aplicación fuera un jugador de fútbol, la arquitectura serían las posiciones (incluidos los que están en banca) más la estrategia que diseña el técnico para el partido.

La arquitectura más conocida y con la que todos comenzamos es la monolítica, que proviene del griego mono (que significa uno) y litos (que significa piedra) y que se usa para referirse a grandes monumentos de una sola piedra (ya sean naturales o creados por el hombre). Como analogía, en el desarrollo de software se usa el término monolito para el software en que el código y las funcionalidades están acopladas en un solo paquete, lo cual si bien funciona muy bien en ciertos escenarios, en otros (sobre todo al crecer) se convierte en un problema. Es como el negocio manejado por una sola persona.

Las aplicaciones monolíticas suelen dividirse en tres capas: capa de datos, capa de lógica y capa de cliente, que en una aplicación web serían base de datos, backend y frontend. Frameworks como Ruby on Rails, Laravel, Django o Spring (entre otros) nos permiten crear una aplicación web monolítica fácilmente, así que son una excelente opción para comenzar. Sin embargo, ten en cuenta que estos frameworks no se limitan a arquitecturas monolíticas.

Los monolitos no son una mala práctica, son tan solo una arquitectura diferente para crear software y en ciertos escenarios la arquitectura monolítica es la mejor opción.

Sin embargo, la arquitectura monolítica tiene desafíos como que al estar todo el código acoplado es muy complicado hacer cambios en una funcionalidad porque podrían afectar a otra, lo mismo si queremos agregar funcionalidades nuevas, lo que hace que escalar sea bastante complicado.

2. ¿Qué son los servicios?

La alternativa a la arquitectura monolítica es la arquitectura de microservicios. Pero, para entender a los microservicios primero debemos entender qué es un servicio.

Un servicio es una pieza de software que provee una funcionalidad específica. Por ejemplo, en un sistema operativo tenemos servicios de red que gestionan las conexiones, servicios de notificaciones, de bluetooth, etc. Estos corren en segundo plano y no solemos interactuar con ellos.

Los servicios van mucho más allá de los sistemas operativos porque tenemos servicios de nube (como lo dice el nombre de Amazon Web Services), servicios de procesamiento de pagos por internet, entre otros.

Dentro de toda esta gama de servicios, uno de los más usados son los servicios web que se encargan de exponer lógica y datos a través del protocolo HTTP, el mismo que se usa para navegar por internet. Eso significa que prácticamente todo lo que ocurre en internet está basado en servicios web, incluida la inteligencia artificial y las aplicaciones móviles.

En otras palabras, un servicio web es la implementación de una API. O sea, la puesta en práctica de los principios teóricos y reglas de las API (aunque en el día a día se suele usar API y Servicio web como sinónimos). Si quieres saber más, tenemos la mejor explicación de APIs en español en YouTube y un curso gratuito en nuestro sitio web.

Cuando hablamos de servicios web, nos referimos al lado del backend de una aplicación (la capa de lógica). Estos servicios pueden ser consumidos por un cliente (la capa de presentación) que puede ser un frontend web, una aplicación móvil, videojuegos de PC o consolas y también por otro servicio (otro backend).

Estos microservicios tienen unas puertas de acceso llamadas endpoints, que son URLs a la que los clientes (u otros servicios) pueden comunicarse, mientras que la comunicación se hace a través del protocolo HTTP.

3. Arquitectura de microservicios

Como acabamos de ver, los servicios son aplicaciones que exponen lógica y datos a través de endpoints para que otros servicios o clientes se conecten. Pero esta definición nos habla más de la función de los servicios que de como están construidos, puesto que un servicio bien podría ser un monolito. Por ejemplo, la App de EDteam puede ser un monolito y, aun así, exponer los cursos, precios y clases a través de endpoints, con lo cual es un servicio, pero no deja de ser un monolito.

Esa es la diferencia con los microservicios, pues son servicios pequeños y específicos (de ahí su nombre) para cada funcionalidad de la aplicación. Al igual que los servicios, los microservicios pueden conectarse entre ellos para construir una aplicación y también pueden exponer sus endpoints a aplicaciones de terceros.

Y puesto que los microservicios son tan pequeños, hablar de microservicios y de arquitectura de microservicios es prácticamente lo mismo. Crear una arquitectura de microservicios significa dividir la lógica de tu aplicación en mini apps (microservicios) con funciones muy específicas que se comuniquen entre ellos a través de ciertas reglas para evitar conflictos.

Por ejemplo, en nuestros inicios, EDteam era un monolito: usábamos un CMS llamado Drupal, y cuando Drupal se nos quedó corto desarrollamos nuestra propia aplicación desde cero, la cual también era un monolito. Y el mundo era feliz, brillaba el sol y trinaban los pajaritos, pero EDteam empezó a crecer y la app empezó a caerse, a ponerse lenta y hacerle mantenimiento era muy difícil. Nos enfrentábamos a los tres desafíos de una arquitectura monolítica.

1. Alta demanda: Cuando la cantidad de usuarios y peticiones aumenta, la carga se concentra en ciertas partes de la aplicación, pero no es posible aislar esa parte porque todo está acoplado. Con microservicios, puedes escalar o darle mantenimiento solo a las partes que lo necesiten.
2. Alta disponibilidad: Cada segundo de downtime (o sea de la aplicación caída) es dinero perdido. En un monolito como todo está acoplado es muy difícil identificar qué parte provocó el error. Mientras que los microservicios pueden monitorearse para saber cuál falló y configurarlos para que escalen, se reinicien o regresan a versiones anteriores automáticamente. Y si definitivamente un microservicio se muere, la aplicación sigue arriba.
3. Alta complejidad: Mientras más funciones se agregue a una aplicación monolítica, será más difícil darle mantenimiento porque cada cosa depende de muchas otras. En cambio, los microservicios son aislados y se pueden mantener y agregar otros sin comprometer a toda la aplicación.

Desde entonces cambiamos nuestra arquitectura a microservicios, con lo que podemos soportar de muchísimos usuarios sin despeinarnos.

4. ¿Cómo son los microservicios?

¿Y cómo son los microservicios por dentro? Son una aplicación y ya está, pero hay tres partes en común:

1. El controller, que es quien recibe las peticiones de otros microservicios y entrega las respuestas. Esta es la capa externa donde está el endpoint. Aquí también se maneja la autenticación para que no haya acceso no autorizado. Si quieres saber más de autenticación puedes ver este curso con el tío Alexys.
2. El validator, que válida que la petición y los datos tengan el formato correcto para evitar los conflictos.
3. El microservicio en sí donde está la lógica del negocio, que es donde se encuentra la función que cumple este microservicio y el acceso a los datos que se comunica con una base de datos externa.

Además, los microservicios deben cumplir con las siguientes reglas:

1. Cumplir una sola función. Si en algún momento vemos que estamos agregando más funciones que se alejan del objetivo original, es recomendable crear un nuevo microservicio.
2. Ser autónomos. Es decir, que no dependan de otros para funcionar. Esto garantiza el desacoplamiento del código y que hacer modificaciones en un microservicio no comprometa a toda la aplicación.
3. Estar aislados. Deben correr en entornos separados, con sus propios recursos y, muy recomendable, cada uno con su propia base de datos.

El último punto (el de estar aislados) implica que podemos usar diferentes lenguajes de programación y motores de bases de datos en un mismo proyecto. Lo cual es sorprendente para quien viene de hacer todo en una misma tecnología. Aunque, el hecho de poder no significa que lo hagamos, pues también puedes crear todos tus microservicios con el mismo lenguaje. Lo que importa es que se decida correctamente cuál es el mejor lenguaje según la función de cada microservicio. Por ejemplo, si vas a crear un microservicio para análisis de datos, Python es una excelente opción, pero si es para comunicación en tiempo real, una opción más interesante es JavaScript con Node.js.

5. ¿Cómo implementar una arquitectura de microservicios?

Si bien, por un lado, la arquitectura de microservicios ayuda mucho a escalar las aplicaciones, por otro, representa varios retos y complejidad adicional en el desarrollo. Así que veamos algunas técnicas que se usan para implementar microservicios.

1. Arquitectura hexagonal

Es una arquitectura basada en puertos y adaptadores para comunicar a los microservicios. Los puertos son interfaces que definen cómo se conectarán los microservicios y los adaptadores son implementaciones concretas de estos puertos.

Si quieres saber más sobre las interfaces, sus implementaciones y los principios SOLID puedes ver este video aquí en YouTube y para ir más a fondo tenemos el curso de SOLID y arquitectura hexagonal en EDteam.

2. API Gateway

Otro reto de los microservicios es gestionar la cantidad de endpoints disponibles (uno más para cada microservicio). Así que para solucionarlo, usamos una puerta de enlace o API Gateway que es un enrutador de las peticiones, ya que administra los endpoints internamente y hacia afuera expone un único endpoint para aplicaciones externas, además que se encarga de gestionar la seguridad.

Los proveedores de nube tienen sus propios servicios para implementar API Gateway. Microsoft tiene Azure API Management, GCP tiene Google Cloud Endpoints y Amazon tiene AWS API Gateway que puedes aprender en EDteam.

Serverless

Otra forma de implementar microservicios es Serverless, cuya traducción en español significa “Sin servidor”. ¿Y cómo puede funcionar una aplicación sin servidor? Simple, no puede. El término Serverless no se refiere a que no existan servidores, sino a dos cosas:

1. No tienes que administrar ni configurar servidores, puesto que el proveedor de nube asigna los recursos necesarios de forma automática.
2. No tienes un servidor encendido, sino que el proveedor de nube asigna los recursos cuando se ejecuta la aplicación y luego los apaga.

Por ejemplo, en EDteam no nos llegan ventas cada segundo (estaría en la lista de Forbes), entonces no necesitamos el servicio de ventas siempre encendido, así que un modelo serverless asigna los recursos cada vez que se ejecuta una venta y luego los apaga (hasta que vuelva a realizarse una venta).

Cada proveedor de nube tiene sus servicios de serverless, como Google con Cloud Functions, Microsoft con Azure Functions y Amazon con AWS Lamba que también puedes aprender en EDteam.

6. DevOps y Microservicios

Una parte importante de la implementación de una arquitectura de microservicios es tener control sobre todo el ciclo de vida del software. Y es aquí donde entra DevOps.

DevOps

DevOps es un conjunto de buenas prácticas (ojo, no es un rol) para derribar el muro de la confusión que separa a los desarrolladores (los que escriben el software) de los profesionales de sistemas (los que se encarga de la infraestructura de servidores donde se ejecutará la aplicación).

Este muro de la confusión representa los problemas de comunicación y flujo de trabajo entre ambos profesionales. Por ejemplo, si la aplicación se cae, ¿es que tiene bugs (culpa de los programadores) o que se configuró mal la infraestructura (culpa de operaciones)?

Para resolver estos problemas, DevOps conecta a todas las etapas del ciclo de vida del software, el cual es infinito.

Dentro de este ciclo de vida, dos tareas son cruciales:

1. La integración (I). Que significa que el código de un programador no entre en conflicto con el código de otros programadores.
2. El despliegue (D). Que significa enviar los nuevos cambios en el software a producción.

CI/CD

Estas tareas podrían hacerse a mano, pero lo ideal es que sean automáticas. Por eso en DevOps se habla de CI/CD (Integración continua y despliegue continuo), donde la palabra “continuo” significa que los cambios se integran y pasan a producción sin detener el proceso a través de tests automáticos. Así, un programador puede enviar sus cambios a producción directamente, siempre que pase los tests, si no, le tocará corregir su código.

Si quieres saber más de DevOps tenemos un excelente video en YouTube y dos cursos en EDteam: uno para empezar en DevOps y otro para crear un flujo de CI/CD en Gitlab (la plataforma líder para DevOps).

Docker y Kubernetes

Y los últimos conceptos de este blog son Docker y Kubernetes. Puesto que los microservicios necesitan entornos aislados y crear una máquina virtual para cada uno sería muy costoso, la mejor solución es usar contenedores que, como su nombre lo dice, contienen, además del microservicio, todas las dependencias que necesita para funcionar y lo aíslan de su entorno.

El siguiente paso es administrar, configurar y escalar estos contenedores, para conseguirlo la solución es Kubernetes, el orquestador de contenedores más utilizado en el desarrollo de software.

Si quieres saber más de Docker y Kubernetes tenemos un video aquí en YouTube y dos cursos que puedes ir a ver en nuestro sitio web para que subas tu nivel como programador.

En el siglo primero antes de cristo, el imperio Romano se expandía conquistando todos los pueblos y culturas vecinas. Una de sus principales estrategias era “divide y vencerás” que consistía en debilitar a sus enemigos, explotando sus rivalidades para que se dividan y vencerlos fácilmente.

Podemos decir que los microservicios son el “divide y vencerás” del desarrollo de software porque dividimos una aplicación grande en aplicaciones pequeñas para poder dominarlas. Si no lo hiciéramos, la aplicación podría crecer tanto que terminaría dominándonos.

Pero, los microservicios no son para todos, se necesitan desarrolladores de alto nivel que entiendan de arquitectura de software, patrones de diseño y DevOps, por lo que implementar microservicios en una aplicación que no lo necesita es un desperdicio de recursos.

Si quieres aprender más de microservicios y subir tu nivel como programador tienes todos estos cursos en EDteam:

1. Introducción a la arquitectura de microservicios
2. Creación de microservicios con Java y Spring Boot
3. Creación de APIs (con todos los lenguajes)

Y por su puesto, todos los demás que ya te mencioné en este blog. Ahora ya sabes qué son los microservicios y recuerda que lo aprendiste en EDteam.