Spring boot se ha convertido en una de las tecnologías más importantes del desarrollo de Microservicios en Java, pues permite crear aplicaciones de forma muy rápida y con una auto configuración sorprendente.

En el siguiente video aprenderás como crear tu primer API REST utilizando JPA para el mapeo Objeto relacional y Swagger para auto documentar el API, te invito a que veas este video que hice como invitado a Init, pero tambien te invito a que te suscribas a nuestro Canal de Youtube y visitar nuestra página oficial Codmind para ver más cursos.

También puedes ver nuestro curso completo de Mastering API REST con Spring Boot

The post Crea tu primer API REST con Spring Boot appeared first on Oscar Blancarte - Software Architecture.

El patrón Circuit Breaker es muy parecido a un fusible, el cual se funde para evitar que una descarga eléctrica afecte al circuito, con la única diferencia de que el software, este fusible se puede restaurar cuando el problema allá pasado. Esto puede resultar un poco confuso, pero analicemos cómo funciona el patrón con el siguiente diagrama:

Antes de explicar cómo funciona el diagrama, debemos de comprender que son y el rol que tiene cada uno de los componentes involucrados:

• Client: representa al cliente que intenta consumir los servicios del Supplier, sin embargo, este lo hace por medio del Circuit Breaker.
• Circuit Breaker: es el componente que se encarga de la comunicación con el Supplier, el cual, mantiene un registro del estado de salud del servicio que usará para abrir el circuito cuando detecte que el Supplier está fallando.
• Supplier: representa el servicio de negocio remoto, el cual expone una serie de funcionalidad para ser consumida por el Client.

Una vez que entendemos esto, pasemos a explicar cómo funciona el patrón Circuit Breaker:

1. El Client realiza una primera llamada al Supplier por medio del Circuit Breaker.
   1. El Circuit Breaker determina que el servicio está operando correctamente el Supplier y redirecciona la petición al Supplier.
   2. El Supplier responde correctamente y envía la respuesta al Circuit Breaker para que sea este quien finalmente reenvíe la respuesta al Client.
2. El Client envía nuevamente una petición al Supplier por medio del Circuit Breaker
   1. El Circuit Breaker redirecciona la petición al Supplier
   2. En esta ocasión el Supplier responde con error o lanza un Timeout
   3. El Circuit Breaker recibe la respuesta de error y toma nota del error, el cual tiene un contado que determina cuantas veces ha fallado el Supplier de forma simultánea. En este caso, el contado de errores se establece en 1.
   4. El Circuit Breaker redirecciona el error al Client.
3. Seguido de un tiempo, el Client envía nuevamente una petición al Supplier por medio el Circuit Breaker.
   1. El Circuit Breaker redirecciona la petición al Supplier
   2. El Supplier nuevamente responde con error o Timeout
   3. El Circuit Breaker recibe la respuesta de error e incrementa el contado de errores en 2.
      1. Dada una configuración, el Circuit Breaker puede determinar que 2 es el número máximo de errores simultáneos que puede tolerar antes de realiza el corto circuito y abre el circuito con el Supplier.
      2. Un paso opcional pero muy deseable es tener algún componente de monitoreo que permite notificar a los administradores en tiempo real sobre los errores para poder tomar cartas en el asunto.
   4. El Circuit Breaker redirecciona el error al Client.
4. El Client nuevamente envía una nueva petición al Supplier por medio del Circuit Breaker.
   1. El Circuit Breaker determina el servicio no está respondiendo debido a los dos errores anteriores, por lo que retorna un error al Client indicándole que el Supplier está fuera de servicio.

Como podemos observar en la explicación anterior, el Circuit Breaker puede determinar que un determinado servicio (Supplier) está fuera de servicio al detectar que ha respondido con error de forma consecutiva un número determinado de veces.

NOTA: es común confundirse con el termino abierto y cerrado, pues podemos pensar que el estado abierto es cuando el servicio está disponible, sin embargo, como estamos utilizando la nomenclatura de los circuitos eléctricos, por lo que un circuito cerrado es cuando la electricidad flujo, por lo tanto, en este patrón, cerrado significa que existe comunicación con el Supplier.

Abriendo el circuito

