Archivo para 18 agosto 2008

Desarrollo (Sistemas I)

18 agosto 2008

Un número razonable de años (tampoco tantos) te da la ventaja de haber probado muchas cosas y tener perspectiva para comparar. De hecho, descubrí los sistemas abiertos, o “el lado oscuro”, hace relativamente poco, como cinco o seis años, después de una larga temporada en el lado luminoso.

Tras este tiempo sigo sin entender la defensa de algunas soluciones en base a términos como el TCO. Algo así como “Si, si, ahora es gratis pero ya verás a la larga”. Igual esto será aplicable para sistemas heredados, sobre los que no has tenido control, o cuando el equipo humano con el que cuentas necesita apoyo vía consultoría o vete tú a saber.

Como experiencia real en Rockola.fm el coste en ingeniería de sistemas, donde incluyo la localización de productos, pruebas de concepto, cambios de idea, integración, esto no vale… probemos otra cosa, y puesta en producción; ha estado controlado hasta el escándalo. Nada que ver con el equivalente en el lado luminoso.

Y esto no es sólo aplicable a la implantación de la solución final, también lo es en otros lugares como en la gestión del proyecto, el desarrollo, las pruebas, la depuración y la monitorización.

A partir de aquí puede que el texto se vuelva un poco críptico pero nada que no se pueda aclarar vía comentarios al post. Se trata de algunos ejemplos de uso de herramientas útiles y libres que empleamos en Rockola.fm durante el desarrollo de aplicaciones.

si, son equipos de sobremesa pero con doble procesador, la memoria a tope y sus discos duros en RAID 1

Desarrollo, pruebas integradas y preproducción: si, son equipos de sobremesa pero con doble procesador, la memoria a tope y sus discos duros en RAID 1

Crear instancias independientes del Apache es fácil de modo que durante el desarrollo disponemos de nuestro propio entrono de ejecución. Los desastres que puede provocar uno no afectan al rendimiento del resto aunque tu código te mande directo al hiperespacio.

Subversion es perfecto como sistema de gestión de versiones pero también es el eje central para nuestra metodología de pases entre entornos. Desde que salimos en febrero de 2008 todos los pases han sido “en caliente” y sin un solo error gracias a que los scripts de automatización eliminan todos los posibles puntos de fallo.

El entorno de pruebas integradas permite validar la calidad funcional del desarrollo pero para verificar que no hay fallos por inconsistencia con la arquitectura de sistemas necesitamos un entorno lo más próximo al de producción. Que mejor que el VMware (versión libre para Linux) con seis máquinas virtuales para simular alta disponibilidad y balanceo en http, base de datos y streaming.

¿Para que gastarse tres o cuatro mil euros en hardware en preproducción cuando puedes simular balanceo de carga por software mediante Pen y sin pérdida apreciable en el rendimiento?

Monitorizamos, igual que en producción, con Nagios que nos proporciona alertas por correo electrónico y SMS en los casos críticos. Analizamos gráficamente el comportamiento de nuestros sistemas mediante Cacti.

En cuanto a las copias de seguridad, usamos LVM, tenemos configurado un snapshot cada dos horas y una copia diaria con retención de una semana sobre un dispositivo de almacenamiento externo.

Siempre hay quien prefiere usar Windows en su puesto de trabajo. Como no somos talibanes, una instancia de Samba y a correr.

No son más que ejemplos (me dejo otros por describir como la gestión de incidencias, el wiki de proyecto, las VPN, el LDAP y un largo etc) pero tal vez lo más interesante del software libre es el código abierto cuya peculiaridad queda bien descrita en el ensayo La catedral y el bazar. Aclaración con un simple hecho:

Actualmente nuestro gestor de base de datos es MySQL en alta disponibilidad. Se trata de un cluster de dos servidores en el que sólo uno da servicio. El otro replica la actividad del primero y toma el control en caso de fallo. Estamos probando un modelo que incluya también balanceo de carga basado en Pen. La idea es que las operaciones de consulta se realicen sobre cualquiera de los servidores. Sin embargo existe un problema de sincronismo que no garantiza el éxito de las órdenes de lectura sobre datos que acaban de escribirse. En otras circunstancias, esto hubiera sido motivo suficiente para buscar otra solución. Sin embargo, Google tiene en marcha un proyecto (google-mysql-tools) que resolverá este problema. Esto sólo es posible en el lado oscuro.

Anuncios