Y ahora verificando la performance (I)

Varias cosas han pasado desde que empezamos a probar en nuevo modelo de Builds en VSTS, primero creamos una build sencilla que desplegaba a una Azure Web App, luego probamos como usar los Resource Groups para desplegar entornos, luego retiramos el paso de despliegue de la Build para trasladarlo a Release Management luego de su integración con VSTS, y hace poco agregamos Sonar como parte del proceso de análisis de nuestro código dentro de la compilación.

Y como el ciclo de evolución del proceso DevOps nunca para, en esta ocasión veremos como hacer algo a lo que le he tenido bastante respeto desde la época de las builds con el modelo XAML, en este caso la evaluación de la performance y estabilidad de nuestras aplicaciones web desplegadas.

En corto, la posibilidad de probar nuestras aplicaciones Web precede aun a .Net, recuerdo cuando probé Web Application Stress Tool (Homer) para hacer unas pruebas sencillas sobre ASP Clásico, de ahí le perdí el rastro pero la cosa se puso interesante desde Visual Studio 2013 se permite que los tests de carga se basen en las capacidades de la nube, lo cual significa que durante nuestras pruebas se provisionaran las maquinas virtuales que hagan falta para cubrir la cantidad usuarios y peticiones deseadas, esto ya lo había probado desde Visual Studio (revisar aquí y aquí), con buen resultado, pero… ¿como hacer que estas pruebas se ejecuten cuando se produzca cierto tipo de despliegue?

Antes de proseguir hay algunas consideraciones a tener en cuenta:

Los recursos que Azure provisiona para efectuar estas pruebas tienen un costo (si se va por encima de los minutos de carga incluidos con nuestra suscripción de VSTS) por lo que hay que tener cuidado de no lanzar estas pruebas por cada commit que los desarrolladores efectúen, así que la sugerencia general seria tener un sitio de DEV donde se despliegue continuamente pero sin efectuar las pruebas de cargar, luego definiríamos un sitio QA (por ejemplo) al cual se desplegara ya sea de manera manual o de manera programada el contenido existente en DEV (con Release Management lo que se despliega son paquetes que no necesariamente son recién compilados) y al efectuar ese despliegue se lanzaran las pruebas de carga, las cuales si son exitosas indicar que en el proceso de despliegue esta listo para ser sometido a aprobación (si lo hemos definido así) para decidir su pase a otro entorno.

Con estas consideraciones en mente procederemos con nuestra primera prueba para lo cual no sera necesario usar Visual Studio simplemente agregar un paso adicional a nuestro proceso de despliegue, esto es porque a veces lo que nos interesa es simplemente ver que tan bien resiste una URL en concreto a cierta petición.

Para esto vamos a la pestaña de Release de nuestra instalación de VSTS, elegimos nuestro plan actual, seleccionamos el “entorno lógico” sobre el cual agregaremos nuestra prueba de carga y agregamos el Step de Cloud-based Web Performance Test, así:

Clipboard01

Clipboard02

Ok, ahora toca parametrizar el paso para lo cual dejaremos los parámetros mas o menos así, en breve explicare el significado de cada parámetro:

Clipboard06

Antes de proseguir prestemos atención al parámetro Registered connection, lo que ocurre es que cada prueba de carga se hace con cargo a los recursos y facturación de una cuenta de VSTS y podría darse el caso de que la organización tenga mas de una instancia de VSTS, así que corresponde indicar explícitamente dicha cuenta, así que hagamos clic sobre el enlace que dice Manage, que nos abrirá una nueva pestaña en el navegador para agregar un Endpoint (como ya hicimos anteriormente para enlazar Sonar y la cuenta de Azure), y en este caso elegiremos Generic, así:

Clipboard04Y llenamos los parametros de configuración de nuestra instancia de VSTS, pero ojo, al hacerlo deberemos utilizar los datos de nuestra conexión alterna a VSTS, algo de lo que hablamos hace tiempo cuando empezamos a trastear con Git.

