El objetivo de este nuevo post es enseñaros qué tiene Azure que ofrecer con su nuevo servicio de Blockchain Workbench. Esto era necesario después de varios posts acerca de cómo desplegar entornos de blockchain (Ethereum) en Azure, y de ver cómo en gran parte de los competidores de Azure se desviven contando lo fácil que es desarrollar aplicaciones con HyperLedger Composer. Por cierto, ya sabréis que recientemente se ha comunicado que Composer se descontinúa por parte del equipo del proyecto, que van a pararlo y a partir de ese momento cualquier nueva funcionalidad se añadirá a HyperLedger Fabric. Si sois seguidores de HyperLedger podéis leer un análisis del comunicado anterior en este interesante post de Walter Montes en Hackernoon sobre Hyperledger Composer has been put on pause, what are your options now?

Bueno volviendo al tema, primero hagamos una breve introducción a Azure Blockchain Workbench

¿Qué es Azure Blockchain Workbench?

Si nos vamos a la página oficial de la documentación sobre Blockchain Workbench tenemos que leer la mitad del primer párrafo para entender qué es Azure Blockchain Workbench:

Azure Blockchain Workbench proporciona el scaffolding de infraestructura para compilar aplicaciones de cadena de bloques, lo que permite a los desarrolladores centrarse en crear lógica de negocios y contratos inteligentes.

Es decir, Azure Blockchain Workbench (por abreviar lo denotaremos como «ABW«) es un servicio que básicamente nos facilita la vida a la hora de desplegar una arquitectura de ámbito empresarial (es importante recalcar la parte de empresarial) para generar de manera sencilla y potente aplicaciones de negocio en las que la tecnología DLT («Distributed Legder Technology«, o lo que es lo mismo Blockchain en cualquiera de sus implementaciones y variantes) forme parte fundamental y central de dicha aplicación. El servicio de ABW aporta comodidad y facilidad en las siguientes funcionalidades y características de una dApp («Distributed Application«):

• Despliegue
• Integración con proveedores de identidad
• Alta disponibilidad y tolerancia a fallos
• API de integración con la dApp
• Seguridad de la aplicación (Roles y permisos)
• Almacenamiento de datos «off-chain»
• Simplicidad a la hora de definir la «lógica de negocio»

Es fácil ver que son cuestiones que consumen gran parte del esfuerzo a invertir en un proyecto de estas características sin aportar nada a las funcionalidades de negocio a implementar. Por ello, ABW más que un servicio es más bien un conjunto de herramientas, servicios y guías que nos ayudarán a que nuestro equipo de proyecto se centre en aquello que realmente aporte valor.

Dicho todo esto, veamos cómo podemos empezar a utilizar Azure Blockchain Workbench.

Primer Paso: Acceso a Azure y selección del servicio de Azure Blockchain Workbench

Dentro del portal de Azure, solicitaremos la creación de un nuevo servicio de la categoría Blockchain, y buscaremos entre todas las opciones la denominada Azure Blockchain Workbench. Acto seguido confirmaremos la sección con el botón de «Ok» correspondiente.

 

Segundo Paso: Información sobre ABW y confirmación

Se nos mostrará un blade con información acerca del servicio seleccionado, así como de qué recursos constará el despliegue y enlaces útiles a información sobre él mismo como precio, documentación, ejemplos, etc. De paso confirmaremos nuestra selección con el botón «Crear» correspondiente. Esto iniciará una especie de «wizard» para guiar el despliegue.

Tercer Paso: Parámetros básicos del «ledger»

En este paso, nos pedirá ciertos parámetros básicos como el prefijo a usar en todos los recursos que va a generar más adelante, los datos del usuario administrador de las VMs que van a soportar el «ledger«, los datos de acceso a la BD que llevará el almacenamiento «off-chain«, la suscripción de Azure sobre la que desplegar los recursos y también la localización de dicho grupo de recursos. Rellenamos todos los parámetros y pulsando «Ok» pasamos al siguiente blade del proceso.

Cuarto Paso: Parámetros del Active Directory

La plataforma DLT  que desplegará ABW utilizará Azure Active Directory («AAD«) para guardar la información de los usuarios del sistema y las diversas dApps, por lo tanto antes de arrancar todo este proceso tendremos que tener un «tenant» de AAD creado y con los datos cliente de una Aplicación Empresarial registrados. Como esta parte toma cierto tiempo y requiere unos conocimientos previos que no son objetos de este artículo, para aquellos que no tengan un «tenant» de ADD es recomendable que se sigan las instrucciones sobre los prerrequisitos de ABW acerca de Azure AD en la documentación oficial.

