Categoría: Otras del Blog

De .Net Core, Webjobs y despliegue automático

En otras ocasiones hemos hablado de .Net Core, de los webjobs y aunque nunca he escrito mucho sobre ello tengo interés por automatizarlo todo lo más posible. Para esto último, intentando no sobretrabajar he usado siempre las funcionalidades de Visual Studio Team Services.

El problema que voy a describir, es un problema con una solución tremendamente sencilla una vez que das con ella, pero que al no haber ningún tipo de documentación y no haber nadie por el mundo que haya hecho exactamente eso y lo haya contado, acabas teniendo que ir deduciendo cosas, poniendo parches y testeando multiples variantes hasta que das con el conjunto de pasos buenos que te salvan la vida.

Como sabéis .Net Core ha roto el cascarón de su primera versión hace muy poquito, y aunque mola mucho porque es muy ligero, es multiplataforma, te facilita (o fuerza) a usar ciertos patrones que merecen la pena… A pesar de todas esas cosas también tiene sus pegas, y las principales creo que son sin ninguna duda el tooling y las librerías que permiten la integración con otras partes del entramado Microsoft.

Del mismo modo, el SDK de los webjobs también es relativamente nuevo, y tiene muy pocas funciones y sólo vale para el Framework de .Net (el de toda la vida).

El tercer componente de nuestra ecuación es el más maduro, ya que Visual Studio Team Services viene de TFS que lleva ya dando vueltas mucho tiempo y tiene multiples opciones con las que solventar las cosas cuando no hay un componente específico (a las malas siempre puedes subir tu propio script de PowerShell por ejemplo).

El problema de juntar estos tres elementos es que no hay SDK de webjobs para .Net Core, y que las herramientas de core no permiten añadir un webjob a tu proyecto.

Las estrategias posibles para afrontar este problema son múltiples:

  • Despliegues independientes. Siempre puedes montar despliegues independientes, pero tendrás que gestionar todo por separado y no en todos casos va a ser lo ideal. No tiene porque suponer un incremento en costes porque lo puedes tener rulando todo en el mismo Service Plan para que compartan recursos y esperar a que todo crezca mucho para separa cada cosa por su lado en ejecución. Sin embargo, a mi personalmente, me deja mal sabor de boca el hacer algo forzado porque no sé, cuando en el caso que teníamos entre manos el ideal era llevarlo junto ya que hay cierta dependencia entre proyectos.
  • Montar el webjob con .Net Core sin el SDK. Al final un webjob no deja de ser un programa o script que ejecutas. Puedes montar un ejecutable independiente o una dll que invocarás con el comando dotnet y las librerías de .Net Core para acceder al storage de Azure y hacerte tu propio acceso a datos y tus disparadores y esas cosas. Esto… es una opción pero multiplica el tiempo de desarrollo de cada webjob al menos por tres, te hace picar mucho más código y asumir más responsabilidades de las que deberías. Sí que es cierto que el rendimiento mejoraría, así que puede ser la opción buena en función de lo intensivo que vaya a ser el webjob. En nuestro caso el webjob necesitaba usar unas librerías que sólo existen en .Net Framework y por tanto no era una opción que pudiésemos tomar sin desarrollar un montón de componentes para .Net Core.
  • Hacer tu webapp con .Net Framework. Siempre es una opción, pero la diferencia de rendimiento creo que justifica suficientemente el no tomar esta opción por defecto nunca.
  • Hacer que las dos tecnologías se entiendan y todos los despliegues funcionen bien. Generalmente todo es posible, y aunque no hubiese documentación al respecto, siempre podríamos haber hecho scripts propios e intentar que se lanzasen cuando tocase (que en una pequeña parte es lo que hemos hecho). Aunque llegar al conjunto de pasos más simple posible para no condenar a tu yo del futuro puede llegar a ser complicado. Esta ha sido la opción que tomé para ponerlo todo a andar.

Lo primero de todo es hacer que cuando publicas desde tu Visual Studio a maneja a Azure para hacer alguna prueba puntual montando una nueva webapp se despliegue con ella el webjob para que no haya problemas y todo funcione correctamente.