Clipboard05

Listo, ya hemos enlazado nuestra prueba de carga a nuestra cuenta de VSTS,  personalmente yo agregaria un checkbox que permita usar la instancia actual y no hacer nada mas, pero siempre es bueno tener una conexión alterna a VSTS especialmente de cara a la integración con herramientas de terceros en Git.

Ok, antes de grabar repasemos los parámetros que estamos configurando:

  • Registered connection: como lo vimos, la instancia de VSTS sobre la cual se hara la facturación de esta prueba de carga.
  • Website Url: La dirección que vamos a probar, en este caso estoy probando la raiz del site (o mejor dicho del slot) en que acabo de hacer el despliegue, cabe indicar que tranquilamente podria haber colocado cualquier URL interna de nuestro site, o peor aun, una URL totalmente externa no manejada por nosotros, pero eso no queremos ¿verdad?
  • Test Name: El nombre con el que identificaremos a esta prueba.
  • User Load: La cantidad de usuarios supuestos que se estarán conectando a nuestra URL.
  • Run Duration (sec): El tiempo de duración de la prueba.
  • Load Location: La zona geográfica de Azure desde donde se hará la prueba, es muy interesante y conveniente hacer la prueba desde una zona que no sea la que aloja a nuestro site, en mi caso la URL esta alojada en East-2, así que la prueba la estoy lanzando desde West.

Marcamos Enabled y grabamos, ya estamos listos para empezar, asi que lo mas sencillo sera hacer un cambio en nuestro codigo fuente, lanzar una nueva Build manualmente, o si queremos divertirnos relanzar un paquete antiguo al ciclo de Release, en todo caso esperamos un poco y veamos cuando nuestra Release se empieza a ejecutar y llega al paso que hemos agregado:

Clipboard08

Para después terminar:

Clipboard09Normalmente pasaríamos a aprobar o rechazar esta Release, pero ahora me interesa conocer los resultados de nuestra prueba, así que vamos a la pestaña Tests, y elegimos la opción LoadTest, para luego seleccionar la prueba mas reciente (en mi caso tengo algunas pruebas anteriores, pero si es la primera vez deberías tener una sola prueba en tu lista).

Clipboard10

Y así entramos a un detalle de los resultados de la prueba:

Clipboard11

Notemos algo interesante, aparentemente nuestra prueba salio ok (o sea, no hubo errores 500 o timeouts) pero el panel nos indica 2 errores, así que veamos el detalle:

Clipboard12

En mi caso el mensaje de error dice “The value 85.10138 exceeds the warning threshold value of 75“, lo cual nos viene a indicar no un error en el sitio que estamos probando sino un exceso en la capacidad de la instancia provisionada para hacer la prueba, esto apunta a que forzamos la maquina dandole 250 usuarios concurrentes, lo cual se relaciona a las pocas opciones de configuración que ofrece este tipo de prueba.

Listo, sencillo y ya podemos empezar a sacar conclusiones, pero como verán esta prueba es muy sencilla y en adición al ya mencionado problema del threshold no permite saber si por ejemplo el comportamiento es diferente desde un browser u otro, desde un tipo de red, etc, para lograr este tipo de análisis lo que se nos ofrece es la posibilidad de crear un test muy detallado desde dentro de Visual Studio y que cuando se efectúe el despliegue Visual Studio Team Services pueda “leer” todos estos parámetros archivados y ejecutar tras bastidores las pruebas programadas, esto sera tema de nuestro próximo post, de momento sugiero familiarizarse con este tipo de prueba, pues los conceptos siguen siendo validos cuando los escalemos, aparte de que estas pruebas tienen su lugar si  hacemos peticiones Get que luego repercuten a nuestra BD, o queremos probar la mejora si usamos un servicio de cache, etc.

Espero sus comentarios 😉

Actualizando la Gestión de la Configuración de ASPNET CORE con Azure

