Air Nostrum

Air Nostrum

air-nostrum

No, no intento convertir esta columna en un curso acelerado de latín (aunque mi profesor de tercero de bachiller nos convenció a todos de que el latín era un idioma utilísimo, de uso corriente en toda Europa menos en España, hasta el punto de que llegué a hablar de un modo razonablemente fluido en el idioma de Julio César).

Me estoy refiriendo a la línea aérea Air Nostrum, del grupo Iberia, con la que solo he tenido la oportunidad de volar un par de veces, pero que me produjo una agradable y sugerente experiencia.

Volaba de Alicante a Bilbao, y preferí seleccionar un vuelo sin paradas (ya me está empezando a cansar eso de pasar tanto tiempo en aeropuertos) y me llevé una sorpresa al ver que el avión en el que haría el viaje era mucho más pequeño de lo normal (seis veces más pequeño que el avión en el que estoy volando ahora mismo). De hecho, la capacidad del avión era de solo 50 asientos.

Pero tras esta sorpresa inicial, empezó una secuencia de agradables sorpresas:

  • Mi maleta de ordenador era demasiado grande, pero un empleado la puso delicadamente en mi presencia en un compartimiento habilitado al efecto en la parte trasera del avión.
  • Los asientos eran cómodos y con tanta separación entre ellos como la clase ejecutiva de otras líneas aéreas.
  • El personal de vuelo me trataron, y al resto de los pasajeros, como si voláramos en primera clase en la legendaria Singapore Airlines.
  • Al aterrizar, un empleado me entregó cuidadosamente el maletín del ordenador sin daño alguno, al pie de la escalera del avión.
  • El resto del equipaje llegó a la cinta de distribución antes de que los pasajeros llegáramos a ella.
  • La misma experiencia se repitió en el trayecto de vuelta a Alicante.

Vamos a aplicar mi lógica de arquitecto de sistemas a esta experiencia: El sistema proporciona un servicio inmejorable, con una utilización de medios y recursos humanos adecuados. Ni más ni menos.

¿Podemos decir lo mismo de todos los sistemas que hemos diseñado hasta ahora?

Admitámoslo: a todos los techies nos encanta estar a la última, utilizar las últimas máquinas y los sistemas más complejos. Cuando nos encontramos con los amigos a tomar unas cañas y presumir de nuestros logros, medimos nuestra importancia por la suma acumulada y ponderada del número de procesadores, cantidad de memoria RAM, y capacidad de almacenamiento de nuestros servidores.

¡Qué vergüenza! ¿No tienes ningún clúster? ¿Cómo te las ingenias para peinarte por las mañanas sin un clúster? ¡Esta sección del bar es solo para personas mayores!

Cuando hablamos con el cliente, casi antes de que empiece a hablar, le decimos convencidos: sé exactamente lo que necesitas: un sistema distribuido, tolerante a fallos y altamente escalable. En otras palabras: un Airbus 787 nuevo y reluciente con 600 asientos. Aún no sabemos si es esto lo que necesita el cliente, pero seguro que capturamos su atención

Lo que pasa es que en muchos casos el cliente necesita unas 50 plazas bien configuradas, ajustadas, y administradas, y no unas 600 plazas para impresionar a amigos y vecinos.

El año pasado, un cliente nuestro de Inglaterra, una empresa de televisión y radio muy conocida por todos, nos pidió que le ayudáramos a evaluar si el servidor que estaban a punto de comprar sería capaz de soportar la carga de trabajo que esperaban recibir tras unos doce meses.

La respuesta sencilla hubiera sido: ¡pues claro! (o “po zi” en malagueño antiguo), ya que se trataba de un “maquinón”. Pero habríamos cometido un error de libro, ya que la carga de trabajo real que el sistema llegó a soportar al cabo de ese periodo resultó ser de más del doble de lo que se esperaba. El hecho es que las limitaciones de la aplicación no hubieran podido solventarse con simplemente la instalación de un servidor más grande, y el sistema hubiera estado abocado a un absoluto fracaso.

Sin embargo, lo que hicimos fue analizar la carga de trabajo actual, intentando detectar las capacidades del sistema, así como qué elementos del sistema estaban limitando su capacidad. Detectamos un número de puntos francamente mejorables, tanto en la base de datos, como en la capa de acceso a datos, y enseñamos a su equipo de profesionales cómo deberían re-programar el sistema para corregir estas anomalías, diseñando para ellos los ejemplos piloto que fueron necesarios para demostrar la validez técnica de nuestras afirmaciones.

Nuestras recomendaciones se implementaron, entre las cuales estaba el no cambiar de servidores, sino solamente mejorar el sistema de almacenamiento, invirtiendo en ello una fracción del coste de los nuevos servidores, ya innecesarios.

Tras los temidos y esperados doce meses, el sistema estaba soportando una carga doble de la esperada, pero seguía funcionando con bastante holgura, para satisfacción del cliente, y de los usuarios.

