DEV Community: Agustin Tosco

ORMs - Active Record & Data Mapper

Agustin Tosco — Fri, 24 Dec 2021 00:53:57 +0000

¿Cuál es la diferencia entre Active Record y Data Mapper?

Cuando trabajamos con datos en una aplicación, probablemente necesitemos un ORM (Object Relational Mapping). Un ORM es la capa entre la base de datos y nuestra aplicación. Al usar un ORM, la mayoría del trabajo de crear, actualizar, leer y eliminar de la base de datos es hecho por este ORM.

La mayoría de los frameworks actuales están preparados para trabajar con un ORM sin problemas. Por ejemplo, Laravel trabaja normalmente con Eloquent.

Las dos más famosas implementaciones de ORMs son Active Record y Data Mapper. En este artículo vamos a explorar la diferencia entre estos dos patrones, cuales son los beneficios y desventajas de elegir uno u otro.

¿Qué es un ORM y por qué necesitamos uno?

Antes de comenzar a hablar acerca de las diferencias entre Active Record y Data Mapper, vamos a hablar un poco sobre qué es un ORM y cuál es su utilidad.

Como dijimos anteriormente, un ORM es la capa que existe entre la base de datos y nuestra aplicación. En POO, trabajamos con objetos como nuestro principal punto de referencia.

Por ejemplo, podríamos tener el siguiente objeto:

user = new User();
user.name = "Elodin";

Sin embargo, las bases de datos pueden almacenar valores como strings o integers.

Un User podría tener varios posteos en nuestra aplicación. Para conseguirlos, podríamos hacer algo así:

posts = user.posts;

Sin embargo, en la base de datos, los posteos estarían almacenados en un tabla, así:

Cuando trabajamos con objetos en nuestra aplicación, trabajamos con objetos simples que almacenan todas sus propiedades y relaciones.

No obstante, estos datos son almacenados individualmente en las diferentes tablas de la base de datos.

Un ORM es esa capa "mágica" que transforma los datos en forma de objetos en datos relacionales que pueden ser guardados en la base de datos y viceversa.

¿Qué es el patrón Active Record?

Este patrón de ORMs es probablemente el más popular.

Un ejemplo de uso típico sería el siguiente:

user = new User();
user.name = "Elodin";
user.save();

En el ejemplo de arriba creamos un nuevo objeto User, configurando el username y luego guardando el objeto en la base de datos.

ORMs del estilo Active Record mapean un objeto con una fila de la base de datos. En el ejemplo anterior, estaríamos mapeando el objeto User a una fila en la tabla users.

Cuando abramos el archivo de modelo User, notaremos que no necesitamos especificar las propiedades del objeto o como se relaciona con la base de datos. Con este tipo de ORMs, el modelo es capaz de determinar las propiedades del modelo automáticamente tomando como referencia el esquema de la base de datos.

Uno de los beneficios de este estilo de ORMs es que podemos llamar al método save() en el objeto para actualizar la base de datos. Cada modelo hereda de un objeto base (del patrón Active Record) por lo que tenemos acceso a todos los métodos relacionados a la presistencia de datos. Esto hace que comenzar a trabajar con ORMs de estilo Active Record sea muy fácil ya que son muy intuitivos.

¿Qué es el patrón Data Mapper?

La gran diferencia entre ambos patrones es que el Data Mapper separa completamente el dominio de nuestra aplicación y la capa de persistencia. Esto significa que ninguno de nuestros modelos (objetos) sabe nada acerca de la base de datos.

Cuando usamos el patrón Data Mapper nuestro código luciría algo así:

user = new User();
user.username = "Elodin";

Hasta ahora, no hay diferencias con el patrón Active Record.

No obstante, los objetos del modelo Data Mapper no son más que objetos que no tienen conocimiento alguno sobre la base de datos. Esto significa que no podemos llamar al método save() en el objeto a almacenar porque este método no existe en este objeto.

En cambio, necesitaremos usar un servicio completamente diferente, por ejemplo, llamado Entity Manager:

user = new User();
user.username = "Elodin";
EntityManager.persist(user);

El gran beneficio del patrón Data Mapper es que los objetos que utilizamos en el dominio de nuestra aplicación no necesitan conocer nada acerca de cómo están guardados en la base de datos. Esto significa que nuestros objetos serán más livianos ya que no deberán heredar el ORM completo, sino que también habrá un proceso más estricto y formal para interactuar con la base de datos debido a que no podremos llamar al método save() en cualquier lugar en nuestro código.