Hace medio año conversábamos acerca de la potencialidad que Microsoft nos empezaba a ofrecer para desarrollar aplicaciones para plataformas Linux y Mac, en el caso Web la iniciativa se llamo ASP NET 5, y en ese sentido se presento una manera para acceder de manera transparente a los valores de configuración (antiguamente manejados por los Web.config) para no tener que preocuparnos si se guardaban dichos valores en un archivo JSON o si por el contrario estábamos guardando dichos valores mediante la consola que Azure nos da para gestionar las Web Apps.

Pues bien, en este lapso varias cosas han transcurrido, y una de ellas es que ASP.NET 5 ahora se llama ASP.NET Core, decisión de Microsoft que ayuda a tener claridad para entender que “este” .Net que corre de manera multiplataforma no es la “siguiente versión” luego de .NET 4.X, así que correspondía regresar al desarrollo puro y duro para verificar si nuestra clase Helper seguía funcionando,  como es lógico habiendo pasado de una versión beta a una release candidate, las API se han actualizado por lo cual algunos de los metodos que se utilizaban ya no funcionan o funcionan de manera diferente, asi que correspondió hacer el ejercicio de revisar el código y dejarlo operativo.

De igual manera aproveche la ocasión para incorporar algo que se me quedo pendiente: soporte para cadenas de conexión, de esta manera seguiremos teniendo (como en ASP.NET 4x) la opción de trabajar en desarrollo con una BD local, y en entornos de despliegue (QA, PROD, etc) con una conexión gestionada por el entorno de Azure, evitando de esta manera trabajar con las ya conocidas Transformaciones, de esta manera si antes teníamos un fragmento de codigo asi:

 services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]));

Con el uso de nuestro HelperConfig quedaria asi:

            services.AddEntityFramework()
                .AddSqlServer()
                .AddDbContext<ApplicationDbContext>(options =>
                    options.UseSqlServer(HelperConfig.GetConnectionString(Configuration, "DefaultConnection")));

Y de esta manera seria posible acceder de manera transparente al valor de la cadena de conexión que podria estar en nuestro JSON, asi:

  "Data": {
    "DefaultConnection": {
      "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=aspnet5-WebTestConfig2-b1ec5227-eb73-448b-86ee-63e3746185e7;Trusted_Connection=True;MultipleActiveResultSets=true"
    }
  },

O, como mencionamos antes, en la consola de Azure:

ConnectionsStrings

Todo esto lo he subido a GitHub junto a un proyecto Web sencillo (vamos, la aplicación por defecto de Visual Studio 2015) para que uds lo descarguen y revisen su funcionamiento, particular atención merecen los siguientes archivos:

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Helper.cs (la clase HelperConfig en si y todo lo necesario para que funcione)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/appsettings.json (Los AppSettings y Connection Strings involucrados)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Startup.cs (Clase de arranque que prepara la Inyección de Dependencias e invoca a HelperConfig.GetConnectionString)

https://github.com/fisica3/HelperConfig/blob/master/src/WebTestConfig2/Controllers/HomeController.cs (Controlador que hace uso de HelperConfig.GetAppSettings)

En los próximos días explicare un poco mas de este pequeño proyecto, espero que les sea de utilidad y no se olviden de enviarme sus comentarios.

 

Monitoreando la calidad del código en nuestros procesos de desarrollo: Sonarqube

Bueno, en nuestras ultimas series de artículos prácticamente hemos completado el ciclo de despliegue de una aplicación desde el cambio de código hasta su publicación en los entornos, pero como es lógico esto no se acaba ahí, nuestro objetivo debe ser siempre la búsqueda de calidad en lo que estamos desarrollando, y esto necesariamente involucra al código: legibilidad, mantenibilidad, seguridad, buenas practicas según lenguaje, etc.

En ese sentido la idea seria mantener unos niveles de calidad y “parar la Build” en caso que la calidad del código no cumpla unos mínimos, tradicionalmente en .Net hemos contado con la opción de definir unas reglas mediante Code Analysis, permitiendo que no se haga checkin de código si no se cumplen las reglas (si usamos TFVC) o que ciertas reglas se cataloguen como error (forzando a corregirlas si o si), alternativa muy interesante sobre la que tratare de regresar en un post futuro.

