98. Microservicios

Este es un tema muy interesante, por eso también vamos a abarcar algunos post, no he dejado el tema de DevOps, por que los micro servicios entran en dicho tema, tampoco quiero empezar por nano servicios que es otro tema interesante, sino que quiero avanzar poco a poco en este tema.

El computo se ha desarrollado de manera vertiginosa, en muy poco tiempo, hace unos cuantos años se hablaba siempre de aplicaciones monolíticas, que lo mas que se dividían en capas, para brindar seguridad y cierta especialización.

En algún momento hablamos de SOA, la arquitectura orientada a servicios, en donde considerábamos que todo era un servicio, todos los front end, son clientes de servicios en el backend, se busco una reutilización de código y de recursos, con grandes servicios que se encargaban de efectuar las tareas de una manera eficiente.

Después entramos a la era móvil, en donde el computo deja de estar en un escritorio y pasa a las manos de los usuarios, en donde se requiere un desarrollo ágil, y  cualquier error nos puede costar la venta de nuestro producto es aquí en donde podemos hablar de micro servicios

¿Qué es un micro servicio?

Es una Arquitectura para el desarrollo de aplicaciones por medio de pequeños servicios altamente especializados y aislados entre si.

Es construir nuestra aplicación por medio de piezas de lego.

¿Cómo es su arquitectura?

Cada micro servicio debe efectuar una sola actividad, tener su propia responsabilidad y ser altamente especializado.

Cada componente debe ser independiente de otro.

Esta independencia se debe dar en el desarrollo, ya que al ser especializados los componentes se convierten en cajas negras, esto también nos permite utilizar múltiples tecnologías para el desarrollo de los micro servicios.

Independientes en el despliegue, los micro servicios se pueden desplegar sin necesidad de desplegar toda la aplicación, esto permite que se hagan cambios con ventanas de mantenimiento pequeñas, permite el poder probar solo partes especificas de la aplicación por que se garantiza que el resto de la aplicación no tiene cambios.

Se tiene un ciclo de vida pequeño, al ser un componente pequeño este puede pasar en muy poco tiempo hasta producción.

No existe acoplamiento entre servicios, cada servicio es independiente, incluso de base de datos, al ser independientes, la información que almacena se puede guardar en sitios muy diversos sin necesidad de tener un repositorio centralizado.

Cada componente tiene su lógica interna el micro servicio y la comunicación entre ellos se efectúa por canales externos de comunicación.

Se trabaja con base a contratos.

¿Qué justifica su uso?

El ambiente cambiante en el que nos encontramos, en el que una aplicación necesita desarrollarse de una manera rápida, el no tener grandes ventanas de despliegue, el poder tener en los equipos de desarrollo a la gente especializada para cada función.

¿Cuáles son sus ventajas?

Pueden crecer muy rápidamente
Es posible encontrar cuellos de botella muy rápidamente y superarlos, escalando de manera individual
La pase de pruebas es rápida, ya que se prueba solo un componente
Se puede agregar funcionalidad nueva en muy poco tiempo
Cuentan con una gran estabilidad

¿Cuáles son sus desventajas?

No todo lo que brilla es oro, y menos en este caso.

Los micro servicios emplean un medio de comunicación que puede ser inestable, por lo que deben ser altamente tolerantes a fallos, todos los errores que puedan ocurrir deben estar controlados.

Al ser aplicaciones independientes estas pueden tener errores de manera independiente, por lo que un error en erras debe ser controlado por la aplicación que la invoca.

Se requiere que los equipos de desarrollo tengan mucha comunicación ya que el comportamiento real de los micro servicios se ve al momento en que se hace la integración de los mismos, por lo que se deben definir los contratos de manera detallada, para que realmente se de comunicación entre ellos.

No existe un control total de la aplicación, al estar separada en servicios, la aplicación se encuentra fragmentada.

Si no existe documentación, el nivel de entropía se incrementa, ya que se convierten en grafos con múltiples ramas y múltiples caminos.

Se incrementa la complejidad del despliegue, no es lo mismo desplegar un servicio que 100, por lo que se deben emplear herramientas de automatización.

Se incrementa el trabajo de administración por parte de infraestructura, no es lo mismo verificar que corra un servicio a que corran 100

Si no se cuentan con procesos automáticos de mantenimiento y despliegue se incrementa la posibilidad de error humano

Se debe contar con una infraestructura que soporte el modelo, mas servicios es mas memoria

Al ser servicios especializados cada servicio es una caja negra, se debe tener una confianza total en los desarrolladores.

Y lo mas importante, esta arquitectura no es para cualquier equipo de desarrollo, se debe tener una madurez entre las áreas, por que de otra forma se perderá el control en la administración de los micro servicios

Felices líneas

97. DevOps (3) - Infraestructura como codigo