Para hacer esto solo hay que seguir unos muy muy simples pasos, y aunque todos tienen su lógica y explicación, voy a pasar muy rápido por ellos para no enrollarme:

  1. Lo primero es crearte en tu proyecto de aplicación web una carpeta app_data si no la tienes ya. En ella tendrás que crear otra que se llame jobs y dentro de esta tienes que actuar en función del tipo de webjob que tengas:
    1. Si es un webjob que se ejecuta continuamente esperando a que salte algún trigger desde el storage, tendrás que crear una carpeta que se llame Continuous.
    2. Si el webjob es de ejecución manual y lo vas a lanzar tú cuando te convenga (¿por qué nadie querría hacer esto?), tendrás que crear una carpeta que se llame Triggered.
    3. Si el webjob es de ejecución programada o agendada (scheduled, vamos), tendrás que crear también una carpeta que se llame Triggered, pero posteriormente deberás dar un paso adicional.
  2. En esa carpeta (o carpetas si tienes distintos tipos de webjobs), deberás crear una carpeta por cada webjob con el nombre que quieras ver en Kudu.
  3. En esa carpeta tienes que meter un script que se llame run.cmd (hay otras opciones, pero no nos compliquemos) invocando al ejecutable del webjob como si estuviese en la carpeta aunque no haya nada en ella. Vamos, que hay que poner el nombre del ejecutable en el archivo y si quieres primero una línea con un «@echo off«, y listo
  4. Si el webjob es de ejecución programada (o si queremos usar otras features como hacer un webjob singleton por ejemplo), meteremos en esa carpeta el archivo settings.job correspondiente.
  5. A continuación hay que decirle a quien corresponda que cuando publique ese proyecto incluya esa carpeta. En el archivo project.json tendremos la propiedad de primer nivel (y si no la creamos) «publishOptions«, y en su interior deberíamos tener (y si no lo creamos) una propiedad de tipo array llamada «include«. Ahí deberemos añadir la ruta de lo creado, por ejemplo «app_data/jobs/**/*.*«. De este modo conseguiremos que cuando se publique se copien esas carpetas con el archivo o los dos archivos que hemos creado.
  6. Por último deberemos decirle que hay que compilar el proyecto del webjob y copiar los archivos a la carpeta de publicación en la ruta adecuada «app_data/jobs/…«. Para esto, en el mismo archivo project.json tienes una propiedad de primer nivel llamada «scripts» y en su interior otra de tipo array que se llama «postpublish» (si no existe alguna, sólo tenéis que escribir). Como el proyecto es de .Net Framework, tendremos que invocar al comando msbuild que nos toque en función del tipo de nuestro proyecto (que espero que sea 2015, no me fastidiéis) la ruta del proyecto y la del destino. En mi caso: «\»%ProgramFiles(x86)%\\MSBuild\\14.0\\Bin\\msbuild.exe\» ..\\ProjectFolder\\ProjectName.csproj /property:OutDir=%publish:OutputPath%\\app_data\\jobs\\Continuous\\WebjobName\\«

Con esto, ya podremos usar la opción de publicar del Visual Studio y que todo funcione. Cuando se publique el proyecto compilará guardando el resultado en la carpeta del webjob en el destino de la publicación.

Como os decía es una chorrada una vez que das con los pasos adecuados.

Lo siguiente es meterlo en el VSTS, y aunque sé que está en preview os recomiendo usar la plantilla de deploy de .Net Core añadiendo los pasos que necesitéis para desplegar en vuestro servidor (por ejemplo un «Azure App Service Deploy» que coja el paquete del destino de la compilación «$(build.artifactstagingdirectory)\**\*.zip«), o si tenéis montado un sistema de release y validaciones que pase por distintos entornos, simplemente la plantilla en cuestión.

Veréis que os pasa en verde, pero que ni webjob ni nada, y si atendéis a los logs de vuestro build, en concreto al del step Publish, veréis que algo no ha ido del todo bien al ejecutar el script de postpublish que introdujimos, y parece que no encuentra muchos archivos. El problema es que en vuestro sistema están todas las librerías necesarias dónde toca porque el plugin de NuGet que tenéis en Visual Studio lo ha hecho sin molestaros.