En este punto te estarás preguntando, bien, ya he abierto el circuito, pero no me puedo quedar todo el tiempo así, necesito cerrarlo nuevamente una vez que el problema se ha resuelto. Pues bien, para eso, tenemos una funcionalidad adicional, en la cual configuramos cuanto tiempo debe esperar el Circuit Breaker antes de mandar una solicitud al Supplier. En este caso, por ejemplo, podríamos esperar una hora desde que se cerró el circuito para enviar una nueva petición, si esta petición retorna exitosamente, el Circuit Breaker cerrará nuevamente el circuito con el Supplier, pero, por el contrario, si este nuevamente retorna con error o Timeout, entonces el tiempo de espera se reiniciará y esperará otra hora antes de mandar una nueva petición para comprobar su disponibilidad.

Dicho lo anterior, veamos cómo quedaría el diagrama de secuencia para la reapertura del circuito:

1. En la parte superior partimos del escenario donde hemos abierto el circuito, lo cual explicamos anteriormente, por lo que nos saltaremos esta explicación. Solo asumamos que, en este punto, el circuito se encuentra abierto.
2. Una hora después de que el circuito se abrió, el Circuit Breaker redirecciona la siguiente petición al Supplier que estaba fallando para comprobar si ya se encuentra en funcionamiento.
   1. Tras redireccionar la petición al Supplier, este falla nuevamente y redirecciona el error al Circuit Breaker.
   2. El Circuit Breaker al darse cuenta que sigue fallando, reinicia el contador para esperar otra hora antes de volver a intentar consumir los servicios del Supplier.
3. Tras una hora desde el paso anterior, el Circuit Breaker redirecciona una nueva petición al Supplier para comprobar si ya se encuentra en funcionamiento.
   1. En este caso, el Supplier ya se encuentra operando correctamente, por lo que recibe la petición, la procesa y retornar exitosamente.
   2. El Circuit Breaker detecta la respuesta exitosa del Supplier y cierra nuevamente el circuito.

Circuit Breaker y los microservicios

En este punto ya hemos aprendido como es que el patrón Circuit Breaker abre el circuito ante una serie de errores consecutivos y como el circuito se cierra cuando el error es resuelto, pero hay algo de lo que no hemos hablado. ¿Te has preguntado que va a pasar con la aplicación si se abre el circuito? Es decir, una hora sin poder lanzar peticiones al Supplier podría causar un caos en nuestra aplicación, pues no podremos hacer nada hasta que el circuito sea restaurado.

Pues bien, te tengo buenas noticias, este patrón no fue diseñado para aplicaciones Standalone, si no que fue diseñado para arquitecturas cloud, donde tenemos alta disponibilidad y escalamiento, lo que quiere decir que debemos de tener múltiples instancias del Supplier, para asegurarnos de seguir operando ante la falla de una o múltiples instancias del mismo Supplier:

En la imagen anterior ya podemos observar cómo es que existe una serie de instancias de un mismo Supplier, por lo que en caso de que alguno falle, el Circuit Breaker deberá ser lo suficientemente inteligente para redireccionar la petición a otro Supplier en caso de que el primero falle, de esta forma, no retornamos el error al cliente, si no que reintentamos la ejecución en el siguiente Supplier disponible.

Ciclo de vida del Circuit Breaker

El Circuit Breaker se puede implementar como máquina de estados, la cual puede pasar por 3 estados diferentes, y cada estado afectará la forma en que funciona, los estados son:

• Closed: Este estado indica que el servicio destino está respondiendo correctamente. En caso de alcanzar un umbral de errores, pasará al estado Open.
• Open: Este estado indica que el servicio destino está fallando, por lo que toda invocación regresara un error de inmediato. Tras un tiempo de espera, pasará a estado Half-Open.
• Half-Open (medio abierto): Tras un tiempo en estado Open, el componente pase a Half-Open, lo que indica que puede recibir una pequeña cantidad de solicitudes para validar si el servicio está nuevamente activo. Si las solicitudes pasan exitosamente, el componente pasa a Closed, en otro caso, regresa a Open.

Entornos Asíncronos

Hasta este punto hemos analizado como es que este patrón se utiliza para servicios donde las invocaciones son síncronas, pero ¿qué pasaría si pasamos a un entorno donde los servicios a consumir se ejecutan de forma asíncrona? Por suerte, este patrón también se puede utilizar bajo estas circunstancias, aun que debemos de cambiar un poco la lógica, aunque el principio es el mismo.

En entornos síncronos, no tendremos respuestas con error ni timeout, por lo que las métricas que utilizábamos anteriormente no aplican, es por ello que podemos utilizar Colas (Queues):

En este caso, el Circuit Breaker en lugar de ejecutar directamente el servicio, tendrá que depositarlo en una Queue, de tal forma que el Supplier los podrá ir tomando a como pueda, lo que impide que lo saturemos de peticiones y lo hagamos colapsar, por otro lado, el Circuit Breaker podrá determinar el número de mensajes que tiene la Queue, y si este alcanza un umbral determinado, podríamos determinar que está fallando o que está procesando los mensajes demasiado lento, por lo que abrimos el circuito para impedir que se sature.

Como vemos, el funcionamiento es el mismo, lo que cambia es la forma de medir si un servicio está fallando o tarda mucho tiempo en procesar los mensajes.

Ventajas de implementar Circuit Breaker

Adicional a las ventajas obvias que podemos ver, como la tolerancia a fallas y el envío de solicitudes a servicios que sabemos que van a fallar, existen otros tipos de ventajas:

Monitoreo:

Dado que tenemos un componente que su única funcionalidad es sondear el estado de vida de los servicios, es posible tener un monitoreo en tiempo real, que nos indique los tiempos de respuesta promedio, frecuencia de falla, estado actual del servicio y, sobre todo, notificaciones en tiempo real si algún servicio comienza a fallar.

Sobrecarga:

La capacidad de abrir el circuito ante un error o Timeout que sabemos que va a pasar, nos ahorra el hecho de tener muchos hilos esperando a que el servicio responda, y más aún, si tenemos miles de usuarios, es probable tener muchísimos hilos detenidos, lo que provocaría que nuestro sistema se sobre cargue, incluso, puede provocar una bola de nieve que comience a afectar a otros componentes.

Tolerancia a fallas

Como ya lo dijimos, el Circuit Breaker puede redireccionar la petición al siguiente Supplier en caso de que alguno falle, evitando tener que enviarle el error al cliente.

Conclusiones

Como hemos analizado a lo largo de este artículo, utilizar el patrón Circuit Breaker permite que inundemos nuestra aplicación con una gran cantidad de solicitudes que sabemos de antemano que van a fallar, por lo que, en lugar de eso, re direccionamos las peticiones a una instancia del servicio que está operativo.

Este patrón de diseño es altamente utilizado en entornos distribuidos y con arquitecturas de microservicios, por lo que no es para nada recomendable utilizarlo para operaciones en memoria o servicios albergados de forma local. Recordemos que este patrón está diseñado para recursos remotos.

The post Circuit Breaker pattern appeared first on Oscar Blancarte - Software Architecture.

Dada la creciente tendencia de migrar nuestras aplicaciones a una arquitectura de microservicios, es cada vez más importante contar con tecnologías que nos ayuden a agilizar el desarrollo, pero sobre todo, que nos permita crear aplicaciones muy ligeras que consuman el menor número de recursos y es justo allí cuando entra Spring Boot.

Es posible que te pueda interesa mi artículo “Que son los microservicios”, donde explico los explico a detalle.

Que es Spring Boot:

Para los que no están familiarizados con esta tecnología, podríamos decir que Spring Boot es una herramienta que nace con la finalidad de simplificar aun más el desarrollo de aplicaciones basadas en el ya popular framework Spring Core. Spring Boot busca que el desarrollador solo si centre en el desarrollo de la solución, olvidándose por completo de la compleja configuración que actualmente tiene Spring Core para poder funcionar.

Spring Boot centra su éxito en las siguientes características que lo hacen extremadamente fácil de utilizar:

• Configuración: Spring Boot cuenta con un complejo módulo que autoconfigura todos los aspectos de nuestra aplicación para poder simplemente ejecutar la aplicación, sin tener que definir absolutamente nada.
• Resolución de dependencias: Con Spring Boot solo hay que determinar que tipo de proyecto estaremos utilizando y el se encarga de resolver todas las librerías/dependencias para que la aplicación funcione.
• Despliegue: Spring Boot se puede ejecutar como una aplicación Stand-alone, pero también es posible ejecutar aplicaciones web, ya que es posible desplegar las aplicaciones mediante un servidor web integrado, como es el caso de Tomcat, Jetty o Undertow.
• Métricas: Por defecto, Spring Boot cuenta con servicios que permite consultar el estado de salud de la aplicación, permitiendo saber si la aplicación está prendida o apagada, memoria utilizada y disponible, número y detalle de los Bean’s creado por la aplicación, controles para el prendido y apagado, etc.
• Extensible: Spring Boot permite la creación de complementos, los cuales ayudan a que la comunidad de Software Libre cree nuevos módulos que faciliten aún más el desarrollo.

Como funciona Spring Boot:

La mejor forma de entender cómo funciona Spring Boot es con un poco de código, por lo que veremos como es que se crea una aplicación. Básicamente existe dos formas de crear una aplicación, mediante ayuda del IDE o con ayuda de la página de Spring Boot:

Spring Start:

Spring Start es una página web que provee Spring para crear un proyecto por nosotros, para lo cual, nos solicitará los datos básicos del proyecto:

Como podremos observar, es posible crear un proyecto basado en Maven o en Gradle, también podemos definir si el lenguaje será Java, Kotlin o Grovy, también nos pedirá la versión de Spring Boot y el grupo (namespace) y nombre del artefacto (nombre del proyecto), finalmente nos pedirá las que selecciones las dependencias, en nuestro caso, solo seleccionaremos Web.

Si desconoces los módulos disponibles, puedes presionar el texto que dice “ Switch to the full versión.” Que se encuentra justo de bajo del botón para generar el proyecto (“Generate Project“), para que desplegará todos los módulos disponibles, los cuales son muchísimos para mostrarlos en una imagen.

Una vez configurado el proyecto, solo nos resta presionar el botón “Generate Project” e iniciará la descarga del proyecto preconfigurado, el cual podrás importar en cualquier IDE que soporte Maven o Gladle.

Spring Boot Suite:

La segunda y más recomendable opción es utilizar Spring Boot Suite, el IDE por excelencia para el desarrollo de aplicaciones basadas en cualquier producto de Spring, el cual ellos mismo desarrollan y lo puedes descargar desde aquí.

Spring Boot Suite es un IDE basado en Eclipse, por lo que no tendrás problemas en utilizarlos rápidamente. Para crear un proyecto tan solo es necesario dirigirse al menú principal y dar click en File => New => Spring Starter Project, el cual desplegará la siguiente pantalla:

Como podemos ver, nos pedirá los mismos datos que la página web, como grupo, nombre, type de proyecto (Maven Gladle), etc. Presionamos Next para continuar:

En esta nueva pantalla nos pedirá que selecciones las dependencias, en nuestro caso, solo seleccionaremos el módulo Web y damos en finalizar.

Con este último paso tendremos el proyecto creado y nos creará la clase HelloWorldApplication, la cual es lo único necesario para ejecutar nuestra aplicación:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class HelloWorldApplication {
	public static void main(String[] args) {
		SpringApplication.run(HelloWorldApplication.class, args);
	}
}

En este momento podríamos ejecutar nuestra aplicación Web, pero no tendría mucho sentido, pues no hemos desarrollado nada, por ese motivo, vamos a crear un servicio REST para poder probarlo desde el navegador. Para ello, crearemos una nueva clase llamada HelloRest en el mismo paquete que la clase anterior:

package com.example.demo;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloRest {
	@RequestMapping("/hello")
	public String helloWorld() {
		return "Hello World";
	}
}

Una vez creada, ejecutamos la aplicación dando click derecho sobre el proyecto y seleccionando Run As => Spring Boot App, lo que iniciará el despliegue de la aplicación sobre un Tomcat embebido:

Lo siguiente será ir al navegador y entrar a la URL http://localhost:8080/hello para ver lo siguiente:

Conclusiones

Como hemos podido observar, mediante Spring Boot es posible crear aplicaciones completas que se ejecuten en un entorno reducido, pues no es necesario tener un servidor de aplicaciones completo que nos consumirá una gran cantidad de recursos, además, Spring boot tiene complementos muy interesantes como Spring Cloud, el cual nos permite crear aplicaciones “Cloud Native”, es decir, aplicaciones diseñadas desde el inicio para ser ejecutadas en la nube.

Todas estas ventajas que hemos analizado son clave para crear microservicios, pues ya no es necesario instalar servidores de aplicaciones o tener configuraciones muy complejas para poder

The post Que es Spring Boot y su relación con los microservicios appeared first on Oscar Blancarte - Software Architecture.

Justo cuando nos estábamos empezando a acostumbrar a SOA, llegan los microservicios para confundirnos más, y es que SOA y microservicios tiene un gran parecido, tanto que para los que no están al tanto, puede resultar lo mismo, sin embargo, SOA y microservicios tienen sus diferencias y es justo de lo que hablaremos en este artículo.

Antes de empezar a leer este artículo te puede resultar interesante leer mi artículo “Que es service-oriented Architecture (SOA)” y “SOAP vs REST” pues pueden resultar de mucha ayuda para tener un contexto más amplio de lo que hablaremos en este artículo.

