Mostrando entradas con la etiqueta DevOps. Mostrar todas las entradas
Mostrando entradas con la etiqueta DevOps. Mostrar todas las entradas

16 mayo 2017

De los Microservicios a Docker


Las nuevas tendencias en el ámbito del software, tratan de dar soluciones, que sean adaptables y que permitan la alta disponibilidad. En respuesta a estos retos se encuentra la arquitectura de microservicios. Un microservicio se implementa descomponiendo el sistema de información en partes con lógicas independientes.

 Actualmente los desarrollos de las aplicaciones y los servicios que incluyen,  se despliegan como una solución unificada y con la lógica de negocio muy interrelacionada con las capas de datos "Un sistema monolítico corriendo en un solo proceso", frente a los microservicios, que se implementa en un único proceso sencillo y se despliegan como soluciones de negocio independientes, aunque pueden estar relacionadas entre si, para generar una composición de microservicios avanzados.

Dada la dificultad en establecer como se modelizan microservicios "Procesos únicos y sencillos", hay diferentes características que nos pueden ayudar:

- Un sistema basado en Microservicios, es aquel que distribuye toda su organización de forma vertical, donde múltiples funcionalidades corresponden con múltiples servicios.

- A nivel de despliegue, se puede hacer de un solo servicio, sin hacer el despliegue de los demás.

- Si se produce un error crítico los demás microservicios seguirán funcionando, o se verán afectados de forma parcial.

- A nivel de escalabilidad y rendimiento, como son independientes, es posible agrupar y distribuir en varios servidores, ganando en la eficiencia, gracias a que cada servicio es independiente de los demás, así mismo se pueden aprovechar mejor los recursos en función de las características intrínsecas de cada microservicio o conjunto de ellos.

A la hora de utilizar este planteamiento, conviene establecer una clasificación básica en Servicios de negocio, Servicios Compuestos y API's, que podemos cruzar horizontalmente en base al dominio funcional de los mismos. Lo mas importante, es tener una arquitectura establecida, antes de ponerse a crear y desplegar microservicios, que se lleguen a convertir en una autentica amalgama de llamadas y relaciones ingobernables.

Ademas hemos de alinear las herramientas de despliegue con la entrega continua (ver DevOps) , para que nos permita desplegar los microservicios garantizando el servicio que ofrecemos a nuestros clientes o usuarios.

¿ Pero que ecosistema software da soporte a todas las necesidades de los microservicios ?, algunos de los posibles serian:

    - Microservicios: Spring Boot

    - Configuración del sistema distribuido y Seguridad: Spring Cloud Config

    - Gestión de logs: GrayLogs

    Netflix OSS  para Descubrimiento, Balanceo , Tolerancia a fallos y el Enrutamiento:
- y las soluciones de



y por ultimo os dejamos un articulo muy interesante de las implicaciones de las maquinas virtuales, cuando trabajamos con aplicaciones desplegadas sobre Servidores de Aplicaciones o cuando utilizamos contenedores Docker.




---------------------------------------------------------------------

Fuentes:

LuisMi Gracia "Un poco de Java Microservicios"
LuisMi Gracia "Un poco de Java Microservicios 2"
Microservicios con docker  
The decline of Java application servers when using docker containers
Daniel Sanchez, En mi local funciona

07 diciembre 2016

Big Data LibreCon 2016 - Zylk Industry 4.0 - Compartiendo la experiencia de proyectos de Big Data

Aprovechando la participación Iñigo Sánchez Méndez de Zylk Industry 4.0 en el Librecon 2016 , donde nos explica junto a Angel Barrio de Euskaltel cómo darle valor a los datos recogidos en tiempo real y apoyándose en herramientas open source. Os dejamos la ponencia "Inteligencia del dato aplicada al negocio de las telecomunicaciones" :





Hemos aprovechado para realizar una entrevista a Gustavo Fernandez  Director Técnico en zylk.net :

En los proyectos de Big Data que has participado, que aspecto reseñarías como importante en el ámbito organizativo (implicación del cliente, infraestructuras, visión tecnológica a medio plazo,...)

