No es un secreto que las aplicaciones de hoy en día generan una gran cantidad de datos y sumado a eso, cada vez tenemos más aplicaciones independientes que van produciendo datos de forma aislada, por tal motivo, llegara un momento en que los datos están distribuidos en varias base de datos, por lo que recuperar información relevante y consistente, nos obliga a crear complejos procesos de extracción y cargado de datos (ETL) para integrarlos en una única fuente confiable para finalmente sea analizada y explotable, sin embargo, como analizaremos en este artículo, este enfoque tiene grandes problemas, entre los que destaca los complicados procesos de extracción y los múltiples procesos ETL que deben de correr una y otra vez para obtener diferente información para diferentes análisis o reportes.

Antecedentes

Cuando las herramientas como Business Intelligence (BI) comenzaron a ponerse de moda, predominaban las aplicaciones monolíticas, donde cada aplicación podía contener una gran cantidad de información sobre una parte del negocio:

Debido a que los sistemas eran grandes silos datos, era muy simple crear procesos ETL para extraer información de estos sistemas y crear los famosos Data warehouses o almacenes de datos, desde los cuales las herramientas de BI generaban sus reportes:

A pesar de que esto es suficiente para muchas empresas, el problema llega cuando se requieren reportes más complejos, donde la información se recolecta de múltiples sistemas para generar un solo reporte, creando una sobre carga de las bases de datos transaccionales, pues múltiples procesos extraen información para diferentes almacenes de datos:

Lo que estamos viendo en la imagen anterior es un caso muy común que he visto en muchas empresas, donde tiene varios procesos ETL que extraen información del mismo sistema, pero como son varios procesos, los tiene que programar a diferentes horas de la noche o del día para que no corran en simultaneo.

Si prestamos atención en la imagen anterior, podrás observar que el ERP es utilizado por 3 procesos ETL para crear diferentes almacenes de datos, y muy probablemente los 3 procesos ETL consulten prácticamente la misma información, pero la procesen de forma diferente, entonces, como la procesan diferente según su objetivo, hace necesario crear cuantos procesos ETL sea necesario para satisfacer todas las necesidades del negocio, lo cual, queda claro que no es para nada eficiente.

¿La solución es un Stagin Area?

Dada la problemática anterior, quizás los más experimentados digan, bueno, pues creamos un Stagin Area en donde volquemos todos los datos y sobre esa base de datos corremos los procesos ETL. Veamos como quedaría:

En esta nueva arquitectura tenemos proceso de extracción que solo extraen los datos una vez de los sistemas transaccionales y los dejan en los Stagin Area, los cuales al nos ser transaccionales, permite que múltiples procesos ETL se conecten a ellos para extraer la información y crear sus propios almacenes de datos. Este enfoque tiene varias ventas:

• Extraemos la información una sola vez de los sistemas transaccionales.
• Permite que los procesos ETL se conecten a los Stagin Area a la hora que sea sin comprometer la operatividad del negocio.
• Tenemos un mejor control sobre los procesos que extraen información de los sistemas transaccionales.

Entonces estarás pensando, listo, problema resuelto, cerremos todo y vamos a casa a descansar, sin embargo, hay una pequeña que no hemos sumado a la ecuación…. Los microservicios y las arquitecturas distribuidas, que es aquí donde todo comienza a complicarse, pues en lugar de tener grandes fuentes de datos, tenemos múltiples fuentes, donde cada una cuenta una parte de la historia y para poder tener toda la historia, necesitamos recopilar información de múltiples puntos.

Datalake

El problema ( o la ventaja, depende de como lo veas) es que en arquitecturas de microservicios no tenemos enormes sistemas desde los cuales obtener los datos, si no que es necesario recopilar datos de varias fuentes solo para poder crear un reporte:

Bajo esta arquitectura se hace impráctico tener múltiples Stagin Area, ya que se tendrían que mantener demasiadas bases de datos, por eso, se propone los Datalake o Lagos de datos, los cuales cambian considerablemente la forma en que los datos se extraen y se procesan.

Un lago de datos es básicamente un vertedero donde son las mismas aplicaciones quienes dejan los datos, en lugar de ser extraídos por un proceso, por otra parte, un Datalake es único, esto quiere decir todas las aplicaciones dejan los datos en el mismo lugar. Creando un lago de datos donde los demás procesos se pueden servir.

Este enfoque puede resultar controversial, pero a medida que avancemos en este artículo, iremos resolviendo algunas dudas que puedan surgir, así que por lo pronto, solo ve analizando esto.

Lo primero que debemos entender respecto al Datalake es que son las mismas aplicaciones las que deciden que información mandar al lago y el formato de la misma, por que cada aplicación es dueña de su parte del lago. De la misma forma, esta tiene la libertada de agregar, quitara o modificar la estructura de la misma, ya que cada aplicación determina que y como la información se envía al Datalake. Aunque claro, siempre será mejor no hacer cambios demasiados bruscos.

Otro aspecto del lago es que la información es incremental y no está procesada, esto quiere decir que los sistemas van depositando solamente la nueva información (aun que podrían borrar y cargar toda la data), pero al mismo tiempo, la información no está procesada al momento de dejarla en el lago, si no que se deja en bruto.

En este nuevo enfoque son los interesados los encargados en buscar que información les sirve y cual no, al mismo tiempo que se puede obtener información de múltiples aplicaciones de forma simultánea. Ha esto yo le llamo los ríos del lago, ya que cada interesado deshoja del lago la información que le sirve para su propósito para dejarla en un data warehouse ya procesada:

Este enfoque es especialmente útil en entornos de Big Data y análisis de datos, ya que todos los sistemas van depositando la data en bruto en un mismo lugar, lo que facilita para que los científicos de datos puedan explotar la información, además, es posible contrastarla con la data de los demás sistemas.

Reservas respecto a la seguridad

Uno de los aspectos más cuestionados sobre este enfoque es la seguridad de los datos, ya que una persona con acceso total al lago tiene visión completa de lo que pasa en todos los sistemas, lo cual no es una observación menor, por lo que hay que tener especia cuidado sobre los accesos que damos a este. No hay una formula clara o única para resolver esto, salvo que limitar bien el acceso al lago y tener acuerdo de confidencialidad bien estipulados.

The post Datalake una nueva forma de análisis de datos appeared first on Oscar Blancarte - Software Architecture.

Uno de los principales problemas en arquitecturas distribuidas es garantizar que múltiples ejecuciones con los mismos parámetros sobre el mismo recurso afectará al sistema como si se hubiera ejecutado 1 o N veces.

En realidad la idempotencia es un término matemático que dice “la idempotencia es la propiedad para realizar una acción determinada varias veces y aun así conseguir el mismo resultado que se obtendría si se realizase una sola vez”. Sin embargo, no quiero aburrirte con matemáticas, así que lo trataremos de explicar desde el punto de vista del software.

La importancia de la idempotencia

A pesar de que el termino idempotencia no es muy conocido, los problemas que pueden producir son mucho más frecuente de los que podríamos pensar, así que para comprender mejor su importancia analicemos el siguiente caso.

