Uno de los conceptos que hoy en día siguen causando más confusión es el de Unicode y sus distintos tipos de codificación. Pero… ¿qué es realmente Unicode? Para ello, déjame que remonte unos cuantos años atrás…

El inicio: ASCII

Los ordenadores los inventaron los americanos y como suele ocurrir se preocuparon de lo suyo: que un ordenador pudiese presentar textos en su idioma. Tampoco hay tantos caracteres en el inglés: las veinte y poco letras (en mayúsculas y minúsculas), los símbolos de puntuación, paréntesis, operaciones matemáticas y poco más. En total eran menos de 128 carácteres. Genial, porque esos espacios que sobraban se podían aprovechar para colocar otros caracteres que no tienen representación gráfica pero que eran (y son) necesarios para controlar el teletipo: retornos de carro, saltos de línea y similares. Había nacido el código ASCII.

Esta es una de las preguntas que tarde o temprano cualquiera que trabaje con Docker y Kubernetes (o cualquier otro orquestrador) se termina encontrando: Tienes toda tu aplicación en contenedores, ejecutándose en Kubernetes. Sabes también que existen versiones dockerizadas de las bases de datos. Así pues… ¿es conveniente ejecutar las bases de datos como contenedores adicionales en el orquestrador?

El hecho de ofrecer SignalR como servicio PaaS en Azure y su integración con Azure Functions nos abre un escenario interesante: ahora es facilísimo hacer notificaciones push desde una Azure Function (AF) a un cliente SignalR (p. ej. una Web).

DevSpaces es una de las grandes novedades para desarrolladores que nos trae Microsoft (ehm sí… es otro producto más que está en preview :p). Básicamente se trata de la posibilidad de desplegar parcialmente y depurar nuestros contenedores ejecutándose en un clúster de Kubernetes. En lo que Hanselman llama un “entorno que huele como producción”.

¿Pero… cómo funciona esa magia? Vamos a ver, dentro de lo posible, qué ha hecho Microsoft para proporcionarnos esta experiencia, dentro de un Kubernetes completamente normal…

Este post **no pretender ser un tutorial de DevSpaces, **ya que la propia documentación lo explica bastante bien. La idea es intentar ver “como” funciona DevSpaces, más que como lo podemos usar.

Dentro de esta vorágine de productos relacionados con los contenedores en la que está inmersa Microsoft, ahora le toca el turno a Service Fabric Mesh que salió hace nada en public preview. En este post quiero comentaros un poco de qué va este producto y como ha ido mi (limitada) experiencia con él.

Disclaimer: Este es un post sobre un producto que está en preview. Lo expuesto aquí puede cambiar a medida que avance tanto el propio producto como mi experiencia en él.

Una de las preguntas más frecuentes que me hacen sobre contenedores es hasta que punto penalizan el rendimiento. Es una pregunta muy lógica ya que al final los contenedores ofrecen un cierto nivel de aislamiento, parecen máquinas virtuales… Algo han de penalizar, ¿no?. En esta entrada voy a hablar de los runtimes de contenedores, para que entendamos un poco más qué significa ejecutar un contenedor.

Una de las novedades de ASP.NET Core 2.1 es que redirige automáticamente todo el tráfico de http a https y, además, fuerza el uso de HSTS. Sobre https nada que decir, seguro que todos lo conocéis.

Sobre HSTS simplemente comentar que es un protocolo mediante el cual el servidor informa a los user-agents de que solo acepta conexiones seguras, es decir que deben usar HTTPS para acceder a sus recursos. A pesar de que HSTS tiene sus limitaciones (y que para evitarlas sería necesaria un protocolo a nivel de DNS y no de servidores) su uso es una práctica imprescindible en seguridad web. De hecho **hoy en día NO HAY EXCUSA PARA NO USAR HTTPS NI HSTS **en cualquier sitio web. Da absolutamente igual lo que haga. No usar https ni hsts es una negligencia que debería avergonzar a cualquiera.

Una de las ventajas que tiene **Visual Studio 2017 es el soporte de depuración para contenedores netcore. **A partir de la versión 15.7 el soporte está relativamente maduro soportando algunos escenarios que daban errores en versiones anteriores (p. ej. dos servicios compose usando la misma imagen).

Pero… ¿y si no podemos/queremos usar Visual Studio? ¿Tenemos alguna alternativa? Pues sí: usar visual studio code, y aunque el workflow no es tan sencillo como en Visual Studio, al final se puede conseguir algo similar: ejecutar y depurar un contenedor. ¡Vamos allá!

Una de las características menos conocidas de Docker son las imágenes multi-arch. Es una característica que agradecerás si trabajas tanto en contenedores Linux como Windows.

Como ya debes saber, Docker no permite ejecutar contenedores cuyos binarios no sean los mismos de la plataforma que los hospeda: es decir, si estás en Windows solo puedes ejecutar contenedores cuyos binarios sean Windows y si estás en Linux pues lo mismo. Y sí, Docker CE For Windows “hace tramas” para permitirte ejecutar contenedores Linux: los ejecuta en una máquina virtual Hyper-V.

Si desarrollas un producto multi-plataforma y quieres ofrecer contenedores tanto Linux como Windows, el uso de imágenes multi-arch es algo que, como digo, vas a agradecer, ya que te permite usar un solo Dockerfile para generar ambas imágenes.

En este post vamos a ver como escalar servicios, tanto en Compose, como en Swarm como en Kubernetes y luego veremos algunas consideraciones cuando usemos HttpClient desde el cliente al acceder a un servidor escalado.

Nos centramos en el escenario de escalado básico, es decir, sin demasiada lógica.

[Autobombo]: Si estás interesado en temas de Docker y Kubernetes, échale un vistazo a mi curso de Docker y Kubernetes en CampusMVP.