Entonces, ¿cuáles son las diferencias entre Active Record y Data Mapper?

Ambos patrones tienen aspectos positivos y negativos, por supuesto. Como ocurre con casi todo lo demás en el ámbito de la programación, no hay uno que sea mejor que otro, sino que... depende.

Con todo esto en mente, puede haber dos formas de juzgar cuál patrón nos conviene más usar en nuestro caso.

El tipo de aplicación que estemos construyendo

Generalmente y a grandes rasgos, existen dos tipos de aplicaciones: aquellas basadas en los métodos CRUD y las basadas en el propio dominio de la aplicación.

En una aplicación basada en los métodos CRUD típicamente estaremos creando, leyendo, actualizando y eliminando entidades. También, puede que tengamos relaciones entre nuestros modelos, pero sobre todo, no hay reglas estrictas respecto a cómo estas relaciones están dadas.

Cuando construimos una aplicación que está basada o pensada desde el lado de la base de datos, la solucíon más óptima es el patrón Active Record. Éste último, nos permitirá rápida y fácilmente levantar y correr nuestra aplicación.

Si por el contrario, nuestra aplicación es construida pensando en satisfacer las reglas y procedimientos de un negocio, el patrón Data Mapper puede que sea la mejor opción. Éste patrón hará cumplir ciertas restricciones de tratar con datos y su persistencia, y también nos permitirá encapsular esas reglas de negocio dentro de las entidades.

La aplicación y el entorno en el que está siendo construida

Si estamos construyendo un MVP (Producto Mínimo Viable) para testear un nuevo mercado, puede que tenga más sentido usar el patrón Active Record. Al principio, generalmente no sabemos del todo cuales reglas del negocio serán más importantes, y nunca lo sabremos si nos obsesionamos con la arquitectura de nuestra aplicación.

Por otro lado, si la idea es trabajar en una aplicación para un negocio ya existente, puede que sea mejor idea usar un patrón Data Mapper. Un negocio existente ya tendrá reglas y procedimientos por medio de los cuales funciona. Si usáramos un patrón Active Record terminaríamos intentando forzar estas reglas del negocio para que se adapten a nuestra idea de una aplicación pensada desde el lado de la base de datos. El patrón Data Mapper nos permitirá encapsular las reglas de dominio del negocio permitiéndonos trabajar de manera intuitiva y clara.

Nota

Este artículo ha sido maś que nada teoría sin muchos ejemplos prácticos. Para ver un tutorial práctico sobre las diferencias entre estos dos patrones, el siguiente enlace será de utilidad => How We Code: ORMs and Anemic Domain Models by Chris Fidao.

Fuente: https://www.culttt.com/2014/06/18/whats-difference-active-record-data-mapper

¿Qué es Kubernetes?

Agustin Tosco — Sun, 19 Dec 2021 19:08:44 +0000

Kubernetes es una plataforma open-source, extensible y portable para el manejo de programas, aplicaciones y servicios contenerizados que hace más fácil tanto la configuración declarativa como la automatización.

Retrocediendo al pasado

Era del despliegue tradicional: hace tiempo, la mayoría de las organizaciones corrían sus aplicaciones en servidores físicos. No había manera de definir los límites de recursos para aplicaciones en un caso como éste, esto causaba diversos problemas. Por ejemplo, si muchas aplicaciones corrían en un mismo servidor físico, podría haber habido una instancia en donde una aplicación acaparara la mayoría de los recursos, y como resultado, las otras aplicaciones tendrían un rendimiento inferior.
Una solución a este problema hubiese sido correr cada aplicación en un servidor físico diferente. Pero esta solución no prosperó ya que la utilización de recursos sería muy ineficiente y muy costoso para las organizaciones de mantener múltiples servidores.

Era del despliegue virtual

Como solución, se introdujo la virtualización. Esto permite correr múltiples Máquinas Virtuales (MV) en la CPU de un solo servidor físico. También nos permite aislar aplicaciones entre MVs y provee cierta seguridad ya que la información de una aplicación no puede ser accedida libremente desde otra aplicación.

La virtualización permite una mejor utilización de los recursos y permite la escalabilidad.

Cada MV es una máquina corriendo todos los componentes, incluyendo su propio sistema operativo, sobre el hardware virtualizado.

Era del despliegue en contenedores

