Windows Azure

Traslade sus aplicaciones a Windows Azure

Alex Homer

Los expertos en estilo de vida le dirán que el cambio a un nuevo hogar es una de las situaciones más estresantes que las personas padecen durante su vida y, sin embargo, enfrentados a optar entre esto y trasladar una aplicación a una plataforma nueva, muchos de nosotros no titubearíamos en comenzar a empaquetar nuestros enseres. Pero afortunadamente el traslado de las aplicaciones a Windows Azure es pan comido.

Desde hace muchos años que Microsoft desarrolla aplicaciones altamente escalables en diversos centros de datos a lo largo del mundo: aplicaciones con un alcance global y una disponibilidad elevada, que ofrecen excelentes funcionalidades para los usuarios. Windows Azure le permite aprovechar la misma infraestructura en la implementación de sus propias aplicaciones, con las capacidades correspondientes para reducir los requisitos de mantenimiento, maximizar el rendimiento y minimizar los costos de sus aplicaciones.

Desde luego, las personas han estado externalizando sus aplicaciones a las empresas de hospedaje durante años. Puede ser en forma de alquiler de espacio de bastidores o un servidor en un centro de datos remoto para instalar y ejecutar aplicaciones, o puede ser simplemente el alquiler de espacio en un servidor web y una base de datos en una empresa de hospedaje. Sea como sea, el espectro de características disponibles generalmente es limitada. En el caso típico, no hay mecanismo de autenticación, mecanismos de puesta en cola de mensajes, administración del tráfico, sincronización de datos ni de los otros servicios periféricos que forman parte integral de Windows Azure.

Podría obtener la impresión que a causa de todas estas funciones el traslado a Windows Azure es un proceso complejo, pero con tal de que se tome el tiempo de analizar sus requisitos y explorar las características disponibles, el traslado a Windows Azure puede ser un proceso rápido y relativamente fácil. Para ayudarle a entender las opciones y tomar las decisiones correctas, el grupo de Patrones y procedimientos de Microsoft recientemente publicó una versión actualizada de la guía de migración a Windows Azure: “Traslado de las aplicaciones a la nube en Windows Azure” (msdn.microsoft.com/library/ff728592).

La guía abarca un amplio espectro de escenarios de migración de aplicaciones a Windows Azure. En este artículo exploraré estos escenarios, revisaré las decisiones que debe tomar y analizaré los consejos prácticos y útiles que la guía ofrece para ayudarle a tomar las decisiones correctas. Aunque el proceso de migración en varios pasos que la guía sigue es un poco rebuscado (y es poco probable que las personas lo sigan cabalmente), este método ilustra la mayoría de las opciones y muestra las características de Windows Azure que podrían serle de utilidad en sus propias aplicaciones. En la Figura 1, tomada de la guía, vemos un mapa conceptual de las rutas de migración que podría seguir para trasladar una aplicación desde un centro de datos local a Windows Azure.

Figura 1 Mapa conceptual de algunas de las rutas de migración en Windows Azure

¿Hospedaje de infraestructura o plataforma?

Como puede apreciar en el mapa, la decisión inicial al migrar a Windows Azure es elegir el camino que va a seguir: el de la infraestructura como servicio (IaaS) o la plataforma como servicio (PaaS).

Como lo dice su nombre, el enfoque de la IaaS entrega la infraestructura del tiempo de ejecución (un servidor virtual y conectividad a la red) para que usted instale el sistema operativo, los servicios y las aplicaciones a su antojo. De hecho, le permite tomar simplemente su servidor y ejecutarlo en los centros de datos de Microsoft. Windows Azure ofrece una variedad de sistemas operativos preinstalados entre los cuales elegir (por ejemplo Windows Server y Linux) y usted también puede aprovechar los servicios periféricos como la autenticación a través de Windows Azure Active Directory, mensajería con colas de almacenamiento de Windows Azure o el bus de servicio, enrutamiento global a su aplicación a través de Traffic Manager, etcétera.

