Diego's profileZonaDiegumPhotosBlogListsMore Tools Help

Blog


    August 27

    Verde Que Te Quiero Verde: Computación Sustentable

    Nuestro rancho Aquellos que siguen  mi blog en inglés saben que el número del Journal a aparecer hacia fin de año (es decir, no el siguiente Journal sino el que sigue a éste) estará abocado a explorar técnicas de computación eco-friendly. Esto es, que no dañen al medio ambiente (o que lo hagan, cuando sea inevitable, en la menor medida posible)

    Me está asesorando Lewis Curtis, arquitecto de infraestructura de Microsoft y una de las voces más activas en la búsqueda de iniciativas que permitan alinear más y más la tecnología a las necesidades de la sociedad -en todos sus estratos: social, empresarial, educativo, etc- con, al mismo tiempo, un mínimo impacto de daño en el ya desequilibrado equilibrio ecológico y que además, ya que estamos, permita reducir el consumo energético de todo el parque tecnológico, habida cuenta del encarecimiento en los costos que la generación de energía viene experimentando (que tarde o temprano se trasladan al consumo)

    De visita por mi oficina, Lewis me tiró unas ideas interesantes acerca de la correcta manera de entender y abordar la "Computación Verde" (Green Computing). Sintetizo su enfoque aquí

     

    6 aristas

    • Físico. En esta perspectiva se estudian alternativas para mitigar el calor liberado por el uso intensivo de las unidades centrales de procesamiento (CPUs). La concentración creciente de CPUs en espacios físicos de dimensiones reducidas torna los centros de datos (datacenters) en verdaderos infiernos. Literalmente hablando. Aquí no son solamente los fabricantes de CPU (Intel, AMD, etc) quienes están batallando para lograr una mejor ecuación performance-per-watt (rendimiento por electricidad consumida) sino que existen algunos estudios que detallan la ideal posición física de las CPUs para que estén lo suficientemente separadas como para que el incremento de temperatura no se potencie pero a la vez lo suficientemente cerca como para maximizar el aprovechamiento del espacio físico
    • Plataforma Operativa. Cuando se asignan procesos a servidores, se lo hace normalmente en función de la carga esperada de trabajo que estos procesos van a tener. El estudio de un consumo más eficiente de recursos dio lugar a dos tácticas: la optimización y la consolidación. La optimización del uso de la plataforma operativa se puede alcanzar de varias maneras, sea mediante la asignación correcta de recursos (CPUs, ancho de banda, etc) como por la detección de estado ocioso prolongado y consecuente hibernación, entre otras (esto, claro está, es también lograble desde el mismo hardware). La consolidación tiene que ver con la aglomeración de varios procesos en un mismo hardware, de modo de maximizar el uso de recursos
      Claro, acá puede impactar el hecho de que diferentes procesos pueden requerir una diferente plataforma operativa, lo que limita las chances de consolidación. Pero esto es mitigado gracias a los avances alcanzados en virtualización de plataformas, lo que ha permitido tirar viejo hardware, costoso de mantener, sin discontinuar las aplicaciones que en el mismo corrían -en muchos casos sistemas legados o legacy systems, los cuales hasta cierto punto pueden resultar tan caros de mantener como de migrar-
    • Regulaciones. A nivel gubernamental los países están avanzando (?) en metas de reducción de niveles de dióxido de carbono (CO2), el principal responsable del efecto invernadero (greenhouse effect). A la corta o a la larga eso se va a trasladar a un sistema de premios y castigos en la calidad y cantidad de energía que las compañías -y a renglón seguido los hogares- consuman. Probablemente esto vaya ligado a excensiones o gravámenes impositivos
    • La "Nube". Las aplicaciones hosteadas en la web misma, y con esto no me refiero a accesibles vía web ya que esto incluye a aplicaciones hosteables en un servidor hogareño, sino a aquellas aplicaciones cuyo "dueño" las recibe distribuidas como un servicio ("as a Service"), en lugar de hacerse responsable de su ubicación física y operación; decía que tales aplicaciones plantean desafíos tanto para el que las consume -quien no debe hacerse cargo del datacenter con lo cual acá tiene un significativo problema menos- como del que las provée, quien tiene ante sí la oportunidad de optimizar la granja de servidores, consolidando los clientes de tales aplicaciones SaaS (por Software as a Service o Software como Servicio). En la ecuación general, bajo este esquema de tiempo compartido (tiempo de ejecución, claro, o creíste que pusimos SaaS y nos rajamos todos de vacaciones... Zaas! smile_omg), el consumo de recursos y de energía es inferior al esperado por el esquema tradicional donde cada consumidor se hostea su aplicación en sus propios servidores (lo que se conoce como on premise delivery)
      Cuanto mayor sea la penetración del esquema "as a Service", mayor el ahorre global. Sin embargo, claro, pasar de la nada a este esquema no es fácil, sobre todo si se necesita que la parte hosteada en la nube interopere con lo que nos quede on premise. Qué de la atomicidad de las transacciones, qué del single sign-on (login único o SSO), qué de muchas otras tantas cosas como disponibilidad, tiempo de respuesta, etc
    • Inteligencia Sustentable. Imaginate un tablero de control donde podés monitorear la energía consumida por tu plataforma respecto de la actividad real que cada una está haciendo. Imaginate que podés establecer umbrales de consumo, disparar alarmas. Imaginate que podés tirar estadísticas históricas de ese consumo a fin de determinar tendencias y consiguientemente predecir la demanda futura esperable. No hace falta imaginarse demasiado porque existen esos monitores. Scry, Cognos (adquirido por IBM) por mencionar algunos de ellos
    • Código de Aplicación. Y llegamos al último, que a su vez engloba a todos los anteriores. En pocas palabras, no es cuestión de echarle la culpa de todo a la infraestructura, al soft de base e ilusionarse con la idea de que la solución pase nada más que por ahí. Por ejemplo, en nuestra apliación distribuida, dónde se conserva el estado de la sesión de cada usuario conectado? Es ese estado persistido al cabo de un tiempo en que el usuario no da señales de vida (y siempre antes de que expire su sesión), a fin de liberar la memoria para otras sesiones activas? Son los servicios state-less (una instancia única para todos) o stateful (una instancia individual por cada sesión que los consume)? Y qué hay para decir del ancho de banda? Se usa en forma eficiente? Qué significa "ancho de banda eficiente"? Enviar la menor cantidad posible de información en cada interacción o tratar de anticipar cierta información que el caso de uso pueda necesitar con una alta probabilidad? Y qué se puede decir del paralelismo en plataformas de más de un núcleo? Se saca tajada del procesamiento paralelo o el binario de la aplicación está pensado para el denominador común mono-núcleo? Podría seguirme extendiendo pero creo que con ésto queda demostrado que nosotros desarrolladores de soft no podemos hacernos los osos por muy ecológico que sea todo este tema

    Bueno, la consigna es enviar propuestas de artículos para computación verde que tengan un enfoque práctico (es decir, más allá del mero mensaje de que ahorremos gas, apaguemos luces y no imprimamos mails si los podemos leer de la pantalla). El plazo de envío se extiende hasta el 10 de Septiembre. Más detalles para hacernos llegar tu propuesta, acá

    August 02

    Mi Primer Journal Está en la Calle (#16, Identidades y Acceso)

    Portada y editorial del numero 16 de The Architecture Journal

     Dos años atrás,  cuando un artículo mío era publicado en una revista independiente de TI, un colega me dijo, "Vos deberías escribir para The Architecture Journal." No podía haber predicho que me iba a encontrar ahora escribiendo para esta revista en mi nuevo rol de editor. Le quiero agradecer a Simon Guest, por esta oportunidad y este enorme compromiso -durante su lapso, la cantidad de lectores se más que duplicó, pasando de 30 mil a más de 62 mil

    En este número, te invitamos a pensar en la Arquitectura de Identidades de tu organización. El manejo de identidades está evolucionando hoy del escenario simple, aislado, al escenario federado, en una forma que te puede sorprender

    Empezamos este decimosexto viaje con la introducción de Fernando Gebara Filho a los conceptos y estrategias en identidades, cómo han evolucionado y el camino por recorrer. Después, Jesús Rodríguez y Joe Klug examinan un surtido de estrategias para hacer de las identidades componentes de primera línea en el portfolio de aplicaciones federadas. Gerrit van der Geest y Carmen de Ruijter Korver consideran el desafío de establecer un entorno de confianza a nivel de aplicación ya que las identidades de usuario, en un mundo orientado a servicios, deben fluir desde el consumidor de un servicio hacia el prestador

    Para el perfil de arquitecto de este número, lo atajamos a Kim Cameron, autor de "Las Leyes de la Identidad", cuyas ideas en identidades federadas están dando forma a la siguiente generación de tecnologías de identidad de Microsoft. (Algo gracioso pasó el día que visité a Kim para esta entrevista: me olvidé mi tarjeta de acceso por lo que necesité que Kim "certifique" mi identidad en la entrada)

    Retomando nuestro paseo, Mario Szpuszta describe cómo el sistema de salud austríaco convirtió una crisis administrativa de provisioning en una clara oportunidad para crear una federación de identidades abierta. Luego Vittorio Bertocci explica cómo ciertos patrones de arquitectura nos ayudan a construir soluciones que consideran demandas (claims), de modo que cuando "la Nube" llegue a las compañías, el manejo de identidades no se va a ver necesariamente nublado

    Finalmente, Mike Morley y Barry Lawrence revelan cómo sincronizaron identidades en varios sistemas y aplicaciones legadas (legacy applications) desde una consola administrativa individual a través de un framework de consolidación

     

    Querido lector, quisiera ser el primero en darte la bienvenida a este número, y deseo que te sientas identificado con sus artículos. A disfrutarlo!

     

    Diego Dagum

    Editorial del numero 16 de The Architecture Journal