Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Quienes han leído mis anteriores artículos sobre el despliegue en Azure pensaran que uff, ya tenemos todo listo para buscarnos la vida hasta que Release Management de un soporte total a PaaS, pero la verdad es que la cosa tiende a evolucionar y hay que hacer pequeños ajustes de cara a los cambios que se anunciaron en el Build y que vienen con el Visual Studio 2015.

Esto a propósito de la posibilidad que nos ofrece Microsoft de desarrollar aplicaciones .Net que corran tanto en Mac como en Linux, una posibilidad totalmente disruptiva que es todo un ejemplo de los cambios que llegaron de la mano de Satya, pero claro, esto no implica que lo que hemos desarrollado hasta ahora en ASP.NET lo recompilamos y lo subimos a Linux y ya esta… no, claro que no, para lograr el objetivo Microsoft ha sacado una nueva edición del .NET Framework llamada Core, sobre la cual se ha desarrollado una nueva versión de ASP.NET (concretamente la 5) mas modular y ligera, sin las dependencias monolíticas usuales, aprovechando tendencias ya existentes en el mercado: Bower, Grunt, npm…

Genial, pero todo esto viene con un precio, el primero y para mi el mas doloroso es que esta nueva versión de ASPNET no incluye proyectos en WebForms (sniff :'( ), ha habido un reacomodo en algunas librerías (sobre todo de cara a lograr la integración entre MVC y WebAPI), desaparición de global.asax, en fin no doy mas detalle porque para eso mejor leer los artículos de José M. Aguilar que va cubriendo con detalle las cosas que van saliendo.

Pero dentro de todos los cambios habidos hay uno que nos afecta especialmente a quienes trabajamos en la gestión de entornos de trabajo y de despliegue, y es que por defecto al crear un proyecto nuevo ya no hay un archivo web.config, esto debido a que la gestión de configuración ya no esta centralizada en un archivo monolítico sino que puede estar dispersa a lo largo de un conjunto de archivos (de preferencia JSON) o de las variables de entorno del sistema, correspondiendonos a nosotros el elegir que archivos usaremos y en que orden de secuencia y prioridad se van sacando, y claro la forma de acceder a estas propiedades, que vimos anteriormente, han cambiado.

slots29

Si pues, ya no mas ConfigurationManager y similares…

Y por lado de la estructura de los archivos JSON seria de esta forma, mucho ojo a este config.json, lo usaremos mas abajo:

configjson

Ok, entonces ¿como hago para acceder a dichos valores desde mi código? Finish Reading: Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Desmitificando la Ingeniería de “Sistemas”

El pasado lunes tuve el honor de exponer en la Universidad de Ciencias y Humanidades una presentación titulada “Mercado laboral del Ingeniero de Sistemas a nivel internacional”, la idea que me propusieron mis anfitriones era contar a los alumnos mi “visión sobre la Ingeniería de Sistemas en la actualidad” y las diversas tendencias en las que puede ejercer un egresado, lo bueno de la conversación previa es que pude comentarles mi idea de contenidos lo cual derivo en esta presentación que invito a ver mas abajo.

Ahora bien, lo mejor no es la presentación en si misma, sino el proceso de reflexión que me llevo a estructurar su contenido, puesto que una de las cosas que tenía claro desde que fui invitado a la UCH era precisar que en Perú (como en Colombia) se tiene una idea totalmente errónea de lo que es la Ingeniería de Sistemas, que como indica el INCOSE(*)  es “An interdisciplinary approach and means to enable the realization of successful systems“, lo cual nos lleva a la palabra SISTEMAS (cuya definición me permitió dar el punto de partida a la charla) que como se indica en la presentación puede ser un sistema de transporte, hidráulico, hasta el sistema digestivo, en ese punto les comente a los asistentes algo que había escuchado esa mañana: los precios del gas en el Perú vienen dados por diversos factores: el que llegue el gas a Pisco, que a falta de un ducto entre Pisco y Lima el transporte del gas procesado hay que hacerlo en barco, lo cual genera una dependencia del oleaje, y por otra parte los precios internacionales del producto, etc…, así pues el modelado de un sistema que asegure un flujo eficiente y a buen precio del gas seria la labor que le correspondería a un verdadero Ingeniero de Sistemas con visión de los sistemas complejos, pero como era esperable y lo vi en las expresiones de mis asistentes no era eso para lo que habían sido preparados en sus años universitarios.

Durante el resto de la expresión explique como el error había persistido, de como el Dr. Maynard Kong impulso nuestra carrera de Ingeniería Informática en la PUCP, lo hizo con la visión de no persistir en la confusión y como en San Marcos por razones comerciales se había retirado la carrera de Computación para abrir una de… Ingeniería de Sistemas.

Con las bases aclaradas, y dejando indicado el hecho de que puede que en Europa o USA no entiendan la denominación de su profesión(**), ya pude introducirme en las diversas especialidades que la ACM esta reconociendo y promoviendo como vinculadas a la Computación o Informática, para luego explicarles mi perspectiva de los problemas actuales en el mercado laboral peruano y de como va a ir la tecnología para cuando estos jóvenes vayan a empezar su ejercicio profesional, pero…..

Lamentablemente el problema de la confusión semántica es muy grande (y como comente Colombia, al igual que Perú no esta ajeno a esto) tan así que en el Perú existe una Asociación Peruana de Ingeniería de Sistemas y Computación que no tiene ninguna mención respecto al desarrollo del enfoque sistémico, y si mucho de computación, siendo que este año en Arequipa se realizara el XXIII Congreso Nacional de Estudiantes de Ingeniería de Sistemas y Computación en cuya agenda se le ha procurado dar un enfoque basado en el enprendimiento tecnológico, pero ante las preguntas sobre si habría cobertura o no de temas orientados al enfoque sistémico bajo las definiciones de la INCOSE las respuestas fueron cortésmente evasivas:

DialogoIngSistemas

Personalmente creo que para evolucionar hay que tener en claro que cosa se es, que hay detrás del nombre y el contenido intelectual que se defiende con ello, si se va a abrazar la informática pues hacerlo con su nombre y las tendencias que se van estandarizando, pero que en el camino no se olviden que en el Perú si que hace falta la verdadera Ingeniería de Sistemas para ayudar a plantear las soluciones a los problemas grandes de nuestro país.

¿Cual seria el perfil de un Ing. Informático?

(*) Que si, que hay un organismo internacional a cargo de la Ingeniería de Sistemas  y que como pueden ver no tiene un enfoque especializado en computación.
(**) Felizmente en España nunca tuve problemas de identidad profesional, pero en Perú si que muchas veces han creído que yo era Ingeniero de Sistemas, lo cual siempre aclaro oportunamente.

Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Quienes han dedicado un rato a ver mi serie sobre automatización en el despliegue de aplicaciones con Azure habrán notado que había varios pasos manuales a la hora de preparar los entornos en los que íbamos a desarrollar y luego desplegar nuestras aplicaciones.

Pero, ¿nos hemos preguntado que pasa cuando hemos llegado a cierta madurez y nos encontramos con un escenario en que?: siempre creamos nuestros Websites en la misma zona geográfica de Azure, el mismo plan de precios, y… que la organización ya definió cuantos slots (ranuras) de despliegue son requeridos para el ciclo de desarrollo antes de que algo pase a producción.

En ese sentido Azure nos ofrece los Azure Resource Manager templates, que nos permiten definir y usar plantillas para automatizar la creación de recursos y entornos completos dentro de Azure, y ojo esto no esta limitado unicamente a Web Apps, sino también a entornos que involucren VM, Docker, Logic App, etc, en suma algo muy potente si queremos simplificar tareas repetitivas.

Este mecanismo llamo mi atención luego de que la genial GiS (a quien pude conocer de pasada en mi época en España) publicara este interesante articulo sobre como crear las citadas plantillas desde Visual Studio y es a ese articulo a donde deben remitirse para entender con detalle las partes de un proyecto de este tipo, luego de lo cual podemos regresar aquí.

¿Ok? En nuestro caso vamos a definir un proyecto de plantilla de tipo Web App (a diferencia de GiS que eligió la Blank Template para explicar con mas detalle la estructura base), así:

RM1En este caso notaremos que a diferencia del ejemplo genérico, lo que obtendremos serán archivos de nombre WebSite.json y WebSite.param.dev.json, los cuales se corresponden con los DeploymentTemplate.json y DeploymentTemplate.param.dev.json que con tanto detalle se describieron en el articulo de GiS.

RM2Ahora lo que haremos sera configurar los diversos archivos a fin de lograr una plantila que automáticamente nos permita:

  • Crear un Web App que incluya dos slots por defecto: “QA” y “Staging
  • Localizar esta Web App (y sus slots) en una zona geografica determinada, en mi caso: “East US
  • Usar siempre un mismo Grupo de Recursos (ya previamente creado en nuestro Portal de Azure, o creado la primera vez que invoquemos la plantilla), en mi caso: “Default-Web-EastUS

Finish Reading: Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue