{"id":112,"date":"2012-04-22T21:14:40","date_gmt":"2012-04-22T20:14:40","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=112"},"modified":"2013-09-24T15:07:39","modified_gmt":"2013-09-24T14:07:39","slug":"elasticidad-del-codigo-22","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/elasticidad-del-codigo-22\/","title":{"rendered":"Elasticidad del c\u00f3digo (2\/2)"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-1543\" title=\"QualElastic3\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/04\/QualElastic31.jpg\" alt=\"\" width=\"280\" height=\"363\" \/><\/a>En mi <a title=\"Elasticit\u00e9 des applications\" href=\"http:\/\/qualilogy.com\/es\/elasticidad-del-codigo-12\" target=\"_blank\">post<\/a> anterior, he explicado el concepto de elasticidad como la capacidad de mover los recursos dentro de una infraestructura virtual para cumplir con las demandas de negocios y los picos de actividad, estos \u00faltimos no siempre predecibles.<\/p>\n<p>Pero la elasticidad no significa unicamente la capacidad de \u00abinflar\u00bb la infraestructura mediante la adici\u00f3n de recursos, pero \u2013 y sobre todo \u2013 poder \u00abdesinflarla\u00bb mediante la reasignaci\u00f3n de esos recursos en otra parte.<\/p>\n<p>Como un globo, m\u00e1s el\u00e1stica la infraestructura, m\u00e1s f\u00e1cil de inflar y desinflarla.<\/p>\n<p>Tambi\u00e9n es necesario que las aplicaciones est\u00e1n programadas con la elasticidad en los objetivos.<\/p>\n<p>&nbsp;<\/p>\n<p><!--more--><\/p>\n<p>La elasticidad de una aplicaci\u00f3n supone:<\/p>\n<ul>\n<li>Escalabilidad: mantener el rendimiento de las aplicaciones cuando aumenta el n\u00famero de usuarios \u2013 y por consecuencia el volumen de datos.<\/li>\n<li>La capacidad de liberar recursos cuando la carga disminuye.<\/li>\n<\/ul>\n<p>Hay dos tipos de escalabilidad:<\/p>\n<ul>\n<li>La escalabilidad horizontal consiste en distribuir una aplicaci\u00f3n en diferentes m\u00e1quinas. Por ejemplo, a\u00f1adir instancias adicionales del servidor de aplicaciones y utilizar un load-balancer para equilibrar la carga.<\/li>\n<li>La escalabilidad vertical es aumentar la capacidad (memoria, CPU, disco duro) en la m\u00e1quina que aloja la aplicaci\u00f3n.<\/li>\n<\/ul>\n<h3><strong>Escalabilidad horizontal<\/strong><\/h3>\n<p>La escalabilidad horizontal no es muy el\u00e1stica, ya que supone a\u00f1adir m\u00e1s o menos manualmente las instancias de arquitectura que se necesitan y que estar\u00e1n inutilizadas cuando no se encuentran picos de actividad. En otras palabras, se infla el globo, pero no se saben desinflar. Sin embargo, es el caso que encontraremos con m\u00e1s frecuencia. No muy din\u00e1mico.<\/p>\n<p>Y mantener una infraestructura basada en la redundancia de diferentes partes de la arquitectura de la aplicaci\u00f3n resulta en en una infraestructura de gran tama\u00f1o para hacer frente a picos de actividad, pero sin usar m\u00e1s del 10 o 20% de la capacidad el resto del tiempo. Pocas ventajas sobre a una infraestructura f\u00edsica.<\/p>\n<h3><strong>Escalabilidad vertical<\/strong><\/h3>\n<p>La escalabilidad vertical es mucho m\u00e1s el\u00e1stica. Se instala la aplicaci\u00f3n en una m\u00e1quina virtual que se llevar\u00e1 50% de los recursos en situaciones normales, dentro de un servidor que aloja otras m\u00e1quinas virtuales con aplicaciones sin tanta variaci\u00f3n de la carga. Si hay un pico de actividad imprevisto y violento de la m\u00e1quina virtual, esta puede pedir prestado recursos a las m\u00e1quinas en el mismo servidor. La capacidad de tomar prestado memoria tambi\u00e9n se conoce como &#8216;ballooning&#8217; (para VMWare). Una vez pasado el pico de carga, la m\u00e1quina virtual va a liberar los recursos prestados y devolverlos a sus vecinas. Todo ello de forma din\u00e1mica, con menos saturaci\u00f3n posible.<\/p>\n<p>Sin embargo, la escalabilidad vertical alcanza r\u00e1pidamente sus l\u00edmites: no se puede aumentar indefinidamente la CPU o el rendimiento de un disco duro. Puede inflar y desinflar el globo, pero dentro de unos l\u00edmites.<\/p>\n<h3><strong>La elasticidad del Cloud<\/strong><\/h3>\n<p>Cualquier aplicaci\u00f3n ganar\u00e1 en fuerza en el Cloud.<\/p>\n<p>Por ejemplo, algunos tratamientos consumidores de memoria, como la creaci\u00f3n de un objeto, no se deben realizar dentro de un bucle. Muy a menudo, los bucles se utilizan para realizar procesamiento de datos de una tabla. M\u00e1s datos contiene la tabla, m\u00e1s alto el n\u00famero de iteraciones del bucle, mayor es la creaci\u00f3n de objetos y el consumo de memoria. Cuantos m\u00e1s usuarios ser\u00e1, m\u00e1s el servidor de aplicaciones realizar\u00e1 estos tratamientos y requerir\u00e1 memoria.<\/p>\n<p>Esto es un ejemplo t\u00edpico de una aplicaci\u00f3n con una escalabilidad baja que se puede superar mediante la adici\u00f3n &#8216;el\u00e1stica&#8217; de memoria durante una actividad m\u00e1xima.<\/p>\n<p>Otro ejemplo: un load-balancer y dos servidores de aplicaciones en dos m\u00e1quinas virtuales. As\u00ed que tienes dos copias del mismo software \u2013 el servidor de aplicaci\u00f3n \u2013 instaladas en memoria. Si el hipervisor de maquinas virtuales es capaz de detectar estos tipos de memorias id\u00e9nticas, se puede establecer un mecanismo para compartir la memoria con el fin de usar un \u00fanico espacio de memoria que se accede por las dos m\u00e1quinas virtuales. Esto ahorra memoria.<\/p>\n<h3><strong>Elasticidad de las aplicaciones<\/strong><\/h3>\n<p>Algunas t\u00e9cnicas de programaci\u00f3n ayudar\u00e1n a hacer las aplicaciones m\u00e1s o menos el\u00e1sticas. La primera y la m\u00e1s citada es hacer la aplicaci\u00f3n la m\u00e1s stateless posible. \u00bfQu\u00e9 significa esto?<\/p>\n<p>En pocas palabras, una aplicaci\u00f3n stateful almacena en memoria los datos de la sesi\u00f3n del usuario y de su contexto. La sesi\u00f3n se mantiene en el mismo servidor, siempre y cuando el usuario est\u00e1 conectado: no es posible la transferencia de sesiones \u2013 los datos almacenados en la memoria \u2013 entre servidores cuando es posible para un servicio stateless.<\/p>\n<p>Imaginemos un sitio web de tienda online, con una alta actividad entre las 9:00 y las 17:00, que corresponde a 10 000 usuarios que est\u00e1n repartidos en 10 servidores. Si la aplicaci\u00f3n es stateful, todos los datos se almacenan en la memoria, incluyendo la identificaci\u00f3n del usuario, y la memoria se libera s\u00f3lo cuando el deja el sitio al cerrar la sesi\u00f3n. Si el 10% de los usuarios se olvide de cerrar la sesi\u00f3n, o si la actividad cae a 1 000 usuarios, entonces vamos a mantener en la memoria 1 000 sesiones &#8230; repartidas en los 10 servidores. En otras palabras, la aplicaci\u00f3n utilizar\u00e1 el 10% de los 10 servidores cuando ser\u00eda suficiente un unico servidor.<\/p>\n<p>Ahora bien, si la aplicaci\u00f3n es completamente stateless, la sesi\u00f3n no se guarda en memoria y por lo tanto, no est\u00e1 atada a un servidor. Aunque 10% de las sesiones permanecen activas, ser\u00e1 posible liberar los servidores como y cuando la actividad disminuye, para mantener un servidor ocupado al 100% (o m\u00e1s bien dos servidores ocupados a 50%).<\/p>\n<p>Es dif\u00edcil programar aplicaciones completamente stateless, ya que debemos almacenar los datos en alguna parte, y si no en la memoria, ser\u00e1 en la base de datos, por lo menos temporalmente. Pero el acceso a una base de datos es m\u00e1s caro en rendimiento que un acceso en memoria. Por lo tanto, se tratar\u00e1 de desarrollar la aplicaci\u00f3n en m\u00f3dulos diferentes o diferentes sub-aplicaciones, algunos stateless, otros stateful.<\/p>\n<p>Por ejemplo, la aplicaci\u00f3n que gestiona la cesta del usuario se beneficiar\u00e1 de ser programada en modo stateful, con varias ventajas:<\/p>\n<ul>\n<li>Se trata de datos que son los m\u00e1s accesidos y modificados durante la sesi\u00f3n, as\u00ed que se requiere el mejor rendimiento: nada peor que tener que esperar 10 segundos cada vez que se agrega un nuevo elemento en la cesta, vas a salir del sitio r\u00e1pidamente y jam\u00e1s volver\u00e1s.<\/li>\n<li>La cesta tiene una vida limitada: por lo general de 30 a 60 minutos. Si un usuario permanece conectado sin actualizaci\u00f3n, la sesi\u00f3n se elimina de la memoria al final de este per\u00edodo, y se &#8216;desinfla&#8217; la memoria. Esto resuelve el problema del 10% de los usuarios que se olvidan de cerrar la sesi\u00f3n.<\/li>\n<\/ul>\n<p>Otros datos, como la identificaci\u00f3n del usuario, pueden ser administrados por un m\u00f3dulo stateless con una tabla temporal. Nota importante: tambi\u00e9n vemos en este ejemplo lo importante que es de pensar en t\u00e9rminos de tiempo de vida de cada m\u00f3dulo y programarlo a trav\u00e9s de un time-out.<\/p>\n<p>Asincronismo es otro mecanismo que promueve la elasticidad. El procesamiento de la cesta en una tienda online no termina con la finalizaci\u00f3n de la compra y el pago: se deben utilizar los datos para la preparaci\u00f3n del paquete, su entrega, los datos en la contabilidad, la transferencia entre bancos, sin hablar de procesos de CRM (Customer Relationship Management) y otras cosas que hacen vivir la gente de marketing. Pero todos estos tratamientos no son urgentes y se pueden hacer cuando los servidores est\u00e1n menos ocupados durante la noche por ejemplo.<\/p>\n<p>Por lo tanto, se tratar\u00e1 de separar el front-end \u2013 la tienda online \u2013 del back-end mediante el env\u00edo de un mensaje de forma asincr\u00f3nica a la contabilidad y las aplicaciones de log\u00edstica, con los datos del pedido para que sean processados durante el tiempo de actividad m\u00e1s baja en los servidores con los recursos liberados<\/p>\n<p>El principal obst\u00e1culo para la elasticidad de las aplicaciones es en mi opini\u00f3n, en la base de datos, sin duda el m\u00e1s dif\u00edcil \u00abescalable\u00bb horizontalmente. La gesti\u00f3n de la persistencia necesitar\u00e1 una vez m\u00e1s una cierta modularidad que permite distribuir la informaci\u00f3n en bases de datos diferentes.<\/p>\n<p>Por \u00faltimo, creo que la realizaci\u00f3n de aplicaciones el\u00e1sticas van a introducir profundos cambios en las metodolog\u00edas y los ciclos de los proyectos, como una mejor integraci\u00f3n entre los equipos de desarrollo, de control de calidad y de producci\u00f3n. Una especie de fusi\u00f3n entre ITIL y Agil.<\/p>\n<p>La principal preocupaci\u00f3n de los equipos de desarrollo y de QA es entregar aplicaciones en tiempo y con la mejor calidad posible, no el consumo de recursos. A menos que tengamos equipos de proyecto dedicados a la realizaci\u00f3n de aplicaciones virtualizadas, tomar en cuenta el consumo de recursos o la elasticidad no est\u00e1 en el orden del d\u00eda. El \u00fanico punto donde estos dos mundos se encuentran es en la disponibilidad de servicios y por lo tanto, los acuerdos de nivel de servicio (Service Level Agreement).<\/p>\n<p>As\u00ed que estoy convencido de que cada desarrollador tendr\u00e1 que agregar conocimiento de virtualizaci\u00f3n en su CV y que cada empresa de servicios tendr\u00e1 que adquirir estas habilidades y metodolog\u00edas para desarrollar aplicaciones el\u00e1sticas.<\/p>\n<p>El Cloud est\u00e1 saliendo de las salas de m\u00e1quinas. Prep\u00e1rate.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En mi post anterior, he explicado el concepto de elasticidad como la capacidad de mover los recursos dentro de una infraestructura virtual para cumplir con las demandas de negocios y los picos de actividad, estos \u00faltimos no siempre predecibles. Pero la elasticidad no significa unicamente la capacidad de \u00abinflar\u00bb la infraestructura mediante la adici\u00f3n de [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,13],"tags":[],"class_list":["post-112","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones","category-cloud"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/112"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=112"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/112\/revisions"}],"predecessor-version":[{"id":729,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/112\/revisions\/729"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=112"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}