Redis - tus bases de datos favoritas en una

Las aplicaciones Software suelen usar herramientas para persistir datos buscando tiempos de respuesta optimizados de forma distribuida y escalable. En muchos casos, los desarrolladores tendemos a persistir datos temporales para estados u otra información que sólo durará por un tiempo, en otros integramos consultas en memoria o en caché usando otras aplicaciones o librerías.

Redis es un motor de base de datos basado en el almacenamiento en memoria, además de permitir la persistencia. A continuación revisaremos algunas características de Redis.

Redis, todo en uno

Usando Redis podemos tener una base de datos que actúa como caché y persistencia al mismo tiempo, así puedes dejar ese trabajo al mismo motor y no necesitas usar librerías externas u otra base de datos para manejar o diferenciar entre esos dos tipos de datos.

Esta herramienta también provee operaciones sobre los datos almacenados en memoria que son identificados como si fueran una variable hash soportando diversas estructuras bastante flexibles [1]. Para cada tipo de variable, Redis provee diferentes operaciones para su manipulación.

En resumen, Redis es una base de datos distribuida que administra datos en memoria, mejorando el performance de las respuestas y ofreciendo operaciones sobre esos datos. [2]

RediSearch

Si lo que necesitas es hacer búsquedas complejas sobre masivas cantidades de datos, puedes usar RediSearch que posee un engine optimizado y moderno que opera sobre Redis, está escrito en C y es comparable a otras herramientas como ElasticSearch. [3]

Usar en una red interna

A pesar de que usa un sistema para autenticar a las aplicaciones clientes, por su naturaleza distribuida, puede permitir muchos intentos sin bloquearse. Lo cual puede ser vulnerable usando técnicas de fuerza bruta para descubrir contraseñas.

Usos de Redis

Algunos de los usos más populares son los siguientes:
- Sistema cache con políticas de persistencia
- Sistema de colas
- Almacenar sesiones en memoria con tiempos de expiración.
- Cuando se requiera guardar un estado temporal, por ejemplo, en una arquitectura de microservicios
- Almacenar sesiones de usuario
- También puede ser usado para: un carro de compras, un juego online, avisar que un elemento está bloqueado o que hay un proceso en progreso.


Redis es flexible, rápido y escalable, entregando la libertad a las aplicaciones sobre el uso y las políticas con las cuales los datos son almacenados de acuerdos a los criterios de velocidad y tamaños que necesites.

Es recomendable para un extenso rango de tipos de aplicaciones, siempre y cuando resuelva algunos problemas que las otras bases de datos necesitan de más componentes para hacer lo que ya tenemos en uno.

[1] https://redis.io/topics/data-types
[2] https://redis.io/commands
[3] https://redislabs.com/blog/search-benchmarking-redisearch-vs-elasticsearch/

Hacer una aplicación para una startup o una empresa grande requiere de muchas tareas necesarias antes de desarrollar la aplicación como obtener una infraestructura adecuada, revisar disponibilidad de máquinas, instalaciones, cableado, etc. ¿Cuántas de esas tareas entregan valor a lo que hace esa compañía?

La espera para obtener servidores puede tomar bastante tiempo, además de los dolores de cabeza  cuando dejan de estar disponible

Los desarrolladores a veces trabajan los fines de semana porque no hay infraestructura para escalar ni asegurar disponibilidad. Y ni hablar sobre los costes para obtener y mantener máquinas, transportarlas, hacer cableado, monitoreos, y otras tareas relacionadas.

Externalizar la infraestructura

Hay empresas que se han dedicado a proveer servidores y servicios para que podamos montar aplicaciones, ya no necesitamos todo un equipo para asegurar disponibilidad de las máquinas.