Es necesario disponer de un caso de uso que aporte valor en un tiempo corto y que a su vez sea tractor del cambio cultural necesario que estos proyectos deben motivar en la organización. No hay que olvidar que este tipo de proyectos deberían ser algo más que artefactos tecnológicos, ya que conllevan un cambio organizativo y un cambio en los paradigma relacionado con el desarrollo IT. De la mano de estos proyectos de Big Data podría hacerse un plan a largo plazo para introducir el desarrollo ágil el devops etc.. si esto no se hace es probable que esta tipología de proyectos, a medio plazo, no puedan ser gestionados en las organizaciones de tamaño medio/grande. Por esa razón en el equipo de zylk hemos añadido ese tipo de perfiles, que facilitan la incorporación de estas nueva formas de hacer a las organizaciones. Por ejemplo es necesario que las organizaciones, a medio plazo, se planteen la necesidad de la figura del CDO.



Como ves actualmente, el posicionamiento y madurez de las soluciones basadas  en Software Libre para dar respuestas a los nuevos paradigmas en Big Data.


En el mundo de las soluciones de este tipo en la actualidad "o se es software libre o no se es". Es algo que en general ya está pasando con casi todo el software pero que en el mundo del Big Data reside en su propia génesis. O se es software libre o no se es. Son casos claros de este cambio todos los proyectos del ecosistema apache hadoop, o la empresa Hortonworks. Recientemente parte del equipo de zylk se desplazó a la apache europe Big Data (http://events.linuxfoundation.org/events/apache-big-data-europe) y en estas conferencias se podía ver claramente que todos "IBM, Microsoft incluso google" apuestan por los modelos de desarrollo abiertos y con licencias open. Allí también pudimos ver que los grandes consumidores, que a su vez son los grandes contributors, de estas tecnologías también usan las soluciones abiertas. Trivago, Linkedin, Soptify etc...

Todo esto se explica de manera bastante natural si entendemos que los desarrolladores que están contribuyendo al desarrollo de estas tecnologías, no las desarrollan con la finalidad última de desarrollar un software, como hacían las empresas de software privativo, sino que las desarrollan porque el core de sus negocios las necesita. Por esa razón son, y no pude ser de otra manera, desarrollos open en comunidad. Han visto la clara ventaja competitiva que supone el software abierto. Un ejemplo de este fenómeno, aunque no pertenece al mundo de apache, son los desarrollos open de Netflix. Casi todas las empresas que en la actualidad juegan un papel fundamental dentro "internet" liberan código y desarrollan en modelos abiertos. AirBnB, Netflix, Facebook, Twitter etc..  Para ser una empresa cool, antes tenías que tener futbolín (google rules), ahora hay que desarrollar proyectos open. Para mi todo se enmarca dentro de una suerte de, responsabilidad social corporativa, de las empresas que dan forma a internet; y no podría, ni debería, ser de otra manera.

En la Analítica de datos, hasta llegar a obtener las beneficios que para las organizaciones tiene el disponer de modelos predictivos de su negocio, por que fases consideras que hay que pasar?  "El reto de pasar del dato y de la información al modelado del negocio, para ser proactivos "

Bueno, creo que hay que pasar por varias fases, y estas cambian dependiendo de la fase de madurez en la que la organización se encuentre. En cualquier caso, desde zylk creemos que la única forma de afrontar proyectos es siguiendo metodologías ágiles. Hay que definir proyectos que resuelvan problemas de negocio y tiene que estar en producción desde el primer día. Un proyecto que no llega a producción, se marchita, y se queda obsoleto en muy poco tiempo. Esto en cuanto a la visión metodológica. También hay una visión técnica y una visión filosófica de todo esto. Hace poco me leí el libro La salvación de lo bello en el que, en una de sus partes, se reflexiona sobre el concepto de conocimiento, verdad e información (http://www.zylk.net/es/web-2-0/blog/-/blogs/la-salvacion-de-lo-bello). Y por último, desde el punto de vista técnico, creemos que hay que empezar por capturar los datos y disponer de un sistema de procesado en tiempo real y luego ir subiendo hacia las capas de Analítica avanzada y Machine Learning. En cualquier caso todo dependerá del proyecto y de la organización.



Entrando en la parte técnica, y comenzando por la ingesta d información de diferentes fuentes, que definición y característica seleccionarías de Apache Nifi?

Hay varias cosas que destacaría de Apache Nifi, la primera es que para una persona versada en BI clásico los conceptos que maneja son sencillos de aprehender. Por otro lado es una herramienta muy versátil que implementa la mayoría de los patrones necesarios a la hora de implementar un sistema de ingesta omnichannel. Backpresure, circuit break etc... Además dispone de un modelo para despliegue en dispositivos propios de lo que se conoce como IoT (https://nifi.apache.org/minifi/), esto es fundamental para poder desarrollar proyectos Big Data alineados con el "Internet de las cosas"


Habéis implementado Microservicios, que buenas practicas recomendarías:

Hemos usado microservicios siguiendo las buenas prácticas definidas Martin Fowler http://www.martinfowler.com/articles/microservices.html. Las características principales que en nuestro caso nos interesaban eran, la elasticidad, resiliencia, autodiscover y la integración dentro de una plataforma de gestión de recursos. En nuestro caso lo que hemos hecho ha sido usar AVRO IPC + YARN para poder desplegar y desarrollar los microservicios dentro de un cluster típico de hadoop. Lo hemos hecho así para no tener que desplegar un sistema de containers basados Docker con Kubernetes o Mesos o cualquiera de estas soluciones. Lo hemos hecho así porque los microservicios que desarrollamos son necesarios para el tratamiento de los datos y por tanto creíamos que lo mejor era definir una arquitectura de los mismos consistente con la tipología de cluster que desplegamos.


Que planteamiento técnico habéis utilizado para el dimensionamiento y monitorizacion de la carga de los procesos en tiempo real?

Principalmente no perder datos. La idea es que el sistema va a fallar en algún momento, las cosas no siempre funciona y lo principal es evitar el efecto bola de nieve. Por tanto siempre montamos sistemas desacoplados y las llamadas entre los sistemas desacoplados usa el patrón Circuit Breaker (http://martinfowler.com/bliki/CircuitBreaker.html)

Para la monitorización lo que hacemos es integrar los desarrollos realizados con el sistema de monitorización del gestor del cluster, en la mayoría de nuestras implantaciones Ambari (https://ambari.apache.org/)

---------------------------------------------------------------------------

Agradecer a Gustavo Fernandez, a Iñigo Sánchez Méndez  y  Angel Barrio por compartir su experiencia en Big Data.




7M9A0107

12 junio 2015

DevOps - En el ámbito de operaciones, desarrollo y administración de sistemas.

Bilbomática, se encuentra analizando e  implementando DevOps a lo hora de ofrecer servicios innovadores y de valor diferencial  a nuestros clientes y socios tecnológicos.

DevOps aplica los principios de  Agile software developmentLean manufacturing, con objeto de aumentar la velocidad de entrega de productos y servicios, rentabilizando la inversión principalmente en tres áreas:

- Mejora de la experiencia de los clientes: Buscando una experiencia positiva, diferenciadora y atractiva respecto a la competencia.
- Mayor Capacidad de innovación: Alineando las necesidades de nuestros clientes con enfoques Lean, con el objetivo de aumentar la capacidad de innovación y trabajar en actividades de mayor valor.

- Rentabilidad mas rápida:  Bilbomática, en su búsqueda constante de la excelencia y como parte de la cultura empresarial de la compañía, que permita ofrecer calidad máxima en sus servicios y productos , dispone de las certificaciones Norma UNE-EN ISO 9001:2000, UNE-EN-ISO 14001 y  CMMi Level 3 desde Julio de 2014. Si le sumamos las buenas practicas aplicadas en el ámbito TIC y los procesos de automatización, permiten una entrega de servicios rápida, eficiente y fiable, cubriendo el ciclo desde el desarrollo hasta la puesta en producción. Garantizando la comunicación fluida con el cliente y su satisfacción.


Cabe reseñar que hay dos aspectos que se incorporan a la forma y método de trabajo de la compañía, como son el desarrollo colaborativo con integración continua y las pruebas como control de calidad (QA), avaladas por la formación específica en Testing de Software siguiendo el programa de estudios del ISTQB (International Software Testing Qualifications Board). Bilbomática ha certificado en los últimos dos años a más de 15 personas con el ISTQB Foundation Level y ISTQB Advanced Level – Test Manager.