Los contenedores son similares a las MVs, tienen su propio sistema de archivos, misma memoria, espacio de procesamiento, entre otros. Debido a que están desacoplados de la estructura subyacente, son totalmente portables.

Los contenedores se volvieron muy populares debido a ciertas ventajas extras, como las siguientes:

Ágil creación y despliegue de aplicaciones: mayor facilidad y eficiencia de la creación de imágenes de contenedores en comparación con el uso de imágenes de MV.
Desarrollo, integración y despliegue continuo: permiten una frecuente y confiable construcción de imágenes y despliegue con la posibilidad de realizar rápidos y eficientes rollbacks (restauración a una versión anterior), debido a la inmutabilidad de las imágenes.
Separación de tareas entre Dev y Ops: podemos crear imágenes al momento de compilar y no al desplegar, desacoplando la aplicación de la infraestructura.
Observabilidad: no solo muestra información y métricas a nivel del sistema operativo, sino la salud de la aplicación y otra información.
Consistencia entre los entornos de desarrollo, pruebas y producción: la aplicación corre de la misma manera en nuestra laptop como en la nube.
Portabilidad entre nubes y distribuciones: puede correr en Ubuntu, RHEL, CoreOS, un datacenter físico, Google Kubernetes Engine, entre otros.
Gestión centrada en la aplicación: aumenta el nivel de abstracción de ejecutar un sistema operativo en hardware virtual a ejecutar una aplicación en un sistema operativo utilizando recursos lógicos.
Microservicios elásticos, distribuidos y bajamente acoplados: las aplicaciones son divididas entre piezas más pequeñas e independientes y pueden ser deployadas y gestionadas dinámicamente, no teniendo un monolito corriendo en una única máquina de gran capacidad.
Aislación de recursos: rendimiento de la aplicación más predecible.
Utilización de recursos: alta eficiencia y densidad.

¿Por qué necesitas Kubernetes y qué puedes hacer?

Los contenedores son una buena forma de agrupar y correr nuestras aplicaciones. En un entorno de producción, debemos manejar los contenedores que corren las aplicaciones y asegurarnos de que no haya momentos en que nuestra aplicación esté caída. Por ejemplo, si se cae un contenedor, otro debe iniciarse inmediatamente. ¿No sería más fácil si este comportamiento fuese manejado por un sistema en vez de hacerlo manualmente?

¡Así es como Kubernetes viene al rescate! Kubernetes provee de un marco de trabajo para correr sistemas distribuidos de una manera más resistente y robusta. Se encarga de la escalabilidad y del manejo de fallos de nuestra aplicación, provee patrones de despliegue, y más. Por ejemplo, Kubernetes puede gestionar fácilmente canary deployments para nuestro sistema.

Nota: Canary deployment es un patrón para desplegar nuevos lanzamientos a un pequeño grupo de servidores, realizar testeos y luego aplicar estos cambios al resto de nuestros servidores.

Kubernetes nos provee de lo siguiente:

Balanceo de carga y exposición de servicios: Kubernetes permite ubicar a un contenedor usando su nombre por DNS o su propia dirección IP. Si el tráfico hacia un contenedor es elevado, Kubernetes es capaz de balancear la carga y distribuirla hacia otro despliegue más estable.
Orquestación de almacenamiento: nos permite montar automáticamente un sistema de almacenamiento a nuestra elección, como almacenamientos locales, proveedores cloud públicos, y más.
Implementaciones y restauraciones automatizadas: podemos definir el estado deseado de nuestros contenedores desplegados usando Kubernetes, y podemos cambiar el estado actual a otro estado deseado a un ritmo controlado. Por ejemplo, podemos automatizar Kubernetes para que cree nuevos contenedores para nuestro despliegue, eliminando los contenedores existentes y tomando esos recursos para asignarlos a este nuevo despliegue.
Agrupación automática: podemos indicar cuánta memoria RAM y CPU cada contenedor necesita para que Kubernetes se encargue de ubicarlos de una manera óptima y así aumentar la utilización y el ahorro de recursos.
Autoreparación: Kubernetes puede reiniciar contenedores que fallan, reemplazarlos y detener a los que no respondan a la configuración establecida por el usuario, no exponiéndolos a clientes hasta que no estén listos para funcionar.
Gestión de configuraciones y secretos (credenciales de autenticación): podemos gestionar y guardar información sensible, como contraseñas, tokens de OAuth, y claves SSH. Podemos desplegar y actualizar nuestras credenciales y configuraciones sin tener que reconstruir las imágenes, y sin exponer dicha información.