Por otro lado, al adoptar el método PaaS puede dejar que Microsoft administre el sistema operativo y la plataforma del tiempo de ejecución por usted. Los sitios web Windows Azure ofrecen una plataforma de hospedaje fácil de usar para las aplicaciones y sitios web con funciones de administración e implementación sencillas que se pueden integrar directamente con muchos sistemas de control de código fuente y permiten programar en una gran variedad de lenguajes. Si requiere de más control sobre la plataforma, por ejemplo la capacidad de ejecutar una mezcla de diferentes tipos de roles e integrar directamente las funciones de almacenamiento en caché, puede optar por el método de los Servicios en la nube. Estos le permiten implementar roles web y de trabajo independientes, ofrece un espectro más amplio de opciones de configuración y es ideal para un entorno de implementación por etapas y con versiones.

Como veremos más adelante, la elección entre IaaS y PaaS no se limita al código de aplicaciones. Cuando seguimos el camino de la IaaS, podemos optar por implementar una máquina virtual de Windows Azure con una base de datos preinstalada como SQL Server o MySQL. En el camino de la PaaS, mientras tanto, Windows Azure también ofrece un mecanismo de base de datos hospedada llamado Base de datos SQL de Windows Azure que, de hecho, es una instancia hospedada de SQL Server que se puede usar prácticamente de la misma forma que un servidor SQL Server local.

Rumbo a la nube con la IaaS

El método de la IaaS tiene varias ventajas claras para hospedar nuestras aplicaciones. Por ejemplo, podríamos trasladarnos a una máquina virtual en la nube sin necesidad de realizar ningún cambio en el código de la aplicación y conectarla a nuestra red y dominio internos a través de una red virtual; todos nuestros sistemas de pruebas, implementación, administración y control seguirán funcionando igual como antes.

En verdad, lo único que hicimos fue reemplazar el cable de Ethernet del centro de datos por una conexión de Internet a Windows Azure. Una red virtual de Windows Azure puede conectar nuestra red local a una red configurada en la nube mediante un enrutador de red privada virtual (VPN) estándar, lo que nos permite usar direcciones IP de red internas, igual como lo haríamos en forma local. Sí, en la conexión se genera un poco de latencia adicional y deberemos pensar en qué hacer con los esporádicos errores de conexión transitorios, pero ya no tendremos que administrar y actualizar el hardware, infraestructura y sistema operativo. (Para lidiar con los errores de conexión transitorios para muchos tipos diferentes de operaciones, podríamos pensar en usar el Bloque de aplicaciones de control de errores transitorios de Microsoft. Para obtener más información, consulte msdn.microsoft.com/library/hh680934(PandP.50).)  

El método de la IaaS con las máquinas virtuales de Windows Azure es ideal cuando debemos ejecutar software o servicios donde no tenemos acceso al código fuente o no podemos modificar la aplicación (por ejemplo, cuando dependemos de una aplicación de otro proveedor). También funciona muy bien cuando necesitamos una configuración fuera de lo común para el sistema operativo o los servicios corrientes, o cuando debemos establecer ciertos permisos determinados en los archivos y recursos.

En términos de las pruebas y la implementación, el equipo de desarrollo no verá ninguna diferencia con los procesos existentes. Los equipos de desarrollo locales y el servidor de compilación pueden llevar a cabo la implementación en los entornos de prueba y de producción en Windows Azure o pueden ubicar los servidores de prueba y de compilación en la nube. En la Figura 2, basada en una ilustración de la guía, se aprecia un ejemplo de una configuración de prueba e implementación que abarca los entornos de prueba, tanto locales como en nube, al usar dos suscripciones a Windows Azure independientes: una para las pruebas y otra para la aplicación activa.

Figura 2 Visión general de un posible mecanismo de desarrollo, pruebas e implementación

Por lo tanto, la única diferencia de verdad al optar por el método de la IaaS de Windows Azure es que la aplicación ya no se ejecuta en su propia sala de servidores costosa con aire acondicionado, donde consume recursos y ancho de banda de la conexión a Internet. En vez de esto, se ejecuta en el centro de datos de Microsoft que usted elija, donde los cambios en la máquina virtual se conservan en el almacenamiento de copia de seguridad de la imagen original, se entrega una conectividad confiable permanente y la plataforma del tiempo de ejecución garantizará que estará disponible en forma continua.

Además, puede elegir entre una variedad de tamaños para su máquina virtual; actualizar las instancias durante la ejecución, cuando haga falta; configurar el sistema operativo junto con sus servicios para adaptarlo a las necesidades específicas de la aplicación; implementar instancias adicionales para responder frente a los cambios en la carga e incluso configurar implementaciones de enrutamiento automático en diferentes centros de datos para maximizar la disponibilidad y minimizar los tiempos de respuesta en todo el mundo.

