JordiGO - Enterprise Architect

Muchas son las experiencias que se va acumulando a lo largo de la vida de un consultor focalizado en el delivery de soluciones. Partes de una mente pura ideal, creada sobre las bases de la teoría universitaria, y el día a día te demuestra que la realidad suele ser mucho mas compleja y sobretodo motivante y divertida. Durante todos estos años he podido enfocar proyectos de forma muy diversa, por tanto he tenido experiencias de mucha índole. Y al final he podido constatar que la realidad es la que manda y los requerimientos de nuestros clientes se deben poder satisfacer de forma que el producto resultante se alinee a sus necesidades que suele en la mayoría de los casos, sobretodo cuando el tiempo de desarrollo es substancialmente grande, cambia con respecto al marco inicial de trabajo. Es por ello que desde hace ya algunos años, soy más afín a planteamientos de desarrollo más próximos a metodologías más dinámicas que nos permitan dar valor añadido adaptable y progresivo a los escenarios cambiantes de nuestros clientes para que el resultado final sea competitivo a lo que están necesitando en el momento de ser liberado.

He escrito en más de una ocasión sobre las metodologías Agile, y como las mismas pueden escalar, pueden ayudarnos a trabajar de forma más eficaz, y me gustaría remarcar en este post, como Agile debe también poderse escalar mediante la ayuda de arquitecturas, SI, Agile también tiene una base arquitectónica, veamos algunas de las estrategias que podemos utilizar. Todas las que citaremos no tienen porque ser excluyentes y dependerá de las circunstancias de cada proyecto que utilicemos unas u otras.

• La primera de ellas la llamaremos Modelar con otros. Esta técnica nos indica que siempre es mejor modelar con dos o más personas trabajando colaborativamente que de forma unitaria. Ello nos permite compartir visiones y conocimientos, es fundamental que las bases más firmes del desarrollo aquellas que se sustentaran sean trabajadas de forma colaborativa. Cuantas veces he podido constatar que las fases iniciales aquellas que a priori no aportan mucho valora añadido, si las desarrollas de forma sólida te permiten después que tus equipos sean realmente productivos puesto que trabajaran de forma sólida.
• La segunda la titularemos algo así como focus en la colaboración por encima de la documentación. Cuantas veces he podido ver arquitectos que diseñan una arquitectura donde se asentará la aplicación y no han escrito ninguna línea de código, si puede parecer una contradicción, pero realmente a veces se confunde que los arquitectos no ven el código y se pasan el tiempo documentando en lugar de diseñar sobre código. Si está claro que lo que se desarrollo ha de estar bien diseñado y bien explicado, pero os puedo asegurar que el mejor diseño es aquel que va parejo al código, sobretodo si después sois los desarrolladores que tenéis que desarrollar sobre esta arquitectura.
• La tercera va muy ligada a la segunda, la titularemos probar con código, una arquitectura no debería quedarse solo con una ppt, o con un documento word, la arquitectura tiene que estar programada, testada y con ejemplos prácticos reales asociados a la aplicación que estamos desarrollando y no a una idea conceptual que está a 100 años luz de lo que estamos haciendo.
• La cuarta comentada ya en alguna ocasión es para mi fundamental, por favor pensar en implementar una arquitectura bajo el paradigma de mantener la simplicidad, no hace falta para ir a comprar al supermecado ir con Arian 5, simplemente con el medido que te resulte más práctico es aquel que se ajustará mas a tus necesidades y dará más éxito, los desarrolladores, no tendrán que hacer un master para aprender tu arquitectura y por tanto el número de malas interpretaciones será menor y por tanto el número de errores será menor y te permitirá como arquitecto supervisar el código desarrollado. SI, el arquitecto deberá supervisar el código y las buenas prácticas que la imaginación siempre creativa de los desarrolladores puede hacer.
• La quinta ligada con la cuarta es, utiliza las herramientas apropiadas, las justas, las más simples, las que te permitan ejecutar tu proyecto para cubrir las necesidades. Cuantas veces no hemos ido a la tienda de la esquina y hemos comprado el kit de herramientas que lo tiene todo para simplemente colgar un cuadro, hemos leído cientos de documentos y luego ha venido el manitas de turno y con un par de herramientas te ha colocado el cuadro sin perder ningún minuto. Ajustemos las herramientas a lo que necesitamos las justas y necesarias de tal forma que nos permita ser productivos y no nos reste tiempo en su uso.
• En un enfoque Agile, y yo diría en muchas de mis experiencias las arquitecturas han de tomarse en la primera fase del proyecto, se debe tomar las decisiones apropiadas que después marcan el desarrollo, así pues es conveniente pensar en los grandes problemas a solucionar primero para asentar la solución y después ya iremos ajustando a las necesidades evolutivas.
• La arquitectura no es cerrada, es dinámica a lo largo del tiempo y no debemos ser puristas y cerrarnos a necesidades o evoluciones a lo largo del ciclo de desarrollo. Cambios ante necesidades diferentes a las iniciales bien acotadas pueden ayudarnos a ser mucho más productivos
• Viaja ligero, no hagamos como nuestros padres que cuando viajaban llevaban la casa a cuestas para simplemente ir a la casa de al lado, generemos la documentación justa y necesaria, muchas veces un diagrama es mejor que 20 páginas de documentación
• Eso sí, no pequemos tampoco de escasez, no dejemos solo un mapa criptográfico que no se entienda, es posible que tengamos que desarrollar ejemplos conceptuales de uso, algún documento explicativo o sesiones de formación y dependiendo de la complejidad supervisión para comprobar que se ha entendido.
• Publicita tu arquitectura, no te conformes con dejarlo en un directorio, motiva su uso, su difusión y su conocimiento, crea si es necesario Wikis para compartir dudas preguntas o mejoras
• Y sobretodo tu arquitectura no es para hacer un rascacielos si tus clientes quieren una casa de verano, es posible no no necesiten tener un ascensor que sube 3 pisos por segunda cuando es solo de una planta baja.

