Aprovechando esa arrancada que ha tenido Cecilio sobre patrones, voy a aportar mi granito de arena ya que leer, escribir, hablar sobre patrones siempre es algo divertido e interesante.

Cecilio no llega a dar una definición, y aunque debería de estar claro con la catalogación y los ejemplos que él ha puesto, pongámosle nombre a las cosas para los que no lo tengáis claro aun: «patrones» es como se llama a las formas de resolver problemas que se repiten. Por ejemplo para un ingeniero de obras públicas que está construyendo una carretera habrá un patrón «puente» que puede usar cuando se encuentra cosas como ríos, vías de tren y otras carreteras, y habrá otro patrón túnel que se emplea casi siempre cuando se encuentra montañas, pero que también se puede usar en otros casos.

Oresund Line, es un puente/túnel entre Dinamarca y Suecia

En el caso de la informática es exactamente lo mismo. Hay problemas que se repiten con más o menos asiduidad y que mucha gente ya ha resuelto. Alguna de esa gente al ver que se repetía cierto problema lo ha documentado para que el siguiente que se lo encuentre no tenga que perder tiempo, ni cometer errores para llegar a la solución óptima.

Por seguir su trabajo podría hablaros sobre alguno de los patrones catalogados en la Wikipedia o en cualquier otro repositorio y luego poner un ejemplo básico, pero ya sabéis que a mi me gusta hacer las cosas a mi modo, así que vamos a partir de un ejemplo básico y veremos patrones que se emplean habitualmente (en la Nube™ especialmente).

Hay que tener en cuenta que los patrones son como la mantequilla, está bien saber que está ahí y para que la puedes usar, pero si la usas para todo acabas muerto o muy gordo. Con los patrones pasa igual y no hay que sobrediseñar, hay que ir aplicando soluciones a medida que nos vamos encontrando problemas y no antes.

Vamos a imaginarnos un bonito servicio web que convierte texto a imagen, que llamaremos Infinitext en memoria del difunto Infinitweet que hice en su día y moló tanto aunque muriese tan joven.

Es un servicio que recibe unas credenciales (un token de OAuth 2) y un texto y devuelve una url en la que encontrar el texto convertido a imagen.

Cuando recibe una llamada accede a una base de datos relacional y trae los datos relacionados con el token y verifica si es válido, si no está caducado y si cumple con las políticas. Si todo está bien genera la imagen, la publica y devuelve la url.

Resulta que el servicio lo empieza a usar alguno más a parte de nuestros amigos, y estos usuarios que no te conocen son exigentes y se quejan de que el servicio tarda mucho en responder a cada llamada. Analizando los datos analíticos que tenemos vemos que hay dos operaciones que tardan de manera notable: una es la conversión de texto a imagen que a priori al ser algo que hace una librería de terceros no podremos mejorar; la otra parte donde el servicio tarda mucho es en la petición a la base de datos.

La query que le tiramos a la BBDD es muy complicada porque es una base datos legacy que cuando se montó estaba pensada para otra cosa y mirando el plan de ejecución no hay por dónde meterle mano. También vemos que lo que se trae de la base de datos es muy poquita información y que al final tampoco tenemos tantos usuarios aun.

¿Cómo podemos mejorar? Hay muchas soluciones, pero hay una que se aplica especialmente en estos casos y que veremos la semana que viene, id dándole vueltas hasta entonces 😉

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

cloud, nube, Patrones