Simplificación de la administración con la PaaS

Si quiere evitar tener que administrar el sistema operativo por su propia cuenta, es posible que elija el camino de la plataforma como servicio. Aunque esto significa que deberá omitir algunas oportunidades de configuración de su propio tiempo de ejecución, reduce las labores y los costos de administración, ya que Microsoft se hace responsable del mantenimiento de los servidores, la actualización del sistema operativo y la aplicación de las revisiones. Usted se puede concentrar únicamente en el código de la aplicación y de su interacción con los servicios periféricos.    

La manera más fácil de trasladar un sitio o aplicación web a Windows Azure es implementarla en los Sitios web de Windows Azure; serán muy pocos los cambios necesarios en la aplicación, si es que los hay. Puede implementar desde Microsoft Team Foundation Server (TFS) u otro repositorio de código fuente como, por ejemplo, GitHub. Según sus necesidades y el presupuesto destinado al hospedaje, puede optar por hospedar la aplicación en un servidor web compartido o en una instancia reservada, donde podrá garantizar el rendimiento y administrar la cantidad de instancias para satisfacer la demanda.

Por otro lado, si necesita un mecanismo integrado para realizar implementaciones con versiones y aplicaciones por etapas, además de tener la libertad de escalar partes de la aplicación por separado, podría optar por usar los roles web y de trabajo de los Servicios en la nube Windows Azure para hospedar su aplicación. Al trasladar las tareas en segundo plano a los roles de trabajo y dejar la interfaz de usuario en los roles web, puede equilibrar la carga de la aplicación, realizar un procesamiento asincrónico en segundo plano y escalar cada tipo de rol por separado al ejecutar la cantidad de instancias adecuada para cada uno.

(Para implementar el escalado automático de los roles en una implementación en los Servicios en la nube en una programación preestablecida o en respuesta a eventos en tiempo de ejecución (por ejemplo cambios en la carga de los servidores), evalúe la posibilidad de usar el Bloque de aplicaciones de escalado automático de Microsoft. Para obtener más información, consulte msdn.microsoft.com/library/hh680892(PandP.50).)  

Para conectar los roles web y de trabajo, generalmente transmitimos los datos entre estos en forma de mensajes, mediante las colas de almacenamiento de Windows Azure o las colas del bus de servicio de Windows Azure. (Las colas del bus de servicio permiten mensajes de mayor tamaño y cuentan con sistemas integrados para la autenticación y el control de acceso.) El uso de mensajes también abre el diseño al uso de patrones de mensajería y almacenamiento estándar como, por ejemplo, solicitud/respuesta, enviar y olvidar, escritura diferida, etcétera. Si su aplicación está formada por componentes que se rigen por un diseño de arquitectura orientada a servicios (SOA), el traslado a los Servicios en la nube Windows Azure será relativamente fácil. 

Por supuesto, el uso de los roles web y de trabajo puede significar que haya que refactorizar parte de la aplicación. Pero en muchos casos esto no es grave y no afecta la lógica de negocio central ni el código de la presentación. Las aplicaciones ASP.NET MVC, por ejemplo, funcionan bien cuando se migran a Windows Azure y pueden tener acceso a los almacenes de datos como SQL Server exactamente de la misma forma como cuando se ejecutan de manera local o cuando se implementan en máquinas virtuales con el método de la IaaS.

El traslado a los Servicios en la nube Windows Azure también puede servir como oportunidad para actualizar el mecanismo de autenticación y autorización, cuando hay que realizar algún trabajo de refactorización en el código. Las aplicaciones modernas emplean cada vez más un mecanismo basado en notificaciones, como la identidad federada y el inicio de sesión único (SSO).

Este tipo de mecanismo permite que los usuarios inicien sesión con una gama de credenciales existentes en vez de exigir credenciales específicas para una sola aplicación y de iniciar sesión una sola una vez cuando se tiene acceso a más de una aplicación o sitio web. La característica de control de acceso de Windows Azure Active Directory, junto con Windows Identity Framework (WIF), facilita la implementación de la autenticación basada en notificaciones y la identidad federada. En la Figura 3, basada en una ilustración de la guía, aparece la aplicación de ejemplo a-Expense de la empresa ficticia Adatum, donde los usuarios se autentican con su propio Active Directory y reciben un token que presentan frente a la aplicación para obtener acceso.