Los proveedores de Cloud, como AWS o Google Cloud, son los que se dedican a hacer ese trabajo por ti, optimizando recursos, electricidad, tiempos y costos. Desde hace un tiempo, tienes la opción de no preocuparte sobre la logística de comprar máquinas y obtener lo necesario para montar los servidores, ahora simplemente tienes que seleccionar lo que usarás con algunos clics y tener consciencia sobre cómo se hará la facturación.

Paga por lo que usas

¿Qué pasa si después de levantar mi infraestructura, todavía no usamos las máquinas?. En la nube,  tendríamos costo cero.

Esa es la filosofía cloud, incluso puedes tener una aplicación disponible y si nadie la usa llamando al servicio o visitando la página web, no hay cobro porque no ha sido utilizado. Obviamente, eso depende de la estrategia que uses al implementar la aplicación.

No es necesario gastar el dinero por algo que no usamos.

Útil para todos los tamaños

Una nueva empresa con recursos limitados puede comenzar con algo pequeño y a medida que va creciendo y obtienen mayores ingresos, pueden solicitar mayor capacidad de cómputo con algunos clics.

Muchas empresas ya se han movido y se están moviendo a cloud [1]. Es una estrategia generalizada debido a los costes y restricciones de infraestructura que se han enfrentado en muchos casos.

Tiempo de los desarrolladores

Los proveedores de cloud ofrecen servicios para que sea más fácil implementar buenas prácticas de programación como el Continous Integration y Delivery. También, los servicios cloud manejan la disponibilidad bajando y subiendo instancias a medida que sean necesarios. Asegurar la alta disponibilidad es posible y no hay excusas para no lograrlo.

Sin duda, hay otras habilidades de los desarrolladores que se están haciendo más necesarias, tenemos que actualizar nuestros conocimientos y modificar nuestros paradigmas.

¿Son necesarios los empleos de infraestructura?

Usando cloud no necesitaremos alguien que revise las conexiones, actualizaciones, estado de las máquinas y otros aspectos. Sin embargo, es vital revisar continuamente esas características de forma automatizada. La forma de trabajar está cambiando ¿No parece ser una más inteligente?

No te quedes atrás

La tendencia es clara, las empresas se están moviendo a este tipo de infraestructuras por diversas razones. Es importante entender los beneficios y los problemas de los servicios Cloud.

Los proyectos e innovaciones están al alcance de todos, ahora podemos tener más tiempo para hacer lo que necesitamos.

Metodologia Spotify

Últimamente se ha estado escuchando sobre una nueva metodología de desarrollo de software llevada a cabo por Spotify. Si, de la misma compañía que provee música con 4 millones de usuario de pago y 15 millones de usuarios en total.

Spotify posee 30 equipos en 3 ciudades distintas, números que obligan a cuestionar otros estándares ampliamente aceptados como los de Scrum y algunos usados por compañías grandes como Safe.

A continuación tenemos un resumen sobre algunos de sus principales puntos.

Squads

Los squads son como los equipos de Scrum. Un squad se encarga del desarrollo, test y entrega en producción. Tienen todas las herramientas para desarrollar su trabajo, contacto directo con Stakeholders y son los dueños de uno o más funcionalidades o productos.

El equipo autoorganizado decide las prácticas a seguir como las stand ups, code review, pair programming, retrospectivas, etc. Así como también tienen un cierto grado de autonomía sobre las tecnologías a utilizar (para desarrollar el producto, integración continua, entrega continua, etc.). La idea es otorgar independencia al squad con el fin de evitar bloqueos o asuntos que puedan demorar una entrega.

No hay team leads, pero si hay un product owner que se encarga de priorizar las tareas. ¿Quién se preocupa del crecimiento del equipo? Puede ser algo que define el propio Squad o los “chapters” que veremos más adelante.

Un agile coach puede estar ayudando a que el equipo use las mejores prácticas según su contexto y apoyar en aspectos claves como la motivación o la adaptación en un equipo.