En todo caso, en paralelo a lo que veíamos en el mundo .Net iba evolucionando una herramienta muy potente que permitía explotar el análisis de código estático al máximo: Sonarqube, herramienta a la que pude conocer cuando me correspondió configurar un proyecto de Integración Continua donde me gustaron mucho sus dashboard que permitía ir analizando con detalle los diversos tipos de deuda técnica existente en nuestras aplicaciones (para verlo en acción revisa aquí) y como esta ha ido evolucionando históricamente; en ese momento si querías integrarlo en .Net tenias dos opciones: invocar manualmente el análisis, o enlazarlo a un ciclo de Integración Continua usando Jenkins, pero ahora Microsoft ha colaborado para que sea posible integrarlo con TFS y VSTS y de esto se trata este post.

Para mas razones por las cuales usar Sonarqube en nuestros desarrollos, revisar este post de Adrian.

Finish Reading: Monitoreando la calidad del código en nuestros procesos de desarrollo: Sonarqube

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Pues si, como fue prometido, ya va tocando meternos con el modelo de Builds, pero antes de proseguir respondamos la pregunta que deje en el post anterior, ¿en que parte de la solución estoy grabando los parámetros de conexión a la BD? pues en el archivo PartsUnlimitedWebsite.pubxml ya que es ahí donde el wizard de deploy guardo los datos de la cadena de conexión a pesar de que al final no sobrescribió los valores del web.config, nos corresponde editar las secciones de dicho archivo a fin de que no persistan los valores dentro de nuestra solución.

Curiosamente, debemos agregar este archivo a nuestra solución, para lo cual hacemos clic derecho y ya formara parte de lo gestionado por VSO, ojo esto solo funciona si hemos editado adecuadamente nuestro archivo .gitignore como ya hemos explicado en el segundo post de esta serie.

Clipboard27
Bueno, ahora si, subamos el cambio y volvamos a nuestro Team Project en Visual Studio Online, dirigiéndonos a la zona de BUILD, de momento estará vacía.Clipboard28
Posicionados sobre la zona que dice “Build definitions” (nótese que aparte tenemos una zona correspondiente a las XAML definitions) y presionamos el “+”, nos saldrá la siguiente pantalla:Clipboard29
Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Bueno, luego de una pausa, proseguimos con esta serie de artículos para establecer un escenario completo de despliegue usando el nuevo modelo de Builds que traen tanto Visual Studio Online como Team Foundation Server 2015, ¡así que manos a la obra!

Para proseguir con el demo de Parts Unlimited, debemos mencionar que en este ejemplo se hace uso intensivo de los Resource Groups que ya conversamos anteriormente, esto permite automatizar la creación del entorno donde se desplegara nuestra aplicación, vale decir que reduciremos nuestras visitas al Portal de Azure para la creación de nuestros recursos.

Para facilitar esto debemos preparar a nuestra maquina para que sea capaz de provisionar directamente en Azure, para lo cual abrimos una ventana de PowerShell (con permisos de Administrador, claro esta) y escribimos Set-ExecutionPolicy RemoteSigned.

5554.image_thumb_6CC60E94

Bien, terminaron los preparativos así que ya con la aplicación cargada en Visual Studio (y bien conectada a VSO) vamos al proyecto PartsUnlimitedEnv, hacemos clic derecho y elegimos New Deployment… Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

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

Los retos para hacer cloud en el Perú

Cloud es una interesante y validad promesa para las empresas peruanas, la promesa de reducir sus costos fijos, haciendo que buena parte de la infraestructura pase a ser costo variable pagando solo lo que se consume, es algo muy atractivo, y mas cuando un caso de éxito como el de Cineplanet llama la atención por la escalabilidad que esta logrando.

