54cuatro
En muchas organizaciones el análisis de datos demora mucho producto de la rigidez de los procesos y de la tecnología. #DataOps sirve para identificar y eliminar los cuellos de botella que ralentizan el desarrollo de los análisis de #datos.
[popup_anything id=”2076″]
Mucho se habla de los trabajos que se perderán por culpa de la automatización y la inteligencia artificial. Pero al dia de hoy las organizaciones se encuentran con un faltante muy grande de perfiles #DevOps/#DataOps y muchos otros tantos de negocios que acompañen el desarrollo de estas tecnologías. Conocen sobre #CitizenDataScientist, el nuevo puesto basado en datos que se esta gestando?
[popup_anything id=”2076″]
El ultimo mes estuve trabajando con varios clientes en proyectos industriales en Buenos Aires, Queretaro, Puebla, Monterrey y Saltillo, la gran cantidad de charlas y recorridas me parecieron una buena oportunidad para escribir una breve reseña de Industria 4.0 y todo lo que trae acarreado este nuevo concepto.
Historia y Concepto:
El concepto de #Industria4.0 nació en #Alemania, y suele ser mencionado también como cuarta revolución industrial, #ciberindustria o industria inteligente. Se espera que la industria 4.0 sea capaz de impulsar cambios sociales al nivel de la primera revolución industrial y las maquinas a vapor, la producción en masa de la segunda, y la electrónica e informática que prolifero en la tercera.
Mark Watson, director de #IHS lo describe de esta manera: “El desafío para la cuarta revolución industrial es el desarrollo de software y sistemas de análisis que convierten el diluvio de datos producidos por las fábricas inteligentes en información útil y valiosa.”
Detalle del significado:
La Industria 4.0 combina la infraestructura física propia de la fabrica tradicional con software, sensores, tecnología de comunicaciones, y analítica. Industria 4.0 viene siendo liderada por las automotrices y supondrá un nuevo modelo de manufactura orientados por la adopción de #IoT (Internet of Things) y #CPS (Cyber-Physical Systems). Esta integración generara cambios horizontales que afectaran a la cadena de valor y cambios verticales que irán desde la sensorización de los parámetros de cada proceso hasta el cambio en la ejecución de toma de decisiones; motivo por el cual, las tecnologías de Big Data cobran principal relevancia dado que son las que dotan de inteligencia a los sistemas que permiten detectar anomalías, predecir comportamientos, simular procesos industriales (y optimizarlos), generar procesos autónomos que incluso puedan contar con tecnología de aprendizaje.
Sabemos que las fabricas tendrán las siguientes características:
Las industrias existentes o nuevas que sean consideradas 4.0 deben tener un fuerte uso de sus datos. Usar sus datos significa convertirlos en informacion, y esa informacion en conocimiento. El conocimiento mejora la toma de decisiones sobre los negocios. La Industria 4.0 permite mejorar la calidad de los productos, optimizar en gran medida los costos, provocar una reducción del time-to-market e incrementar la seguridad en todos sus aspectos.
Recorriendo el camino hacia 4.0:
El camino de una fabrica entorno al concepto Industria 4.0 se basa en gran parte en la adopción de forma masiva de sensores que permitan controlar distintos parámetros de interés, monitorizando todo lo que se nos ocurra y junto a ello generando una gran cantidad de datos. El abaratamiento del costo de sensores hace pensar que incluso cada producto pudiera contar con uno incorporado. Actualmente una maquina compleja cuenta con miles de sensores que son leídos en mili segundos. A eso se le suma la gran cantidad de dispositivos IoT que crecen exponencialmente dia a dia y que generan millones de datos. Transformar una fabrica a un modelo 4.0 significa también adoptar los requisitos necesarios para poder procesar el gran volumen de datos que cada dispositivo genera y que se seguirán incrementando a lo largo de los años. Ademas los orígenes de los datos son de lo mas diversos, de manera que se tiene que tener en cuenta la complejidad que significa procesar datos con fuentes y formatos distintos en tiempo real para asociar y relacionar distintas variables para entender comportamientos que permitan armar predicciones. Reemplazar la toma de decisiones a un modelo guiado por datos fehacientes por sobre el modelo de toma de decisiones por intuición sera un gran paso en materia de disminución de errores y que traerá aparejado un significativo aumento de la calidad.
Realidad aumentada e Inteligencia artificial como motor del cambio:
Vale destacar que los cambios vendrán por otros medios como el del añadido de informacion virtual al entorno físico de una planta. Para ello la Realidad Aumentada cobra vital importancia. Podríamos visualizar un almacén y por medio de AR analizar el stock, tener visualmente detalles de productos, KPI, realizar simulaciones y muchísimos usos prácticos mas.
Un ejemplo practico de como la AR ayuda en la vida real, podemos ver el vídeo de VW y su software MARTA, que ayuda a los técnicos guiándolos cuando necesitan desarmar algún componente de un auto.
Con respecto a la validación y simulación de procesos de fabricación, la AR permite obtener planes industriales probados desde el minuto 0, lo que genera un proceso de manufactura optimizado, sin errores y seguro. Una gestión optima de la planta industrial permite aumentar la competitividad desde diferentes puntos de vista, como el ahorro energético analizando los patrones de consumo de cada proceso y permitiéndonos optimizar dichos procesos o adoptar fuentes renovables que permitan generar energía dentro de la planta a través de paneles solares, baterías, etc y reducir la dependencia de la red eléctrica.
Otro factor clave que lideran los cambios de la industria es la adopción de tecnología de Inteligencia Artificial. La definición del cofundador del laboratorio de AI del MIT Marvin Minsky es: “Es la ciencia de hacer que las maquinas hagan cosas que requerirían inteligencia si las hicieran personas”.
La AI debe ayuda a la toma de decisiones, entendiendo y analizando patrones que para un humano serian imposibles. Es por eso que resaltamos la importancia de Big Data y todos los componentes basados en algoritmos que debemos adoptar para conseguir tomar decisiones automatizadas y tener previsibilidad de comportamientos.
Para entender el uso practico de la #AI, podemos resumir el ciclo de uso de los datos asi: recoger los datos generados por #PLC y sensores para convertirlos en informacion, manejar esa informacion y explotarla desde sistemas de #BigData, y usar esa informacion para entender patrones y tendencias mediante #algoritmos.
Lógicamente que cuanto mas datos, mas informacion y cuanto mas informacion, mas herramientas a nuestro favor. Podemos dotar a las maquinas de un comportamiento de aprendizaje automático (#MachineLearning) y que a medida que avance el tiempo la maquina pueda entender esos patrones y tendencias para ejecutar acciones automáticas. De esta manera y para usar de ejemplo, una maquina podría reportar la presión de sus inyectores, eso generaría un entendimiento de la situación de la maquina y del proceso de fabricación como así también el control de calidad; y con el aprendizaje realizado basado en tendencias avisar sobre el agotamiento de alguna materia prima, disminuyendo de esa manera la parada de la maquina para ser recargada, mejorando #OEE y manteniendo estable el proceso de calidad preestablecido.
Los desafíos que vienen y su hoja de ruta:
Algunos desafíos claves en el proceso de adopción de Industria 4.0, son el análisis de millones de sensores generando datos, asegurar la inviolabilidad de esos datos generados, la trasmision de datos hacia servidores o nubes para su análisis (#5G sera un gran aliado de la expansión de la Industria 4.0 simplificando gran parte del proceso de trasmision) y finalmente la #ciberseguridad de todos los componentes ya que mayores dispositivos conectados son también mayores puertas de acceso que controlar.
Junto con los requisitos claves, surge el concepto de #PLM (product lifecycle management). Consiste en la gestión, a través de soluciones integradas de software, del ciclo completo de vida del producto, desde la concepción del producto con soluciones #CAD (Computer Aided Design), pasando por el análisis y la optimización del producto con soluciones #CAE (Computer Aided Engineering), llegando al análisis de cómo se va a producir y dar mantenimiento a este producto con soluciones #DMF (Digital Manufacturing) y capturando, reutilizando y compartiendo con cada uno de los actores del ciclo productivo toda la información generada en cada una de las etapas antes mencionadas con soluciones #PDM (Product Data Management).
En resumen, para transformar nuestra organización a un modelo de Industria 4.0, debemos considerar:
Para comenzar es necesario efectuar un assessment total de las fabricas, entender la situación actual e indice de maduración tecnológica y trazar una hoja de ruta con los requerimientos a implantar y como recomendamos siempre, empezar con cambios progresivos y que dichos cambios cuenten con el apoyo de las personas que son quien en definitiva son los promotores de los cambios de envergadura.
[popup_anything id=”2076″]
Nota publicada originalmente en Linkedin
Hace unos días, mientras esperaba en el aeropuerto, escribí una nota #Industria 4.0. Para seguir profundizando en el ecosistema de #I4.0, voy a hacer entradas complementarias para no hacer la entrada original muy larga.
En este caso para escribir sobre #EDGEComputing, o Procesamiento de Borde. Algo fundamental para Industria 4.0 y de lo que se esta hablando mucho.
Sabemos que la cantidad de dispositivos crece exponencialmente, y junto a ello la cantidad de datos que se generan (y que queremos analizar). Por tal motivo se empieza a hablar cada vez mas de Edge, y de un formato de arquitectura tecnológica donde el procesamiento de la informacion se acerca cada vez mas a los orígenes de los datos (datacenters descentralizados, lineas de producción, almacenes, robots, etc) para brindar una rápida respuesta en pos de obtener informacion de valor de los datos generados. Procesar en origen (o cerca de el) evita transportar los datos a centros de cómputos o proveedores de nube, disminuyendo sustancialmente su tiempo de análisis, realizando la tarea casi en tiempo real. Este es quizás el mayor beneficio, no solo por mejorar el procesamiento, sino también por generar un ahorro significativo del consumo de ancho de banda.
Algunos especialistas pronostican que Edge sera un nuevo modelo de procesamiento, AT&T lo definió como una supercomputadora inalámbrica.
Y es importante destacar que no se trata de elegir si #EDGE o #Cloud. Son ambas. Una arquitectura #IIoT (#Industrial IoT) de alto nivel debe considerar un modelo de que abarque el procesamiento EDGE y Cloud, para unir el mundo de las operaciones tradicionales (OT) con la TI empresarial. Macario Namie de Cisco deja una gran frase en esta nota: Uno de las mejores resultados de conectar “cosas” es el acceso sin bloqueos a datos en tiempo real. Lo siguiente es convertir esos datos en información, y lo que es más importante, acciones que impulsan el valor comercial. Al tratar de hacerlo, las empresas se encuentran saturadas de datos. Tanto es así que ha surgido la demanda de grandes necesidades de computo y almacenamiento, muy bien administrada por los proveedores de nube pública. Pero el costo del transporte y la velocidad de procesamiento también han aumentado, lo cual es un desafío para muchos casos de uso como los servicios de misión crítica.
El tema del trasporte es un detalle a considerar. En gran medida el avance de este modelo vendrá impulsado por despliegue de la red #5G, y todas las ventajas operacionales que esto tendrá aparejado como por ejemplo la baja latencia. #Cisco, #Dell, #Intel, #Microsoft entre otros armaron un consorcio llamado #OpenFog, para trabajar en el concepto de #FOG computing, una capa de red por debajo de las nubes que permita incrementar la conectividad del mundo.
Para simplificarla un poco: FOG tiene que ver con el transporte, EDGE tiene que ver con el procesamiento.
Para finalizar el post, me quedo con esta frase de Tony Antoun, SVP de GE Digital:
“Para habilitar la transformación digital, debe desarrollar el lado EDGE de la informática y conectarlo con la nube; es un viaje desde EDGE a la nube y viceversa”.
[popup_anything id=”2076″]
Nota publicada originalmente en Linkedin.
Alguien lo tenia que decir. Hablando con clientes, conocidos y amigos, creo que hay un poco de confusión respecto al concepto de containers y al de microservicios.
El container permite correr una app de forma isolada del sistema operativa. Una VM en cambio debe correr siempre un sistema operativo. En un contenedor el kernel y partes de la infraestructura del SO se comparten. Para la máquina virtual, se debe incluir un SO completo.
El #microservicio es la visión funcional de lo que estamos armando, y podriamos hacerlo en containers y también con #VMs. Los microservicios son conceptualmente la división de las aplicaciones en componentes pequeños e independientes entre sí. A diferencia de un enfoque tradicional y monolítico sobre las aplicaciones, en el que todo se crea en una única pieza, los microservicios están separados y funcionan conjuntamente para llevar a cabo las mismas tareas. Dada la historia de #SOA, los microservicios no son realmente tan nuevos como una idea. Sin embargo, los microservicios se han vuelto más viables gracias a los avances en las tecnologías de “contenedorización” (se dice asi???).
Acá es donde veo habitualmente un concepto erróneo. Tomar una aplicación #PHP corriendo en un #LAMP y subirla a #Docker es tan solo un #shift&lift. Tiene ventajas? Si, claro que tiene ventajas. Sacamos varios componentes del medio, dependencias de librerías, y la aplicación es mucho mas portable. Ahora, por hacer eso no convertimos nuestra app a microservicio.
Para que la aplicación sea un microservicio necesitamos transformarla. Mínimo que hable API.
Aquí viene el desafío. Un microservicio requiere mucho mas esfuerzo que resolver la parte técnica. Un equipo desarrollando microservicios necesita mucha mas autonomía para testing, seguridad, operación, etc, que el habitual modelo de silos instaurado en las organizaciones.
Melvyn Conway en 1967 dijo: “Cualquier organización que diseñe un sistema producirá un diseño cuya estructura sea una copia de la estructura de comunicación de la organización.”.
Haciendo foco en esa mención, y apoyado por este gráfico de Martin Fowler es que necesitamos realizar modificaciones organizacionales para construir aplicaciones como microservicios.
Tiene ventajas desarrollar en microservicios? Claro. Los microservicios son versátiles, se pueden portar de una instalación on-premise a cloud en segundos (y viceversa), son fáciles de escalar y de mejorar de forma constante, mejora las tolerancias a fallas. Pero también tienen contras. Por ejemplo, hemos visto que las pruebas integrales son mas complicadas, es necesario evitar la expansión sin control dado que son difíciles de gestionar y controlar, algo que puede ser minimizado recurriendo a procesos automatizados de orquestacion.
Mientras redactaba esta nota me tope con este manual técnico de Manuel Barrios sobre Docker. Para los sysadmin de la vieja escuela, les recomiendo la lectura.https://blog.mymware.com/2019/03/19/docker-desde-cero-p1.html
La idea de la nota no era desalentar el shift&lift, muy por el contrario, larga vida!
Entendiendo bien cada caso puntual tiene muchos beneficios que tienen que ver con mayor eficiencia, disminución de recursos de hardware, reducción de costos de licenciamiento, portabilidad y muchas otras ventajas.
[popup_anything id=”2076″]
Esta nota fue publicada originalmente en Linkedin
Ya es sabido que es #DevOps. Un movimiento cultural combinado con una serie de prácticas de desarrollo de software que permiten entregar productos finales de forma rápida.
DevOps tiene pilares fundamentales como son la comunicación, responsabilidad, respeto y confianza de los miembros de un equipo.
El uso de herramientas y flujos de trabajo aptos para DevOps puede ayudar a su equipo a trabajar de una manera más DevOps “friendly”, pero es crucial crear una cultura que respalde el ideal del movimiento.
Analizando algunos ideales, entendemos que el foco está en el producto. Un equipo DevOps trabaja sobre el rendimiento del producto en todo su ciclo de vida, discutiendo los requisitos, las características, los cronogramas, los recursos y la cantidad de datos que podrían surgir, y genera objetivos conjuntos.
Esos Objetivos medibles comunes pueden ser:
Estos objetivos tienen un impacto monetario en su negocio, ya que le cuesta mas horas-hombre cuando el software tarda mas días de lo planificado en ser liberado. Le cuesta ingresos cuando el producto no está disponible para el uso de sus clientes. Aumenta su costo operativo por ejecutar su infraestructura de manera poco eficiente.
Tomando lo que sabe sobre estos valores, puede poner un valor monetario para mejorar cualquiera de ellos.
Su #stakeholder estará interesado en los objetivos mensurables que haya desarrollado.
Los objetivos nos permiten fijar metas.
Recuerde que DevOps es un nombre inapropiado: lleve DevOps más allá de los desarrolladores y las operaciones, para incluir aseguramiento de la calidad, servicio al cliente, personal comercial y liderazgo ejecutivo si es posible.
¿Necesitamos ser 100% Devops?
Tal vez no. DevOps es arriesgado para aplicaciones heredadas y organizaciones establecidas. Quizás deba mantener estos dos modos de operación separados según la aplicación. Tal vez necesitamos un sistema híbrido como el modelo definido por Garnet como IT Bimodal.
#Gartner describe a #IT-Bimodal de la siguiente manera: es la práctica de administrar dos modos separados y coherentes de entrega de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y la precisión. El modo 2 es exploratorio y no lineal, destacando la agilidad y la velocidad. ¿Necesitamos ser 100% DevOps? Quizás no, pero de una forma u otra, se necesita hacer cambios, fundamentalmente romper con los silos y mejorar la productividad.
(Producto = Tiempo + Recursos)
Hay dos formas de aumentar la productividad. Disminuir los tiempos o aumentar los recursos.
Se alienta a los sectores de desarrollo a reducir los tiempos de desarrollo. Y se alienta a los sectores de Operaciones a mantener la productividad. Estos incentivos no son compatibles entre sí.
DevOps debería ayudar al negocio de la compañía a actuar por igual sobre los responsables del tiempo y los recursos.
El desafío para cualquier compañía es tener diferentes equipos que funcionen como uno solo.
Y en ese marco es importante gestionar el Estancamiento y Obsolescencia. Las organizaciones deben asegurarse que los sistemas de información con los que trabajan estén en un proceso continuo de actualización de los componentes. Es por ello que se debe crear un plan de obsolescencia.
La tendencia actual de IT, es tener todo definido como servicio. #IaaS, #PaaS, #SaaS. Todo será definido por el software. Los sectores de infraestructura deben superar el desafío de la transformación. El modelo de infraestructura actual está orientado a servicios y no a la granja de servidores. “El software se está comiendo el mundo”.
¿Cómo llevar un desarrollo obsoleto y estático a un modelo DevOps?
Una forma de actualizar una aplicación obsoleta es dividir las funciones en microservicios. Un microservicio debe hacer una sola cosa, pero debe hacerlo bien.
Los microservicios son simples, fáciles, pero es necesario mantenerlos estrechamente controlados y tomar precauciones para que no haya creación descontrolada de microservicios en toda la compañía.
Tener una entrega continua ayuda a las empresas a mantenerse alineadas con el objetivo de tener un producto de acuerdo con los requisitos del mercado, gracias a la reducción del tiempo de lanzamiento al mercado.
Y si algo funciona, hay que seguir mejorandolo. No importa qué tan bien funcione un sistema, siempre se puede mejorar. Mejorar y aprender nos ayuda a tener un sistema “vivo” que se adapta mejor a las demandas del negocio.
Mucho se habla acerca de Herramientas DevOps. Pero… ¿Cuáles son herramientas DevOps?
No existe un método de implementación de herramientas DevOps. Cada uno debe crear su propia caja de herramientas, pero debe centrarse en la automatización. Es importante lograr que cualquier tarea repetitiva sea automatizada. Automatizar aumenta las capacidades de los sistema, reduce las fallas, reduce el tiempo de ejecución y principalmente, puede medirse.
Que se puede automatizar?
Lograr el despliegue automático tiene grandes implicancias en la reducción del time-2-market, en reducir la fricción entre desarrollo y operaciones, permite un rollback de manera rápida y disminuye en gran medida los downtimes provocados por fallas.
Para el control de funcionamiento y fallas, es necesaria una gestión inteligente de eventos ayuda a identificar problemas, errores y posibles desviaciones en el funcionamiento de un sistema. Esta informacion, junto a la medición de rendimiento nos permite medir la capacidad de los recursos para cumplir los objetivos establecidos y saber qué tan bien estamos utilizando nuestros recursos. Y junto con saber sobre la utilización de los recursos, es importante realizar la planificación de capacidades de nuestra plataforma. Conocer el uso de los recursos (y optimizarlos), proponer alternativas tecnológicas, analizar el cumplimiento de SLA, listar riesgos y principalmente aumentar la alineación entre negocios y tecnología.
DevOps nos permite aumentar el ROI. Porque? Porque en muchas casos nos permite reutilizar infraestructura o aprovechar las ventajas de plataformas más elásticas que se adaptan mejor a la estrategia de la empresa. La nube ofrece un concepto de “pago por uso”, lo que se traducido a gastos permite un ahorro en costos y convertir CAPEX en OPEX.
¿Que se puede esperar a corto plazo en materia de DevOps?
Creo que es importante llevar la conversación de DevOps más allá del ámbito técnico. Participar a la cadena de negocios completa para entregar valor de extremo a extremo. Esto incluye grupos como marketing, ventas, finanzas, legales, recursos humanos y más. Involucrar a estos grupos tan pronto como sea posible en el proceso ayudará a las organizaciones a construir mejores soluciones, al tiempo que evitarán los retrasos que se suelen generar por la burocracia del propio funcionamiento de silos verticales tradicionales.
Actualización 31/05/2019: esta nota fue publicada en #Infotechnology, mi ultima nota como #CTO de #Nubiral antes de emprender www.54cuatro.com
[popup_anything id=”2076″]
Este articulo fue publicado en linkedin
#Agile, #DevOps, #Cloud, #Microservicios, pusieron en foco optimizar el Time to Market (o sus derivados #TTM, #T2M, #Time2Market).
El TTM se relaciona directamente con la velocidad con la que un producto puede ser lanzado o en el caso de la tecnología, en la rapidez con la que se puede entregar valor (ya sea un nuevo producto, una nueva característica de algo existente, una mejora, etc).
El TTM es importante por motivos varios. En la actualidad, los clientes, tanto internos como externos, se han vuelto más exigentes. Exigen mayor calidad y mayor velocidad. Es también importante porque la agilidad con que se crean nuevos productos, se agregan nuevas características o se genera valor es un diferencial respecto a competidores más lentos, por lo tanto, una ventaja competitiva.
Focalizando en lo que hace a productos tecnológicos, años atrás cuando el modelo de desarrollo estaba basado en una metodología de cascada, los ciclos de vida de desarrollo eran muy altos, lo que generaba cancelaciones de proyectos, mayor tasa de errores, y hasta la depreciación de lo que se estaba construyendo antes de conocer la luz. Todo esto representaban perdidas económicas significativas.
En la actualidad, con metodologías ágiles de trabajo y la automatización de las cadenas de desarrollo, se logró que la entrega de software sea más rápida y regular, lo que genere una ventaja competitiva, aumentando la calidad y optimizando tiempos, algo que se torna importante tanto para el #Time2Market como para la optimización del #ROI, promueve la mejora continua y por lo tanto existe un notorio aumento del rendimiento y la rentabilidad.
Optimizar el TTM trae aparejado aspectos muy positivos. Al tener toda nuestra cadena de desarrollo automatizada, es más simple recolectar los resultados del testing, e incluso del feedback de los usuarios, lo que permite no solo mejorar la calidad del software sino incluso re-adaptar las estrategias empresariales. También, a partir del desarrollo SOA y ahora Microservicios, se logró reducir la tasa de errores, ya que desarrollos chicos suelen tener menos complicaciones que aquellas implementaciones gigantes (monolíticas) que requerían muchos cambios, muchas personas, mucha burocracia.
Resumiendo: la capacidad de entregar desarrollos de forma ágil, cumpliendo con estándares de calidad, eficiencia y seguridad, nos permite crear valor en las compañías, mejorar los costos operativos y marcar diferenciales competitivos de mercado que se terminan traduciendo en mejor imagen de la compañía, mayores ventas y ahorros operativos.
[popup_anything id=”2076″]
El concepto de contenedor no es nuevo. Desde hace muchos años existe la creación de contenedores en sistemas corriendo #Solaris, #HP-UX o #AIX. Ahora parece que la contenerización sobre Linux llegó para quedarse a partir de buenas herramientas como #Docker o RKT.
Para diferenciar ambos modelos de virtualización podemos aclarar que en un entorno virtual se debe instalar un servidor físico con un #hypervisor, que dentro contendrá máquinas virtuales cada una con su sistema operativo corriendo.
En el caso de un entorno mediante #contenedores, el servidor físico ejecuta un solo sistema operativo que será compartido con la cantidad de #containers creados. Cada container hace uso del núcleo compartido del sistema con modalidad de “solo lectura”.
En la práctica los contenedores son más livianos, fáciles de administrar y consumen menos recursos que una vm.
Mientras que un container solamente lleva instalado sus aplicaciones particulares, una virtual machine lleva encima todo un sistema operativo instalado.
De esa manera, en un equipo físico se pueden agrupar muchos más contenedores que máquinas virtuales.
A nivel funcional, usar contenedores permite mucha flexibilidad para el escalamiento de recursos, y por otro lado la administración se ve simplificada al tener en un solo kernel toda la plataforma de software de base, dependencias y demás componentes.
La respuesta es sí. Para cada solución que se busque se debe analizar que conviene. Mientras que para algunos entornos es más apropiado un container, en otros casos la vm es lo apropiado.
Los contenedores suelen tener asociada la impresión de que ante una falla en el sistema operativo host, todos los contenedores se ven afectados, lo que es una realidad. A nivel seguridad en caso de verse comprometido un único sistema operativo, se vería afectado la totalidad de los containers.
De todos modos, los containers existen hace mucho tiempo y tienen larga vida por delante. Muchos artículos suelen enfrentar la tecnología de containers contra la tecnología de virtualización sobre hipervisores. En nuestro modo de ver, creemos que no son competencia sino más bien un complemento uno de otro y que incluso podrían optarse por tener ambientes mixtos.
Por mencionar el caso, Microsoft anuncio que la versión de Hyper-V disponible a partir de Windows Server 2016 permitirá la creación de containers, lo que es un claro mensaje que ambas tecnologías pueden convivir y entre ambas poder brindar soluciones a necesidades cada día más complejas.
[popup_anything id=”2076″]