Cuando hablamos de serverless todo el mundo lo asociamos a las soluciones tipo FaaS como Azure Functions o Amazon Lambda, pero hay otros productos que se engloban dentro de ese paradigma y en Azure uno de los más interesantes es Azure Container Instances. Del mismo modo que con una Azure Function me limito a poner código en “ejecución” y esto se ejecuta en algún sitio, usando ACI lo que hago es “poner un contenedor” que se ejecutará en… bueno, donde sea. Eso es serverless señores.

Con este post quiero iniciar una pequeña serie dedicada a ACI, como ACI se compara con su primo Zumosol (AKS) y como AKS y ACI habilitan interesantes escenarios (altísima escalabilidad y workloads mixtos de contenedores).

Este es un post cortito y motivado porque hace algunos días en el curso de JavaScript avanzado que tengo, junto al maestro José Manuel Alarcón, en CampusMVP un alumno preguntó más o menos eso: como se podía tener un timeout en una promise, de forma que esa fallase automáticamente si se superaba un determinado tiempo.

A ver, era algo que se veía a venir… Microsoft ha anunciado finalmente el abandono de Full Framework, en favor de Net Core. Cualquiera que estuviese al tanto de los intríngulis de pasillo del gigante de Redmond sabía que ambos equipos andaban bastante a la greña.

¡Buenas!

Este post pertenece al “calendario de adviento de C#“, y me gustaría hablaros de un tema que parece sencillo pero que bueno, esconde sus cosillas. En concreto sobre comparaciones en C#.

Una de las características más útiles, aunque más potencialmente peligrosas de C# es la posibilidad de sobrecargar los operadores de conversión (casting) y concretamente el de conversión implícita.

Poder sobrecargar el operador de conversión explícita, aunque lo entiendo como una característica que agrega ortogonalidad al lenguaje, no es algo que me guste. Antes de eso prefiero crear un método AsXXX(). De hecho me parece que un cliente de mi clase encontrará más lógico un método AsXXX() que no “un casting a XXX” que debes saber que se puede hacer para hacerlo.

Imagina que estás probando alguna versión release de netcore (pongamos la 2.2-preview3) y quieres generar imágenes Docker de tu proyecto para esa imagen. Pero a la vez quieres también crear las imágenes usando la última versión estable (pongamos la 2.1).

Asumiendo que el código fuente es compatible, ¿como puedes gestionar eso sin morir en el intento?

Hoy he tenido que afrontar la dolorosa situación de un código en netcore que funcionaba correctamente en mi máquina (Windows 10) pero que al ejecutarse en Docker fallaba miserablemente.

Dado que el error que imprimía por consola era que no encontraba un fichero, lo primero fue comprobar que nuestro código era cross-platform (p. ej. que usábamos siempre Path.Combine y no concatenábamos el caráter \ para separar directorios) ya que la imagen Docker era de Linux. Luego hicimos todas las verificaciones habidas y por haber (permisos, etc) y nada. Todo parecía correcto. Al final, nos preguntamos si era un problema de Docker o de cualquier Linux en general y ahí acudimos a WSL.

Ejecutamos el programa bajo WSL y obtuvimos el mismo error. Eso era bueno por dos motivos: No era Docker la fuente del error y además nos permitía depurar el proceso.

El otro día habé de como crear imágenes Docker para las aplicaciones SPA de .NET Core. Hoy quiero comentaros como crear imágenes Docker para aplicaciones SPA puras y un tema importante al respecto: como configurarlas.

¡Buenas!

Cuando creas un proyecto SPA de netcore, ya sea mediante VS o bien usando dotnet new y alguna plantilla SPA como react (dotnet new react), se genera una estructura parecida a la siguiente:

La carpeta “ClientApp” contiene todo el código de cliente (javascript, CSS y demás) mientras que el resto es el código netcore que se limita a “lanzar” la SPA.