Tenemos una aplicación móvil que levante pedidos de los clientes, por tal motivo, la aplicación la tiene instalada varios vendedores que están en la calle ofreciendo los productos. Cuando un cliente quiere comprar alguno de nuestros productos, el vendedor levante el pedido desde la aplicación y posteriormente lo envía a nuestro ERP para procesar el pedido y programar la entrega del mismo.

Hasta aquí todo bien, pues es la clásica aplicación de creación de pedidos, sin embargo, un problema muy frecuente con las aplicaciones móviles es la conectividad con Internet, ya que hay zonas en las que no hay buena recepción o simplemente está no se tiene acceso al servicio, en tal caso, la aplicación lo que hace es que guarda el pedido en el celular y posteriormente lo sincroniza con el ERP.

Cuando la aplicación envíe el request al ERP, enviará un mensaje como el siguiente:

URL: https://myapp.com/orders
Method: POST
Headers:
   Accept: application/json
   Content-Type: application/json
Body:
{
	"customer": "oscar",
	"regDate": "2021-01-29T12:00:00Z"
	"productos": [
		{
			productId: 1,
			quantity: 10
		}
	]
}

Y obtendrá una respuesta como la siguiente:

URL: https://myapp.com/orders
Status: 201 CREATED
Headers:
   Content-Type: application/json  
Body:
{
	"id": 1,
	"customer": "oscar",
	"regDate": "2021-01-29T12:00:00Z"
	"productos": [
		{
			productId: 1,
			quantity: 10
		}
	]
}

Esto que estamos viendo es el escenario ideal, donde cada solicitud al servidor tiene una respuesta, sin embargo, es posible que durante el proceso de sincronización el pedido sea recibido por el ERP, pero por problemas de conectividad, la aplicación móvil no reciba la respuesta del ERP, lo que dará como resultado que el ERP creará el pedido, pero la aplicación móvil no tendrá una respuesta, por lo que el usuario asumirá que hay un problema con el envío, así que reintentará enviar nuevamente el pedido, lo que provocará que una solicitud idéntica a la anterior sea enviada al servidor, y una nueva orden sea creada en el ERP. Si este error continúa, el usuario seguirá enviando el pedido al ERP hasta tener éxito, lo que provocaría que tuviéramos N pedidos en el ERP.

Otro caso similar se da cuando por errores en el diseño de la aplicación,  el usuario puede presionar repetidas veces el botón de guardar sin que este se bloqué hasta recibir una respuesta. Este caso provoca que el usuario pueda enviar N veces la misma solicitud al servidor, creando también N pedido en el ERP.

Otro caso en el que se puede presentar este problema es cuando enviamos las solicitudes de creación por colas de mensajes (Queue), ya que no hay garantía de que un mensaje que enviemos sea entregado al destinatario, así que es posible que reenviemos el mensaje en más de una ocasión.

Cómo sortear la idempotencia

Bueno, en este punto creo que ya nos queda claro el problema con aplicaciones que no tiene presente este problema, así que ahora nos enfocaremos en como evitar este problema para cumplir con el principio de la idempotencia.

Aunque existen varias formas de evitar este tipo de problemas, sobresalen dos técnicas que son las más utilizadas, las cuales explicamos a continuación:

Identificador Virtual

Esta técnica se utiliza sobre en todos en entornos síncronos, donde el cliente se queda esperando hasta obtener la respuesta, y consiste en dos pasos.

El consumidor deberá solicitar al servidor la creación de un identificador virtual del objeto que va a crear, en este caso, podría tener un servicio que regresa un identificador para un pedido, de esta forma, el cliente primero solicita la creación del identificador mediante un payload vacío:

URL: https://myapp.com/orders
Method: POST
Headers:
   Accept: application/json
   Content-Type: application/json
Body:

Como resultado, el servidor le regresará el identificador generado del lado del servidor, tal y como se muestra a continuación:

URL: https://myapp.com/orders
Status: 201 CREATED
Headers:
   Content-Type: application/json  
Body:
{
	"id": 1
}

Ya con el identificador creado del lado del servidor, se puede procede a actualizar el pedido con el identificador retornado por el servidor mediante una segunda llamada al API:

URL: https://myapp.com/orders/1
Method: PUT
Headers:
   Accept: application/json
   Content-Type: application/json
Body:
{
	"customer": "oscar",
	"regDate": "2021-01-29T12:00:00Z"
	"productos": [
		{
			productId: 1,
			quantity: 10
		}
	]
} 

Podrás observar dos cambios significativos en este segundo request, y es que el ID del pedido ya no viaja a nivel del Payload, si no que lo enviamos como parte de la URL, ya que estamos realizando una actualización concreta sobre un pedido del cual ya conocemos el identificador.

El segundo cambio importante es que realizamos la llamada por el método PUT en lugar del método POST, ya que estamos actualizando el pedido.

Desde luego que esta estrategia plantea nuevos problemas, por ejemplo, que pasa si ejecuto el servicio para crear el identificador y no obtengo una respuesta. Este escenario sería parecido al problema original, ya que el servidor si crearía el identificador virtual, sin embargo, este solo sería un identificador y no un pedido, por lo que podríamos crear cuantos identificadores virtuales sin precisamente crear pedidos.

La segunda duda es, que pasaría si envío la solicitud de actualización (PUT) en más de una ocasión, pues bien, la respuesta es simple, por que solamente la estamos actualizando, por lo que si se envía en más de una ocasión solo actualizaremos el registro existente, no creando nuevos registros.

Identificador Único Universal (UUID)

Esta estrategia consiste en que cada objeto que es creado, debe ser asociado a un Identificado Único Universal (UUID), el cual deberá ser asignado en el momento en que un objeto es creado por primera vez, de esta forma, el sistema que crear por primera vez un objeto, será el responsable de asignar este identificador.

Un dato importante a resaltar es que el UUID puede ser independiente del Identificador de base de datos (llave primaria), ya que más bien, el UUID será un identificado de integración,  de tal forma que podrá ser replicado por todos los sistemas por lo que viaje, de esta forma, es posible rastrear un objeto en todos los sistemas por lo que pase.

En este orden de ideas, podemos ver que el flujo de creación de ordenes se ve de la siguiente forma. Cuando el usuario levante un pedido en la aplicación móvil, la misma aplicación le genera un UUD, luego, cuando quiere enviar el pedido al ERP, este lanza un request como el siguiente:

URL: https://myapp.com/orders
Method: POST
Headers:
   Accept: application/json
   Content-Type: application/json
Body:
{
	"UUID": "2da46052-584f-11eb-ae93-0242ac130002",
	"customer": "oscar",
	"regDate": "2021-01-29T12:00:00Z"
	"productos": [
		{
			productId: 1,
			quantity: 10
		}
	]
}

Si prestamos atención en el request anterior, podemos observar dos cosas, la primera es que el request es sobre el método POST, lo que quiere decir que efectivamente estamos solicitando la creación de un nuevo pedido. El segundo punto es que estamos enviando el parámetro UUID como parte del objeto del pedido. Mas adelante analizaremos que implica todo esto, por ahora veamos el resultado de esta ejecución:

URL: https://myapp.com/orders
Status: 201 CREATED
Headers:
   Content-Type: application/json  
