Una gran parte de las aplicaciones que se construyen hoy en día, requieren de un API para funcionar, dicha API ofrece todos los servicios necesarios para que la aplicación puede interactuar con el Backend y así afectar la información de la base de datos, sin embargo, de esa gran cantidad de aplicaciones que se conectan con APIs, requieren saber exactamente donde está alojado (IP y puerto) cada uno de los servicios que conforman el ecosistema de microservicios, es allí donde entra el Service Discovery pattern para solucionar ese tipo de dependencias.

Arquitectura tradicional

Para comprender exactamente cómo funciona el patrón Service Discovery es necesario entender cómo es que las aplicaciones que se conectan a un API normalmente:

Si analizamos la imagen anterior, nos podemos dar cuenta que la aplicación (APP) requiere leer una configuración local para saber dónde están alojados los servicios, este almacenamiento puedes ser un archivo de propiedades, una base de datos local o cualquier medio de persistencia. Una vez que la aplicación sabe dónde están los servicios, entonces ahora si realiza una llanada a ellos.

Una vez analizada la arquitectura pasada, veamos qué pasa si más aplicaciones son dependientes de los mismos servicios:

En esta arquitectura podemos ver que tenemos 3 aplicaciones que dependen de los mismos servicios, y cada uno de ellos tiene su configuración para determinar dónde están los servicios. Ahora imagina que algún servicio cambia de puerto o de dirección IP, lo cual es muy frecuente en una arquitectura Cloud donde la IP es flotante.

Tras cambiar la dirección (IP y puerto) del servicio, la aplicación empezará a fallar de forma inmediata, pues en su configuración le seguirá diciendo que el servicio está todavía en la antigua dirección, lo que nos obligará a cambiar a actualizar la configuración en todas las aplicaciones para apuntar a la nueva ruta del servicio.

Por otro lado, tenemos el caso de que tengamos más de una instancia del mismo servicio:

En estos casos, es posible que optemos por meter un balanceador de cargas, de tal forma que nosotros solo necesitamos comunicarnos con él, y será el balanceador quien finalmente reenvíe la petición a la instancia correspondiente. Este escenario es bastante prometedor y muchas aplicaciones funcionan así, pero aquí también tenemos el problema anterior, ¿qué pasa si una instancia cambia de dirección?, en este escenario no habría tanto problema, porque el balanceador redirigiría la petición a otra instancia, pero entonces ya solo nos quedamos con dos instancias operando, para resolver este problema, un administrador de servidores tiene que ir a la configuración del balanceador de cargas y actualizar con la nueva dirección del servicio. Como podemos ver, en esta arquitectura estamos más protegidos contra la falla o cambio de dirección de una instancia, sin embargo, el problema de la ruta física del servicio continua allí.

Y finalmente, el escenario más interesante de todos, imagina que tu arquitectura está funcionando muy bien, nada está fallando, pero el número de usuarios está en alza y requieres agregar una nueva instancia para soportar la carga, en tal caso tendrías que levantar una nueva instancia del servicio y nuevamente actualizar el balanceador de cargas para agregar el nuevo servicio.

Puede que esta arquitectura no tenga nada de extraño, incluso, es posible que algunas de las aplicaciones que estamos actualmente desarrollando estén configuradas de esta forma, pero entonces ¿qué tiene de malo utilizar esta arquitectura? Esta arquitectura no es que sea precisamente mala, pero tiene grandes inconvenientes que se acentúan a medida que migramos a una arquitectura de microservicios y tenesmos cada vez un número más grande de servicios, incluso, podemos tener más de una instancia de cada servicio.

Service Discovery pattern

Qué pasaría si no fuera necesario indicar en nuestras aplicaciones donde están físicamente los servicios y que, en lugar en su lugar, sean los mismos servicios que nos digan donde están físicamente, pues bien, eso es precisamente lo que nos propone el patrón Service Discovery.

La idea central de esta patrona es que todos los servicios cuando inician, se registran ante una entidad llamada Service Registry, el cual lleva el control de todos los servicios activos. De tal forma que cuando nosotros queremos consumir un servicio, buscamos en el Service Registry las instancias disponibles. Suena extraño esto que estoy diciendo, pero vallamos por partes, veamos como un servicio se registra:

En la imagen se puede apreciar como cada servicio se registra de forma individual, indicándole por lo menos, su nombre y la dirección en la que se encuentra el servicio, de esta forma, el Service Registry tiene un registro de todos los servicios que están disponibles. Adicional al registro inicial, los servicios tienen que mandar señales de vida cada X tiempo para que el Service Registry sepa que el servicio continúa disponible, ha esto se le conoce como heartbeat (latidos).

Si un servicio no se reportar (heartbeat), el Service Registry sabrá que hay algo mal en ese servicio y asumirá que no está disponible, por lo que todas las peticiones serán redirigidas a las demás instancias. Adicional, es posible que el Service Registry nos mande notificaciones cuando un servicio no está disponible para poder actuar en consecuencia.

Ya que hemos comprendido que es un Service Registry, continuaremos hablando del patrón Service Discovery. Este patrón nos permite ejecutar un servicio determinado sin conocer la dirección física del servicio, para esto, utilizamos un balanceador de cargas que se apoyará del Service Registry para conocer la ubicación real del servicio.

Esta nueva arquitectura funciona de la siguiente manera, primero que nada, los servicios se registrarán ante el Service Registry, con la finalidad de saber qué servicios tenemos disponibles, por otra parte, los clientes ejecutarán llamadas a los servicios por medio del balanceador de cargas, el cual se apoyará del Service Registry para determinar la dirección física del servicio y redireccionar la petición a la instancia correcta del servicio.

En esta nueva arquitectura, podemos ver los componentes que ya conocíamos, como los servicios, el Service Registry, el Balanceador de cargas y los clientes, por lo que seguramente te estés preguntando, que tiene de diferente esta arquitectura con la que hablamos al principio. Bueno la diferencia es muy grande, aunque de entrada no quede muy clara. Para empezar, ya no tenemos la necesidad de conocer la dirección física de los servicios, pues ellos mismo se registran al iniciar y nos permite saber su estado mediante el heartbeat, por otro lado, si aprovisionamos una nueva instancia de un servicio, este se registrará de forma automática ante el Service Registry, por lo que no habrá necesidad la configuración de ningún componente.

Por otro lado, el balanceador de cargas puede estar ubicado en dos puntos diferentes, a estas dos variantes se les conoce como Server-Side (del lado del servidor) o Client-Side (del lado del cliente). Debido a que cada uno tiene sus ventajas y desventajas, las analizaremos por separado:

Client-Side

En esta variante, el balanceador de cargas se ubica directamente sobre la aplicación, de tal forma que no requiere realizar una llamada remota al balanceador, en su lugar, la implementación local del Balanceador se comunicará con el Service Registry para obtener las instancias disponibles, y luego, desde la misma aplicación, se seleccionará la instancia a ser consumida.

Esta arquitectura puede verse algo confusa, pues parece un plato de espagueti, ya que cada aplicación se puede comunicar directamente con cada instancia de los servicios disponible, provocando que visualmente se vea más complicado de lo que parece.

Ventajas

1. No existen tantos puntos móviles, lo que evita tener que depender un balanceador externo.
2. Es más fácil de administrar, pues no es necesario administrar un balanceador externo
3. Dado que cada cliente implementa su propio balanceador, se evita un único punto de fallo.

Desventajas

1. Debido a que se une el cliente con el balanceador, hay que implementar el balanceador en cada aplicación que sea necesario.
2. Es necesario implementar la lógica de descubrimiento de servicios en el cliente.

Server-Side

En esta arquitectura, el balanceador de cargas es un componente externo, al cual todos los clientes se conectan, de esta forma, cuando una petición llega, el balanceador será el encargado de buscar la instancia adecuada por medio del Service Registry.

Esta arquitectura es visiblemente más limpia, pues los clientes solo se comunican con el balanceador de cargar y él se encargará se redirigir la petición al servicio adecuado. En esta arquitectura, el cliente no se preocupa por el descubrimiento de los servicios ni de balancear la carga entre las diferentes instancias de un mismo servicio. Adicional, es posible tener un cluster de Balanceadores de carga para evitar un único punto de fallo.

Ventajas:

1. Desacoplamos la responsabilidad del balanceo y descubrimiento de servicios por parte del cliente
2. Evitando tener que desarrollar esta funcionalidad en cada cliente.

Desventajas:

1. Es necesario administrar el balanceador de cargar, lo que puede llevar una carga administrativa adicional.
2. Si no se configura adecuadamente, puede crear un único punto de fallo, provocando que todo el ecosistema falle.

Como implementar este patrón

Un patrón solo define como las aplicaciones deberían de funcionar, pero da carta abierta al programador sobre cómo se debe de implementar, es por eso no existe una sola forma o tecnología para implementar este patrón, por lo que tu podrás desarrollar cada pieza o utilizar algunas herramientas que ya existen en el mercado, donde sin duda, Spring Boot + Netflix OSS son las tecnologías más innovadoras y fáciles de implementar.

