[Article] Azure | ¿Que es Docker?

Continuando el tema de micro-servicios y cómo podemos implementarlo vamos tocar el tema de Docker. Seguramente hemos escuchado de Docker en alguna conferencia o de algún compañero de trabajo pero no nunca llegamos a comprender del todo que es y en que podría ayudarnos esta tecnología.

Objetivo

El objetivo de esta publicación es tocar las posibles utilizaciones y el alcance de dockers. Ver cómo podemos utilizarlo en una arquitectura de microservicios. Sus beneficios como también que puntos debemos tener en cuenta para poder llevarla adelante.  El objetivo principal es entender de una forma clara y sencilla que es Docker.

Audiencia

Este documento está dirigido a personas que conocen muy poco o nada sobre el tema. No nos meteremos en aspectos técnicos, tampoco como ejecutarlo o como se debe usar.

Desarrollo

Básicamente Docker nos da la posibilidad de crear contenedores muy livianos y fácilmente portables para nuestras aplicaciones. Independiente del sistema operativo que utilicemos podremos ejecutar un contenedor Docker en cualquier máquina. Esta característica nos facilita mucho el despliegue de nuestras aplicaciones.

Seguramente se preguntaran, ¿Pero… que es un contenedor? el concepto viene originalmente de la plataforma linux, no es realmente un concepto nuevo, pero hoy muy de moda. La idea viene de los contenedores que llevan los barcos para transportar productos que pueden ser o no del mismo tipo.

Docker nos permite meter todo lo que necesitamos para ejecutar nuestra aplicación en un contenedor e inclusive la propia aplicación. Supongamos que queremos implementar un micro-servicio que está desarrollado con .Net Framework. Dentro del contenedor podremos poner todos los componentes necesarios para la ejecución del servicio, el servidor web, componentes de terceros sin preocuparnos de las versiones de software que tiene instalada, si las tiene instalada, si están lo componentes necesarios en nuestra máquina donde se alojara el contenedor.

¿Y en qué nos beneficia?

Docker puede ser utilizado en cualquier entorno de IT. Puede dar soporte a equipos de desarrollo o equipos de infraestructura ayudando a que las aplicaciones y ejecuten fácilmente y aumentando nuestra capacidad de despliegue de estas.

Desde mi punto de vista, como desarrollador, me permite olvidarme si el la aplicación que estoy construyendo funcionara correctamente en la máquina que va a ser ejecutada permitiendo enfocarme completamente en dicha construcción.

Vamos a dar un ejemplo bastante usado en internet:

  • Matías tiene en su computadora instalado la versión de .Net Framework 4.5 y se encuentra programando una micro-servicio con funcionalidades específicas de esta versión.
  • Florencia en su máquina tiene instalado las versión de .Net Framework 3.5 debido a que está trabajando en un proyecto distinto. Matías quiere que Florencia pruebe su micro-servicio en su máquina pero si ella no instala .Net Framework 4.5 la aplicación no funcionará.

Si estamos usando Docker no tendremos este inconveniente.  Matias creará un contenedor con todo lo necesario para que el micro-servicio funcione y se lo pasará a Florencia. Como Florencia tiene instalado en su máquina Docker podrá ejecutar la aplicación sin necesidad de instalar nada.

Algo para lo cual usamos mucho Docker es para hacer testing. Es muy fácil crear o eliminar un contenedor. Al ser muy livianos podemos usar varios contenedores en la misma máquina y el contenedor funcionara en cualquier maquina que tenga instalado docker sea Windows, Linux, MacOs o Inclusive en la Nube como Azure. También al contenedor es ser más liviano que una máquina virtual puede reducir mucho el hardware que utilizaremos

Docker Vs Máquina Virtual

Podemos tener varios contenedores en la misma máquina, pero… ¿en qué se diferencia de una máquina virtual si también podemos tener varias? Es muy similar en algunas cosas pero la gran diferencia es que en una máquina virtual necesitamos instalar un sistema operativo y en un contenedor no.

Algunas características específicas de los sistemas operativos pueden causar problemas cuando queremos portar nuestras aplicaciones en diferentes entornos. Un contenedor de Docker toma los aspectos básicos de funcionamiento de un sistema operativo donde se encuentra ejecutándose este.

Cosas que tenemos en Docker

Tenemos varios elementos que tenemos disponibles en docker. Cada elemento nos brinda un serie de beneficios dependiendo de cómo los usemos. Los más fuertes son Imágenes y Contenedores.

Imágenes

Las imágenes son muy parecido a un snapshot de una máquina virtual pero no olvidemos que es mucho más liviano. Los usaremos como una plantilla para nuestros contenedores. Estas imágenes las utilizaremos para crear nuestros contenedores.

Hay mucho repositorios públicos donde podemos obtener imágenes para crear contenedores siendo un buen punto de partida para crear los nuestros e ir agregando las cosas que necesitemos. Podemos empezar buscado aqui https://hub.docker.com

Contenedores

Podemos decir que son instancias de nuestras imágenes y son finalmente lo que ejecutan nuestras aplicaciones y de una imagen podemos ejecutar varios contenedores. Supongamos que necesitamos escalar nuestra aplicación porque aumentó su consumo. A partir de la imagen podríamos ir creando contenedores para atender las solicitudes.

Con Docker podemos ir administrado las versiones como si fuera una herramienta de control de versiones. Hacemos unos cambios, damos commit y se nos guardarán los cambios. Esto nos permitirá volver a versiones anterior por algún inconveniente que tengamos.

Conclusión

Docker puede darnos una gran ayuda en una arquitectura de micro-servicios. Nos facilitará no solo el desarrollo y el testing si no que nos garantizara una gran capacidad de despliegue con tiempo muy cortos. También, puede reducirse mucho los costos de infraestructura ya que son mucho más livianos que una máquina virtual. En el futuro vamos a ver una implementación de docker en Azure.

[Article] Arquitectura | Que es MicroServicios

Seguramente habrán escuchado sobre micro-servicios, o  de alguna software que sigue el patrón de una arquitectura de micros-servicios.  Micro-Servicios es un tema que actualmente se encuentra en boca de todos y probablemente escuchemos cada vez más hablar de ello.

Objetivo

El objetivo de esta publicación es tocar las posibles utilizaciones y alcance una arquitectura de microservicios. Sus beneficios como también que puntos debemos tener en cuenta para poder llevarla adelante.

Audiencia

Este documento está dirigido a personas que conocen pero no saben que realmente es, como también a personas que no conozcan el tema, o bien profesionales que desarrollan tareas de consultoría de desarrollo o que simplemente están interesados en leer e investigar sobre la tecnología alcanzada por esta publicación.

Desarrollo

Cuando hablamos de una arquitectura de microservicios tenemos que pensar en una aplicación construida sobre una serie de pequeños servicios. Estos tienen la característica de ejecutarse de forma autónoma y también pueden comunicarse entre sí. Uno de los mecanismos comunes de comunicación es por medio de peticiones http hacia sus APIs.

Al referirnos a pequeños servicios podemos decir que cada uno corresponde a un área de negocio de la aplicación como por ejemplo: Clientes, Ventas, Stock, etc. Básicamente el objetivo es tener una cantidad mínima de servicio que manejan cosas comunes para todos como acceso a base de datos o bien servicios de terceros.

Cada servicio es independiente y debe poder ser desplegado sin tener ningún impacto sobre los otros. Otra característica muy interesante es que pueden escribirse en cualquier tecnología y cómo estos se comunican por medio de las APIs pueden hablar sin inconvenientes.

No hay especificaciones de qué tamaño deben tener los micro-servicios, tampoco, cómo debemos dividirlo para una aplicación. Jon Evans publicó que la mejor característica de un microservicio es que puede ser re-escrito nuevamente en 2 semanas.

Arquitectura sin MicroServicios

Para poder entender mejor el objetivo de la arquitectura de microservicios vamos a usar el siguiente ejemplo: Pensemos en una aplicación de gestión para una empresa que se dedica a la venta de productos en línea. Los usuarios interesados en los productos podrán ver, comprar los productos y seguir sus pedidos.

Nuestra primera aproximación de nuestra arquitectura seria algo asi sin la utilización de microservicios:

 

 

Nuestros usuarios entraran a la aplicación, una aplicación web, y podrán visualizar los productos, seleccionarlos,  agregarlos a un carrito y finalmente cerrar su compra junto a su forma de pago y datos de envío. Todo nuestro codigo se ejecutara en el servidor el cual puede conectarse a una base de datos u otro servicio de terceros. En nuestro caso podría ser un servicio de pago especial.