Infrastructure as Code (IaC), es uno de los pilares de DevOps y quizás también uno de los pilares de la computación de esta era, ¿En que consiste este pilar?, consiste en poder crear la infraestructura necesaria para que el servicio opere por medio de archivos de definición.

Esto en el pasado, podía sonar imposible, ya que la infraestructura era adquirida tomando en cuenta las necesidades de la empresa y las proyecciones de crecimiento de la misma, de tal forma que por lo regular se adquiría una infraestructura que la mayoría del tiempo permanecía ociosa, o peor aun se compraba la infraestructura para responder a los momentos en que se requiriera mayores recursos de hardware, cuando muchas veces esto era solo un periodo pequeño en el transcurso del tiempo.

El computo en la nube, promueve la infraestructura como servicio, permitiendo crear los equipos de computo en la nube, en cuestión de minutos partiendo de un archivo de definiciones.

¿Qué ventajas tenemos?

Reducción de costos, usamos solo lo que necesitamos usar y solo cuando el proceso esta listo para ello, por lo que no existen equipos en espera de un nuevo componente.

Velocidad, la velocidad de implementación es alta, así mismo la velocidad para crecer o decrecer la infraestructura.

Velocidad al momento de efectuar liberaciones, una liberación se puede efectuar en un equipo clon del equipo productivo, y únicamente sustituir la IP del productivo por la del Clon, con lo que los tiempos de despliegue, o de actualizaciones por parches de seguridad se vuelven mínimos

Los equipos de pruebas pueden efectuar ciclos de pruebas en ambientes similares a producción.

Reducción de riesgos, al desarrollar y probar en un ambiente similar los riesgos atribuidos a los cambios de ambiente se reducen dramáticamente.

En asure podemos crear diferentes archivos de declaraciones que nos permiten generar la infraestructura desde código, pero al ser este un pilar (mejores practicas de DevOps) se puede considerar que al día de hoy prácticamente cualquier ambiente de nube, tiene la característica de generar Infraestructura como código.


Felices Lineas

96. Pruebas cudradas (Desde el divan del gato)

Un tema muy interesante en desarrollo en el que yo en lo personal no coincido con muchos colegas o incluso con la literatura, es el tema de pruebas, principalmente en esta época en que las aplicaciones dejan de construirse para un grupo pequeño de usuarios (anteriormente yo hablaba que una aplicación era usada en una PC con características que conocía, y era usada por los usuarios de una empresa o sector en particular) a aplicaciones que si tienen éxito serán empleadas por millones de usuarios en dispositivos con características que desconozco.

Sumemos otro factor, la exigencia de los usuarios hoy en día es mayor, si hablamos de hace 10 años los usuarios estaban acostumbrados a que un buen numero de aplicaciones eran lentas y si fallaban pues había que vivir con el problema, no existía otra opción, hoy en día, esas opciones nacen todos los días y si la aplicación falla, o no enamora al usuario, simplemente se dejara de usar.

Un error grave debe corregirse en minutos, mientras menos usuarios lo vean, menos usuarios perderé.

Otro factor importante, es el numero de entradas que hoy en día tiene un sistema, cada una de ellas puede ser un factor que genere un error no controlado.

La comunicación, puede variar aun en sitios en los que se supone esta no falla, un ambiente heterogéneo, no controlado, que debe hacernos mirar para muchos lados para conseguir un verdadero sistema, que sea capaz de recuperarse de una falla.

Esto hace que los casos de prueba, que en la mayoría de los casos solo revisan reglas de negocio, dejen de ser suficientes, y mas por que la mayoría de los ambientes de pruebas son ambientes controlados, es decir yo se lo que hay, conozco la infraestructura y esta nunca falla.

El equipo de pruebas hoy en día debe ver mas allá, pero no solo ver que el sistema no falle, debe ver también que el usuario, que es un cliente potencial (el puede recomendar el sistema) se sienta cómodo con el.

Mi sistema debe sobreponerse a fallas en este ambiente heterogéneo, ya que una falla puede ocasionar que el usuario se sienta inseguro y lo deje de usar.

¿Qué debo mirar?

Ve 2 cosas al desarrollar, primero que nada que el sistema sea fácil de usar, y no complique de mas los procesos, este punto es el mas complicado de hacer, por que todos somos diferentes, y recordando la frase que dice que el sentido común es el menos común de los sentidos, la situación se vuelve mas complicada.

Observa el sistema como los bloques que lo forman

Los procesos que se desarrollan en el sistema son un núcleo aislado que se compone de un conjunto de entradas y salidas, estas entradas y salidas forman flujos que conectan diversos componentes.