Algunas alternativas para el Registro de servicios son:

• Eureka: Parte de Netflix OSS, un conjunto de utilidades desarrolladas por Netflix y liberadas como código abierto.

• Etcd: un almacén de valores-clave distribuido, consistente y de alta disponibilidad que se utiliza para la configuración compartida y el descubrimiento de servicios.
• Consul: una herramienta para descubrir y configurar servicios. Proporciona una API que permite a los clientes registrarse y descubrir servicios. El cónsul puede realizar controles de salud para determinar la disponibilidad del servicio.
• Apache Zookeeper: un servicio de coordinación de alto rendimiento y uso generalizado para aplicaciones distribuidas.

Algunas alternativas para el balanceo de cargas:

• Ribbon: Parte del stack tecnológico de Netflix OSS. El cual permite realizar el balanceo de cargar por medio de Eureka.
• Nginx: pronunciado como “engine-ex”, es un servidor web de código abierto que, desde su éxito inicial como servidor web, ahora también es usado como proxy inverso, cache de HTTP, y balanceador de carga.

Conclusiones

Como hemos podido analizar a lo largo de este artículo, el patrón Service Discovery es uno de los patrones más potentes en arquitecturas de microservicios altamente escalable y que permite librarnos de configurar las direcciones físicas de los servicios, algo sumamente valorado en ambientes cloud, donde tenemos IP flotantes que pueden cambiar de la noche a la mañana o que simplemente requieren del aprovisionamiento dinámico de nuevas instancias.

The post Service Discovery pattern para microservicios appeared first on Oscar Blancarte - Software Architecture.

Este video es la continuación del video de introducción a al patrón Factory Method. En esta segunda entrega aprenderemos a utilizar el patrón mediante in ejemplo del mundo real, en el cual aprenderemos a crear una aplicación que permite conectarse a más de una base de datos, la cual podrá ser intercambiada por medio de la configuración.

The post Patrón Factory Method – Proyecto [Segunda parte] [Video] appeared first on Oscar Blancarte - Software Architecture.

En este video te enseñare la teoría que hay detrás del patrón Factory Method, este patrón permite la creación de objetos de un subtipo determinado a través de una clase Factory. Esto es especialmente útil cuando no sabemos, en tiempo de diseño, el subtipo que vamos a utilizar o cuando queremos delegar la lógica de creación de los objetos a una clase Factory. Utilizando este patrón podemos crear instancias dinámicamente mediante la configuración, estableciendo cual será la implementación a utilizar en un archivo de texto, XML, properties o mediante cualquier otra estrategia.

Puedes ver la segunda parte en aquí

The post Patrón Factory Method – Introducción [Primera parte] [Video] appeared first on Oscar Blancarte - Software Architecture.

En esta charla explicaré la importancia de los patrones de diseño, así como las ventajas que te traerá en tu crecimiento personal. De la misma forma, analizaremos como los patrones de diseño, son la base para convertirte en un arquitecto de software y aremos un análisis de los salarios que pueden alcanzar.

The post Introducción a los patrones de diseño (video) appeared first on Oscar Blancarte - Software Architecture.

El patrón de diseño Factory Method nos permite la creación de un subtipo determinado por medio de una clase de Factoría, la cual oculta los detalles de creación del objeto.

El objeto real creados es enmascarado detrás de una interface común entre todos los objetos que pueden ser creado, con la finalidad de que estos pueden variar sin afectar la forma en que el cliente interactúa con ellos. 

Es normal que un Factory pueda crear varios subtipos de una determinada interface y que todos los objetos concretos fabricados hagan una tarea similar pero con detalles de implementación diferentes. 

La intención del Factory Method es tener una clase a la cual delegar la responsabilidad de la creación de los objetos, para que no sea el mismo programador el que decida que clase instanciará, si no que delegará esta responsabilidad al Factory confiando en que este le regresará la clase adecuada para trabajar.

Lo anterior puede resultado un poco absurdo, pues para que necesitaría el programador ayuda de una clase para crear un objeto, en su lugar puede hacer simplemente un new y listo, tiene la instancia creada, sin embargo, el patrón Factory method se utiliza para casos en los que no se sabe en tiempo de diseño que subtipo vamos a necesitar, y en su lugar, definimos eso en la base de datos, en un archivo de configuración, o simplemente por medio de alguna condición en tiempo de ejecución podemos determinar que clase se utilizará.

Estructura del patrón Factory Method

El siguiente diagrama muestra los componentes que conforman el patrón de diseño:

• IProduct: Representa de forma abstracta el objeto que queremos crear, mediante esta interface se definen la estructura que tendrá el objeto creado.
• ConcreteProduct: Representa una implementación concreta de la interface IProduct, la cual es creada a través del ConcreteFactory.
• AbstractFactory: Este componente puede ser opcional, sin embargo, se recomienda la creación de un AbstractFactory que define el comportamiento por default de los ConcreteFactory.
• Concrete Factory: Representa una fábrica concreta la cual es utilizada para la creación de los ConcreteProduct, esta clase hereda el comportamiento básico del AbstractFactory.

Secuencia de ejecución

La siguiente sección describe la secuencia de ejecución del patrón

El diagrama se interpreta de la siguiente manera:

1. El cliente le solicita al ConcreteFactory la creación del ProductA .
2. El ConcreteFactory localiza la implementación concreta de ProductA y crea una nueva instancia.
3. El ConcreteFactory regresa el ConcreteProductA creado.
4. El cliente le solicita al ConcreteFactory la creación del ProductB.
5. El ConcreteFactory localiza la implementación concreta del ProductB y crea una nueva instancia.
6. El ConcreteFactory regresa el ConcreteProductB creado.

Ejemplo práctico

Para comprender mejor como funciona el patrón Factory Method analizaremos un ejemplo prácticos con el cual podemos presentarnos alguno de nuestros proyectos, el cual corresponde a una aplicación que se puede conectar a más de una base de datos, sin embargo, la base de datos a utilizar no se sabrá de antemano, si no que por medio de la configuración es como podremos determinar que base de datos estaremos utilizando.

Como vemos, en este caso, no está clara la base de datos que vamos a utilizar, por lo tanto no podemos crear una aplicación que se conecta a una base de datos determinada, si no que tenemos que esperar hasta conocer la configuración para poder establecer la conexión. Una posible solución es crear una serie de IF…ELSE IF para crear la conexión al momento de leer la configuración, sin embargo, esto no es para nada recomendable, pues crearemos una aplicación difícil de mantener y que además revuelva la lógica para determinar la base de datos junto con la lógica propia del sistema.

En su lugar, lo recomendable es crear un Factory Method que nos cree un objeto que nos permita conectarnos a la base de datos, y que este objeto oculte los detalles de implementación, por otro lado, el Factory Method ocultara los detalles de implementación para leer la configuración y crear el objeto adecuado según la configuración, de esta forma, todos los detalles son ocultados al cliente y este solo se preocupa por implementar la lógica.

Antes de comenzar, puedes ver todo el código fuente en GitHub: https://github.com/oscarjb1/blog-patterns-factorymethod

Lo primero será definir la interface que implementarán las clases que se conectarán a la base de datos:

package com.oscarblancarteblog;

import java.sql.Connection;

public interface IDBAdapter {
    public Connection getConnection();
}

Esta interface solo define el método getConnection, la cual deberá regresar una conexión abierta a la base de datos.

El siguiente paso es crear las clases concretas que se conectarán a las bases de datos Oracle, MySQL y SQLServer:

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class OracleDBAdapter implements IDBAdapter {
    
    static{
        try {
            //new oracle.jdbc.OracleDriver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load Oracle Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("Oracle.user");
            String password = ConfigLoader.getPropery("Oracle.password");
            String host = ConfigLoader.getPropery("Oracle.host");
            String port = ConfigLoader.getPropery("Oracle.port");
            String db = ConfigLoader.getPropery("Oracle.db");

            String url = "jdbc:oracle:thin:@${host}:${port}:${db}"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("Oracle connection error " + e.getMessage());
        }
    }
    
}

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class MySQLDBAdapter implements IDBAdapter {

    static {
        try {
            new com.mysql.jdbc.Driver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load MySQL Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("MySQL.user");
            String password = ConfigLoader.getPropery("MySQL.password");
            String host = ConfigLoader.getPropery("MySQL.host");
            String port = ConfigLoader.getPropery("MySQL.port");
            String db = ConfigLoader.getPropery("MySQL.db");

            String url = "jdbc:mysql://${host}:${port}/${db}?zeroDateTimeBehavior=convertToNull&serverTimezone=UTC&useSSL=false;"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("MySQL connection error " + e.getMessage());
        }
    }

}

package com.oscarblancarteblog;

import java.sql.Connection;
import java.sql.DriverManager;

public class SQLServerAdapter implements IDBAdapter {
    
    static{
        try {
            //new com.microsoft.jdbc.sqlserver.SQLServerDriver();
        } catch (Exception e) {
            throw new RuntimeException("Unexpected error on load SQLServer Driver");
        }
    }