La solución es tan sencilla como antes de ese paso meter un componente de NuGet install con la opción de restore seleccionada, para que restaure todas las dependencias que tengan los proyectos de .Net Framework de la solución, así como tenéis el Restore de .Net Core.

Con esto ya tendréis todo funcionando, dos tecnologías distintas conviviendo juntas en amor y compañía 😀

Tened en cuenta que en un tiempo indeterminado llamemosle X la información de este post estará obsoleta. En diciembre de 2016 la comunidad abrió un ticket en uno de los githubs de estos proyectos, y unos se lo han pasado a otros cerrando sus tickets, hasta que alguien ha decidido que lo que había que hacer era primero abrir un ticket para pensar lo que hay que hacer… Parece uno de esas chistosas historias paralelas que contaría la voz en off de «La guía del autoestopista galáctico», pero es real, podéis buscarlo vosotros mismos xD. Esperemos que ese X no sea demasiado largo, crucemos los dedos en forma de X.

Cualquier duda o pregunta, o si no se entiende algo, o si algo está mal… escribid un comentario o me contactáis por dónde sea. ¡A cuidarse!

3+1 problemas típicos para que las empresas se vuelvan ágiles

En mi paso por las distintas empresas en las que he tenido el placer de trabajar y aprender, y en mi contacto con muchas otras empresas que me ha permitido ver como trabajan, he observado que se repiten ciertos puntos clave respecto al agilismo.

El primero sin duda, no es un problema per se, pero sus bases sí lo son.

En todas las empresas quieren ser ágiles, todas quieren aplicar Scrum, Lean, Kanban, o cualquier otra cosa que suene a agilidad. Todas siempre están empezando, pero ninguna lo está haciendo del todo, ninguna de verdad.

Esto no es un problema en si mismo, pero sí los cimientos en los que se basa. En ninguna de las empresas que he conocido querían ser ágiles para asegurar su supervivencia en un mundo cambiante, ni para ser más eficientes, ni siquiera para ganar más dinero.

En todas esas empresas, lo que he observado es que, se quiere ser ágil simplemente por moda, porque es de lo que habla todo el mundo, porque hoy en día si no eres ágil es porque estás haciendo una mala gestión.

Esto es un problema obviamente. Es importante que los procesos de cambio se asienten en unas buenas bases, pero al menos es un problema que te lleva por el buen camino. Es el menos malo de los problemas.

El resto sí que son grandes problemas que afectan de manera directa al proceso de cambio que requiere pasar de la gestión que se tenga a una gestión ágil:

Burocracia
La burocracia, esa traicionera que nadie reconoce, pero que efectivamente está en muchas muchas empresas.La burocracia mata muchos procesos, el orden excesivo, la sobredosis de normas provocan que no se pueda mover con velocidad de un punto a otro, que no se puedan probar distintas cosas e incorporar a los nuevos procesos aquellas que funcionen.
Desorden
Sí, aunque parezca que se contradice un poco con la anterior, es tan problemático el exceso de orden como su ausencia total. Para ser ágiles hay que tener orden, hay que conocer en todo momento los «recursos» de los que se dispone y sobre todo el más preciado de ellos que es el tiempo de las personas que ejecutan los trabajos. Si no se tiene cierto orden es imposible ser ágil porque nunca se podrá prever que trabajo se va a poder realizar y a que retos se va a poder enfrentar, y la gente que realiza los trabajos no va a saber nunca a que atenerse, que es lo que debería hacer en cada momento sin preguntar a su micromanager cual debe ser el siguiente paso que tienen que dar.
Miedo
Efectivamente el miedo es un gran problema. Generalmente es el miedo de los mandos intermedios. El medio que les impide enfrentarse a sus superiores para llevar a cabo los cambios. El miedo que les hace no asumir que a veces es necesario perder tiempo en tareas no directamente productivas. El miedo que les hace no asumir que optimizando es posible que se tengan que enfrentar a reducciones de presupuesto o a no cumplir con los objetivos erróneos que les hayan puesto los de arriba. Ese miedo les impide lanzarse a liderar el cambio.