¿Qué podemos aprender de este ejemplo? Según nuestra experiencia, en sistemas grandes y pequeños, el mayor limitante de una aplicación no suele ser ni la potencia de procesamiento, ni la de almacenamiento sino la materia gris de los profesionales que diseñan el sistema. Dicho de otro modo: mejorando el hardware es posible mejorar el rendimiento de cualquier sistema de un modo bastante limitado. Sin embargo, las mejoras que un profesional bien entrenado puede aplicar al mismo sistema son prácticamente ilimitadas.

“Más caña” no suele ser la respuesta adecuada. Nuestro cliente no nos contrata para que nos protejamos en salud y le instalemos lo mejor simplemente para asegurarnos de que va a estar sobrado, porque muy posiblemente nuestra incompetencia no pueda ser compensada por un mejor equipamiento. Por otro lado, no es financieramente eficiente sobredimensionar los sistemas para que estén preparados para un futuro lejano, cuando la realidad de la Ley de Moore (http://research.microsoft.com/~gray/Moore_Law.html) nos asegura unas mejoras de prestaciones con un mantenimiento del precio de un modo continuado.

Nuestro cliente necesita que le diseñemos el sistema que resuelve sus problemas hoy y en un futuro cercano, permitiéndole un camino de crecimiento adecuado al ritmo de crecimiento de su negocio; nada más y nada menos. El cliente no necesita que diseñemos algo a la medida de nuestro ego, o para darnos publicidad. Necesita el sistema más simple y económico que resuelve sus requerimientos de negocio.

Quizá sea mi mentalidad de ingeniero civil pugnando por liberarse de mi barniz de informático pero, según recuerdo, la ingeniería se basa fundamentalmente en diseñar soluciones adecuadas a los requerimientos, al mismo tiempo que se busca poder implementar estas soluciones con un coste lo más ajustado posible.

Microsoft y otras compañías se esfuerzan permanentemente en competir para conseguir los mejores records TPC-C (www.tpc.org). Lo que sucede es que hay que saber leer esta información. A la mayoría de los clientes, les dice bien poco el que haya sistemas que sean capaces de manejar millones de transacciones por minuto. Ver qué empresa consigue el número más grande (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) no es lo interesante que pudiera parecer. Nuestro cliente muy probablemente no necesite un millón de transacciones por minuto, por lo ques estas estadísticas son irrelevantes para él.

Sin embargo, el record que más me importa a mí personalmente, y a muchos de nuestros clientes, es otro: el hecho de que se haya logrado bajar de la barra de un dólar por TPC-C (http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp) ya que el que esto se haya logrado con un volumen de casi 40,000 transacciones por minuto sí que está en línea de lo que la mayoría de los clientes necesitan

Por supuesto, le puedo recomendar a mi cliente que se gaste unos quince millones de dólares en un sistema que le permita procesar 3 millones de transacciones por minuto. Sin embargo, esto solo será interesante si mi cliente necesita este volumen de trabajo en un futuro previsto, y hay clientes que realmente podrían necesitarlo, no nos llamemos a engaño.

Sería más adecuado recomendarle que gaste cuarenta mil dólares en un sistema que le cubre las veinte mil transacciones por minuto que realmente necesita procesar hoy y las cuarenta mil de dentro de dos años. Y cuando veamos que el sistema está cercano a su límite, habrán pasado posiblemente 18 meses, y podremos adquirir un hardware del doble de capacidad con el mismo precio que el que acabamos de comprar hoy.

Por cierto, ¿sabéis porqué Microsoft u otros fabricantes no han batido el record absoluto del TPC-C que fijó IBM hace ya año y medio? La respuesta es muy simple: porque no es suficientemente interesante, ya que requiere un despliegue de medios humanos y materiales desproporcionado al beneficio que se pueda obtener al batir este record.

Air Nostrum: habéis dado en el clavo. Un avión de 50 plazas puede ser más eficiente para algunos trayectos que uno de 150, y hasta quizá pueda dar un servicio de mejor calidad para sus viajeros. Por supuesto, en otros casos habrá que seleccionar uno de 600 pasajeros, y esa será la solución adecuada. Lo importante es poder determinar cuál es la solución adecuada, independientemente de nuestras preferencias personales.

Por cierto, estoy escribiendo este artículo a bordo de un avión de 300 pasajeros lleno hasta la bandera. ¿Qué modelo habrán utilizado para determinar la distancia óptima entre filas de asientos? Creo que eso es tema para otro artículo.

Print this entry

Fernando G. Guerrero

Fernando G. Guerrero

President of SolidQ, Non-Executive Director, Digital & Data Strategist, crazy about technology, NBA, movies and music of all kinds. Tom Peters' fan since 1982


Tags assigned to this article:
diseño adecuadooptimizacion

Related Articles

Sequimos bajando en competitividad

Estaba repasando algunos artículos antiguos, cuando he visto uno de los primeros de este blog, que escribí en el 2003, “España

Mi primera experiencia como vendedor

Con 20 años, y en medio de una de las mayores crisis económicas del comienzo de la transición política en

¿Quién controla en qué trabaja mi mente?

Esto que escribo a continuación es una ficción “novelada”, pero que no es muy diferente de la realidad de mi

No comments

Write a comment
No Comments Yet! You can be first to comment this post!

Only registered users can comment.