¿Qué NO es Kubernetes?

Kubernetes no es el tradicional sistema todo incluido de Plataforma como Servicio (PaaS). Dado que opera a un nivel de contenedores en lugar de a un nivel de hardware, proporciona algunas características de aplicación general que son comunes a lo que ofrecen las PaaS, como despliegue, escalabilidad, balanceo de carga y permite a los usuarios integrar sus soluciones de registro, monitoreo y alerta. No obstante, Kubernetes no es un monolíto, y estas soluciones por defecto son opcionales y vinculables. Kubernetes proporciona los componentes básicos para la creación de plataformas para desarrolladores, pero conserva la elección y la flexibilidad del usuario donde realmente es importante.

Kubernetes:

No limita los tipos de aplicaciones soportadas. Su objetivo es admitir una gran variedad de aplicaciones y programas, incluyendo los de tipo stateless, statefull y de procesamiento de datos.
No despliega código fuente ni tampoco compila nuestra aplicación. Los flujos de trabajo de desarrollo, integración y despliegue continuo (CI/CD) están determinados por las preferencias y la cultura de la organización como así también los requerimientos técnicos.
No provee servicios a nivel de la aplicación, como middleware, frameworks de procesamiento de datos, bases de datos, caches, o sistemas de almacenamiento como servicios integrados. Estos componentes pueden correr en Kubernetes y/o ser accedidos a través de aplicaciones que corren en Kubernetes por medio de mecanismos portables, como Open Service Broker.
No impone soluciones de registro, monitoreo o alerta. Sí proporciona algunas integraciones como prueba de concepto, y mecanismos para recopilar y exportar métricas.
No provee ni impone un lenguaje o sistema de configuración (como por ejemplo, Jsonnet), sino que proporciona una API declarativa que puede ser utilizada con cualquier tipo de especificacion declarativa. [más información(https://www.meshcloud.io/2021/08/02/should-i-provide-a-declarative-api-you-propably-should/)].
No proporciona ni adopta ningún sistema exhaustivo de mantenimiento, gestión, autorepación o configuración.
Adicionalmente, Kubernetes no es más que un simple sistema de orquestamiento. De hecho, elimina la necesidad de orquestamiento. La definición técnica de este concepto es la ejecución de un flujo de trabajo definido: primero hacer A, luego B, luego C. En contraste, Kubernetes comprende un conjunto de procesos componibles e independientes que continuamente buscan llegar a un estado deseado partiendo del estado actual. Sin importar como llegamos de ese estado A al estado C. El control centralizado tampoco es requerido. Esto resulta en un sistema que es fácil de usar y muy robusto, poderoso, sólido y totamente extensible.

Fuente: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Refactorización de un monolito (Refactoring of a monolith)

Agustin Tosco — Wed, 08 Dec 2021 00:05:12 +0000

Lo primero a tener en cuenta es que el título del artículo no sugiere directamente comenzar a migrar un proyecto de una arquitectura monolítica a una de microservicios. Previamente, deben tenerse en cuenta algunos puntos importantes.

La arquitectura monolítica no es un anti-patrón de diseño.
La arquitectura de microservicios no es la solución a todos nuestros problemas. Adoptar este tipo de arquitectura no solucionará problemas como código de mala calidad, falta de testing, baja calidad en el proceso de desarrollo.
Éxito != Cantidad de microservicios

Arquitectura monolítica
Es una estructura que consta de un gran sistema en el que se integran la gran mayoría de las funcionalidades y componentes de un proyecto. Son aplicaciones basadas en un lenguaje de programación específico, al igual que poseen una sola base de datos.

Algunas ventajas:

Simplicidad: fáciles de construir, testear y deployar.
Asuntos interdisciplinarios: al ser un "único" código, pueden manejarse de una mejor manera estos asuntos interdisciplinarios (cross-cutting concerns), como el logging, manejo de configuraciones, monitoreo de performance.
Performance: Normalmente los componentes en un monolito comparten memoria, lo que hace que las comunicaciones entre los diferentes servicios sean más rápidas.

Algunas desventajas:

Confiabilidad: un simple error en cualquiera de los módulos/componentes puede comprometer y dejar fuera de servicio a toda la aplicación.
Actualizaciones: debido a que es un gran bloque de código una actualización requiere deployar toda la aplicación nuevamente.
Stack de tecnologías: un monolito usa el mismo stack de tecnologías. Realizar un cambio del mismo es muy costoso, tanto en tiempo como en costos involucrados.

Arquitectura de microservicios
Por otro lado, consisten en servicios independientes y poco acoplados entre sí. De hecho, esta arquitectura divide los componentes de nuestra aplicación en pequeños y autónomos servicios que pueden ser deployados y escalados independientemente. A diferencia de los monolitos, estos microservicios pueden estar programados en diferentes lenguajes de programación, al igual que poseer varias bases de datos.

Algunas ventajas:

Escalabilidad: para escalar una aplicación de microservicios solamente se necesitan escalar ciertos componentes, lo que optimiza el uso de recursos.
Bajo nivel de acoplamiento: los microservicios están poco acoplados entre sí, por ende no son interdependientes y pueden ser testeados individualmente. Además, hace a la aplicación más adaptable a los cambios a lo largo del tiempo.

Algunas desventajas:

Equipo humano preparado: los beneficios de los microservicios son discutibles si no se tiene un equipo preparado.
Testeo y monitoreo: Una vez que dividimos a la aplicación en componentes, tendremos un montón de partes individuales sobre las que realizar seguimiento y eventualmente fixes. Sin unas buenas herramientas de testeo y monitoreo, las cosas pueden salirse de control muy rápido.
Velocidad de comunicación: al ser servicios aislados la comunicación es más complicada. O bien, usan HTTP o directamente queues.

Cómo decidir
Generalmente, las arquitecturas monolíticas son la opción correcta para aplicaciones simples y pequeñas.

Por otro lado, una arquitectura de microservicios es una buena opción cuando queremos desarrollar sistemas más complejos, especialmente cuando se tiene un equipo de trabajo capacitado para este tipo de aplicaciones.

Entonces, cuando tenemos que elegir entre una y otra arquitectura, debemos considerar estos cuatro puntos básicos:

¿Tenemos un equipo capacitado y que puede trabajar con microservicios?
¿Tenemos la infraestructura suficiente para trabajar con aplicaciones distribuidas?
¿Hemos evaluado los riesgos de negocio involucrados?
¿Están definidos claramente los límites de nuestra aplicación?

Si se decide adoptar una estructura de microservicios, deben tenerse en cuenta beneficios y costos al momento de elegir por cual servicio comenzar.

Relación costo-beneficio de extracción de un servicio

Beneficios	Costos
Resuelve un problema significativo	Adaptar / Reescribir el módulo
Frecuencia de uso del servicio	Dificultad en desacoplar dependencias
Escalabilidad del servicio	Nivel de participación del servicio en sagas

Características de cada (micro)servicio:

Altamente mantenible y testeable.
Puede ser deployado independientemente.
Bajo responsabilidad de un pequeño equipo.
Organizado en torno a las capacidades del negocio.

Pasos recomendados para migrar de una arquitectura monolítica a una de microservicios

Identificar los componentes de nuestra aplicación / proyecto.
Refactorizar los componentes.
Identificar las dependencias de los componentes.
Identificar los diferentes grupos de componentes.
Crear una API para utilizarla como el único modo de comunicación entre el sistema, sus componentes y los usuarios del sistema.
Migrar los grupos de componentes a macroservicios.
Migrar de macroservicios a microservicios.
Repetir los pasos 6 y 7.

Fuentes:

Array - ArrayList / Array List - Linked List

Agustin Tosco — Fri, 03 Dec 2021 12:20:09 +0000

Array and Array Lists

Arrays

Fixed length
Anything => Primitives (integer, long, boolean) and also Objects (string, Dog, etc)

ArrayList

Dynamic length
Only hold objects. ArrayList => Error! but can you can use its class wrapper, e.g.: Integer for int.
Access elements
array[1];
arrayList.get(1);
Get length
array.length;
arrayList.size();
Add elements
Cannot do it with Arrays
arrayList.add("New element"));
Set an element
array[0] = "New element";
arrayList.set(0, "New element");
Remove elements
Cannot be done it in arrays
arrayList.remove(1)
or
arrayList.remove("Name of element to be removed")

Array Lists and Linked Lists

They are both part of the Collection framework and they implement the List interface.

LinkedList

Each element is called a node and it has a reference / pointer to the next and the previous node.
The linked list start with a pointer to the first element (HEAD).
They are not in contiguous memory spots.

ArrayList

Good performance for random access.
Not so good when adding or removing new elements, because it needs to run over all the array for changing only one element.