Ray Ozzie, de Microsoft, nos habla de Open Source y Azure

¿Qué supone La estrategia de diseño de Microsoft para Azure?

eWEEK – Me interesa el desarrollo de herramientas y aplicaciones. Por tanto, me interesa Oslo y lo que significa la estrategia de diseño de Microsoft para el entorno en nube de Windows Azure. También me interesa lo que usted piensa sobre diseño general.

Ozzie – En teoría, el reto, el objetivo último, es que forcemos los límites tanto como podamos para ver cuánto podemos abstraernos en el diseño, viendo el ciclo completo desde el analista al desarrollador y a la persona que entiende… y desde la persona que entiende el problema empresarial que debe resolverse al desarrollador, que probablemente en muchos casos tiene que buscar soluciones con código, con algún código de procedimiento, para ver cómo se comporta y cómo se desenvuelve en un entorno operativo.

La gente de Oslo ha estado a la cabeza del desarrollo y lo han hecho esto con gran vision conceptual, y lo han diseñado desde esa visión conceptual.

Si usted le echa un vistazo a Azure, si tiene una posibilidad para ver debajo del capó, lo que usted verá es fundamentalmente un modelo guiado en términos de como funciona ésto, y esos chicos han estado trabajando muy, muy estrechamente. Aún no han escrito nada, pero no importa, porque Don (Don Box, ingeniero distinguido de Microsoft) tiene algunas cosas que les podrán servir.

Pero la clave es, en esencia, que lo que Azure hace es tomar un modelo de servicio, un modelo de servicio robusto, en el que hay switches, hay multiplexores, equilibradores de carga e interfaces web; defines los roles, la relación entre ellos y cuanto necesitas en un sistema equilibrado; expresas máximos y mínimos, dices cuánta afinidad necesitas entre esos roles, cuántas copias necesitas de los mismos, dónde quieres que estén situados, etc. Es una descripción un poco sofisticada, pero nuestro tejido operativo puede tomar el código y hacerlo.

Estamos aprendiendo mucho. Vamos a aprender mucho durante el próximo año de la gente que lo está utilizando, pero llevarlo a un alto nivel no puede hacerse sin diseño. Es la manera de hacerlo.

¿Podemos salpicarlo con procedimientos, permitiendo que la gente añada código para que se puedan tomar decisiones inteligentes sobre la duplicación? Sí. Podemos y lo haremos. Pero hasta ahora es una pura declaración de intenciones.

El objetivo es conseguir la herramienta completa, empezando el camino en el analista de empresa y siguiendo adelante, así que ya veremos. Estamos en un punto en el que tenemos un repositorio común de unos cuantos proyectos que se están llevando a cabo y estamos avanzando.

Es un poco difícil… Hemos encontrado algunos retos en Azure porque tenemos un requisito fundamental del sistema: que no existan puntos de fallo, y que si se usa una base de datos como almacén, el controlador haga lo que se espera de él. Hay demasiada complejidad para que sirviera de base, a menos que sea un subsistema en un nodo.