Para lograr esto hay que mirar con otros ojos a nuestras conexiones de internet, si antes se orientaba a facilitar acceso a la web y al correo, ahora… las cosas cambian, si antes el servidor de correo estaba en la red local ahora lo esta fuera, así que cada request sale fuera de la red de la organización por mencionar el detalle que podría ser mas común.

Otro escenario en que nuestra velocidad de conexión puede asomar un lado poco amable es el de la carga de datos desde nuestra organización hacia la nube, y claro como usualmente la infraestructura de la nube esta fuera de nuestro país la latencia si que es un factor a considerar, para lo cual habrá que recurrir a herramientas como Azure Speed y así determinar en que zona geográfica nos conviene mas provisionar nuestros servicios en la nube; pues como vengo insistiendo, el hecho de que haya datacenters cloud en Brasil no implica que vayamos a conseguir mejores velocidades de conexión que las que tenemos con USA.

Pero por mas de que elijamos bien la zona geográfica y aumentemos razonablemente el ancho de banda, hay otro factor que toca considerar y es que la mayoría de conexiones a Internet que se contratan son de tipo ADSL (Asymmetric Digital Subscriber Line) siendo que la A, que antes usualmente no nos importaba pues solo consumíamos contenido, nos puede jugar una mala pasada pues la Asimetría nos recuerda que la velocidad con la que nos podemos bajar contenido siempre sera mucho mayor que la velocidad de subida… upss y eso se refleja en los problemas mencionados anteriormente, de ahí que dentro del planeamiento de uso de soluciones cloud debe hacerse la evaluación de pasar de conexiones ADSL a conexiones DSL que no restrinjan la capacidad de subir contenido.

Ya en el lado que no esta mucho en nuestras manos esta el reclamar por los precios y las velocidades que se ofertan en el Perú (penosas realmente) y esperar que a se haga una NAP a nivel de la Comunidad Andina, lo cual justificaria a los proveedores de cloud el montar un datacenter en la región, o que se mejore la conexión vía fibra óptica con Brasil y así reducir la latencia con los datacenter de dicho país.

Por otro lado, corresponde hacer una mayor difusión respecto a lo que implica cloud en cuanto a generar nuevas aplicaciones (PaaS) o gestión de Infraestructura (IaaS), pues percibo que aun en los departamentos de IT se habla de cloud solo en términos de compartir información en repositorios de facil acceso o usar herramientas de ofimática basadas en Web, y como bien sabemos es mucho mas que eso, todo un reto para los informáticos en estos tiempos ¿no?

 

 

Cloud, de manera sencilla

A veces tiendo a emocionarme con la tecnología, y hablar “en binario”, pero el hecho es que es necesario tener conceptos claros, e ideas fuerza para poder hacer aterrizar una idea en publico no tecnológico, y en el caso de cloud, mas aun.

En este caso, la razón por la cual uno debería estar interesado en cloud desde el punto de vista de negocios es simple: tradicionalmente las empresas han tenido la necesidad de hacer inversiones de infraestructura en previsión de “lo que pueda pasar”, con cloud el esquema cambia, la provisión se hace conforme vayan creciendo tus requerimientos, pagando solo por lo que de veras se necesita.

Consideraciones adicionales vienen después, pero la idea fuerza es esa, atacando por la cuenta de resultados, que al final es lo que define la decisión.

¡Mudanza!

Si has sido un visitante que ha pasado por aquí en semanas anteriores te habrás dado cuenta del cambio de estilo en el blog, lo cual ya es mas obvio, pero lo que no lo es tanto es que desde hace una semana este blog ha dejado de estar alojado en Blogger para estar alojado en Azure usando WordPress.

Las razones para ello son varias, con WordPress hay una mayor escena de temas y plugins para usar, en ese sentido Blogger se había quedado muy atrás, pero una razón muy importante es que siendo que ahora me he enfocado en Cloud Computing en general y en Azure en particular, decidí que una buena opción seria hacer uso de esas opciones y así profundizar en el uso continuo de un recurso en Azure.