Estos 3+1 problemas son los más repetidos en base a mi experiencia en las distintas empresas que he podido ver como funcionan. ¿Y en la tuya? ¿Quieren ser ágiles? ¿Desde hace cuanto? ¿Son ágiles de verdad o tienen algún problema para conseguirlo?

Lean is not dead

Hace unas semanas dije en Twitter que «el punk es la música más emprendedora que existe». A esto, Juan me reto a que lo desarrollara aquí para la posteridad (es más fácil reencontrarlo entre unos pocos posts, que entre un montón de tontos twits):

Bien, probablemente me equivoqué. Emprender es una palabra que abarca mucho, emprender es muchas cosas, y unas son más punk que otras. Sin embargo, creo que sí que hay una forma de emprender en la que encaja mucho el punk.

Punk

Ya hablamos en su día de qué era y de dónde venía el concepto Lean.

También dejé caer ya en su momento, en aquel «libro» que escribí tras el viaje con Yuzz a San Francisco, algún nombre de algún grupo con letras muy emprendedoras como Sioux (que anteriormente era parte de Kaos Etiliko).

Ese «teníamos un plan: si algo no funciona lo vuelves a intentar» es muy de emprendedores, de no rendirse, de aprender del error.

Pero no sólo por sus letras el punk es lean o el lean es punk.

El lean se basa en implementar, medir y aprender. Ponerse manos a la obra y meterse en harina, ver como funciona y qué se puede mejorar, para enriquecer la siguiente iteración de lo que sea que estás haciendo.

El punk, el del principio: el de los Saicos, el de los Sex Pistols, el de The Clash, Kortatu, Toy Dolls, Manolo Cabezabolo, … Todos tan distintos pero con tanto en común. Ese punk era de empezar por dar conciertos, por tocar (aunque no se sepa) e intentar hacerlo cada vez mejor (¡o no! ¡qué más da!).

Además, el punk usa canciones sencillas que se pueden replicar fácilmente igual que lean intenta repetir lo que ya se ha hecho, mejor y a mayor escala.

Otro punto que tienen en común es que ambos, tanto el punk como la metodología lean startup, surgen como respuesta a algo que ya no funcionaba.

El punk viene de esos ritmos del rock and roll que primero representaban la rebeldía y que iban contra el sistema. Ese rock se volvió algo mainstream que ya sólo podían crear los que eran grandes músicos, y que tuvo su muerte absoluta el día que su Rey que había escandalizado a todos con sus movimientos, Elvis Presley, aceptó hacer la mili (aunque fuera bajo presión). El punk es una respuesta a esa comercialización de la rebeldía, de la escandalización, a que sean los de arriba los que decidan que es bueno y que no, muy nihilista todo. El punk lo hace cualquiera que quiera hacerlo y sólo es punk mientras se mantenga rebelde.

Punk

Del mismo modo, la metodología lean startup apareció cuando los desarrolladores (y no los empresarios «de carrera») empezaron a montar empresas en un entorno en el que ya no funcionaba el modo habitual de hacer las cosas. En ese valle del silicio, en ese área tecnológica, en ese mundo cambiante en el que hay una gran incertidumbre y que es imposible anticipar resultados ni presupuestos a tres años, en el que hay que reaccionar a las condiciones variables que alteran el entorno como una galerna. El lean llegó para estructurar un modo de trabajar ágil que tuviera siempre una respuesta a «¿qué es lo siguiente que hay que hacer?» porque los sistemas tradicionales ya no funcionaban ahí, habían sido derrocados.

Otra similitud es que ambas «metodologías» dan distinto resultado cuando se aplican en distintos entornos, en distintos mercados. No creo que haya que ejemplificar que ni ha aparecido el mismo punk en España que en los países anglosajones, así como la aplicación de lean startup no resulta en el mismo tipo de empresas en España que en USA.

