Non nobis Domine...
Isaac Ruiz Guerra's Weblog
- Todo
- Internet
- Politica
- frases
- ruby
- ESB
- Libros
- Oracle
- SOA
- Haskell
- Urbi
- 97things
- Humor
- General
- Justicia Social
- Cine
- Java
- TecNo
domingo jul 26, 2009
[11 de 97] Tambien tienes que saber de hardware.
El axioma de hoy (tomado del libro 97
things Every Software Architech Should Know) dice:
"También tienes que saber de hardware"
Kamal Wickramanayake.Kamal Wickramanayake es un arquitecto de software que vive en Sri Lanka. Está certificado en TOGAF por el Open Group.
[NT. El título original del axioma es: You have to understand Hardware too]
Aquí parte importante del axioma:
For many software architects, hardware capacity planning is a topic that lies beyond their comfort zone, yet it remains an important part of the architect’s job. There are a number of reasons software architects often fail to properly consider hardware but they mostly have to do with a lack of understanding and unclear requirements.
The primary reason we neglect hardware considerations is that we are focused on software and tend to ignore hardware demands. In addition, we are naturally isolated from hardware by high-level languages and software frameworks.
Unclear requirements are also a factor as they may change or may be poorly understood. As the architecture evolves hardware considerations will also change. In addition, our clients may not understand or be able to predict the size of their own user base or system usage dynamics. Finally, hardware is constantly evolving. What we knew about hardware in the past does not apply today.
Without hardware expertise predicting hardware configurations for systems to be developed is highly error prone. To compensate some software architects use large safety factors. Such safety factors are generally not based on objective assessments or founded in any methodology. In most of the cases, this leads to excessive infrastructure capacities that will not be utilized even in periods of peak demand. As a result, clients' money is wasted on more hardware than a system will ever need.
The best defense against poor hardware planning is to work closely with an infrastructure architect. Infrastructure architects, unlike software architects, are specialists in hardware capacity planning and they should be a part of your team. However, not every software architect has the luxury of working with an infrastructure architect. In such cases there are some things a software architect can do to mitigate errors when planning for hardware.
Hardware capacity planning is as important as software architecture and it needs to be given a first order priority whether you have an infrastructure architect on hand or not. Just like an architect is responsible to establish the links between business demands and a software solution, she is responsible to envision the links between hardware and software.
A riesgo de equivocarme, creo que una de las cosas que hacemos en nuestros inicios en este peregrinaje evolutivo, es que, pasamos por alto cuestiones de bajo nivel, y, escudándonos con la abstracción, dejamos los temas relacionados con el hardware para "alguien más".
Voy a iniciar este post compartiendo una anécdota para ejemplificar un poco lo costoso que puede ser que pasemos por algo que: lo efímero y etereo de nuestro código requiere bases físicas, tangibles, medibles y sobre todo, algo que se nos olvida constantemente, limitadas.
Hace un par de años me encomendaron realizar una pequeña aplicación de escritorio que tenia que ser distribuida mediante JNLP, la tarea parecía sencilla (iluso de mí) sólo se trataba de manipular en promedio unas 20 imágenes y agruparlas de una manera amigable, estaba a punto de terminar cuando el encargado de proyecto me dijo:
A partir de ahí, una tarea sencilla se convirtió en una tarea algo compleja y llena de pruebas, certificaciones por parte del cliente y cambios en la manera en que manipulaba los BufferedImage :P-"Espero que ya te hayan comentado de la restricción que tenemos con las maquinas-cliente"
-Lo primero que pensé fue: "Sabia que no sería fácil".
-"¿Cual restricción?" pregunté.
-"Los equipos solo cuentan con 256MB en memoria RAM" argumentó.
- No pude evitar reírme, cuando me dice:
-"No, no te rías, es en serio"
Y, aquí el punto es que, no sólo importa conocer las condiciones actuales del hardware sobre la cual se ejecutará nuestra aplicación, sino que además cuales serán las previsiones que debemos tomar para el crecimiento de nuestra aplicación.
Aunque suene más filosófico que técnico, debemos aprender a crecer (o ¿aprender es crecer?); y en ese viaje seguramente nos toparemos con los términos: Escalabilidad y Capacity Planning.
Así que, me permito compartirles estos enlaces que considero pueden ser útiles:
- Diseñar para favorecer la escalabilidad.
- Documento del
sitio MSDN con teoría sobre la escalabilidad.
- Fundamentos de escalabilidad.
- Breves conceptos sobre la escalabilidad.
- Estrategias
para la escalabilidad de aplicaciones
- (PDF)Presentación del SG06.
- Martín ha tocado el tema constantemente.
The Art of Capacity Planning: Scaling Web Resources (Paperback)
by John Allspaw (Author)
Seguramente, como hasta ahora, sus comentarios enriquecerán este post. ;) pero, en lo que llegan, Dilbert tiene cosas que decir:
Buena semana a todos!!!
---
RuGI
Isaac Ruiz Guerra.
Posted at 11:24PM jul 26, 2009 by Isaac Ruiz Guerra in 97things | Comentarios[18]
Siguiendo la misma línea del post, quisiera aportar con un artículo de Joel Spolsky:
http://local.joelonsoftware.com/wiki/De_vuelta_a_lo_b%C3%A1sico
Joel Spolsky no se refiere en ese artículo directamente al hardware, pero al igual que Rugi, indica que se deben tener en consideración los aspectos básicos durante el desarrollo de software. Eso incluye al hardware.
Excelente post Rugi, saludos!
Enviado por Germán G. en julio 26, 2009 a las 11:56 PM CDT #
Ummm, no llego a estar 100% de acuerdo con este consejo, sobre todo con esta frase:
"To compensate some software architects use large safety factors. Such safety factors are generally not based on objective assessments or founded in any methodology."
le respondería: ya bueno, ¿y que? ;-) Preguntad a cualquier ingeniero civil: tras realizar todos sus cáculos de elementos finitos de infraestructuras, siempre aplicará márgenes de seguridad a todos sus cálculos (alguno me ha comentado que van desde un 10% hasta un 20%).
[OT]E incluso cuando hablamos de dinero: un veterano ingeniero (con un montón de proyectos a sus espaldas) me comentó que como mínimo el siempre ponía en sus presupuestos un 12% para "imprevistos"[/OT]
Enviado por Ibon Urrutia en julio 27, 2009 a las 06:44 AM CDT #
Lo digo porque a veces el ingeniero de software parece frustrado porque su trabajo no se basa en fórmulas exactas con base científica probada (necesitaré ln 2*xE3 megas de RAM siendo X el LOC de mi proyecto ;-)), y desprecia los "desperdicios" de hardware. Y parecen olvidar que en nuestra industria el recurso más caro es la hora-hombre.
Dedicar 20 horas a estudiar hasta sus últimas consecuencias si necesitamos 512Mb de RAM o 4 gigas es en sí mismo una pérdida económica bestial, teniendo en cuenta el precio de la memoria RAM. Por no hablar de la pérdida que pueden suponer las equivocaciones por abajo. Las equivocaciones por arriba, dentro del ámbito de lo razonable (no usar un cluster de 20 servidores cuando sólo era necesario 1 ;-)), no son tan costosas, y además siempre dejan el camino libre para que el sistema evolucione a proporcionar más servicios que los previstos inicialmente (cosa que pasa un montón de veces).
Enviado por Ibon Urrutia en julio 27, 2009 a las 06:44 AM CDT #
No digo que no haya que estudiar las necesidades hardware de nuestro sistema, pero más por predictibilidad de su comportamiento en distintas configuraciones y no por ajustar exactamente en que sistema debe funcionar. Pero ello se puede hacer mientras se testea la aplicación, midiendo estadísticamente (y para ello aprendiendo nociones básicas de estadística:http://zedshaw.com/essays/programmer_stats.html ) como se comporta la aplicación. Y además esa medida puede poner de manifiesto errores más graves (de repente de un build al siguiente la aplicación pasa a necesitar el doble de memoria, ¿que ha pasado?)
Enviado por Ibon Urrutia en julio 27, 2009 a las 06:45 AM CDT #
Creo que en estos momentos el factor hardware que más deberíamos tener en cuenta, y que en algunos casos se está despreciando, son la explosión de quores en las cpu's modernas, porque es un factor que realmente fija el sistema operativo a utilizar, la máquina virtual e incluso, en determinados casos, el diseño-programación de la aplicación. Pero es que el concepto "infraestructure architect" (oh no! otro arquitecto más no por diosss! ;-)) me ha chirriado un poco al leerlo ;-)
Salu2
PD: @Rugi, creo que en la anécdota que cuentas el hardware es un requisito del proyecto, no una necesidad. Por lo tanto te debían informar al principio, y no tiene que ver con planificar correctamente el despliegue de la aplicación (cosa que tu hiciste correctamente para los requisitos que te dieron inicialmente)
Enviado por Ibon Urrutia en julio 27, 2009 a las 06:49 AM CDT #
Lo que apuntas, considero, sigue siendo importante: los programas corren dentro de sistemas, y esos sistemas pueden ser (y muchas veces lo son) distintos. Recuerdo más de un ejemplo de Java 1.2 donde se escribía en un lado, pero no sucedía exactamente lo mismo en todas las arquitecturas. Adiós portabilidad.
Otro aspecto es el que dice el dicho "según el sapo es la pedrada". Ibon, como siempre un genio, apunta que la RAM es muy barata estos días, pero en mi Mexicalzingo veo que en muchas empresas pequeñas es sencillamente imposible en estos días de "ajuste económico" encarar tales actualizaciones. Lo más divertido/frustrante es cuando se obvia el SO del cliente, y te encuentras máquinas con Win95A (sin siquiera la actualización de Explorer 4) con 64 MB (menos 8 de video). La lógica del cliente es irrefrutable: le han funcionado hasta entonces. ¿Por qué habría de gastar miles de pesos en actualizar con todo lo "bueno" que oye de Vista?
Enviado por Miguel Zúñiga González (miguel~1.mx) en julio 27, 2009 a las 06:05 PM CDT #
No puedo olivar la cara del ingeniero, flamante a instalar el framework del .NET 3 para que corriera su mini-aplicación. ¡Ya mero! Y la verdad, yo no tendría cara para recomendar que cambiaran 40 computadoras a XP, Vista, OSX o algún Linux... o que sus empleadas (gente medianamente mayor) aprenda un nuevo entorno... tomando en cuenta que tienen sus licencias de su flamante Office para Win95. ¿512 megas para que arranque el .NET? Ese es el espacio en disco que 5 de esas máquinas tenían... ¿dónde queda entonces la optimización de nuestros sistemas?
Enviado por Miguel Zúñiga González (miguel~1.mx) en julio 27, 2009 a las 06:17 PM CDT #
And Capacity Planning isn't nearly as hard as people think: for a software person doing "scrum" or XP, it's just another unit test, to make sure the response time of the program stays the same or improves as you do more development.
For a QA person, it looks like this http://broadcast.oreilly.com/2009/05/sizing-to-fail.html
Enviado por David Collier-Brown en julio 27, 2009 a las 06:41 PM CDT #
Absolutamente de acuerdo con la recomendación. Y en desacuerdo con Ibon, un descuido en hardware no es sólo de unos centavos y tampoco tiene que ser escoger entre 1 y 20 instancias, he tenido experiencias verdaderamente costosas para pasar de un cluster de 2 a 6 (unos US 800k).
Y no sólo es importante para dimensionar, en ambientes de clustering en decidir si activar o no transferencia de sesión puede decidirse en base a tener un etherchannel o no, por la cantidad de RAM que tenga disponible el servidor (que no siempre es tan barata, menos cuando es una actualización masiva), etc.
Aparte de hardware yo agregaría conocimientos de sistemas operativos, red y todos los elementos sobre los que se soporta el software.
¿Qué es una locura un arquitecto de infraestructura? ¿qué no es necesario?
Te mostraría un par de proyectos donde sin 3 ó 4 de estos la cosa nunca hubiera posible.
Saludos.
Enviado por Pedro en julio 27, 2009 a las 07:30 PM CDT #
@Pedro
Perdona, pero no me salen las cuentas. Me he ido a la página de Dell (ya que el precio va apareciendo según eliges configuración), he elegido un powerEdge R900 (su servidor más potente), y me he puesto a configurarlo con una selección bestial (256Gigas de Ram!, teras y teras de discos duros en RAID, procesadores cuadruples), y a lo máximo que he llegado han sido a 60.000 €. 6 servidores andarían sobre los 360.000, más todo el equipamiento de redes que quieras, no llego a los 800.000 $ ni de lejos. Y eso, partiendo de unos servidores monstruosos que no he llegado a tener el placer de ver en mi vida profesional (lo cual no significa nada... pero es que no veo la aplicación que llegue a necesitar 256Gigas de Ram!)
¿Podrías especificar más en que se fueron esos 800.000 $? (Tal vez en IBM's, pero es que aún siendo muy bestia con el hardware, me parecería un error pagar el DOBLE por unos IBM's)
[sigue...]
Enviado por Ibon Urrutia en julio 28, 2009 a las 08:24 AM CDT #
"en ambientes de clustering en decidir si activar o no transferencia de sesión puede decidirse en base a tener un etherchannel o no, por la cantidad de RAM que tenga disponible el servidor"
Por supuesto, pero es que ahí estás hablando del despliegue. Creo que los dos estaríamos de acuerdo en que diseñar la aplicación pensando en que tenemos un etherchannel disponible, sería un error, o por lo menos una imprudencia. Mejor diseñarla no teniendo en cuenta el hardware/configuración de red concreta, para que se pueda adaptar a distintos despliegues.
Vamos, o esa ha sido una de las promesas de muchos servidores de aplicaciones, hacernos transparente detalles como la transferencia de sesión entre nodos de un cluster o la tolerancia a fallos.
[sigue]
Enviado por Ibon Urrutia en julio 28, 2009 a las 08:34 AM CDT #
No digo que haya que diseñar pensando en que tenemos un hardware con capacidades infinitas (lo cual puede redundar en necesitar mega-servidores); lo que creo es que partir de ciertas suposiciones (o confirmaciones) del hardware a utilizar, pueden desembocar en decisiones de diseño erróneas, que esas sí que son costosas (sospecho que en los 800.000$ también hay metidas muchas horas de rediseño y refactorización de la aplicación).
[sigue]
Enviado por Ibon Urrutia en julio 28, 2009 a las 08:42 AM CDT #
Repito, según se vaya testeando la aplicación, hay que ir teniendo en cuenta que exigencias de hardware tiene. Doy por hecho que el testeo se realiza en una configuración hardware lo más parecida posible a la de puesta en producción, pero la verdad, no se como se puede hacer un "hardware capacity planning" REAL, sentándose en una mesa y estudiando el CPD disponible. Lo siento, pero creo que usar esos "safety factors" de los que parece renegar el axioma, son la única solución razonable cuando aún no hay código real corriendo en ningún sitio.
Precisamente, yo soy ingeniero de telecomunicaciones, especialidad telemática, y siempre agradezco mis conocimientos de redes a la hora de diseñar/programar software, y creo que todo el mundo debe tenerlos. Pero tenerlos en cuenta en su justa medida, y viendo que el recurso humano puede ser mucho más costoso que el hardware (lo sigo pensando)
[sigue]
Enviado por Ibon Urrutia en julio 28, 2009 a las 08:45 AM CDT #
Acabo:
Lo que me chirría es la palabra "arquitecto" en todos y cada uno de los niveles técnicos necesarios en una empresa. No un menosprecio a la labor de la gente de sistemas, extremadamente necesaria en el despliegue, pero que pueden inducir a errores y suposiciones en la etapa de diseño.
Mi mantra: diseña pensando en el despliegue, no en el hardware concreto.
Salu2
Enviado por Ibon Urrutia en julio 28, 2009 a las 08:48 AM CDT #
Hombre, leyendo lo que dice yo no creo que "reniegue" de los "safety factors", de lo que reniega es de que se calculen sin la más mínima base ni metodología, que es en muchos casos lo que se hace.
Y por mi parte considero que ha de haber un equilibrio, ni debes basarte en el hardware en concreto hasta el último detalle para diseñar tu aplicación, ni debes diseñarla pensando que vives en un mundo feliz donde todos los recursos serán infinitos y luego ya veremos como lo instalamos en el mundo real.
...
Enviado por GreenEyed en julio 29, 2009 a las 03:40 AM CDT #
No, escalar no es tan fácil como echar mano a la cartera y cascar más servidores/RAM o lo que sea, y aunque no creo que para diseñar buenas aplicaciones haya que saber diseñar puertas logicas a base de colocar trozos de semiconductores, tampoco creo que se pueden diseñar buenas aplicaciones ignorando la capa física sobre la que han de correr, si tendrán que ir en cluster.
Para mí no es únicamente parte del deploy, es parte del análisis y como todos los factores, hay que tenerlo en cuenta en su justa medida. Si prevees andar corto de RAM pero tu maquina es un PC y la RAM es barata, pues sin problemas, si tu maquina es un hardware específico donde pedir más RAM no sólo es caro sino que puede tardar tiempo, pues mejor ir con ojo.
Al igual que si tienes una máquina con un S.O. donde la JVM no pasa, ni pasará, de 1.4. Diseñar tu aplicación con Java 5/6 y luego llevarte la sorpresa significa que no has hecho bien tu trabajo.
...
Enviado por GreenEyed en julio 29, 2009 a las 03:40 AM CDT #
Y la aparición del "hardware architect" es por lo que les mola asignar distintas tareas con distintos nombres a distintas personas, a los americanos, ya que tienden a la formación especializada. Yo creo que es más un "hay que tener en cuenta también el hardware/comunicaciones y si el diseñador/programador no sabe, que busque a alguien que si sepa para trabajar con el".
Para mi esa es una de las "Leaky Abstractions" (Joel Spolsky) en las que la gente cae.
Enviado por GreenEyed en julio 29, 2009 a las 03:40 AM CDT #
Señores, me disculpo por apenas comentar sus opiniones, pero, he tenido un par de semanas, algo, ejem.. extremas.
Inicio confirmando lo que decia al final del post....sus comentarios son los que enriquecen cada axioma ;)
Creo que, como mencionaba en el post, buena parte de los problemas que intenta superar este axioma se evitarian si nos enfocamos en primer plano a construir una aplicación como decimos en México para decir que algo esta BIEN hecho: "con todas las de la ley" y le damos la justa atención al "ecosistema de despliegue".
Seguramente el tema seguirá dando mucho de que hablar ahora que, todo se esta pasando a la "nube" y que "todos" queremos (y tenemos la oportunidad un tanto más cercana de) construir aplicaciones "con alto nivel de escalabilidad"
Ya veremos que ocurre, mientras tanto:
Saludos a todos!!!
RuGI
Enviado por RuGI en agosto 09, 2009 a las 11:31 PM CDT #