Son reglas básicas, pero las mismas nos pueden ayudar a que nuestros equipos Agile sean mucho más productivos en el desarrollo, os lo puedo asegurar no desde el punto de vista teórico sino práctico.

El problema del paralelismo no es un elemento nuevo en este blog, cada día más los requerimientos de negocio nos demandarán soluciones que no bastarán con planteamientos simples y tradicionales, la tecnología está aquí y no tardará el momento que tengamos PC de sobremesa con 8-C. Empezamos a desgranar este problema en el post Paralelismo si resuelve problemas, con este nuevo post quiero analizar que nos aportará Visual Studio 2010, la iniciativa de Microsoft que nos ha de permitir simplificar la complejidad que siempre supone para los desarrolladores y testadores de las aplicaciones donde aplicamos paralelismo. La aproximación y compresión hacia el problema de Microsoft es conocido como solution-stack que comprende:

Mejoras en el lenguaje y compiladores, pero la apuesta importante son las librerías que nos ayudarán a generar aplicaciones en paralelo. VS 2010 es la primera wave de un planteamiento de Microsoft a largo plazo donde nos ayudarán a construir aplicaciones en paralelo.

Aplicaciones que aprovechen las capacidades del paralelismo ya se pueden construir a día de hoy, pero requieren tener conocimientos específicos y profundos para poder desarrollar estas aplicaciones. Lo que se pretende en mejorar la productividad de los desarrolladores, que nos permita abstraernos de la actual capa que nos encontramos actualmente cuando queremos programar aplicaciones en paralelo.

Una de las herramientas que tenemos actualmente son los Asynchronous agents library, sin duda ayudan pero se hace complicado construir aplicaciones realmente robustas y escalables y siempre nos queda el gusanillo de si dada determinadas circunstancias, escenario no testado se nos quedará bloqueado el sistema. Así pues necesitamos herramientas que nos ayuden a identificar bottlenecks o cuellos de botella, detectar áreas donde podríamos mejorar significativamente aplicando técnicas de paralelismo.

Parafraseando a Justin Ratner, CTO de Intel en los próximos 10 años deberíamos poder desarrollar aplicaciones de forma fácil que gestionen 80-Core, veremos a ver.