Body:
{
	"id": 1,
	"UUID": "2da46052-584f-11eb-ae93-0242ac130002",
	"customer": "oscar",
	"regDate": "2021-01-29T12:00:00Z"
	"productos": [
		{
			productId: 1,
			quantity: 10
		}
	]
}

En la respuesta podemos ver que el servidor nos arrojado nuevamente el UUID que le enviamos para la creación, pero además, nos retorna el ID, lo cual puede resultar confuso, pues ahora tenemos dos Identificadores, sin embargo, cada uno juega una papel diferente, pues el Id es el identificar único del pedido en el ERP, mientras que el UUID es el identificar universal, por lo que ahora es posible relaciona el pedido en la app móvil con el del ERP mediante este identificador, además, si este pedido tiene que ser replicado del ERP a otro sistema, puede seguir usando el mismo UUID para sincronizarlo con el este tercer sistema.

Pero bien, pasemos a los que nos interesa, que pasa ahora si enviamos la misma solicitud más de una vez. Pues bien, si volvemos a enviar este misma solicitud al ERP, este podrá detectar que ya existe un pedido asociado con ese UUID, por lo que pueden pasar dos cosas, la primera es que marque un error al crear el pedido, indicando que el pedido ya existe, o en su lugar realizar un update del pedido, de esta forma, si la primera solicitud creo el pedido, la segunda solicitud no creará un nuevo pedido, si no más bien, solo lo actualizará, por lo que en cliente recibirá el mismo Id con cada ejecución.

Conclusiones

Como hemos podido analizar el principio de idempotencia es un problema que se puede presentar muchas más veces de lo que parecería, por lo que es importante garantizar que el sistema se comporte adecuadamente aun cuando el mismo request sea enviado muchas veces, sobre todo en sistemas distribuidos.

También analizamos dos formas se garantizar el principio de idempotencia, y cada estrategia se podrá adecuar mejor a cada situación, sin embargo, creo que la estrategia por UUID es la mejor, ya que es mucho más simple de implementar, pero sobre todo, permite una rastreabilidad entre todos los puntos de la integración, ya sea entre dos sistemas o varios sistemas y puntos intermedios, como colas de mensajes o persistencia en base de datos.

Finalmente, en este artículo nos centramos en las peticiones por HTTP, como es el caso de REST, pero cabe mencionar que este problema se da con cualquier tipo de tecnología o protocolo de comunicación, por lo que no es un problema ajeno solo a REST.

The post El principio de idempotencia appeared first on Oscar Blancarte - Software Architecture.

Hola, aquí Oscar Blancarte,

Estamos muy contentos por anunciar que hemos publicado el nuevo curso de Python Core Essentials, el cual busque enseñarte a utilizar Python desde cero, donde aprenderemos desde la instalación hasta terminar un proyecto final con conexión a la base de datos.

Este curso está diseñado para cualquier persona, incluso si no tiene nada de experiencia en Python u otro lenguaje y busca que aprendas lo siguiente:

• Sintaxis básica
• Ciclos y estructuras de control
• Dominio de las variables y tipos de datos
• Arreglos y estructuras de datos
• Programación Orientada a Objectos (POO)
• Conexiones con bases de datos
• Introducción a los frameworks más importantes

Todo esto lo aprenderás mediante un proyecto final que se desarrollará a lo largo del curso.

Finalmente, déjame recordarte que ya tenemos un plan de suscripción mensual o anual, con el que podrás acceder a todos los cursos por solo 19usd al mes o puedes suscribirte todo el año pagando solo 10 meses y nosotros te regalamos los otros dos.

Además, ya se viene varios cursos más en los próximos días, como es el caso del curso de PHP, Arquitectura de software, C#, uso de terminales con Linux, y el curso profesional de GIT. que podrás acceder sin costo con tu suscripción.

The post Nuevo curso de Python appeared first on Oscar Blancarte - Software Architecture.

La documentación de un API es casi tan importante como construirlos con buenas prácticas, pues su finalidad es que terceros la utilicen, por tal motivo, documentarla correctamente puede representar el éxito o fracaso en su implementación dentro de los sistemas de terceros:

Codigo fuente: Antes que nada, puedes descargar todo el código fuente en: https://github.com/codminddev/blog-spring-boot-swagger

La documentación de un API es casi tan importante como construirlos con buenas prácticas, pues su finalidad es que terceros la utilicen, por tal motivo, documentarla correctamente puede representar el éxito o fracaso en su implementación dentro de los sistemas de terceros:

Por suerte, Spring Boot cuenta con la librería de Swagger que permite analizar todo el proyecto y auto documentar todos los servicios REST que encuentre de forma automática. De esta forma, nos ahorramos una gran cantidad de trabajo de documentación. Por ejemplo, veamos el siguiente servicio:

@RestController
public class UserController {
	
	private List<UserDTO> users = new ArrayList<>();
	
	public UserController() {
		users.add(new UserDTO(1L, "admin"));
		users.add(new UserDTO(2L, "supervisor"));
		users.add(new UserDTO(3L, "cajero"));
	}

	@GetMapping(value = "users")
	public ResponseEntity<List<UserDTO>> findAll(){
		return ResponseEntity.ok(users); 
	}
	
	
	@PutMapping(value = "users")
	public ResponseEntity<UserDTO> update(UserDTO request){
		UserDTO user = users.stream()
				.filter(currentUser -> currentUser.getId() == request.getId())
				.findFirst()
				.orElseThrow(() -> new RuntimeException("No existe el usuario"));
		user.setName(request.getName());
		return ResponseEntity.ok(user);
	}
	
	@PostMapping(value = "users")
	public ResponseEntity<UserDTO> create(UserDTO request){
		users.add(request);
		return ResponseEntity.ok(request);
	}
	
	@DeleteMapping(value = "users/{userId}")
	public ResponseEntity<?> delete( @PathVariable("userId") long userId ) {
		UserDTO user = users.stream()
		.filter(currentUser -> currentUser.getId() == userId)
		.findFirst()
		.orElseThrow(() -> new RuntimeException("No existe el usuario"));
		users.remove(user);
		return ResponseEntity.ok().build();
		
	}
}

Podrá observar el clásico servicio CRUD de usuarios, donde tenemos un servicio para consultar todos los usuarios (GET), crear nuevos (POST), actualizarlos (PUT) y finalmente eliminarlos (DELETE).

Por suerte, Swagger es tan potente que puede aprovecharse del API de reflection para analizar la estructura de los métodos, sus anotaciones y los parámetros de entrada y salida para auto documentar el API, tal como se puede ver en la siguiente imagen:

Instalación

Para lograr esto, es requerido solamente dos pasos, agregar las librerías de Swagger y crear un objeto de configuración llamado Docket, veamos cómo sería:

Lo primero es agregar las siguientes librerías en el archivo pom.xml:

<dependency>
	<groupId>io.springfox</groupId>
	<artifactId>springfox-swagger2</artifactId>
	<version>2.9.2</version>
</dependency>

<dependency>
	<groupId>io.springfox</groupId>
	<artifactId>springfox-swagger-ui</artifactId>
	<version>2.9.2</version>
</dependency>