En nuestro caso, nos limitaremos a introducir los valores del nuestro «tenant» de AAD, nuestro Application Id, y el valor de nuestra Application Key en las cajas de texto del blade.

Una vez hecho esto, pasaremos al siguiente paso pulsando en el botón «Ok«.

Quinto Paso: Parámetros de rendimiento del Ledger

A continuación se nos pedirá que indiquemos si nuestra red de bloques es una nueva o queremos que los recursos desplegados formen parte de una cadena de bloques ya existente. En el primer caso (cadena nueva) no tendremos que indicar más sobre este tema. Si seleccionamos la opción de formar parte de una cadena existente, se nos pedirá el endpoint RPC  de la cadena de bloques de la que se quiere formar parte.

A continuación se nos pedirá que indiquemos cuantos nodos de validación de transacciones queremos que tenga nuestro despliegue y también a qué familia de VMs queremos que pertenezcan. Recordemos que a mayor numero de transacciones a validar por nuestras dApps, mayores serán las necesidades de computación que deberán tener nuestros nodos. En cualquier caso, veremos posteriormente que dichas VMs estarán formando parte de un conjunto de escalado («Scale Set«) por lo que será muy fácil escalar horizontalmente en caso de que las necesidades de computación de los nodos no estén cubiertas perfectamente de manera inicial. Una vez seleccionados los valores de nuestros parámetros, pulsamos «Ok» y pasamos al siguientes paso.

Sexto Paso: Parámetros de Monitorización

ABW también tiene en cuenta las necesidades de monitorización de un sistema de negocio como el que se despliega, por ello en el siguiente blade  nos preguntará si queremos habilitar la monitorización del sistema y en caso afirmativo o bien lo conectamos con una instancia del servicio de «Log Analytics» ya existente, o bien creamos una instancia de dicho servicio específicamente para el despliegue de ABW.

Al pulsar el botón de «Ok» pasamos al siguiente blade de parametrización.

Séptimo Paso: Sumario

En el siguiente blade se muestra una recopilación de los diferentes parámetros que hemos ido introduciendo en los anteriores pasos a efectos de recapitulación y también como paso de confirmación de que todo está correcto. Como siempre, además del botón de «Ok» para proceder al despliegue, tenemos un enlace que nos permitirá descargar la plantilla de despliegue o plantilla ARM, que es el documento que nos permitirá disponer de una descripción exhaustiva de lo que será desplegado. Dicha plantilla nos permite tener como código nuestra infraestructura («Infrastructure As Code«) que es una buena práctica para poder tener descrita y versionada nuestra infraestructura, al tiempo que nos sirve como backup y como base para un pipeline de despliegue continuo.

Al pulsar el botón de «Ok» pasaremos a un blade final donde podremos leer información útil sobre qué se va a desplegar y su coste asociado. Esto es importante porque un despliegue de ABW puede llevarnos a incurrir en un consumo importante dentro de Azure. También tenemos información de términos de uso. Es importante hacer notar el aviso de que el despliegue está pensado para usuario avanzados de Azure.

Paso final: Realizando el despliegue

Como se ha comentado, ABW realiza un despliegue de un importante número de recursos. Por lo tanto, en el paso anterior el planificador de Azure empezará a invocar y crear los diferentes servicios involucrados. Esto hará que se necesiten varios minutos (en ocasiones entre 10 y 20 minutos) para finalizar el despliegue.

Ultimo Paso: Verificación

Como último paso, y para comprobar todo lo que un despliegue de ABW implica, se puede verificar el grupo de recursos que hemos creado donde estarán agrupados todos los recursos. Se puede ver que los componentes que van a soportar nuestras futuras dApps no son pocos ni sencillos, pero es un precio a pagar por disponer de una plataforma de características empresariales con lo que eso conlleva.

Si observamos con detalle el grupo de recursos, veremos que uno de los recursos es una WebApp. Si accedemos a su URL pública con un navegador. Se nos presentará (previo proceso de login de AAD) la pantalla principal de nuestro sistema de soporte a dApps.

Con esto, hemos visto cómo es el procedimiento para generar un Azure Blockchain Workbench de manera sencilla y rápida. En posteriores posts se mostrará cómo realizar el despliegue de una dApp así como qué implica el desarrollo de la misma en esta plataforma. Mientras tanto es interesante echar un vistazo a la documentación oficial y sobre todo entender cómo funciona Azure Active Directory pues es parte importante de la arquitectura de Azure Blockchain Workbench tal y como auzremuestra el siguiente esquema.