Para conseguirlo deberemos irnos apoyándonos en las libraries que nos proporciona Microsoft las Parallel Extensions (librería que soportan tanto programación declarativa como programación imperativa para datos, tareas y estructura de datos que hagan fácil la coordinación entre ellos), en la librería System.Threading (aunque aquellos que hemos utilizado hemos visto siempre serias barreras para acometer grandes aplicaciones paralelas, por la dificultad de gestionar threads en paralelo y sincronizar zonas de memoria común) y en Unified Cancellation Model (gestión de cancellation token que permita a las partes involucradas cancelar las tareas iniciadas en paralelo, para ello utilizaremos el objeto Barrier y el método SignalAndWait y CancellationToken).

Ejemplo de Parallel Extensions en .NET Library tenemos:

1. Parallel LINQ (PLINQ)
2. Task Parallel Library (TPL)
3. Coordination Data Structures (CDS)

La evolución lógica en la programación sería primero pensamos en Threads, luego nos pasamos al ThreadPool y luego llegamos a las Tasks, realmente sencillo y potente. Así pues toda sentencia independiente bien podríamos paralelizarla con Parallel.Do, ejemplo si tenemos MétodoA MétodoB y ambos son independientes porque hacerlos secuenciales, paralelizemoslo con Parallel.Do

Sin duda VS2010 nos dará herramientas que nos facilitará esta tareas, como el Parallel Stacks, pero ya si queremos podemos empezar a trabajar en .NET Framework 3.5 y VS2008 descargándonos de las Parallel Extensions. Tenemos que empezar a conocerlo para cambiar la forma como enfocamos las aplicaciones. Seguiremos desde este blog trabajando y analizando que nos va incorporando VS2010. Otra site que recomendamos sin duda es Concurrency

Haciendo un poco de memoria, todos recordaremos la primera versión de Windows Workflow Foundation (conocido con las siglas WF) en el año 2006 y dentro del framework 3.0 y que posteriormente fue actualizado en la versión 3.5. Estas dos versiones representaron el punto de partida que si bien fueron muy interesantes, bajo mi punto de vista y mi experiencia no marcaron un antes y un después en los desarrolladores para las compañías y poco impacto tuvo en las consultoras que desarrollamos en .NET. La nueva versión .NET Framework 4.0 pretende cambiar esta percepción ya que formará parte intrínseca del toolkit de los programadores de .NET, por tanto habrá que tenerla especial atención. Aunque seguramente nos preguntaremos que es, que me aporta, para que es útil, cuando lo podría utilizar. Para dar respuesta quizás nos deberíamos preguntar como debemos trazar nuestros caminos de aplicación?

Veamos el siguiente ejemplo, tenemos una aplicación, recibe una petición del cliente se atiende en un único proceso, llega una segunda petición que requiere un comportamiento diferente, mediante sentencias if/else se redirección su proceso y se ejecuta el componente de negocio más apropiado. Programación sencilla, muy básica y por tanto a priori, yo inicialmente optaría por ella, siempre vayamos a lo simple. Pero la simplicidad si va reñida con el no cumplimiento de los requerimientos es cuando no se debería seguir, en este ejemplo esta forma de procesar implica dado que tenemos  una variable que gestiona el estado implica un secuenciamiento de las peticiones y por tanto una limitación en la escalabilidad de la aplicación, si este es un requerimiento la solución no sería correcta por muy sencillo que sea. Así que la siguiente derivada que seguramente ya todos hubieseis implementado es la paralelización de dichos procesos.

Siguiendo el ejemplo veamos como quedaría, por supuesto esto es mucho más escalable que la versión inicial. Y naturalmente surge el tema que dado que tenemos multiproceso ya no podemos tener la variable estado en memoria tal como la teníamos, sino debemos mantenerla en un repositorio común a los dos procesos, hasta aquí nada nuevo que no supiésemos y que hubiésemos implementado. Por tanto fácil de implementar y fácil de seguir… o no es tan fácil, en este ejemplo concreto quizás si, pero y si los flujos son más sofisticados, quizás esta visión no sea muy fácil de seguir ni testar…Quizás deberíamos pensar en otro elemento que nos ayude a tener este control… Aquí es donde entraría en juego WF, veamos como quedaría nuestro ejemplo utilizando WF. En el ejemplo vemos como la petición es recibida por la activity ReceiveMessage, le sigue el condicionante if, existe otro actividad de recepción donde le sigue un while que procesa la actividad Z