Figura 3 Adopción de un sistema de autenticación basado en notificaciones

Para obtener más información sobre la autenticación basada en notificaciones, consulte la publicación relacionada del grupo de Patrones y procedimientos “Guía para la identidad y el control de acceso basados en notificaciones” en msdn.microsoft.com/library/ff423674. 

¿Dónde residirán mis datos?

Casi todas las aplicaciones empresariales emplean datos, y estos frecuentemente se almacenan en una base de datos como SQL Server o un sistema de administración de bases de datos relacionales (RDBMS) de otro proveedor. Una situación común al migrar una aplicación que emplea una base de datos relacional es implementar una máquina virtual de Windows Azure que hospeda el servidor de bases de datos (Windows Azure ofrece máquinas virtuales preconfiguradas que contienen Microsoft SQL Server o MySQL). También se puede instalar prácticamente cualquier otro tipo de almacén de datos que se pueda ejecutar en una máquina virtual con Windows o Linux en Windows Azure.

La conexión a una base de datos hospedada en la nube desde una aplicación hospedada en la nube se realiza igual como si la base de datos y la aplicación estuvieran hospedadas en un centro de datos local. Pero esta solo es una de las opciones disponibles en Windows Azure. Por lo general, deberemos decidir si implementamos los datos de la aplicación en la nube o si los conservamos en nuestras instalaciones propias y si nos comunicamos con el servidor de la base de datos a través de una red virtual o por medio de mensajes. Si nos decidimos por la nube, también deberemos decidir si vamos a seguir el camino de la IaaS o PaaS (base de datos SQL).

El patrón de Segregación de responsabilidades de consultas de comandos (CQRS) normalmente emplea mensajes para comunicar las actualizaciones de datos y resultados de consultas entre los diferentes componentes de la aplicación, y Windows Azure ofrece dos mecanismos de cola que podemos usar en nuestras aplicaciones. Pero para el acceso estándar a los datos, la participación de una red como Internet entre la aplicación y la base de datos puede generar demoras y conducir a un rendimiento insatisfactorio. Si las circunstancias o los requisitos de las disposiciones legales exigen que la base de datos se instale en forma local, el Almacenamiento en caché de Windows Azure puede ayudar a reducir estas demoras. (Para obtener más información sobre el patrón CQRS, consulte la guía relacionada del grupo de Patrones y procedimientos “Recorrido por CQRS” en msdn.microsoft.com/library/jj554200.) 

La Base de datos SQL de Windows Azure es una solución ideal para el almacenamiento general de datos al migrar una aplicación existente que use Microsoft SQL Server. A menos que el código requiera de alguna de las características más exóticas de SQL Server (como búsqueda de texto libre, funciones XML, procedimientos que requieren de la característica de programación del CLR o consultas distribuidas que dependen de SQL Server Service Broker), la aplicación existente funcionará sin cambios.

La Base de datos SQL de Windows Azure también es muy económica cuando tenemos que almacenar solo las cantidades de datos usuales. Para cantidades muy grandes de datos o cuando debemos implementar varias bases de datos, en cambio, el uso de un servidor de bases de datos hospedado en una máquina virtual se vuelve más atractivo. Podemos elegir el tamaño adecuado para la máquina virtual e incluso usar varias máquinas virtuales para implementar una conmutación por error de base de datos o un almacén compartido.

A veces el almacenamiento y la consulta de datos tienen que ir más allá de los sistemas de bases de datos relacionales. Por ejemplo, las empresas frecuentemente cuentan con petabytes de datos almacenados en registros de servidores, archivos con transacciones financieras, información de los medios sociales u otros tipos de datos que no se procesan con regularidad pero que podrían ser útiles en consultas ocasionales o futuras. Windows Azure ofrece el servicio HDInsight (basado en las tecnologías Hadoop de código abierto) exactamente para estos casos. Para obtener más información, consulte hadooponazure.com.

Tablas, blobs, colas y unidades

Windows Azure también ofrece diferentes tipos de almacenamientos que no se basan en el paradigma relacional de SQL. Podemos usar las tablas de almacenamiento y blobs de Windows Azure para almacenar datos de las aplicaciones, las colas de almacenamiento para transmitir mensajes entre los componentes de una aplicación y las unidades de almacenamiento que pueden actuar en forma similar a un sistema de archivos tradicional basado en discos.