La ¿última? de estas similitudes es el inevitable final de quien decide seguir cualquiera de los dos caminos. O acabas muerto o acabas corrompiéndote. No tiene por que ser necesariamente malo ese corromperse, y más con esa alternativa. Es imposible que una empresa que crece mucho y se hace enorme siga siendo lean en todos los aspectos, igual que es imposible que un grupo que triunfa y se hace mainstream y se casa con discográficas potentes y todas esas cosas, siga siendo enteramente punk.

Es el curso de la vida, es como hacerse mayor, preferiblemente lo evitaríamos pero teniendo en cuenta que la única alternativa es morirse tendremos que celebrar hacer años, no ser tan punk o no ser en todo lean.

Imágenes del flickr de Mikel García Idiakez y de Dr Case

Introducción a Azure API Management

Estamos atendiendo a un cambio en el modo de afrontar la incorporación de software externo a un proyecto. Cada día es más habitual el incorporar el uso de APIs externas para suplir funciones en lugar de incorporar el software y los datos necesarios para llevarlas a cabo internamente. Todos hemos oído o leído que el paradigma del futuro cercano son los microservicios y llevamos muchísimo viendo las bondades de las APIs REST. Este cambio, como todos, tiene sus cosas buenas y sus cosas no tan buenas.

Seguir leyendo en CompartiMOSS.

Consejos de emprendedores para emprendedores #Yuzz

El viernes pasado fui a compartir un ratito con los Yuzz de Cantabria. Me habían pedido que compartiera mi experiencia, y aproveché para hacer un experimento: ¿todos los emprendedores damos los mismos consejos?

Fue idea de Juan: «estaría guay que los consejos no sólo les dieses tú». Y pensando me dije: probablemente todos mis conocidos del mundo estartapil darían los mismos consejos.

Seleccioné de mi lista de contactos a aquellos implicados en el mundo emprendedor, no tenía sentido preguntar al aire por Twitter o en cualquier otro foro, porque sólo de los que conozco personalmente y conozco su historia podría desentrañar el porqué de ese consejo y no otro. Me salieron 76, y a esos les mandé el siguiente mensaje por Whatsapp:

Hola! Soy Javi López (el ex yipi por si no me ubicas) y sí, esto es un mensaje de difusión. Estoy haciendo un experimento y quería pedirte que pares un minuto de disfrutar de este domingo y me grabes un consejo desde tu experiencia para quien se esté planteando hacerse autónomo, o montar su propio negocio, o montar una startup. Muchas gracias de antemano ¡un abrazo!

17 (o contándome a mi 18) se pudieron permitir el dedicar un minutillo a contestar.

Obviamente, estos 17 no son una representación de todo el mundo estartapil, ni de la sociedad, ni de nada. Esto que quede claro, que ya me ha costado una buena bronca con una de mis mejores amigas, porque por ejemplo de los originales 76 sólo el 20% eran chicas (¡ojalá conociese yo a más emprendedoras!) y ninguna llegó a sacar tiempo para contestar al «reto».

La charla iba mucho más allá de esto, ya que les conté con detalles toda mi experiencia e hicieron muchas preguntas, y buceamos en cada uno de los consejos que nos dieron mis amigos, viendo si tenían sentido y cuales podrían ser los porqués. Aun así, aquí os comparto esos consejos para que os lleguen a vosotros también, pero sobre todo tened en cuenta lo que son: consejos, no verdades absolutas. Nadie tiene una respuesta 100% veraz y que valga para todos los casos, así que como todo: cogedlo con pinzas.

(usa las flechas para moverte o visita la fuente)

Quiero agradecerles a todos ellos ese ratito que dedicaron a contestarme sin tener muy claro para que era: Muchas gracias Cesar, Luis, Marc, Berny, Oscar, Rafa, Iñaki, Miguel, Paco, Chema, Asier, Héctor, Jesús, Carlos, Pablo, Tivo y Nacho.

Y a aquellos que no recibieron ese mensaje… o no tengo vuestro número, o se me escapó, mil perdones.

La amo con locura

La amo con locura, pero eso no evita que siempre me rechace. Yo insisto e insisto, ya sabéis que no soy de rendirme, pero parece que no quiere que mi vida sea con ella.

