Decisiones técnicas en Tractis

La elección del framework: Rails y Java

En su día ya comentamos nuestra decisión de usar Ruby on Rails para desarrollar Tractis y lo que nos alegrábamos de haber escogido Rails en lugar de Java. También mencionamos que, debido a las carencias de Ruby, habíamos optado por emplear servicios web en Java para el backend de firma digital.

Entonces nos alegrábamos mucho sobre la decisión que habíamos tomado al escoger Rails, y todavía lo hacemos. El framework nos ha dado muchísima agilidad y trabajar con él es divertido. Quién sigue el blog ha visto que incluso participamos en los eventos que podemos sobre Rails, con lo que resulta bastante evidente nuestra satisfacción con la herramienta.

Ahora bien ¿qué ha sido del desarrollo que hemos hecho en Java?

Releyendo aquel post parece que estamos desarrollando en Java porque no hay más remedio. Que si hubiésemos tenido las librerías necesarias en Ruby ahora no tendríamos código Java y seríamos aun más felices. Con la aparición de JRuby hay quien nos pregunta si no preferiríamos tener la aplicación en JRuby on Rails y tener así acceso a las librerías que necesitamos de Java, eliminando nuestra necesidad de los servicios web.

Sin embargo, aquella decisión que tomamos no fue solo sobre frameworks, sino que también consistió en una decisión sobre el diseño de la aplicación.

La elección de diseño: arquitectura de servicios web

Como decíamos, cuando escogimos framework, también escogimos arquitectura. Decidíamos que preferíamos desarrollar varias aplicaciones específicas que una que lo englobase todo, al más puro estilo UNIX.

La verdad es que, volviendo la mirada atrás, nos alegramos mucho de haber optado por Rails para el frontend, pero nos alegramos mucho más de haber optado por una arquitectura de servicios web. Así que, igual que entonces os contamos las ventajas que habíamos tenido al escoger Rails, ahora queremos compartir con vosotros las ventajas de esta decisión de diseño.

Otra buzzword

Este tipo de arquitecturas está de moda y tienen buzzword propia: SOA (Service Oriented Architeqture). Así ya podrás tener tu aplicación SOA, hecha en Rails y con mucho AJAX.

Si por el contraro, eres como nosotros y prefieres motivos de verdad. Sigue leyendo

Calidad

Enlazando con lo que comentamos antes, la idea de diseñar aplicaciones más pequeñas y específicas que conformen un todo sigue la línea de la filosofía UNIX.

Si nos paramos a pensarlo, es esa filosofía la que hace que UNIX sea tan potente y nos guste tanto. Tienes un montón de programas específicos: ls, grep, sed, awk… Esos programas hacen cosas muy específicas, pero las hacen muy bien.

Al trabajar con aplicaciones específicas que tienen que resolver un problema concreto podemos centrarnos mucho mejor en el problema en cuestión. Podríamos pensar que para esta labor de aislamiento de tareas basta con desarrollar librerías en lugar de aplicaciones, y estaríamos en lo cierto. No obstante, el desarrollar aplicaciones distintas conectadas por servicios web nos permite tener una arquitectura totalmente agnóstica sobre lenguajes, frameworks y pilas de despliegue. Si más adelante resulta que con C++ o .NET tenemos mejores herramientas para la validación de firmas podemos migrar únicamente esa aplicación sin que el resto de nuestro sistema lo perciba. Desarrollando aplicaciones específicas podemos emplear las mejores herramientas en cada caso

Además de la calidad en la implementación, nosotros encontramos una mejora en la calidad a la hora de dar servicio, por un lado por motivos de escalabilidad que comentaremos en el punto siguiente, y por otro ante la posibilidad de redesplegar o desactivar un servicio en concreto sin que esto implique parar el resto de los servicios.

Escalabilidad

Cuando nos referimos a escalabilidad hablamos tanto de escalabilidad de recursos técnicos como humanos.

Por parte de los recursos técnicos es muy simple. En un principio puedes empezar con todos los servicios en una misma máquina, si alguno te supone un cuello de botella, pues le pones una máquina dedicada. Es más, si el servicio es un share-nothing, puedes poner tantas máquinas como necesites para dar un buen servicio. Los que trabajéis en Rails esto lo tendréis claro

Entrando en el terreno humano, una arquitectura de servicios nos da más fórmulas para escalar nuestro desarrollo, permitiendo desde la gestión de un único equipo, hasta la asignación de un equipo por servicio. De este modo, cuando nuestro proyecto crece y requiere de más desarrolladores no es necesario que tengamos un equipo cada vez más grande, sino que podemos mantener varios equipos más pequeños y ágiles que se encarguen de uno o más servicios.

En futuros posts

En futuros posts esperamos comentaros más detalles sobre la arquitectura que tenemos, qué servicios la componen y para qué sirven.

Un saludo!

Por Ernesto Jiménez
Guardado en: Programación, Tecnología, Tractis | Sin comentarios » | 27 de Enero de 2008