Las tablas de almacenamiento de Windows Azure no tienen esquemas, lo que significa que cada fila es una entidad que incluye un contenedor de propiedades con valores, y una tabla puede tener diferentes tipos de entidades en cada fila. Esto resulta ideal para los datos estructurados (columnas y filas) y semiestructurados. Los blobs de almacenamiento de Windows Azure, por otro lado, se prestan mejor para almacenar datos sin estructura, como documentos, datos binarios, archivos en XML e imágenes.  

El almacenamiento de Windows Azure también es muy barato en comparación con un servidor de bases de datos o Base de datos SQL hospedada en una máquina virtual, pero esto significa que deberemos reescribir el código de acceso a datos existente. Normalmente las tablas y blobs de Windows Azure son más útiles cuando diseñamos nuestras aplicaciones desde cero para ejecutarlas en Windows Azure. Sin embargo, cuando la aplicación tiene una capa de acceso a datos claramente delimitada, que se puede reemplazar con una nueva, diseñada para usar las tablas y blobs de Windows Azure, entonces resulta razonablemente fácil comenzar a usar el almacenamiento de Windows Azure en vez de una base de datos relacional.    

Al igual que con todos los servicios basados en nube, existe la posibilidad de que los problemas de red transitorios o la limitación intermitente y temporal de los recursos provoquen que una solicitud de conexión inicial fracase. El Bloque de aplicaciones de control de errores transitorios (que se mencionó previamente) sirve para detectar en forma automática los errores y volver a intentar todas las operaciones de almacenamiento, incluidas las bases de datos relacionales y el almacenamiento de Windows Azure. Este procedimiento se recomienda para todas las aplicaciones basadas en nube y el Bloque de aplicaciones de control de errores transitorios facilita la implementación.

Roles de trabajo y tareas en segundo plano

Una de las fortalezas de los Servicios de nube de Windows Azure es el aprovisionamiento de un tipo especial de rol diseñado para realizar el procesamiento en segundo plano. El rol de trabajo no se limita solo a las partes subordinadas de las aplicaciones; en verdad se trata de un rol web que no tiene instalado el servidor web (IIS). Sin embargo, la situación más común es usar el rol de trabajo para ejecutar las tareas continuas que están atentas a las colas de Windows Azure (o colas del bus de servicio) para responder a los mensajes que instruyen al rol que realice alguna acción en segundo plano, como se aprecia en la Figura 4.

Figura 4 Traspaso de mensajes desde un rol web al rol de trabajo

Al separar de esto modo las tareas asincrónicas y las tareas en segundo plano, se simplifica la implementación de varios principios de diseño de aplicaciones básicos, como la separación de los intereses y la responsabilidad única. Al pasar información y comandos en forma de mensajes entre los roles ayudamos a la encapsulación de cada rol y reducimos las dependencias, de manera muy similar a cuando aplicamos los principios de la arquitectura orientada a servicios.

Por ejemplo, la guía explora cómo Adatum usa roles de trabajo para comprimir y almacenar las imágenes de los recibos que cargan los usuarios, para conservar el espacio de almacenamiento y exportar los datos de los costos a la aplicación de nóminas de Adatum. Las dos tareas se inician con un mensaje en una cola. El mensaje contiene los datos pertinentes a la tarea puntual.    

Cuando refactorice su aplicación para la implementación en los Servicios de nube de Windows Azure, las tareas que se prestan para ejecutarse en un rol de trabajo generalmente serán obvias. Las tareas en segundo plano también se pueden iniciar mediante programaciones y usted puede minimizar los costos de hospedaje al ejecutar más de una tarea en un mismo rol de trabajo, siempre que incluya el código necesario para reiniciar todas las tareas que puedan generar errores o detenerse. Windows Azure detecta cuando se genera un error en un rol e intentará reiniciarlo en forma automática, pero no puede detectar los errores en las tareas mismas.

También deberá evaluar qué va a hacer con las respuestas o salidas que llegan de la tarea en segundo plano. Por ejemplo, podría decidirse por emplear el patrón de escritura diferida para almacenar los detalles de los pedidos que los usuarios envían, para lo cual deberá empaquetar cada uno en un mensaje que la interfaz de usuario enviará a una tarea en un rol de trabajo. El rol de trabajo leerá el mensaje de la cola y almacenará los detalles en la base de datos. Sin embargo, si el número del pedido solo se genera en el punto del almacenamiento, entonces el rol de trabajo tendrá más dificultades para devolver este número de pedido al rol web para que lo presente en la interfaz de usuario.

