Aplicaciones intensivas en datos: capitulo 1

En esta ocasión compartiré con ustedes lo que considero más relevante del capítulo 1 del libro “Data intensive applications” de Martin Kleppmann.

Este libro considero que es un must para cualquier entusiasta o profesional de la ingeniería de datos porque detalla aspectos muy importantes (y a veces pasados por alto) de las aplicaciones enfocadas a datos.

Hoy en día, muchas aplicaciones son data intensive lugar de compute – intensive. Raramente el CPU power es el problema, los verdaderos issues son usualmente la cantidad de datos a procesar, la complejidad de los mismos, la velocidad a la cual están cambiando, etc. 

Una aplicación intensiva en datos, es normalmente construida por bloques que proveen la funcionalidad requerida, por ejemplo muchas aplicaciones necesitan: 

• Almacenamiento de datos donde por ejemplo otra aplicación haga uso de ellos, o simplemente los podamos utilizar después (Base de Datos). 
• Recordar operaciones costosas: para después leerlas rápidamente! (cachés).
• Búsquedas: Buscar datos por keyword o filtros en diferentes maneras (search indexes).
• Enviar señales a otros procesos: (stream processing), para ser manejados, asíncronamente.  
• Procesamiento de datos: Procesar datos en grandes cantidades o datos acumulados (batch processing).

Todo eso sin embargo, suena a mucho trabajo, sobretodo porque nosotros solo estamos acostumbrados a usar los servicios, no a construirlos. Cuando se construyen estos sistemas, los ingenieros normalmente no piensan en construir un motor de base de datos para el almacenamiento de los mismos, porque ya hay muchos en el mercado que funcionan perfectamente bien. 

Aunque no es tan sencillo escoger un sistema de base de datos porque hay muchos con diferentes características, esto porque diferentes aplicaciones tienen requerimientos particulares: hay muchas maneras de cachear datos, de construir índices, de almacenar la información, etc. 

Cuando se construye una aplicación, nosotros tenemos que descubrir cuáles herramientas y cuales approaches son más apropiados para satisfacer nuestras necesidades y por supuesto, puede ser muy difícil combinar herramientas cuando necesitas hacer algo que una herramienta no puede hacer por sí sola. 

Este capítulo (el único que he leído hasta ahora :P) nos habla de 3 aspectos muy importantes a tener en cuenta a la hora del diseño de aplicaciones intensivas en datos: la fiabilidad, escalabilidad y mantenibilidad.

Los sistemas de datos 

Muchas herramientas para almacenamiento y procesamiento de datos han surgido en los últimos años; esas herramientas están optimizadas para diferentes casos de uso y ya no encajan en las categorías tradicionales. 

Por ejemplo: hay data stores que son usados como message – queue (colas de mensajes – Redis) y hay message queues con propiedades de base de datos como Apache Kafka. Las fronteras entre categorías son cada vez más delgadas. 

Por otro lado, muchas aplicaciones tienen gran variedad de requerimientos que pueden ser cubiertos por una sola herramienta, por ello, el trabajo es dividido en tareas que pueden ser desempeñadas por cierta herramienta, y al final, todas esas herramientas forman una sola aplicación. 

Si estás diseñando un servicio de datos o una aplicación de datos, muchas preguntas podrían venir a tu cabeza. 

1. ¿Cómo te aseguras de los datos que permanezcan correctos y completos aún cuando algo pueda salir mal internamente? 
2. ¿Cómo proveer constantemente un buen performance a los clientes aun cuando algunas partes del sistema ya son obsoletas? 
3. ¿Cómo escalar y manejar el aumento de la carga? 
4. ¿Cómo luce una buena API para el servicio? 

Hay muchísimos factores tienen que ver con el diseño de un sistema de datos, incluyendo las habilidades y experiencia de la gente en el proyecto, dependencias de servicios legacy, el tiempo de entrega, la tolerancia de la empresa para tener riesgos, etc. Los factores dependen mucho de cada situación.

Fiabilidad 

El sistema debe continuar trabajando correctamente aun cuando se presente alguna adversidad (fallo). 

Todos tenemos una idea intuitiva de lo que significa que algo sea confiable o no confiable; hablando de software, normalmente decimos que es confiable si: 

• La aplicación desempeña la función que se espera.
• Tolera que el usuario se equivoque 
• Tolera que el usuario use el sistema de manera equivocada.
• El performance es bueno bajo ciertas condiciones.
• El sistema previene accesos no autorizados o abuso. 

Por tanto, podemos decir que fiabilidad significa (básicamente) que algo siga trabajando correctamente aún cuando algo salga mal!

De esta definición viene la idea de crear sistemas tolerantes a fallas.No es posible hacer un sistema tolerante todas las fallas, pero se pueden reducir bastante.

Algo que es muy importante, es diferenciar un defecto y una falla. Defecto es diferente a falla. Defecto es cuando un componente del sistema no cumple sus especificaciones; falla es cuando el sistema deja de proveer un servicio al usuario.

Es imposible que un sistema tenga cero defectos por ello es recomendable diseñar sistemas tolerantes a fallas para prevenir que los defectos causen fallas. 

Escalabilidad 

A medida que crece el sistema, debe haber maneras razonables de lidiar con ese crecimiento. 

Si un sistema está trabajando bien hoy, no significa que pueda trabajar así en el futuro.  Escalabilidad es el término que utilizamos para describir la habilidad del sistema de trabajar con un incremento de carga. 

Debemos siempre preguntarnos, ¿si el sistema crece de esta u otra manera que opciones tenemos para lidiar con ese crecimiento?

• La carga 
  • Cuando decimos que ya incrementó la carga ¿que hacemos para controlarlo?
• Performance 
  • ¿Cómo se comporta el sistema cuando la carga aumenta? 
  • ¿Qué pasa si mantienes igual la infraestructura?
  • ¿Tienes que agregar más recursos para mantener la performance?

Mantenibilidad 

Con el paso del tiempo, mucha gente vendrá a trabajar en el sistema y deben ser capaces de trabajar productivamente.

Es bien sabido que todos los sistemas tienen sus detalles desde el inicio y que se les tiene que dar mantenimiento, arreglar bugs investigar fallos, adaptarlos a nuevas plataformas etc. 

No nos gusta hacer eso, pero si diseñamos el sistema de manera que reduzca el pain, podríamos hacerlo sin problema. Para ello debemos seguir los principios del software: 

• Operabilidad: Facilita al equipo de operaciones mantener el sistema funcionando sin problemas.
• Simplicidad: Mantiene un fácil entendimiento del sistema para los nuevos ingenieros.
• Evolucionalidad: Hace fácil hacer cambios al sistema en el futuro adaptándose a casos no previstos.

Resumen:

El capítulo 1 del libro Data Intensive Application de Martin Kleppmann, nos ayuda a pensar en los fundamentos del diseño y desarrollo de aplicaciones intensivas en datos. Una aplicación debe cumplir varios requerimientos para que sea útil. Los requerimientos funcionales que podrían ser: almacenar datos, procesar datos, cachear datos, etc… y los requerimientos no funcionales que son la fiabilidad, la escalabilidad y la mantenibilidad (entre otros).

Aquí concluye mi aportación para este primer capítulo, espero leer pronto el capítulo 2 para poder compartirlo con ustedes, las cosas se empiezan a poner emocionantes y tengo muchas expectativas!