Nuestra aplicación pueda estar separado por módulos con diferentes lógicas de aplicación, pero, esta tiene como resultado siempre el mismo compilado ejecutable. Supongamos que debemos hacer un cambio en el módulo de envíos y debemos implementarlo en producción. Ante esta situación no tenemos opción de tener que implementar todos los módulos aunque la gran mayoría no hayan cambiado.

Otra situación es, que pasa si nuestro sitio tiene comienza a tener mucha demanda. Necesitaremos escalar para poder brindar servicio a todos los usuarios nuevos. En esta arquitectura debería crear nuevas instancias de mi aplicación y usar algún tipo de balanceador de carga para que los usuarios vayan dirigiéndose a cada instancia dependiendo de la carga. Pero, si en realidad es solo el modulo de ventas está sobrecargado, igualmente, deberemos crear instancias totales de nuestra aplicación.

No debemos olvidar que en el punto anterior la aplicación es fácil de gestionar porque posee un solo ejecutable para actualizar todas las instancias de nuestra aplicación de una forma manual o automática.

Arquitectura MicroServicios

 

 

En lugar de tener todo en un solo servicio o ejecutable, cada componente puede auto-ejecutarse y los servicios que lo componente pueden comunicarse entre si sin ningún problema.

Los usuarios pueden interactuar con ellos por medio de la aplicación, que tranquilamente también puede ser un micro-servicio, comunicándose con los servicios de clientes por ejemplo.

Al usar este tipo de arquitectura tenemos los siguientes beneficios:

  • Como la lógica de negocio está bien separada o sectorizada es muy simple de comprender.
  • Cada microservicio es autónomo y puede desplegarse sin afectar a otro. Si el módulo de clientes necesita actualizarse no afectará por ejemplo al módulo de proveedores o no será necesario implementarlo nuevamente.
  • Mejor escalamiento debido a que no es necesario replicar toda la aplicación, si no, balancear o replicar los módulos que están teniendo más carga.
  • Podemos tener varios equipos de desarrollo autónomos encargándose cada uno de un módulo o micro-servicio tanto en el desarrollo como en la gestión del mismo.

Si bien este tipo de arquitectura tiene muchos beneficios… no todo es color de rosa. Como toda arquitectura tiene sus pros y sus contras.

Una falsa creencia es que sin microservicios no podemos tener despliegue continuo o entrega continua, esto no es cierto. Grandes empresas como Facebook, Twitter u otras poseen este tipo de capacidad sin la utilización de una arquitectura de microservicios en su totalidad.

Los micro-servicios agregan complejidad en nuestra gestión. Si tenemos mucha cantidad de servicios debemos tomarnos el tiempo de crear una buena estrategia gestión. Deben estar bien monitoreados, debemos saber exactamente cual esta fallando, gestionar sus fallos, velar por la consistencia de datos y tener una buenas estrategias de pruebas.

Martin Fowler dice : “hay muchas formas de gestionar todo esto, pero necesitamos esfuerzo extra, y nadie que conozco en desarrollo software parece tener muchísimo tiempo libre.”

Si nuestra aplicación es muy simple tal vez no sea necesario usar micro-servicios. Pero si nuestra aplicación crece y comienza a volverse compleja vale la pena invertir esfuerzo en llevarla a este tipo de arquitectura. Grandes empresas, clientes nuestros, se han encontrado con que gestionar la aplicación en un solo componente con el tiempo es cada vez mas complejo y han empezado a separar sus aplicaciones en microservicios o bien, los proyectos nuevos, desarrollarlos con una arquitectura de micro-servicios.

Conclusión

La arquitectura de micro-servicios no es simplemente una moda. Para una empresa que hoy no posee esta arquitectura es aconsejable que vayan hacia ella poco a poco, manteniendo las aplicaciones actuales e ir separando las partes críticas en micro-servicios mediante algunas estrategias como Branch By Abstration. Esta estrategia hablaremos en algún post junto a Visual Studio On-Line. En azure podemos usar docker para llevarla adelante. En próximo post estaremos viendo como usar docket en azure.