    @Override
    public Connection getConnection() {
        try {
            String user = ConfigLoader.getPropery("SQLServer.user");
            String password = ConfigLoader.getPropery("SQLServer.password");
            String host = ConfigLoader.getPropery("SQLServer.host");
            String port = ConfigLoader.getPropery("SQLServer.port");
            String db = ConfigLoader.getPropery("SQLServer.db");

            String url = "jdbc:sqlserver://${host}:${port};databaseName=${db};"
                    .replace("${host}", host).replace("${port}", port).replace("${db}", db);

            Connection connection = DriverManager.getConnection(url, user, password); //connection to MySQL
            return connection;
        } catch (Exception e) {
            throw new RuntimeException("SQLServer connection error " + e.getMessage());
        }
    }
    
}

Como acabamos de ver, estas clases tiene como única responsabilidad de crear la conexiones a las base de datos y registrar el driver JDBC correspondiente. Adicional, utilizan un archivo de configuración para recuperar los datos de conexión, el cual analizáramos más adelante.

Para recuperar la configuración se utiliza una clase de utilidad llamada ConfigLoader, la cual lee y carga en memoria el archivo dbconfig.properties:

package com.oscarblancarteblog;

import java.io.InputStream;
import java.util.Map;
import java.util.Properties;

public class ConfigLoader {

    private static Properties props;

    static {
        try {
            InputStream stream = ClassLoader.getSystemResourceAsStream("META-INF/dbconfig.properties");
            ConfigLoader.props = new Properties();
            props.load(stream);
        } catch (Exception e) {
            throw new RuntimeException("Faild to load configuration");
        }
    }
    
    public static String getDBType(){
        return props.getProperty("dbtype");
    }
    
    public static String getPropery(String propName){
        return props.getProperty(propName);
    }
    
    
}

El archivos de propiedades se ve de la siguiente manera:

dbtype MySQL
#Values -> MySQL | Oracle | SQLServer


MySQL.user root
MySQL.password 1234
MySQL.host localhost
MySQL.port 3306
MySQL.db factory

Oracle.user sys
Oracle.password 1234
Oracle.host localhost
Oracle.port 1521
Oracle.db factory

SQLServer.user sa
SQLServer.password 1234
SQLServer.host localhost
SQLServer.port 1433
SQLServer.db factory

Finalmente, tenemos la clase DBFactory, la cual se encarga de crear la instancia correcta de la interface IDBAdapter basado en el valor de la propiedad dbtype del archivo dbconfig.properties:

package com.oscarblancarteblog;

public class DBFactory {
    public static IDBAdapter getDBAdapter(){
        String dbType = ConfigLoader.getDBType();
        System.out.println("DBType => " + dbType);
        switch(dbType){
            case "MySQL":
                return new MySQLDBAdapter();
            case "Oracle":
                return new OracleDBAdapter();
            case "SQLServer":
                return new SQLServerAdapter();
            default:
                throw new RuntimeException("Unsupported db type");
        }
    }
}

Como podemos apreciar, esta clase tiene una lógica para determina la clase que deberá de regresar, por su parte, el cliente no tiene por que saber cual es la implementación concreta que creará el Factory, lo que permitiría que en el futuro cambiáramos de implementación sin afectar al cliente.

Probando la solución

Finalmente, ejecutaremos una prueba para comprobar que todo funciona según lo explicado, para eso, creamos la clase Main, la cual se ve de la siguiente manera:

package com.oscarblancarteblog;

import java.sql.Connection;

public class Main {

    public static void main(String[] args) {
        try {
            IDBAdapter adapter = DBFactory.getDBAdapter();
            Connection connection = adapter.getConnection();
            System.out.println("Is Open => " + (!connection.isClosed()));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Al ejecutar este prueba tenemos como resultado la siguiente salida:

DBType => MySQL
Is Open => true

Como vemos, DBType indica que estamos utilizando la conexión a MySQL y al propiedad Is Open nos indica que la conexión se realizo correctamente. Si cambiamos la propiedad dbtype del archivo dbconfig.properties veremos como nos podemos conectar a las demás base de datos.

Conclusiones

Como hemos pido observar, implementar el patrón de diseño Factory Method es muy simple y otorga grandes ventajas que son fáciles de apreciar, como separar la lógica de creación de objetos en una clase de factoria o la facilidad de variar dinamicamnte la implementación del objeto fabricado sin afectar al cliente.

The post Patrón de Diseño Factory appeared first on Oscar Blancarte - Software Architecture.