La primera decisión que tome fue el tipo de servicio de Azure a usar, descartadas las maquinas virtuales (el uso continuo de procesador garantiza una factura alta) la opción obvia era elegir un Azure WebSite, y dentro de esta opción opte por un servicio de hospedaje “Compartido” (Shared).

wordpress03

La razón por la que elegí este nivel fue porque es el mas “barato” que permite asignar un dominio personalizado (en este caso consultorinternet.com) y no quedarse con el modelo sitio.azurewebsites.net que viene por defecto. Y si por alguna razón este site crece en trafico siempre podre crecer a alguno de los modelos como “Basic” o “Estandar”.

Implementar WordPress fue muy sencillo, solo tuve que elegir de la galeria que te ofrece Azure a WordPress y listo.

wordpress04

Ahora bien, en la siguiente pagina si que hay que tener cuidado en agregar todos los parámetros (son varios) que se piden, y anotar sus valores en lugar seguro.

wordpress05

Nótese que en WebScaleGroup estoy usando un plan de hosting que ya tenia previamente,  y que ya había migrado del modelo “Gratis” al “Compartido” para de esta manera poder hacer uso del tema de los dominios personalizados que ya mencione mas arriba. Con respecto a la BD si es tu primer site en WordPress tienes que crear una BD nueva, si ya tienes otro site deberás usar una BD ya existente a menos que por tu volumen requieras contratar BD extra en ClearDB.

Ya con el WordPress corriendo seguí las indicaciones de este enlace para efectuar la migración de Blogger a WordPress, todo bien pero creo que no es necesario efectuar los pasos recomendados en la sección “Redireccionar los enlaces de blogger a wordpress” (que incluye el uso de un plugin) siendo que mas practico es configurar el formato de los enlaces permanentes de esta manera:
wordpress02
Esta configuración (ojo a la palabra html que hay que agregar manualmente) es la que ya tenia en Blogger, por lo que si los buscadores tenían referenciado un enlace “antiguo” esta referencia no se perderá, lo que si se ha perdido son los enlaces que hacen referencias a entradas agrupadas por mes, bueno… no se puede tener todo.

Con todo esto listo, toca configurar los parámetros en el proveedor de dominios (en mi caso Network Solutions) de acuerdo a lo indicado en esta documentación, nótese que el tiempo en que se propagan los cambios en los valores puede variar, en unos casos en 5 minutos ya Azure “sabia” de los cambios, en otros se tardo como media hora, pero nunca ha tardado las horas que se supone que tienen de colchón para propagar los cambios.

Ya configurado el site, me percate que si bien al entrar a www.consultorinternet.com accedía al nuevo site en WordPress y ya no al de Blogger, cuando administraba el site o iba a los enlaces veía el dominio en azurewebsites.net que no era lo que esperaba, luego de revisar tanto en la consola de Azure como en Network Solutions por si había algún error, revise la administración en WordPress percatándome que tenia que editar algo tan simple como lo que se ve en el siguiente gráfico, upsss.

wordpress06

Bueno, ya esta listo, espero sus visitas y comentarios en esta nueva etapa. Lo mas probable es que en breve migre Fisica 3, el site hermano.

Reflexionando sobre DevOps y Cloud computing

Como indique en el post anterior, mi sesión “El reto del DevOps ágil” trajo buen debate e inquietudes, por lo que en el Open Space del #Agiles2014 propuse una sesión dedicada al tema de Cloud Computing, a la vez Adrian Moya propuso otra para profundizar el tema de DevOps, luego de una breve coordinación fusionamos las sesiones, así que luego del almuerzo nos reunimos en una de las salas y empezó la conversación cuyas ideas fuerzas trate de reflejar aquí:

_DSC0059

Mas que un tema técnico, la reunión se enfoco desde el punto de vista organizacional, ver el porque las organizaciones están adoptando cloud, como lo están haciendo y también porque no lo hacen.