Creo que puedo decir sin equivocarme que la quiero desde que nos conocemos. Vale, puede que alguna vez haya renegado un poco, puede. Puede que fuese ese puntito de rebeldía adolescente, puede. Pero lo cierto, es que no me visualizo viviendo sin ella, no entiendo mi futuro lejos de ella, no lo veo.

Una vez más me ha dicho que me vaya, y una vez más, cansado de aguantar, voy a darla su tiempo, a esperar que me eche de menos aunque no sepa si alguna vez lo hizo o sólo me echa siempre de más.

Así que me voy, ¡ahí la dejo!

Estoy seguro de que volveré a rondarla, en algún momento volveré a insistir, volveré a intentar que mi vida esté ligada a la suya, o que al menos sea a su vera. Ya sabéis: no soy de rendirme. Volveré, pero de momento la dejo para otros mejores que yo, otros que la llenen más, o que la entiendan, o que sepan adaptarse a ella mejor de lo que yo he sabido.

¡Ahí la dejo! ¡Ahí os la dejo! Ahí la tenéis vosotros que sois mejores. No es que yo no la quiera, la quiero y la querré siempre, pero no la quiero a cualquier precio y yo también necesito sentirme querido, útil, necesitado ¿y quién no?

Así que adiós. O mejor aún: hasta luego Tierruca; y no adiós.

Big Data talks

I was attending a talk about Big Data past week. The organizer was Ascentic and the speakers were IT workers from Cantabria with high responsibilities in their companies. I think that it is interesting know about different use cases on different sectors.

[Leelo en español en CantabriaTIC]

Celestino Güemes works at Atos Worldgrid and he is a member of its wise committee. He was talking about “new” types of analytic and the issues. He explained us that analytics of historic data is something easy nowadays. However, systems are evolving with predictive analytics and prescriptive analytics, providing to an operator possible actions to take, and what is the recommended one.

He also remarked the use of deep learning and multi-sided market analytic platforms to develop new products and services.

He exposed some interesting and real cases as example of the different types of use of Big Data:

Operational excellence: An oil company uses drilling heads with 120 sensors. They can analyze the data in real time and compare them with the historic  data to know when a head will break avoiding problems.

User experience: They work for a telecommunications provider in the relation between mobile network configuration and use of the clients. For example, they can detect where a user lives or works based on the network elements the user uses. They also can improve the quality of service for a specific VIP user when she is using Youtube during a trip or notify a client with information or an offer when he walk into a street (this is very similar to what I did with my team at GPMESS, my last company).

Bussiness re-invention: A seller of electricity is putting their data with other data sources to look for new possible services and business models. They are exploring things like detect the different machines in a house and offer discounts in new machines when they detect a problem in one of them based on the use of electricity.

Confidence and compliance: he is working in a solution to detect non-technical economic losses (frauds and errors) for electricity companies. These losses represent 1% of the business (3.7M€ per year).

Miguel Sierra is a manager at CIC. He leads a product called IDbox that is a software for Operational Intelligence. It integrates all available information sources, processes that captured signals and offers the tools for analysis to assist in operational decision making. This product is used by companies from different sectors: nuclear plants, electricity companies, private parking companies, water companies, and also high performance sports training.

He was talking about their history and how they became a company with high expertise on Big Data.

He said that the size is important but the frequency is more important. They process 1.5M signals from Iberdrola each second and 80K signals from a nuclear plant each 20 milliseconds (it is almost the same that 4M signals each second).

They help business that are not scalable at first sight providing them ways to become scalable and more profitable companies. He used the example of a clinic that work with professional athletes. They needed a doctor attending a single athlete inside their installations. Now they can provide a service to other clinics and gyms monitoring trainings from a control center operated by a group of doctors. A single doctor can work now with more than 20 athletes that are training at anyplace.

Raul Uría, CEO at Zzircon Business Intelligence. He did a basic presentation thinking in non-technical attendees. He explained what is and for what is the data mining. He showed a complete example with a single product (a slide for kids) talking how data mining helps to know to what users you have to offer this product, and how you should impact them and what message you should use.

I am sure that it was a great explanation for people that are not involved on IT everyday.