En esta imagen vemos como el runtime de WF procesaría la primera actividad la más externa, ya que estamos tratando con un ejemplo secuencial y seguiría por las siguientes actividades. Y naturalmente me preguntareis todo esto, para que, que ganamos de entrada… Como suelo decir siempre a la gente que trabaja conmigo, principio de la simplicidad, principio de la claridad, y bajo mi punto de vista un diagrama siempre es más clarificador que tratar de entender el flujo en el código, por tanto es una buena razón para su uso, no os parece? Pero me diréis, quizás con esta aproximación hemos perdido la escalabilidad que habíamos ganado. Veamos si esto es así o no…

El siguiente gráfico podemos ver, que no es cierto, no perdemos escalabilidad, claramente lo vemos en las dos 

imágenes que os he agregado, donde podemos ver como podemos seguir procesando las peticiones en múltiples máquinas, pero es ahora el runtime de WF quien nos facilita la gestión de la persistencia del estado, liberándonos y facilitándonos la programación, por tanto vamos por buen camino y si parece que nos ayuda en lugar de complicarnos la vida. Y un punto extremadamente importante es la hidratación de los procesos, estos pueden estar esperando un cambio de estado por tiempo (segundos a meses) que en el momento preciso se continuará el proceso.

Pero yo destacaría otras características importantes de WF que ya vemos puede ayudarnos, coordinar trabaja en paralelo, veamos un ejemplo de como, podríamos implementarlo, la siguiente imagen muestra el uso de la actividad Parallel (forma parte de WF Base Activity Library) hemos lanzado dos peticiones, por ejemplo de WCF y estamos esperando a que se hayan procesado para continuar el flujo de ejecución.

Otro interesante ejemplo que nos puede ayudar WF es el que muestro en el siguiente gráfico para la trazabilidad de nuestro flujo de trabajo, podemos a través de WF trazar por donde está pasando nuestras actividades, esta parte es muy interesante para monitorizar actividades de negocio de tu aplicación.

WF también nos va a permitir crearnos nuestras actividades custom mediante Custom Activity, estás pueden ser escritas en código C# o VB.NET o cualquier otro lenguaje .NET. De esta forma podemos crear actividades para ser reutilizadas en otras partes de la aplicación o en otros sistemas.

Seguro que ya estaréis pensando, pues esto me iría bien con mis servicios WCF, sería posible, la respuesta es SI, por supuesto, es un escenario perfectamente válido, en este caso nos preguntamos donde se ejecutaría, estas actividades se tienen que ejecutar en un proceso, pero cual es este… pues la respuesta sería la misma que para WCF, podemos tener nuestro propio host o como haríamos con WCF hospedarlo en IIS, con la finalidad de facilitar este proceso a los desarrolladores, Microsoft ha lanzado la tecnología que se conoce actualmente con el nombre de Dublin, implementa una extensión por decirlo de alguna manera del IIS

Podemos ver en este gráfico como funcionaría. Naturalmente esto nos lleva a pensar en otros escenarios con el uso combinado de una aplicación ASP.NET con servicios WCF y el uso de WF y dando una vuelta más de tuerca si lo combinamos con la potencialidad del balanceo de carga de Dublin tenemos los escenarios que seguramente tanto ansiamos en el pasado. Pero son los únicos escenarios donde pensaríamos que es válido WF? nos plantearíamos su uso en los clientes de aplicación? Nos platearíamos para la gestión del flujo de navegación de la aplicación, de las ventanas? La respuesta es SI por supuesto que si.

Sin duda con .NET 4.0, WF, Dublin, WCF debemos plantearnos nuevas formas de diseñar las soluciones, que no pasan por complicarnos la vida, sino todo lo contrario, ganar en productividad, ganar en eficiencia, en escalabilidad, en control. Veamos si esta vez nos motivamos a su uso de forma empresarial.

Quisiera esta vez, mostraros un par de vídeos, uno es realidad, el otro nos invita a imaginar el futuro de la mano de las tecnología Microsoft que estoy seguro vendrán en un futuro no muy lejano, es solo cuestión de tiempo que alguna de las ideas que veremos en el siguiente vídeo sean una realidad. Sin duda, nuevas formas de interactuar con la información mejoran la calidad del servicio, y por supuesto mejora la productividad de las tareas realizadas. ya sea ocio, ya sea trabajo, relaciones sociales. Dispositivos virtuales, inexistentes antes de que la información fluya por ellos, adaptables, configurables, un abanico de divertidas formas de comprender la información, os invito a que dediques unos minutos a ver la totalidad de este primer vídeo, sin duda aquellos más apasionados de la tecnología pensarán ya queremos que sea una realidad, simplemente os digo que creo que estamos cerca.