_DSC0058

Dentro de las experiencias se evidencio que el cloud permite empoderar a las unidades de negocio (que usualmente tenían que esperar mucho para la asignación de un recurso *), lo cual puede lograrse mediante nube publica o mediante nube privada si es que hubiera restricciones de seguridad (generalmente por temas legales).

Algo que me llamo la atención fue que si bien un escenario PaaS (Plataform as a Service) esta mas orientado para implementar aplicaciones escalables desde el inicio, las empresas han empezado usando IaaS (Infraestructure as a Service) debido a que ya hay mas madurez en herramientas de automatización, como Puppet y Cheff, y porque este modelo no se queda tan corto como Paas aparte de que nos permite desplegar las aplicaciones ya existentes, a tenerlo en cuenta para entender las necesidades de una organización que quiera dar el salto a la nube.

Un punto clave que salto en el dialogo es que para una implementación adecuada de cloud es imprescindible medir las fortalezas de la organización, así como entender cuales son los blockers que afectarían a la organización en este proceso, en adición a los ya mencionados de seguridad y leyes hay que tener en cuenta el si la organización ya ha hecho una fuerte inversión en hardware, eso me hizo acordar lo que comento Alex Le Bienvenu de Microsoft en su momento, que ese es un escenario muy difícil de adopción y que se podría intentar entrar ofreciendo cloud como mecanismo de contingencia.

Ya metidos en el tema de los blockers afloro el tema del sector bancario, sector que (aparte del tema legal y seguridad) por su dependencia a tecnologías legacy como AS/400 y RPG se encuentran en escenarios mas complicados para poder implementar cloud, pero se menciono que algunos bancos están utilizando cloud para proyectos No Core, y que han empezado a surgir plataformas cloud especialmente orientadas a sus necesidades como FinQloud, habrá que hacer seguimiento a estas opciones.

Llegados al tema de precio, quedo claro entre los asistentes que debemos entender que el uso de cloud no necesariamente es mas barato que tener una infraestructura on premise, siendo que los ahorros van por otro lado debido a que se pueden provisionar los recursos teniendo en cuenta los picos y caída de demanda, en ese sentido es necesario validar los costes desde el principio, hacer seguimiento del consumo (un compañero comento como se les disparo la facturación mensual por una transferencia de datos) y tomar en cuenta la letra pequeña de los contratos.

El tema de desarrollo no podía ser dejado de lado y se recordo que los desarrolladores deben ser conscientes del entorno en que se va a correr la aplicación, pues de lo contrario no se podrá aprovechar las características de escalabilidad de la nube, o tener problemas al toparse con algo usualmente trivial como los FileSystem.

El tiempo paso rápido y fue un gran momento de aprendizaje mutuo para todos los asistentes, espero poder repetir esta clase de diálogos mas adelante en Perú o en próximos Ágiles.

Luego los amigos de Tech & Solve tuvieron otra charla donde comentaron su experiencia y problemas en la evolución del modelo DevOps, donde de paso nos explicaron sobre un producto muy interesante: Docker que están utilizando como una manera ágil para poder provisionar infraestructura (de momento Linux) vía código de manera sencilla, como feedback ante sus problemas debemos recordar que la tendencia DevOps se trata de colaboración entre áreas para llegar a soluciones y no centrarse unicamente en lo técnico, esto viene después.

_DSC0067

Ademas de Adrian, un gran agradecimiento a Diego Garber (extremo derecho en la foto **) que estuvo presente en todas estas sesiones compartiendo su experiencia y punto de vista.

_DSC0068

* Como dije en otro post, en este blog no usamos la palabra “recursos” para referirnos a las personas, siendo que en este caso usamos la palabra para referirnos a maquinas físicas, maquinas virtuales, espacio en disco, websites…

** El asistente del medio también estuvo muy presente y activo en estas sesiones DevOps, pero se me paso apuntar su nombre, así que si alguno de los asistentes al Ágiles lo puede identificar se agradecerá.