Todo aquello que entre y salga del núcleo son puntos en los que siempre se puede suscitar una falla que se encuentre fuera de los casos de prueba de un sistema, además todos estos son los puntos que se vuelven vulnerables a ataque principalmente en este mundo conectado.

Ve la base de datos, es algo externo a tu sistema, siempre puede fallar
Ve las comunicaciones por red, nada te garantiza que la red siempre este conectada
Ve el almacenamiento, los accesos a disco, nada te garantiza que tienes un espacio ilimitado
Ve las comunicaciones entre tus componentes, pese a que sean en el mismo equipo, los datos están viajando
Ve todos aquellos componentes que ocupes de terceros, que trabajen junto a tu sistema
Ve los dispositivos de entrada y salida

No pierdas de vista esto, por que recuerda, hoy en día el usuario no perdona, el usuario abandona


Felices líneas

95. Visual Studio 2017 (Noticias)

Ya tiene fecha de lanzamiento, el largamente esperado Visual Studio 2017, el cual se lanzara en un evento los próximos 7 y 8 de Marzo.

Pueden participar en el evento desde la siguiente liga: https://launch.visualstudio.com/

Se espera un gran cambio en este Visual Studio, principalmente debido a la política que actualmente tiene la administración de Microsoft guiada por Saiya Nadella, que presenta una política de inclusión de varios de los ecosistemas de software (llámese mac, Linux, Windows), bajo una premisa de trabajar para todos en un solo lugar, de que cada mundo de software, no es un mundo aislado, y todos conviven tomando como eje el ecosistema de Microsoft.

Desarrolla una vez y distribuye donde quieras, un sueño de todo desarrollador que cada día es mas palpable.

Presenta una madures de los lenguajes de programación y del .NET Agregar a diccionario que es su núcleo, así como una evolución para la multiplataforma.

Una orientación hacia DevOps y a aplicaciones organizadas siguiendo metodologías de desarrollo de software, esta es una temática en la que los desarrolladores .NET llegan a tener grandes deficiencias, pero que cada día es impulsada con mas fuerza en la industria.

El día de hoy ya esta liberada la versión RC, por si no quieren esperar a que se libere la versión oficial.

Nuevamente Visual Studio se muestra como la mejor alternativa para el desarrollo de software multiplataforma.

Felices Lineas

94. Configurar el IIS para https (pruebas) - Ayuda rapida

Las aplicaciones web son muy útiles, dado que se pueden ejecutar en distintos equipos con en cualquier parte del mundo, muchas veces es necesario efectuar pruebas de dichas aplicaciones de manera local, por lo que tenemos 2 opciones, usar el IIS express que viene con nuestro Visual Studio, o usar el IIS que viene dentro de Windows, cuando una aplicación madura, siempre es mejor instalar dichas aplicaciones en nuestro IIS antes de que estas sean liberadas, esto para verificar configuraciones, y el comportamiento de las mismas.

Una configuración necesaria que en muchos casos olvidan los desarrolladores es montar el sitio sobre https, esto es importante, por que en algunas aplicaciones por ejemplo WCF, la configuración cambia si en sitio es http o https.

El principal impedimento para esto, es que se requiere un certificado digital y estos certificados son costosos, por lo que para desarrollo, siempre podemos usar un auto certificado.

Para crear un auto certificado, debemos entrar en el Administrador de Internet Information Services (IIS).

Seleccionar sobre el nombre del servidor

Y seleccionar en la configuración del IIS Certificados de servidor

Entramos en la pantalla

Con el botón derecho sobre esta pantalla aparece un menú, y en el seleccionamos Certificado autofirmado

Seleccionemos un nombre para el certificado y con esto tendremos un nuevo certificado autofirmado

Ahora tenemos que configurar el protocolo https para nuestro sitio.

Entremos al sitio sobre el cual deseamos hacer esto.

y del lado derecho vamos a encontrar el menú enlaces

Seleccionemos el enlace y agreguemos un nuevo enlace

Se indica que es tipo https, y se selecciona nuestro certificado, con esto ya podemos entrar a nuestro sitio con http y https

 Felices lineas

93. DevOps (2)

Ya hemos platicado acerca de DevOps, que son una serie de mejores practicas que nos permiten en este mundo vertiginoso que es la tecnología, poder tener desarrollos que cumplan en tiempo y forma con las necesidades planteadas por el cliente.

Una idea debe explotarse lo mas rápidamente posible, por que esta puede perder su vigencia, hay que aprovechar la novedad, la notoriedad para que una idea crezca, sin embargo, si una aplicación es de mala calidad, aunque la idea sea buena, la aplicación puede perderse y olvidarse, hoy en día los usuarios no dan segundas oportunidades.

En un desarrollo no empresarial, el amor es a primera vista, o me gusta me enamora y me atrapa para que regrese continuamente a la aplicación, o simplemente la desecho y nunca me vuelvo a acordar de ella.