¿Puedo permitirme Windows Azure?

Como vimos, Windows Azure contiene una amplia gama de características y servicios que deben satisfacer todos los requerimientos de sus aplicaciones, aunque todavía no tenga exactamente claro cuáles tiene en el momento. Puede implementar la aplicación en cualquiera de los centros de datos ubicados alrededor del mundo y aprovechar las funciones inmensas de almacenamiento y escalado. ¿Pero económicamente puede permitirse tener sus aplicaciones en Windows Azure? 

En el capítulo 6, “Evaluación de los costos de hospedaje”, de la guía, Adatum realiza varios ejercicios de estimación de costos para descubrir aproximadamente cuánto deberá pagar por ejecutar la aplicación a-Expense en Windows Azure. La aplicación solo usará un rol web y un rol de trabajo y deberá almacenar aproximadamente 20 GB de datos en una base de datos relacional y 120 GB de imágenes en el almacenamiento de Windows Azure. Con los precios actuales, Adatum calcula que esto tendrá un costo aproximado de USD 3000 al año. Aunque Adatum no puede definir el costo exacto de ejecutar la aplicación en su propio centro de datos, porque muchos de los recursos que usa se comparten con otras aplicaciones locales, el costo esperado en Windows Azure contrasta favorablemente.

Mejor aún, al introducir una solución de escalado automático como el Bloque de aplicaciones de escalado automático de Enterprise Library, Adatum calcula que podrá ejecutar la aplicación solo durante el horario de oficina, pero deberá agregar instancias de rol adicionales al término de cada mes para duplicar la capacidad, cuando se procesa la mayoría de los gastos y así podrá reducir el costo total a unos USD 2000 al año. Además, al adaptar la aplicación para que use las tablas y blobs de Windows Azure en vez de las bases de datos SQL o Microsoft SQL Server, Adatum calcula que podría ahorrar otros USD 750 anuales.

Por supuesto que sus propios requisitos de capacidad de aplicación y programaciones de operación serán diferentes y dependerán de la carga que deben soportar las aplicaciones y del almacenamiento del que requieren. Sin embargo, parece evidente que usted puede permitirse estar en Windows Azure y que el traslado será bastante menos traumático que una mudanza a un hogar nuevo.

Más información

La guía del grupo de Patrones y procedimientos “Traslado de las aplicaciones a la nube con Windows Azure” está disponible en msdn.microsoft.com/library/ff728592. Puede descargar una copia en PDF de la guía en microsoft.com/download/details.aspx?id=29252.

Las guías y marcos asociados del grupo de modelos y prácticas son:

• Desarrollo de aplicaciones de varios inquilinos para la nube: msdn.microsoft.com/library/ff966499
• Compilación de aplicaciones híbridas en la nube en Windows Azure: msdn.microsoft.com/library/hh871440
• Guía para la identidad y control de acceso basados en notificaciones: msdn.microsoft.com/library/ff423674
• Bloque de aplicaciones de control de errores transitorios: msdn.microsoft.com/library/hh680934(PandP.50)
• Bloque de aplicaciones de escalado automático: msdn.microsoft.com/library/hh680892(PandP.50)

Puede encontrar la página principal de Windows Azure en windowsazure.com y el Centro para desarrolladores de Windows Azure en windowsazure.com/en-us/develop/overview.

Alex Homer es escritor técnico asignado a la división de modelos y prácticas de Microsoft en Redmond, Washington. Sin embargo, hasta ahora ha resistido los atractivos dudosos del clima de Seattle por trabajar desde casa en las idílicas afueras rurales de Derbyshire Dales en Inglaterra. Sus divagaciones semicoherentes sobre el sector de las TI y la vida en general pueden encontrarse en blogs.msdn.com/alexhomer.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Masashi Narumoto
Masashi Narumoto es director jefe de programas en el grupo de modelos y prácticas. Ha estado trabajando en una serie de guías sobre Windows Azure y actualmente está enfocado en los big data. Anteriormente pasó más de 20 años desarrollando diversas soluciones y proporcionado asesorías, especialmente en el sector minorista y de manufactura. Puede encontrarlo en https://blogs.msdn.com/masashi_narumoto o en Twitter como @dragon119.