Primero que nada, es importante entender que los microservicios son un “tipo de arquitectura de software” y no un API o tecnología, la cual podemos instalar y utilizar, sin embargo, sí que existen frameworks que implementan esta arquitectura para facilitarnos la vida, como es el caso de Spring Boot en Java o Express para NodeJS.

Las arquitecturas de software son totalmente ajenas a los lenguajes de programación, pues solo establecen la forma en la que las tecnologías deberían de funcionar y no como fueron implementadas, es por eso que tenemos una gran variedad de frameworks que nos ayudan a implementar microservicios, se podría programar de formas diferentes, pero son profundamente parecidas en la forma en que trabajan.

¿SOA y microservicios son lo mismo?

Para comprender que son los microservicios es fundamental entender que son los servicios (SOA), pues es la base en la que se sustentan los microservicios. Tanto SOA como Microservicios son “tipos de arquitectura de software” que se basan en servicios, sin embargo, SOA es una arquitectura de más alto nivel, pues nos invita a construir aplicaciones basada en servicios, donde un servicios es la unidad más pequeña de un software, por otro lado, los microservicios también nos invita a crear servicios, la diferencia radica en que los microservicios están diseñados en la construcción de pequeños servicios o incluso programas  que cumplan una funcionalidad muy precisa y muy pequeña, la cual pueda ser desacoplada del resto de aplicaciones y funcionar de una forma totalmente autónomos del resto de aplicaciones.

Cómo funcionan los servicios SOA

Por otro lado, en SOA podemos tener aplicaciones monolíticas que expongan servicios, como son los clásicos ERP o CRM, las cuales son aplicaciones gigantes que exponen una gran cantidad de servicios, y que es imposible separar alguna funcionalidad para instalar por separado.

Como se puede apreciar en la imagen anterior, un ERP es una aplicación muy grande, que podríamos llamar monolítica, la cual implementa una arquitectura SOA para exponer los servicios, sin embargo, es imposible separar alguna funcionalidad de instalarla por separado, incluso, apagar cierta funcionalidad que no sea necesaria, en este esquema tenemos todo o no tenemos nada.

Cómo funcionan los microservicios

En el caso de la arquitectura de microservicios, la idea se centra en separar la funcionalidad en pequeñas aplicaciones independientes que puedan operar con completa autonomía, las cuales expongan su funcionalidad como servicios, con la idea de que sean reutilizables. En esta arquitectura tenemos varias aplicaciones desplegadas en lugar de una sola:

En la imagen anterior podemos ver como una serie de servicios pueden ser desplegados de forma independiente, de tal forma que cada uno funciona de forma autónoma y sin importar si los demás servicios están operando o no.

Microservicios y el escalamiento

Sin duda, una de las grandes ventajas que ofrecen los microservicios contra las arquitecturas monolíticas, es la posibilidad de un escalamiento más controlado, pues una arquitectura monolítica escala de una forma monolítica, es decir, que, si necesitamos clusterizar una app, es necesario escalar toda la app sin importar que existan módulos con poca demanda que no requieren ser escalados, en cambio, con los microservicios, es posible escalar únicamente los módulos de alta demanda aprovechando al máximo nuestro hardware.

En la imagen anterior podemos ver la diferencia que existe entre escalar una app monolítica vs una con microservicios. Lo primero que podemos observar, es que la aplicación monolítica se ha replicado exactamente igual en los cuatro contenedores, es decir, que los módulos A, B, C y D están presentes en todos los contenedores, sin importar si son realmente requeridos o no. Por otro lado (derecha), tenemos escalamiento con microservicios, lo primero que podemos observar, es que cada contenedor tiene una combinación diferente de componentes desplegados, pues algunos módulos son más críticos que otros, como es el caso del módulo B, el cual está presente en todos los contendedores, incluso, se encuentra más de una vez algunos contenedores. Por otro lado, tenemos el módulo D el cual solo se encuentra en un solo contenedor, debido a que no es un proceso crítico, como podría ser el módulo de envío de Emails.

Conclusiones:

Como podemos observar, los microservicios son en realidad una evolución de la arquitectura SOA, la cual nos invita a crear aplicaciones más modulares, capaces de funcionar de una forma autónoma y que puedan ser reutilizadas de una forma más eficaz, de la misma forma, optimizamos la utilización de nuestro hardware, pues solo desplegamos lo que es realmente necesario, en lugar de desplegar aplicaciones monolíticas completas.

The post ¿Que son los microservicios? appeared first on Oscar Blancarte - Software Architecture.