La primera (springfox-swagger2) es la más importante, pues es que se encarga de analizar la estructura de nuestro proyecto y crear los metadatos para crear la auto documentación del API. La segunda (springfox-swagger-ui) es que se encarga de tomar los metadatos de la primera y crear una interfaz gráfica amigable con los usuarios.

Configuración

El segundo paso es crear el archivo Docket, mediante el cual le indicamos a Swagger que es lo que debe de tomar en cuanta al momento de crear la documentación. Para esto, debemos de crear una clase que este anotada con @Configuration y @EnableSwagger2 y tenga un método que cree el objeto Docket:

@Configuration
@EnableSwagger2
public class SwaggerConfig {

	@Bean
	public Docket apiDocket() {
		return new Docket(DocumentationType.SWAGGER_2)
				.select()
				.apis(RequestHandlerSelectors.basePackage("com.codmind.swaggerapi.controllers"))
				.paths(PathSelectors.any())
				.build()
				.apiInfo(getApiInfo())
				;
	}
	
	private ApiInfo getApiInfo() {
		return new ApiInfo(
				"Order Service API",
				"Order Service API Description",
				"1.0",
				"http://codmind.com/terms",
				new Contact("Codmind", "https://codmind.com", "apis@codmind.com"),
				"LICENSE",
				"LICENSE URL",
				Collections.emptyList()
				);
	}
}

Dentro del método apiDocket construimos el objeto Docket, en el cual le indicamos que tome todos los servicios que se encuentre en el paquete com.codmind.swaggerapi.controllers y los auto documente por nosotros.

Finalmente, en el método getApiInfo, creamos el objeto ApiInfo, el cual define los datos de la propiedad del API, como su nombre, correo de contacto, licencia, etc.

La ejecución

Si todo salió bien y corremos la aplicación, veremos el siguiente log:

Podrás ver que nos ha generado un path llamado /v2/api-docs, por lo que si los accedemos en el navegador (http://localhost:8080/v2/api-docs) podremos ver los metadatos del API generado por la librería springfox-swagger2:

Sin embargo, esta documentación no es para nada intuitiva, y es por ello que hemos instalado la librería springfox-swagger-ui, la cual toma esta metadata y crea la URL: http://localhost:8080/swagger-ui.html, la cual se ve así:

En esta página podemos apreciar 3 secciones, la primera corresponde al objeto ApiInfo, que contiene nombre del API, licencia, datos de contacto, etc.

La segunda sección corresponde a los servicios, agrupados por controlador. En este caso, podemos apreciar el UserController (user-controller) con las 4 operaciones CRUD que hemos definido.

Finalmente, tenemos la sección de Models (modelos), la cual describe todos los objetos que utilizamos como request/response.

Probando el API

Finalmente, si expandimos cualquier servicio, por ejemplo, el método create (POST) y presionamos el botón Try It Out, podremos probar el servicio allí mismo:

Nos desplegará los campos esperados por el servicio y si damos click en la sección Model, podrás ver la estructura de la respuesta esperada.

Conclusiones

Documentar solo este servicio, nos podría tomar varias horas, ya que es necesario documentar su nombre, los parámetros que recibe, los retorna y además, habría que describir cada unos de los objetos que recibe y responde, para que los consumidores tengan claridad de la estructura de cada uno de estos, pero como hemos podido comprobar, mediante Swagger nos evitamos todo este trabajo.

The post Documentar un API REST con Swagger y Spring Boot appeared first on Oscar Blancarte - Software Architecture.

La configuración es una de las partes más importantes de cualquier aplicación, pues permite que se pueda configurar según el entorno de ejecución o el ambiente en el que se desplegará, por suerte Spring boot cuenta con el archivo application.properties, en el cual podemos guardar todos aquellos valores que pueden cambiar con el tiempo, lo que evita la mala práctica de crear código hardcode o código duro.

Pero la pregunta es, como podemos acceder a estar propiedades desde una aplicación, pues bien, gracias a la inyección de dependencias que caracteriza a Spring Boot, es posible inyectar cualquier propiedad mediante la anotación @Value, tal como se puede ver a c continuación:

@Configuration
public class ConverterConfig {
	@Value("${path.to.prop.name }")
	private String myProp;
}

Y el archive application.properties quedaría de la siguiente forma:

path.to.prop.name=my value

Esto aplica exactamente igual cuando con un archivo application.yml:

path:
 to:
  prop:
   name:my value

Mediante esta técnica ya no necesitarás poner código duro nunca más.

The post Spring boot – Inyectar propiedades con @Value appeared first on Oscar Blancarte - Software Architecture.

Seguramente todos nos hemos encontrado alguna vez con que la petición a un servicio o un recurso de internet nos retorna con un Timeout, lo que significa que el servidor ha tardado tanto en responder que, el navegador o el cliente que estamos utilizando para consumir el recurso corta la comunicación, lo cual es muy frustrante, sin embargo, el Timeout es una de las estrategias más importantes para proteger la salud de nuestro servidor.

Problemática

Seamos sinceros, casi todo nos hemos topado con un Timeout al momento de consumir un servicio, y en lugar de controlar el error y hacer algo en consecuencia para que todo nuestro servicio no falle, simplemente aumentamos el Timeout. En algunos casos solamente le agregamos unos segundos adicionales y en el peor de los casos dejamos el Timeout en indefinido, lo que es una muy mala práctica.

Desafortunadamente, como programadores siempre buscamos la solución más fácil y la que requiere un menor esfuerzo de nuestra parte, lo cual nos lleva a establecer un Timeout indefinido, sin embargo, da igual si le pones 1 minuto o 10hrs, o indefinido, al final, si un servicio no responde a los pocos segundo, lo mas seguro es que no lo haga nunca, lo que provoca que no solo no obtengamos la respuesta del servidor, si no que ahora acarreamos un problema crítico a nuestra aplicación, la cual analizaremos con el siguiente ejemplo.

Imagina que estas construyendo un servicio para autorizar créditos. Este servicio debe de recibir como parte de la solicitud del crédito, los datos del cliente que lo esta solicitando, y luego deberá de consumir un servicio externo para validar el historial crediticio del cliente, según su calificación, se le podrá ofrecer o declinar el préstamo:

En este caso, nuestro servicio (CreditService) recibirá la petición de la solicitud de crédito y luego llamará al servicio de consulta del historial crediticio (CreditHistoryService), si todo sale bien, nuestro servicio obtendrá la respuesta del servicio anterior y podrá determinar si puede o no, ofrecerle el crédito a nuestro cliente.

Ahora bien, en una arquitectura distribuida donde tenemos múltiples servicios distribuidos por la red, siempre existirá la posibilidad de que uno de estos no esté disponible o simplemente nos arroje un Timeout, lo cual rompe por completo nuestro flujo, pues al no tener respuesta del servicio de historial crediticio, el error se propaga hasta al cliente, por lo que no será posible dale una respuesta:

Cual es el problema aquí, que como no queremos batallar y queremos reducir al máximo la posibilidad de error y garantizar el happy path, incrementamos el Timeout del servicio, lo cual es correcto si se hace dentro de un periodo de tiempo considerable, sin embargo, solomos abusar de esto y poner tiempo larguísimos como de 1 minuto o indefinido, lo que provoca que nuestro servicio se comience a saturar de peticiones entrantes y al no tener respuesta del servicio, nuestra aplicación se comienza a saturar de hilos:

Podrás ver que ahora los hilos se comienzan a acumular en nuestro servicio, ya que al no tener respuesta del servicio, no podemos concluir con la ejecución, y tras un largo periodo de tiempo o hasta que el cliente decida cortar la comunicación, veremos que todas las ejecuciones terminaran fallando, y en el peor de los casos, nuestra aplicación podrá verse seriamente afectada en los tiempos de respuesta por la gran cantidad de hilos vivos que tiene y finalmente caerse.

Solución

Para evitar este problema, es importante aceptar que los Timeout ocurren, y no solo eso, que pueden ocurrir mucho más de lo que nos gustaría, y es por ello que, en lugar de tratar de ocultar el problema, es mejor aprender a lidiar con ello, es por esto que, lo primero que debemos de hacer cuando consumimos recursos externos, es siempre definir un tiempo de espera máximo, de esta forma, somos nosotros los que cortamos la comunicación y procedemos con un plan B.

En esta nueva estrategia, siempre que lanzamos un request, definimos el tiempo de espera que estamos dispuesta a tolerar y si este tiempo de espera se excede, entonces cortamos la comunicación y hacemos algo en consecuencia. Dado que no podemos aprobar o rechazar la solicitud de crédito en ese momento, no podríamos darle una respuesta al cliente de inmediato, pero tampoco tendría necesariamente terminar en un error, ya que en lugar de regresarle un error, podríamos guarda la solicitud, decir al cliente al cliente que estamos procesando su solitud y que más tarde le notificaremos el resultado de la autorización.

Con esta nueva arquitectura no solo hemos quedado bien con nuestro cliente, si no que evitamos que los hilos de ejecución se acumulen en nuestro servidor, evitando que este degrade sus tiempos de respuesta o finalmente muera.

Conclusiones

Como programadores siempre queremos asumir que todos los servicios responderán correctamente, y de esta forma lavarnos las manos diciendo que si nuestro servicio falla, es por culpa de otros, sin embargo, nuestra responsabilidad como buenos desarrolladores es hacer aplicaciones resilientes, que puedan recuperarse ante un error y responder adecuadamente.

Como hemos analizado en este artículo, nunca hay que asumir que todos puede salir mal, al contrario, siempre hay que ser desconfiados y plantearnos que pasarían ante un error, en este caso, ante un Timeout.

The post La importancia del Timeout appeared first on Oscar Blancarte - Software Architecture.

La llegada de la nube ha cambiado para siempre la forma en que consumimos software, pasando de tener que instalar una aplicación en nuestro equipo, ha simplemente acceder a un sitio web para tener acceso a toda nuestra información, pero la pregunta clave aquí es, ¿cómo es que una aplicación que vive en la nube, puede albergar múltiples clientes y al mismo tiempo mantener separada la información? Bueno, para resolver esta pregunta tenemos el termino Multi-Tenancy.

Multi-Tenancy es un principio de arquitectura de software donde una aplicación puede albergar a múltiples clientes, de esta forma, todos trabajan sobre la misma instancia de software que se ejecuta en el mismo servidor, con la única diferencia de que los datos que pueden ver cada cliente son diferentes, logrando un efecto en el que la aplicación se pueden ver como si fuera construida exclusivamente para uno de ellos.

Para poner un ejemplo claro de Multi-Tenancy que todos podremos comprender, hablemos de Gmail. Seguramente todos aquí tenemos una cuenta de correo en esta aplicación, sin embargo, cuando entramos solo podemos ver nuestros correos, a pesar de que seguramente existen millones de correos electrónicos en toda la plataforma. De esta misma forma, podemos personalizar la forma en que se visualiza la página, ya que podemos cambiar la forma en que organizamos los correos, las carpetas, colores, logotipo (si es una cuenta empresarial), etc. Sin embargo, cada una de estar personalizaciones solo podrán ser observadas por el dueño de ese cliente y nada más.

Multi-Tenancy hace posible que existan muchas de las aplicaciones que hoy conocemos como SaaS ( Software as a Service), en la cual pagamos (o no) una renta mensual para utilizar, como puede ser el mismo Gmail, Trello, Netflix, YouTube, Salesforce, Twitter, Facebook, etc.

La pregunta ahora es, como es que estas aplicaciones logran separar la información de sus clientes. Para empezar, sería buen aterrizar el termino Multi-Tenancy, que si lo traducimos al español sería algo así como “Multi inquilino” o “Multi usuario”.  Una aplicación Multi-Tenancy la podemos comparar con un edificio de apartamentos, donde todos los inquilinos viven en el mismo edificio, utilizan la infraestructura general de este, como lo es, personal de seguridad, áreas comunes,  elevadores, etc., sin embargo, y a pesar de que viven en el mismo edificio, no viven en el mismo lugar, pues cada uno tiene su propio apartamento, donde pueden guardar sus pertenencias de forma seguras, y la única personas que puede acceder, sería su dueño(s).

Siguiendo esta misma analogía en una aplicación Multi-Tenancy, el edificio completo sería la aplicación, y cada apartamento sería su información. En este sentido, podrás observar que todos los usuarios hacen uso de la misma aplicación,  pero la información permanece asilada entre los diferentes usuarios.

Creo que a nivel conceptual esto puede resultar fácil de entender, sin embargo, implementarlo en una aplicación real no es tan simple, ya que hay que tener mucho cuidado de aislar correctamente la información de los diferentes usuarios, ya que de lo contrarios, estaríamos exponiendo información privada a otros usuarios.

Formas de implementar una aplicación Multi-Tenancy

Básicamente existen tres formas de lograr que una aplicación sean Multi-Tenancy, las cuales son las siguientes:

DB y esquema compartidos (Shared DB, Shared Schema)

Este es la forma más simple de crear una aplicación Multi-Tenancy, la cual consiste en compartir una misma base de datos y esquema para todos los usuarios registrados:

Para lograr la separación de la información, se suele segmentar la información por columnas en la DB, de esta forma, cada registro indica a que Empresa o usuario pertenece y cada uno de los Query que lancemos a la base de datos deberá de contemplar este campo dentro del WHERE, para evitar que la información se mescle:

SELECT * FROM ORDERS WHERE TENANT = ?

En este caso, el WHERE es la única forma de segmentar la información, ya que en caso de omitir ese filtro, se podría mostrar información de todos los demás clientes, o incluso, borrar datos que no son de ese cliente en particular.

Solo por poner un ejemplo, mi plataforma de cursos Codmind yo la he construido desde cero utilizando esta estrategia, ya que en una sola base de datos tengo la información de todos mis clientes, separando la información por el ID del usuario.

Ventajas:

• Fácil de implementar: como lo mencioné al inicio, este método es el más simple, pues con solo agregar filtrar los registros mediante una columna, es posible segmentar la información.
• Cero configuraciones: Cada que un nuevo cliente se registra, solo hace falta registrarlo en la DB y comenzar a segmentar su información según su TenantID.
• Fácil de mantener: Dado que solo tenemos una DB, es muy simple darle mantenimiento y respaldar la información.

Desventajas:

• Aislamiento: Dado que toda la información está en la misma base de datos, es mas propenso a que mesclemos información de los clientes.
• Seguridad: Si el acceso a los datos se ve comprometida, el atacante tiene acceso a la información de todos los clientes. Por otra parte, cuando le damos acceso a un programador a la DB, automáticamente tiene acceso a la información de todos los clientes, aun cuando solo quiera analizar un problema con un cliente determinado.
• Escalamiento: Dado que toda la información vive en una sola DB, es escalamiento se ve limitado hasta el número de transacciones que un solo manejador de base de datos pueda soportar.
• Disponibilidad: La disponibilidad entera de la aplicación depende de una sola base de datos, por lo que si se cea, todo el sistema se muere.

DB compartida, diferente Schema

Este método es muy similar al anterior, ya que los clientes comparten la base de datos, con la única diferencia de que la información se almacena en schemas diferentes:

Esta técnica permite un mejor aislamiento de la información, pues cada schema tiene un usuario diferente y cada uno de estos tiene una replica de las tablas, por lo que ya no es necesario segmentar la información mediante el WHERE del query, en su lugar, el reto consiste en conectarnos al Schema correcto según el cliente que está realizando la solicitud.

Ventajas:

• Mejor Aislamiento: Esta técnica tiene un mejor aislamiento que la estrategia anterior, pues cada cliente tendrá su propio schema, sin embargo, aun tenemos el problema de que con un usuario administrado de la DB es posible acceder a todos los Schemas.
• Optimización de la infraestructura: Dado que varios clientes pueden utilizar la misma base de datos, es posible compartir los recursos del servidor, de esta forma, si un cliente tiene poca demanda, deja los recursos para los clientes que consumen mas recursos, de esta forma evitamos tener recursos no utilizados y que estemos pagando.
• Escalamiento: Dado que las conexiones son por schema, esto permite tener múltiples bases de datos con múltiples schemas, por lo que podemos crear más servidores de base de datos a medida que el número de clientes aumenta.

Desventajas:

• Mantenimiento: Al tener múltiples schemas, es necesario crear mecanismos que creen los schemas de forma automática cuando un nuevo cliente se registre, además de que hay que darles soporte de forma separada.
• Respaldo: El respaldo de vuele una tarea un poco más complicada, porque ahora hay que gestionar un respaldo por cada schema.
• Configuración: Debemos preparar al sistema para conectarse dinámicamente a diferentes fuentes de datos, lo que puede representar un reto de ingeniería del lado del servidor.

Una base de datos por Inquilino (Database per Tenant)

Esta técnica consiste en que cada cliente utiliza una base de datos totalmente separada, lo que implica que tengamos una base de datos por cliente

Esta es la estrategia que permite el mayor nivel de aislamiento y seguridad, pues separar por completo la información de cada usuario en su propia base de datos, pero también implica el mayor esfuerzo en configuración, pues se tendrá que crear una nueva base de datos por cada cliente que se registre. Además, cada servidor de base de datos consume recurso del lado del servidor, los cuales estarán reservados, los utilice o no.

 Ventajas:

• Seguridad: Dado que cada base de datos es independiente, proporciona el mejor nivel de seguridad, pues de comprometerse una base de datos, solo afectará a un cliente y no a todos.
• Aislamiento: relacionado con el anterior, cada base de datos contiene la información de un solo cliente, lo que hacer muy difícil mesclar información entre clientes.
• Escalamiento: Dado que cada cliente utiliza su propia base de datos, es posible escalar los recursos de cada cliente a medida que estos crecen. Además, la carga de la base de datos no se comparte entre clientes, pues cada uno tiene su propia base de datos.
• Disponibilidad: Dado que cada cliente tiene su propia base de datos, si alguna se cae, no afecta al resto de clientes.

Desventajas:

• Mantenimiento: Las múltiples instancias de las bases de datos hace más complicado el mantenimiento, pues se tendrá que cuidar N servidor de base de datos.
• Respaldo: Hacer respaldos se hace una tarea complicada, pues habrá que configurar proceso que se conecten a múltiples servidores para hacer los respaldos.
• Configuración: En esta arquitectura no basta con clonar los schemas, si no que es necesario levantar dinámicamente más servidores que alberguen las nuevas bases de datos.
• Costo: Dado que es necesario tener bases de datos separadas, también será necesario contar con servidores de base datos separados, lo que puede incrementar los costos operativos.

Conclusiones

Las aplicaciones Multi-Tenancy llegaron para quedarse, incluso, creo que en un futuro, todas las aplicaciones que utilizaremos serán bajo este principio, ya que nos permite accederlas desde cualquier lugar y cualquier equipo, algo muy diferente a las aplicaciones a las aplicaciones convencionales, donde tenemos que estar en la computadora donde instalamos el software o de lo contrario no tenemos acceso ni al software, ni a la información. Otra de las ventajas que ofrece es que no requiere configuración e incluso, muchas de las veces son gratuitas, o al menos hasta cierto tiempo o uso.

Creo que hoy en día, todos los productos de software que creemos, deberán estar enfocados al Multi-Tenancy, ya que nos permite llegar a más clientes, además que el modelo por suscripción ha demostrado ser más rentable que el pagar una cuota fina por licencia (sin contar que evitamos la piratería).

NOTA: Estoy pensando en escribir un artículo de como implementar un sistema Multi-Tenancy usando Spring Boot, así que si te interesaría que lo escribiera, me gustaría que me lo comentaras, así puede que me anime a crearlo.

The post Multi-Tenancy | Principio de arquitectura de software appeared first on Oscar Blancarte - Software Architecture.

Hoy les quiero hablar de estos principios que como arquitectos de software nos encantan, pues nos permite expandir mas nuestro vocabulario y aprender de pasada algunas nuevas técnicas, en este caso, les quiero hablar del principio Command Query Separation (CQS), que en español sería algo así como “Separación de consulta y comando”, aunque en lo particular me gusta utilizar el término en inglés,  pues en español suena espantoso.

Pero bueno, basta de tonterías y pasemos a lo realmente interesante. Este principio fue acuñado por Bertand Meyer en su libro “Object Oriented Software Construction”.  Este principio dice básicamente que, deberíamos de separar los métodos de una clase en dos categorías, una de consultas (query) y otra de comandos (command).

• Query: son aquellos métodos que consulta información pero no modifican el estado de la aplicación.
• Command: son los métodos que actualizan el estado de la aplicación pero no retornan un valor.

Básicamente, este principio nos ayuda a construir software más mantenible y testeable, pues deja muy en claro que los métodos de consulta (query) solo consultará el estado de la aplicación, y por ningún motivo lo cambiarán, lo que permite utilizar todos estos métodos con toda seguridad y sin la preocupación de que estos actualizarán el estado. Pero por otra parte,  los métodos de comando (command) solo actualizarán el estado de la aplicación.

Para comprender este principio, podríamos comprar este principio con los métodos get y set de una clase:

public class Product {
	private Long id;
	private String name;
	
	public Long getId(){
		return id;
	}
	
	public void setId(Long id){
		this.id = id;
	}
	
	public String getName(){
		return name;
	}
	
	public void setName(String name){
		this.name = name;
	}
}

Podrás observar claramente que los métodos get y set solo sirven para consultar el estado de la clase pero sin actualizarlo, ahora bien, si nos vamos a los métodos set, podrás ver que su único objetivo es actualizar el estado, pero no retornan ningún valor (void).

A pesar de que este principio es relativamente fácil de comprender, no pasa lo mismo a la hora de llevarlo a la práctica, pues en muchas ocasiones es necesario crear método que actualicen el estado y retornen un valor, por ejemplo, un servicio que guardar un Producto en la base de datos y nos regrese el ID generado:

public Long save(Product product) {
	Long id = dao.persist(product);
	return id;
}

Y bueno, se que estarás pensando, quizás se pueda hacer de otra forma, ¿pero te has puesto a pensar como es posible recuperar el ID generado si no lo hace justo en el momento de la inserción?

Ahora bien, esto no ocurre solo con un servicio que inserta en la base de datos, existen cientos de casos muy similares donde este principio no se cumple, un ejemplo de esto es el legendario método pop de una pila, el cual saca el primer elemento y lo retorna, o que tal el método next de un iterador en Java, el cual retorna el siguiente elemento de una colección pero incrementa el apuntador al siguiente elemento, o que pasa por ejemplo con servicios auditables, donde tenemos que guardar un registro para saber cada vez que un usuario intento leer un recursos, algo muy similar a cuando un usuario se intenta autenticar sin éxito en varias ocasiones, lo que daría como resultado el bloque del usuario, pero entonces, si el login es solo una consulta, ¿cómo podríamos actualizar el contado de logins falidos?

Dicho lo anterior, no quiero parecer fatalista y decir que este principio no sirve, al contrario, creo que es un excelente principio que deberíamos de utilizar donde sea posible, y quiero hace un especial énfasis en la palabra “posible”, pues este principio no es la panacea, ya que como hemos expuesto en este artículo, no siempre podrá ser posible cumplirlo y eso está bien, pero habrá otros casos donde sí.

A modo personal, me gustaría pensar que este principio nos deja una enseñanza, la cual yo interpreto de la siguiente forma, “busquemos en la medida de los posible separar los método que consultan de los que actualizan, de tal forma que los consumidor sepan con certeza que un método solo consultará el estado y los otros solo para actualizarlo”, como nota final, yo dejaría como opcional que un método de comando (command) no retorne datos, ya que en la práctica vemos que es muy normal que este tipo de método retorna algún resultado.

Finalmente, yo agregaría que los nombres de los métodos deberían de cumplir cierta nomenclatura que deje muy claro la intención del método, ya que al igual que tenemos los métodosget y set, podríamos utilizar prefijos claros como:

Para actualizar

• set
• delete
• update
• create
• save
• remove
• change

Lo que nos darían nombres para métodos como: setName, updateOrder, deleteEmployee, removeUser, createCustomer, etc.

Para consultar:

• get
• find
• retrieve
• query
• search
• is

Estos nos darían nombres de método como: getName, findOrder, retrievePayment, queryUser, searchProduct, isActive, etc.

Conclusiones

Como siempre, me gusta dar una conclusión de lo que pienso, aun que debe de quedar claro que es una apreciación personal, por lo que tu podrías pensar diferente y eso está bien, ya que es parte del debate que podríamos tener.

Pues bien, lo que yo pienso es que este es un patrón que nos invita a separar claramente los método en dos categorías, lo cual está super bien por que hace el código más entendible, mantenible y testeable, sin embargo, yo veo que es un principio que romperemos más de lo que nos gustaría, lo que nos puede hacer creer que estamos creando código con malas prácticas, sin embargo, y como hemos demostrado en este artículo, en la práctica es difícil lograr en muchos casos cumplir al pie de la letra este principio, por lo que me mi recomendación es, trata de cumplirlo cuando puedas, pero no dudes en romperlo cuando sea necesario.

The post El principio CQS (Command Query Separation) appeared first on Oscar Blancarte - Software Architecture.

JavaScript es sin duda uno de los lenguajes más extraños en cuanto a su comportamiento, pues para muchos, se puede comportar de una forma impredecible, y uno de estos casos es algo llamado Hoisting, el cual es concepto para referirse a cómo funcionan el contexto de ejecución de JavaScript.

Si buscamos por Internet una definición de lo que es Hoisting, veremos que dice algo así como: “Las declaraciones de variables y funciones son enviadas físicamente al inicio del código”, sin embargo, esto no es del todo cierto, ya que si bien, si son enviadas al inicio del código, esto solo se hace en memoria, cuando JavaScript esta siendo interpretado por el navegador, sin embargo, los método y variables permanecen físicamente en el mismo lugar en donde fueron declaradas.

Básicamente la imagen anterior ilustra el concepto de Hoisting, pero la pregunta es, con qué intención JavaScript hace esto y por que no simplemente deja el código tal y como esta, bueno, la respuesta es simple, cuando JavaScript se ejecuta, carga todo el código en memoria para ejecutarlo, sin embargo, existe la limitante de que un método o variable no estará disponible si esta no ha sido definida antes de que sea utilizada, por tal motivo, si el Runtime de JavaScript ejecutara el código tal y como se ve del lado izquierdo, provocaría que el método helloworld no esté definido al momento de mandarlo a llamar, ya que la invocación se está haciendo antes de que la función fuera declarada, por este motivo, el Runtime coloca las variables y métodos al inicio, de esta forma, veremos algo como lo que vemos del lado derecho, donde el método es colocado al inicio del código y cuando se realice la llamada a la función, está ya estará definida.

Algo a tomar en cuenta es que tanto las variables como las funciones no se envían arbitrariamente al comienzo del código, sino que se envían al comienzo del contexto que las contiene, por ejemplo, una variable definida dentro de una función, será enviada al comienzo de la función, no de todo el código.

El ejemplo anterior es también un poco confuso, pues si observamos, tenemos dos variables llamadas a, una a nivel del archivo y otra a nivel del método, luego, cuando ejecutamos el método print, imprimimos la variable a, la cual se imprime como undefined, pero luego, declaramos la variable a = 20, e imprimimos nuevamente la variable, lo que ahora si nos arroja el valor 20.

¿Pero que diablos está pasando aquí?, pues bien, el Hoisting está haciendo nuevamente de las suyas, pues lo que en realidad está pasando es lo siguiente:

Observa como la variable a que está dentro de la función, en realidad está siendo llevada al comienzo de la función, pues la función es el contexto directo de la variable. Un dato importante a tomar en cuenta es que la asignación de la variable no se eleva al comienzo de la función, sino únicamente su declaración. Debido a esta elevación, a ya está disponible al momento de la primera impresión en pantalla, aun que su valor es undefined por que no se le ha asignado ningún valor. Es cuando a es igualada a 20, cuando la segunda impresión ya muestra el valor de 20.

The post Hoisting – Un concepto desconocido de JavaScript appeared first on Oscar Blancarte - Software Architecture.

El patrón Throttling permite controlar la cantidad de recursos que una aplicación puede utilizar antes de estrangular los procesos no esenciales a favor de mantener a flote el barco, evitando una interrupción del servicio o el incumplimiento de los SLA.

Problemática

Hoy en día es bastante común encontrarnos en situaciones donde nuestra aplicación recibe una carga inusual de trabajo, que pone en peligro el funcionamiento de la aplicación, a tal punto que puede ralentizar los tiempos de respuesta, abortar operaciones o finalmente, terminar tumbando la aplicación por completo.

Si bien, este tipo de problemas son fácilmente manejables con estrategias de autoescalado, tiene la limitante de que esto no es inmediato, si no que requiere breve periodo de tiempo para aprovisionar más instancias de un servicio determinado, lo que podrías dar lugar a una breve interrupción del servicio.

Puedes aprender más de escalamiento en mi artículo donde explico que es el escalamiento horizontal y vertical.

Solución

La solución que propone el patrón Throttling es permitir que la aplicación utilice recursos hasta cierto límite, y luego limitar (en realidad es estrangular, pero se escucha muy extraño) el funcionamiento de la aplicación para evitar comprometer los tiempos de respuesta o el funcionamiento total de la aplicación.

El termino estrangular (Throttling) puede resultar un poco confuso, pero se refiere a la capacidad de una aplicación o servicio priorizar el funcionamiento vital de la aplicación, y limitando o denegando el servicio a todos aquellos menos importantes.

Dicho lo anterior, existen varias formas en las que podemos limitar el uso de recursos de una aplicación, entre las que destacan:

1 – Limitar el número de peticiones

Una de las estrategias más ampliamente utilizada es el estrangulamiento por número de peticiones, que consiste en limitar el número de peticiones que un cliente puede realizar al servicio en un tiempo determinado, lo que obliga a la aplicación a medir el numero de solicitudes por cliente, y finalmente denegar el servicio cuando el umbral ha sido alcanzado.

Este enfoque es especialmente útil cuando ofrecemos un API a nuestros clientes, los cuales pueden utilizar a demanda cualquier servicio que proporcionemos, sin embargo, como no tenemos el control de cuantas llamadas realicen, es importante blindas nuestra API para que no hagan un uso irresponsable de los servicios que les proporcionamos y terminen degradando o tumbando el API.

Por ejemplo, hay casos donde un cliente utiliza técnicas irresponsables como el Pooling para consultar con demasiada frecuencia cierta información, lo que puede implicar el uso de una gran cantidad de recursos del servidor para atender cada petición.

Puedes leer más del patrón Pooling en el siguiente artículo de mi libro de arquitectura de software.

Pero el uso excesivo de los recursos del servidor no solo se puede dar por un uso irresponsable, si no que se puede dar el caso de que nuestro cliente presente un crecimiento natural en su operación, lo que implica un mayor número de peticiones al API, lo que implicaría un uso mayor al negociado al comienzo.

Throttling con Nginx

Una de las formas más simples de implementar el patrón Throttling por número de peticiones es utilizar Nginx, un proxy web que permite limitar el número de peticiones por medio de configuración:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=mylimit;
        
        proxy_pass http://my_upstream;
    }
}