Un error debe ser corregido de la misma forma, ágil, ya no puedo darme el lujo de dejar una aplicación fuera de línea por periodos de tiempo muy altos.

Estamos en un mundo que realmente es 24*7*365.

Es aquí en donde es necesario una técnica para desarrollar software de una manera rápida y muy eficiente.

 Si se desea aplicar DevOps es muy importante no perder de vista 7 reglas que se deben convertir en un mantra para todos aquellos que quieran aplicar realmente DevOps.

1. Infraestructura como código
2. Integración continua
3. Pruebas automatizadas
4. Monitoreo de rendimiento de la aplicación
5. Liberaciones continuas
6. Administración de liberaciones
7. Administración de la configuración

¿Pero que significa cada paso?

Infraestructura como código: elimina uno de los problemas mas grandes que existen en el desarrollo de aplicaciones, el que en equipos diferentes (desarrollo siempre es diferente a producción), las aplicaciones se comporten de manera diferente. Además de que los ambientes de desarrollo por lo regular tienen instalados software que se emplea para diversas actividades, software que normalmente no esta instalado en el ambiente productivo.

El desarrollo en la nube elimina en gran medida este problema ya que se pueden tener equipos con mejores características.

Integración continua: Se acabo la época del programador héroe, en el que un solo programador hacia todo, hoy estamos en una época de grupos distribuidos geográficamente, en la que se busca a los mejores para efectuar tareas que antes hacia el equipo de un solo hombre, pese a que el arquitecto es el gran orquestador de las actividades del desarrollo, las aplicaciones que fueron desarrolladas por personas o equipos diferentes en diferentes partes del mundo, deben operar correctamente entre si. Es aquí en donde entra la integración continua, cada componente debe tomar la parte del rompecabezas que le corresponde, para así generar un todo, los errores de integración deben ser detectados al momento, para evitar que por un error en las piezas, se incrementen los tiempos o se baje la calidad.

Pruebas automatizadas: Grandes softwares, requieren grandes cantidades de pruebas, pero el tiempo para hacerlas es cada día menor, hay pruebas de regresión para ver si las liberaciones no han funcionalidad en el pasado, el rendimiento es importante, es necesario saber como será el desempeño de la aplicación en la vida real, de nada me sirve probar con un solo usuario y que cuando meta un segundo la aplicación deje de funcionar.

La cantidad de pruebas que puede tener una aplicación a lo largo de su vida puede superar algunos miles, y el permitir que se hagan con factor humano, trabajando bajo presión y con tendencia al cansancio, genera productos de baja calidad. Las pruebas automatizadas deben ser validadas para que aporten valor.

Un buen set de pruebas automatizadas reduce el tiempo de pruebas de días a incluso minutos.

Monitoreo del rendimiento de la aplicación: Hoy en día estamos ante aplicaciones que se encuentran activas 24x7x365, es necesario saber que pasa en ellas, pero sin ser intrusivos,

se debe brindar el soporte para poder contestar a las siguientes preguntas ¿Qué pasa en una aplicación? ¿Cuándo se degrada el servicio? ¿Sufro algún ataque? ¿Mis recursos son suficientes? ¿Cuántos usuarios tengo? ¿El crecimiento es el esperado?

Liberaciones continuas: Un tema escabroso sobre todo para aquellos que vienen de otras generaciones en las que los ciclos de desarrollo se encontraban completamente divididos, las liberaciones continuas permiten pasar cambios de un ambiente a otro prácticamente de manera instantánea, el subir los cambios en desarrollo actualiza la versión que se encuentra en una ambiente de integración, con una simple aprobación esta versión pasa a QA, a preproducción o incluso a producción, haciendo que los tiempos de liberación pasen de ventanas de varias horas a ventanas de minutos, en los que incluso el servicio puede continuar disponible.

Liberaciones continuas permite la solución de problemas o la integración de funcionalidades en tiempos pequeños, permitiendo que el cliente conserve su capacidad de asombro, o evitando la partida de clientes por errores en el aplicativo.

Administración de liberaciones: Una liberación pasa una versión aprobada, de una manera sencilla entre ambientes, tenido un código único, que ya fue probado y se encuentra completamente estable.

Administración de la configuración: Establece la consistencia de los productos durante el ciclo de vida, determina ¿Qué requisitos se cumplen? ¿Cuáles faltan? ¿Qué versiones de los productos se manejan? ¿Qué componentes se liberan? su función es tener un conjunto de fotografías de lo que ocurrió, ocurre y ocurrirá en un proyecto

Una ventaja de DevOps es que nos entrega métricas del proceso, por lo que se puede seguir la premisa de "Lo que no se mide no se puede mejorar" por lo que podemos tener este proceso en mejora continua.

Felices líneas.