Actualmente Spotify entrega libertad para que el Squad dedique el 10% de su tiempo para hacer lo que quieran, inventar un producto nuevo, aprender una nueva tecnología, etc.. También realizan una encuesta cada 3 meses para medir la mejora o sus esfuerzos.

Dependencias

Una tribu es un grupo de Squads que trabajan en una área parecida. Los squads de una tribu están en la misma oficina promoviendo la colaboración.

El líder de la tribu se encarga de proveer el mejor hábitat posible para los squad y las relaciones entre éstos. Una de las dependencias más comunes son los equipos de operaciones. Aunque un squad debería poseer el rol de operaciones, es importante tener un equipo encargado exclusivamente a eso y entregar las herramientas a los squads para que puedan lograr su autonomía..

Chapters y Guilds

Spotify propone autonomía con equipos independientes, pero también hay que aprovechar las instancias para compartir conocimiento y desarrollar habilidades comunes en la compañía. Un chapter es un equipo con habilidades similares dentro de una tribu.

Los liderazgos se ven a nivel de chapter porque tienen habilidades parecidas, el líder puede ser la persona con más experiencia o experticia sobre el rango de habilidades del chapter.

Un guild se puede ver como un grupo con intereses similares donde comparten conocimiento, habilidades, herramientas y prácticas. Las personas que integran un guild o chapter, son las mismas que participan en la entrega del producto siendo parte de un squad.

Architectura

Para hacer que las integraciones entre los diferentes squads sean más fáciles y coherentes, se considera el rol “System Owner” que se preocupa de la calidad, documentación, technical debt, escalabilidad y el proceso de release. Esta persona es parte de un squad.

El chief architect es quien se encarga de coordinar el trabajo de architectura en un alto nivel. Promoviendo la visión del producto, lineamientos de tecnologías o problemas futuros a mitigar.


La metodología o prácticas de Spotify están enfocadas en las entregas proporcionando una estructura con independencia y las instancias para coordinar y compartir habilidades que la aseguren. Podemos mirarla como una evolución de las prácticas ágiles con constantes cambios.

Los desarrolladores de Software son inversionistas

¿Qué tan importante son los detalles para un desarrollador de Software?

¿Qué pasa si dejamos los casos bordes para el final, o hacer los arreglos cuando ocurra el error? ¿O decir que el performance no es importante hasta que parezca lento?

Ahora tú podrías estar trabajando en una aplicación que funciona en el escenario feliz donde el usuario no experimenta o no intenta usar todas las funcionalidades esperadas.

Comienzo rápido, después lento 

Al comienzo, un desarrollador puede entregar funcionalidades rápidamente, todo es nuevo y no hay obstáculos que lo detengan. 

A medida que la aplicación crece, emergen los errores, el performance disminuye, los requerimientos de seguridad se hacen críticos y ya no se puede entregar algo nuevo hasta arreglar todo lo anterior. ¿Fue una buena práctica preocuparse por los detalles al final?

El inversionista

Un programador es como un inversionista convencido de lo que necesita su empresa para progresar. 

Consciente del trabajo que tiene que entregar ahora y donde debe realizar los esfuerzos de inversión como la integración continua, automatizar deploys, pruebas automatizadas, capacitaciones, etc. El programador tiene que detenerse y pensar sobre lo qué está haciendo y cómo. ¿Es mantenible lo que estamos desarrollando? 

La solución temporal es permanente.

Ver el futuro 

¿Cómo puedes tener un diseño mantenible si no ves los cambios que vienen? Cada línea de código tiene implicaciones que pueden favorecer al equipo o no. No podemos avanzar a ciegas sin conocer la visión del producto y las nuevas funcionalidades que vienen. 

Quizás no puedas ver cuantos clientes van a usar tu aplicación y no tener claridad sobre lo que van a usar o querrán cambiar. Tal vez la arquitectura cambie. Pero si puedes ver qué tan estable, rápida, segura y mantenible sea el producto software en qué trabajas.