El ejemplo muestra como limitar las llamadas al servicio de login (/login/) con una taza de 10 request por segundo (rate=10r/s).

Puedes ver el ejemplo completo en la documentación de Nginx (https://www.nginx.com/blog/rate-limiting-nginx/)

2 – Priorizar servicios esenciales

Otra de las estrategias más utilizadas para implementar el Throttling es limitar o denegar los servicios no esenciales, de esta forma, podemos simplemente denegar el servicio a ciertas operaciones hasta que el sistema se ve restablecido o utilizar una estrategia menos agresiva como degradar la calidad del servicio para permitir liberar recursos para que los procesos esenciales puedan seguir funcionando.

Para implementar esta estrategia es importante poder identificar cuales son los procesos vitales y cuales son prescindibles, de tal forma que podamos apagarlos o degradarlos de forma rápida, evitando que el sistema llegue a un estado de saturación.

Un ejemplo bastante contundente de esta estrategia es la que utilizo Netflix durante la pandemia del COVID-19, en el ancho de banda de Europa se saturó por la masiva cantidad de gente que se quedaba en casa y solo podría ver TV, lo que obligó a Netflix a degradar la calidad del servicio a HD en lugar de ofrecer 4K o Full HD.

3 – Distribución prioritarias de solicitudes

Esta estrategia se utiliza mucho en sistema multitenant, donde varios inquilinos utilizan la misma aplicación, sin embargo, se les ofrece un SLA diferente según el nivel de cada cliente. Mediante esta estrategia es posible priorizar los mensajes mediante de colas de mensaje de prioridad y atender estos mensajes según su prioridad, de esta forma damos prioridad a nuestros clientes premium y dejamos en espera o denegamos el servicio al resto de clientes.

Esta estrategia es muy utiliza por ejemplo en aplicaciones en la nube donde tenemos clientes gratuitos y clientes premium, lo que nos permite garantizar una experiencia constante a los clientes premium y a los clientes gratuitos los dejamos en espera hasta que el sistema se regulariza. Ya que al final, lo más importante es mantener contentos a los clientes que si esta pagando por el servicio.

Consideraciones

A pesar de que Throttling es un excelente patrón, no todo es felicidad, pues hay ciertas cosas que debemos de considerar antes de implementarlo, y que son clave para su éxito.

• Lo primero es más importante, la aplicación debe de a ver sido diseñada desde el comienzo para soportar esta capacidad, pues es necesarios desde el inicio, determinar los servicios vitales y de los que podemos preceder por un breve periodo de tiempo.
• Este patrón debe de actuar rápido, ya que ante un pico de demanda, si el patrón no estrangula rápidamente el servicio, puede que el servicio se degrade por un breve periodo de tiempo o incluso, se caiga antes de que el estrangulamiento entre.
• Es importante distinguir entre un error de la aplicación y uno de estrangulamiento, ya que de esta forma el cliente podrá saber el motivo por el cual su invocación está siendo rechazada.
• El estrangulamiento de puede utilizar como una estrategia temporal en lo que el autoescalado se lleva a cabo.
• Finalmente y no menos importante, el sistema deberá de tener la capacidad de regresar a su estado una vez que la carga de trabajo se ha normalizado, de lo contrario quedarán los servicios estrangulados por tiempo indeterminado.
• El estrangulamiento debe de ser un proceso automático y no manual, lo que quiere decir que este debe de entrar de forma automática por ciertas reglas determinadas y no por un operador que active y desactive componentes.

Cuando deberíamos de usar Throttling

• Cuando necesitamos garantizar el cumplimiento de los SLA a pesar de los picos altos de demanda.
• Evitar que un solo cliente monopolice los recursos del servidor.
• Para permitir la operatividad del servicio a pesar de un pico de demanda no esperado.
• En ciertas ocasiones nos pueden servir como una válvula para impedir que ciertas aplicaciones consuman más recursos de los esperados, sobre pasando un límite de facturación, muy parecido a lo que hacen lo que hace AWS o Azure en sus servicios en la nube.

Conclusiones

Throlling es uno de los patrones más utilizados para servicios que son habilitados para ser utilizados por terceros, donde no tenemos el control sobre la cantidad o demanda que puedan necesitar, logrando protegernos de picos de demanda no esperados o que sobre pasan un umbral esperado.

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