Ian Sands, Director of Envisioning nos explica en este video lo que acabamos de ver

Para llegar a ello, sin duda pasos como los que está llevando a cabo Microsoft en el tema de la interacción (Microsoft Interactive Canvas) ayudarán a que sea una realidad, el siguiente vídeo no es fantasía sino una realidad del uso de la tecnología que ya hemos comentado en este blog en alguna ocasión conocida con las siglas WPF (windows presentataion foundation) y el uso que esta tecnología a permitido a una empresa de diseño aventurarse al uso de la misma por encima de otras tecnologías que en su pasado claramente eran dominadoras en su campo, pero que van cediendo espacio a la imaginación de nuevas formas de ver entender y jugar con la información, el conseguido por esta empresa es el conocido por "Design Week" que es un equivalente a los Oscar. Lo que veremos es una aplicación conectada a varios monitores y sensores de movimiento, y una estación con una pluma digital para crear animaciones en tiempo real.

Aquellos que os habéis quedado con más ganas de ver más cosas os invito a que vayáis a la siguiente dirección: vimeo

Existen otros videos realmente apasionantes sobre el futuro que os animo a que visiteis

Os puedo garantizar que seguiremos estando atentos para ver que otras novedades se nos presenta.

Seguramente nunca antes, se había escrito tanto sobre un concepto como se está haciendo en tiempo record con Cloud. Que es? Generará tantos beneficios? Se movilizará tanta industria? En que situación nos encontramos?. Seguramente nunca antes había generado tantas dudas para los CTOs, CIOs, Directores de Sistemas la viabilidad de subirse a la nube/Cloud. En varios post con anterioridad hemos ido entendiendo que era este concepto y si sería tanta revolución como se anunciaba. Retomemos una pregunta inicial, Cloud y Cloud Computing es lo mismo…? Quizás no exista una respuesta única y seguramente cada uno matizará en base a lo que entiende y su propia visión. Me quedo con la idea que Cloud después de analizarlo no difiere mucho con respecto al concepto Internet, llevamos 25 años subidos a la nube, Internet ha ido evolucionando siendo un gran repositorio de datos y múltiples aplicaciones que nos han permitido analizar y ver la información desde la localidad y con la potencia de la globalidad. Cloud Computing pretende dar un paso más, pretende aprovecharse de toda la potencia “infinita” de escalabilidad que ofrece Internet para que cualquier aplicación puede aprovecharse de ella con una concepción global. Por tanto Cloud Computing es más bajo mi punto de vista una evolución que una revolución, ya que esta se inicio realmente con Internet, quizás el factor diferencial es la tecnología que permitirá un nuevo modelo de negocio = PAY-FOR-WHAT-YOU-USE. Seguramente ya no será necesario pagar por la totalidad de la aplicación si realmente solo hacemos uso de un 40% de la misma. Porque no trasladar modelos de negocio como los servicios domésticos como el agua o la luz, pagamos (en teoría) por lo que gastamos, porque no trasladar este mismo modelo al hardware, software, servicios?

Por tanto si encima de la mesa nos ponen este nuevo plato, nos preguntamos debemos comerlo, nos sentará bien? Debemos llevar nuestras aplicaciones a la Cloud, seguramente os estaréis preguntando. Si es así, podemos llevar todas nuestras aplicaciones existentes, deberemos desarrollar nuevas aplicaciones? Seguramente las primeras respuestas lógicas serían, todas aquellas aplicaciones desarrolladas en clave de gran escalabilidad por la población de usuarios bien pueden ser candidatas a llevar a la Cloud, así pues si hemos diseñado una solución teniendo presente factores como seguridad, gestión de la información, mantenibilidad, reusabilidad, disponibilidad, escalabilidad, experiencia de usuario, distribución, etc., seguramente ya tendremos los primeros pasos realizados. Estas primeras claves nos llevarán a otra multitud de preguntas como por ejemplo si tomamos el ejemplo de la gestión de los datos, estos serán accesibles on-line o off-line o ambas necesidades son requerimientos de la aplicación, así pues será necesario implementar técnicas de sincronización de información. En función de los aspectos claves que necesitemos para nuestra aplicación clasificaremos nuestra aplicación en base a estas categorías como Cloud Infraestructura, Cloud Storage, Cloud Plataforma, Cloud Aplicaciones y Cloud Core Servicios. Veamos que dice el mercado respecto a estos conceptos:

• Cloud Infraestructura o más comúnmente conocido como virtualización de servidores en la Cloud. Lo que ofrecerá es procesamiento, para aplicaciones donde se requiera gran capacidad de escalamiento será imprescindible este tipo de servicios. Ello nos llevará a los grandes centros de proceso/datos donde permitan “enchufar o desenchufar” proceso de forma rápida y eficaz, sin duda el factor clave será la virtualización de entornos.
• Cloud Storage, se refiere al tipo de almacenamiento de datos incluyendo servicios de bases de datos, servicios de almacenamiento, servicios de sincronización de datos entre repositorios de datos servicios de NAS. Estos servicios deben poder ofrecer el modelo de pay-as-you.go o payper GB. Seguramente todos nos puede venir a la mente los beneficios que esto conlleva, disponibilidad de almacenamiento y obtención de datos en cualquier localización y en cualquier momento. Estos servicios deben ser rápidos y más económicos que si optamos por el método tradicional.
• Cloud Platform, sin duda parte esencial y que puede llevar al éxito o fracaso de muchas aplicaciones que queremos llevar a la Cloud es la plataforma en al que vamos a desarrollarla, ya que esta es la que nos dará la disponibilidad, el como construirla, el como testarla. Sin duda ya tenemos plataformas que hemos utilizado para llevar nuestras aplicaciones a Internet como la plataforma ASP.NET Ajax, pero las nuevas demandas exigen nuevos paradigmas, nuevos modelos como el que hemos citado en mas de una ocasión en este blog como es Microsoft Azure.
• Cloud Applications, aquí ya nos podemos encontrar con la primera pregunta importante, tengo la totalidad de mi aplicación en la Cloud? tengo parte de ella y esta hace uso de los Cloud Services? Sin lugar a duda la arquitectura que presentemos diferirá de forma importante a como hemos venido desarrollando las aplicaciones tradicionales, requiere un diseño orientado a los procesos, por tanto después de adecuar nuestra aplicación al uso de la Cloud y habilitarla en nuestra Cloud Platform deberemos diseñar los procesos que habilitaremos en la Cloud. El uso de Cloud Applications, puede eliminarnos la necesidad de instalación localmente de la aplicación, reduciendo el esfuerzo de despliegue de gestión de soporte. Este tipo de aplicaciones se conocen como SaaS Software as a Services. Pero una alternativa a ello pueden ser las aplicaciones S+S (que ya explicamos en post anteriores) donde conjugan un modelo híbrido de implementación entre despliegue en la Cloud de los servicios y uso de aplicaciones locales instaladas con mayor adaptación al medio que las hace uso.
• Core Cloud Services, conjunto de servicios de arquitectura que podremos hacer uso en nuestras aplicaciones como por ejemplo la gestión de la identidad, servicios de integración, de mapeo, sistemas de facturación y de pago, de búsquedas, de procesos de gestión del negocio, de workflows, etc.

Seguramente una pregunta natural sería decirnos hay un solo Cloud o puede haber más de un Cloud? O la siguiente pregunta el Cloud debería ser público o gestionado de forma privada? Todos los Clouds públicos deberían hacer uso de la misma tecnología? Y yo me pregunto, es importante esta cuestión? era importante esta pregunta cuando vivíamos en el mundo Internet? Creo que la selección de la misma y el éxito vendrá más de la mano de como se implementa, del conocimiento, visión, estrategia y conocimiento de la plataforma, de la infraestructura que de la decisión de una u otra, por tanto sepamos como hacer uso de la misma y hagámoslo bien desde el principio, pues si una cosa aprendo con el día a día es que el factor tiempo cada vez es más crítico para sacar algo con beneficio a medio plazo. En sucesivos post seguiremos analizando aspectos claves de este apasionante estado del arte.