 Bueno, voy a comenzar, que ya estamos 10 minutos atrasados, entonces mejor ya comenzar. Bueno, ¿quién no aquí conoce DevOps? O ya escuchó hablar. ¿Y quién está aquí para aprender DevOps? Ah, muy bueno, fecal. Bueno, mi charla va a ser para enseñarte cómo comenzar con DevOps. DevOps es un proceso muy, demora más de un año, en fin, es un proceso un poco difícil. Entonces esta charla es orientada para pasar las experiencias que nosotros tuvimos al implementar DevOps hace menos de un año atrás. Y para mostrar un poco sobre de dónde viene DevOps y qué es exactamente. Bueno, antes de comenzar, mi nombre es Sebastián Ferrari, trabajo en Taller, como director DTI. Soy cofundador también, cuando comenzamos Taller. Y quería hacer un aviso antes de comenzar, que voy a tocar sobre algunos asuntos y algunas marcas. Y capaz que puede ser un poco confuso. Y bueno, no estoy aquí para hacer ningún tipo de propaganda. Voy a hablar sobre algunos as, sobre algunos software como servicio. No es que realmente esos sean los mejores o es lo mejor que hay en el mercado ni nada, simplemente es un tipo de recomendación. Algunos ya lo hemos probados, hemos tenido problemas con otros, lo hemos cambiado por otros. Entonces voy a hablar un poco sobre eso. Y otra cosa es que, ¿por qué utilizar SAS? ¿Por qué voy a hablar sobre software that serves? Porque el objetivo aquí es enfocarte en tu negocio. Y no enfocarte en cómo hacer toda la infraestructura, cómo automatizar todos los procesos y todo ese tipo de cosas. A veces es mejor y es más barato, vos pagar una mensalidad por un servicio y vos ocuparte de lo que vos sos bueno haciendo. O sea, de lo que es tu negocio. Otra cosa, disculpen por mi español. Hace un tiempo que no lo practico. Vio hace 8 años en Brasil. Entonces, está medio gastado ahí. Bueno, entonces, una de las cosas por qué usamos SAS es porque queremos ser una line start up. Y uno de los fundamentos de ser una line start up es vos utilizar recursos que te diminuyan cualquier tipo de desperdicio y cualquier tipo de custo extra que vos tengas en tu operación. ¿Quién conoce line start up acá? Para quien no conoce, hay un libro que se llama line start up, que es muy bueno. Te va a abrir la cabeza para muchas cosas. Al adoptar cosas nuevas, uno tiene que aceptar un poco de riesgo. Porque son cosas nuevas, uno no conoce, no tenés todo el mundo conociendo exactamente cómo funcionan. Entonces, tenés un poco de riesgo. Pero el tema es que el riesgo es uno de los patrones que tenemos para el éxito. O sea, si vos no arriesgas, es aquel dicho. Si quien arriesga, no gana. Y bueno, eso vale para la innovación. Entonces, cuando vos querés innovar, tenés que aceptar el riesgo y tratar de diminuirlo al máximo. ¿Y cómo se hace eso? Aprendiendo de las experiencias de otras personas. Para que vos no tengas que caer de nuevo en el mismo problema. Bueno, ahí voy a empezar a explicar un poco por qué DevOps. Al principio, cuando estábamos trabajando con Drupal y otras tecnologías, nos vimos en un tipo de caos. Todas las máquinas eran diferentes, teníamos problemas bugs que aparecían de la nada y no sabíamos por qué. Porque mi máquina estaba funcionando, en fin, ese tipo de cosas. Y no teníamos registrado exactamente cómo estaban aquellas máquinas. O sea, cómo aquella máquina estaba funcionando en aquel momento. Y el problema es que todos los proyectos tienen una dependencia intrínseca entre su infraestructura y su configuración y instalación de sus offers. Entonces, a veces, cuando queríamos hacer un nuevo deploy y un nuevo servidor, no sabíamos exactamente cómo recrear todo ese ambiente. Entonces, voy a presentar algunos de los problemas para ver si ustedes se identifican. Entonces, tenemos algunos de los top 10 problemas. Uno de ellos es el más común de todos. Aquel de mi máquina funciona, lo mandaste para producción y chao. Pero ahora es el problema del otro tipo. Ya no hay más problema tuyo. Y eso es por causa de que tenés diferencias entre los ambientes. Y estoy contando ambiente local. O sea, tu ambiente donde vos desenvolves es también donde vos desarrollas. He explicado bastante bien. El señor de mi máquina, no sé. Bueno, falta de estanderización en las soluciones implementadas. Cada vez que creamos un proyecto nuevo, medio que como que recreamos todo de nuevo y aprendemos que aprender todo de nuevo. O sea, si tenés una empresa un poco grande, a veces se pierden esas experiencias que uno va teniendo y no se reaprovechan. Entonces, por eso es importante tener un poco de estanderización. Desperdice de experiencias acumuladas, que es lo que acabé de decir. Entonces, a muchas experiencias que aprendemos a veces, simplemente por una falta de comunicación entre los equipos, el otro no sabe cómo resolverlo. Siendo que en la empresa ya fue resolvido eso. El costo alto para creación de infraestructura es esto. Yo soy este tipo y este es el cliente. Y entonces siempre es lo mismo. El tipo va y gasta para crear nuevas máquinas y hacer instalación y configuración. Y es siempre lo mismo y siempre lo mismo. Y para nosotros eso es como tirar dinero al piso porque hoy en día no tenés por qué más hacer ese tipo de cosas. Hoy podemos automatizar todo eso. Entonces, una de las cosas que pasan bastante también es que como la infraestructura no es tan bien con nosotros. No es tan conocida por los desarrolladores. A veces refactoring, mantenimiento, desarrollo, generan bugs y atrás. O sea, cada vez que queremos hacer algo en el sistema, tenemos aquel miedo para ¿será que se va a romper? ¿Por qué no tenemos test automatizado? No tenemos como saber si lo que acabé de hacer va a romper una cosa que le hicimos allá en el principio. Porque nadie lo usa a veces. Pero el cliente es experto en eso. Él siempre va a testar la cosa que vos nunca viste que no está funcionando. Entonces, de alguna manera tenemos que garantizar eso. Bueno, esto pasa bastante. Tenés una nueva funcionalidad, pero está vestida de un bug. Y bueno, el mantenimiento parece que estás en una enterprise, en una nave espacial, que ya no sabe más cómo arreglar las cosas, no sabe cómo mantener eso. Y a veces tiene que contratar especialistas que saben cómo hacerlo y centralizar ese tipo de conocimiento. Y ahí se crean esas islas de conocimiento. Ah, solamente Fulano sabe, se arma ese gurú, esa aura. Que solo él sabe cómo manejar ese tipo de servidores, ese tipo de cosas. Deploi caro, peligroso, lento y de baja frecuencia. Eso es crucial. Deploi caro no debería acercar. Deploi debería ser totalmente frecuente. Todos los días por lo menos tres deploi deberías hacer. Y bueno, hoy puedes sentirlo tipo así, un deploi. Cada vez que alguien dice, bueno, vamos a hacer un deploi, ya llamas a tu mujer. Y se dice, bueno, hoy no voy a llegar a casa. Ya sabes que todo el mundo ya entiende. Todo el mundo entiende que deploi y viste, ya es así. Bueno, costo alto para replicación de ambiente. A veces, por ejemplo, queremos medir hasta dónde nuestra aplicación va. Antes de ponerla en el aire. Y el problema es que esa infraestructura es carísima. Es una súper infraestructura de producción. Y para replicar eso para hacer un test de carga, te puede llevar el doble de lo que era antes. Porque ahora lo vas a hacer de una mejor manera. Entonces, ese tipo de replicación de ambiente. No estoy hablando solamente de escalación aquí, de tipo de escalar. Tenés más ambientes para poder escalar tu aplicación. Estoy hablando de replicar. Entró una nueva persona en el proyecto. Tiene que bajar todo el ambiente, instalar, configurar. No sé qué hizo, demora bastante. Y ahí, ¿dónde empieza la diferencia? Entonces, no debería ser una cirugía. Eso no es una ciencia de foguette que es difícil. No existe monitoración podreploy. O sea, es como andar en la acuridad. Y de repente te encontrás con que se cayó y no sabes ni de dónde vino eso. Entonces, la monitoración podreploy es muy importante. Porque es como andar en la calle sin ninguna luz. O sea, no sabes qué hay para adelante. Y a veces no tenés ni como prevenir eso. Muchas veces nosotros, gracias a... Nosotros usamos New Relic. No estoy haciendo propaganda, ya dije. Es que lo usamos porque bueno. Pero hay otros. Hay otros buenos también. Y a veces vemos que está así, ¿viste? Y ya sabes que de raquipoca se cae el servidor. Pero lo ves antes, ¿viste? Entonces, ese tipo de visibilidad vale mucha plata. Esto es otra de las cosas cruciales. Y ahí donde voy a tocar sobre el asunto de la cultura. Los equipos no tienen ninguna libertad. A veces contra el equipo de infraestructura. O sea, vos ves un deservolvedor. Sí, viste chiquitito. Me gustaría instalar MongoDB. ¿Qué? MongoDB. ¿Estás loco? Nadie conoce MongoDB. No está probado. Es horrible. Entonces, ese tipo de atrito no debería existir. Además, un trabajo en equipo. Bueno, vamos a intentar MongoDB aquí. Vamos a arreglar un poco. Pero vamos a aprender juntos. Bueno. El chiste de siempre, ¿no? Funcionó bien en DEV. Ahora, el problema del equipo de operación. Entonces, se genera esa lucha entre los equipos. Horas dedicadas a tareas repetitivas donde el error humano tiene a crecer de forma exponencial. Por la deuda técnica. Esto explica muy bien por qué nosotros necesitamos DevOps. Nosotros necesitamos automatizar cualquier tipo de cosas que el humano se puede equivocar. No podemos perder más tiempo en eso. El cliente no puede continuar pagando para vos e ir a instalar todo nuevo y configurar y ver a ver si hay un problema o descubrir un problema de la nada. Tenemos que ser más eficientes. Y bueno, ahora humana debería ser aprovechada para crear y no para hacer procesos repetitivos. Tenemos las máquinas para eso. Y lo hacen mejor que nosotros. Porque lo hacen siempre igual. Y bueno, ustedes conocen ese tipo. Pero ustedes pasan por esos problemas. ¿No? Bueno, nadie quiere decir. Y bueno, si te encuentras así, te aprecen todo DevOps. Pero DevOps no es una persona. No es un cargo. No es una herramienta que voy a usar. No es un... voy a usar las herramientas DevOps. No es eso. Primero que DevOps se originó de un evento que se llamaba DevOps Days. Era un evento donde los desarrolladores y la parte de operaciones de infraestructuras se reunían para discutir y presentar cosas de automitación y cómo resolvían los problemas en conjunto. Y ahí eso, bueno, fue un buzzword y se compartió para todo el mundo. Y bueno, ahí quedó DevOps. Entonces, DevOps puede ser visto más como un movimiento, como una cultura. Puede ser llamada hasta una metodología. Es trabajo en equipo. Es trabajar en equipo. Es una de las partes del ágil. Es el arte de aumentar la eficiencia y la calidad. Es muy importante eso. Bueno, como dije, es un movimiento y es una revolución. Ahora voy a explicar un poco de mejor también porque es una revolución. Para dejar bien claro, la persona de operaciones es la persona que se encarga de infraestructura. Son las personas que se encargan de cuando cae el site, cuando cae el portal o algo así. La primera cosa que hacen es llamar al tipo de operaciones. No llaman al desarrollador. Eso pasa después. Pasa después, después que todo el mundo se empezó a hacer finger point y me diste tipo fue él, fue él, fue el desarrollador, fue no fue operaciones. Y el cliente se está ahí esperando a ver cómo va a arreglar. Bueno, DevOps para hacer un poco más amplio envuelve algunas áreas. La área de desarrollo. La área de que hay. Que ahí envuelve la parte de test automatizados en fin. Y la parte de operaciones. Entonces engloba todo eso. Intenté resumir un poco sobre por qué DevOps. Y es porque automatizar todo lo que no agrega valor para el cliente. O sea, si yo estoy parado. Configurando de nuevo el apache. No estoy agregando valor. Estoy agregando valor cuando hago un deploy y le entrego código a mi cliente. Ahí sí estoy agregando valor. Entonces automatizar todo lo que no agrega valor para el cliente aumentando la eficiencia, calidad y previsibilidad de las entrega. Nosotros vivimos, trabajamos en un mercado donde la previsibilidad es crucial. Nosotros necesitamos prever más o menos cuando que podemos entregar las cosas. Eso es lo que va a pasar. Ese tipo de previsibilidad es lo que nos da la mayor acertividad para nuestros estimativos. Este es el ciclo de DevOps. Entonces... ¿Cómo? Está en el teléfono. Está en el teléfono. Entonces todo empieza aquí. Primero planificamos si ustedes... ¿Aquí nos usa Agil aquí? O algo relacionado a Agil. Por favor, comiencen. Por lo menos a ver cómo es. Bueno, entonces empezamos a planificar junto con el equipo, todo el mundo juntos y eso. Después, bueno, nos ponemos a codificar. Después hacemos el primer build. O sea, casi el primer release. Lo testamos. Después hacemos el release y pasó todo bien. Aquí podemos tener, no solamente este automatizado. Tenemos este de exploración, por ejemplo. Generamos el release, hacemos el deploy. La parte de operaciones se va a encargar. Si necesitamos en este próximo deploy necesitamos un varnish o necesitamos un DVD o un Redis o alguna cosa así. Ellos se deben encargar de eso. Y la parte de monitoración. Y ahí, ¿no? Es un ciclo alternativo, ¿no? Y bueno, pero es muy lindo hablar sobre eso. Sobre cómo funciona y eso. ¿Será que funciona? Y bueno, todos los años hay un DevOps status report. De la Puppet Labs. Después, yo les muestro eso. Tengo un link ahí con todo el reporte que lanzan todos los años. Y ellos todos los años tienen el mismo resultado. Entregan 30 veces más frecuente en el mismo tiempo. Entonces, si en una semana vos entregas una vez, ahora en una semana vas a pasar a hacer 30 veces. Eso es muy buenísimo. Porque estás entregando valor a tu cliente mucho más rápido. Y podés medir mejor si aquello que le entregaste realmente le está dando valor a él. Entonces, bueno, para vos y bueno para él. Bueno, esto es una de las por qué también nosotros estamos usando DevOps. Es porque antes estábamos aquí, ¿no? Nuestras estimativas estaban allá, ¿viste? Y ahora con DevOps tenemos 8000 veces más rápido. 8000 veces más rápido. Eso es muy gritante. Y es todos los años, todos los años lo mismo. Todos los años lo mismo. Y los bugs diminuchen 50%. Eso es una de las otras cosas cruciales de que tipo a veces muchos de los bugs son generados por mal configuración de producción o de station o algo así, ¿no? O hasta también de local. Porque funciona en la maquina de él y bueno, lo mando para producción y en fin el mismo problema de siempre. Y no en el ambiente de donde fue testado y todo eso, ¿no? Entonces, DevOps diminuye eso bastante, ¿no? Y hay que acordarse de que los bugs son exponencialmente más caros con el pasado del tiempo. Entonces, si vos tenés un bug que nadie lo vio y pasó un día él es mucho más caro ahora. Entonces, cada vez que pasa el tiempo más caro es para realarla. Y bueno, ¿por dónde comenzar? ¿No? Por eso que es esa charla, ¿no? Pero primero, lo más importante es la cultura y principios. Pero eso no viene solamente de DevOps. Eso es algo, ¿no? Eso es algo del ágil. Pero la cultura es muy importante porque vos podés poner todas las herramientas pero si no existe la cultura de entender de que existen riesgos de que existen momentos donde las cosas no van a funcionar de la manera como se está tan esperando tenemos que tener un equipo consciente sobre esos desafíos para mejorar. Y no simplemente hacer... hay un... en Brasil le dicen mimimi que mimimi es tipo mimimi tipo te estás quejando siempre porque no funciona, no, no, no pero no es solamente eso. Tenés que ayudar a la gente. Tenés que ayudar a tu compañero a poder pasar por esas barreras. Porque no es fácil, no es tan fácil. Y también una de las culturas que viene de Ansible de hacer SSH en tus máquinas entrar y hacer una cantidad de cosas no le decís a nadie, ¿viste? Entonces después nadie sabe qué es lo que pasó, ¿cuáles son las configuraciones que están en ese video? Entonces lo mejor es hacer un Ansible Playbook. ¿Quién conoce Ansible aquí? Bueno, Ansible es como Puppet o, bueno, no sé si conocen pero es un sistema de generizamiento de configuraciones. Y queda en código. Entonces lo puedo versionar. Se lo puedo mandar a la parte de operación. Le digo, mirá, solamente corre esto que está todo bien. Entonces, como decía, DevOps hace parte de Lean y, bueno, de Lágin. Entonces, no es una cosa nueva. Es simplemente un pedacito donde dos equipos tienen problemas que es el equipo de operación y el equipo de desarrollo tienen algunos problemas y bueno, entonces por eso es que DevOps, ¿no? Pero en verdad viene todo de Lean y Lágin que es detectar desperdicios y generar procesos para aumentar la eficiencia. Entonces, como dije, concentrarse en el valor. Es el arte de detectar el desperdicio. Y bueno, ¿cómo se detecta un desperdicio? Tenemos la primera cosa que tenemos que hacer es mapear porque necesitamos encontrar este desperdicio. Entonces, esto es Value Mapping. Es un mapa donde tengo aquí lo que genera valor y aquí es totalmente desperdicio y esto es el tiempo, ¿no? Entonces, cada vez que vos tenés a tus desarrolladores esperando o tenés a tus clientes esperando o ese tipo de cosas, no estás agregando valor, ¿no? Entonces, vos necesitás mapear esto y esto viene del sistema de Toyota de la fábrica, de cuando hicieron Lean y eso. Para saber dónde están los desperdicios. Agarraban un papel y salían por la fábrica por toda la línea de fabricación, salían con un papel y salían anotando. Aquí demoró tanto tiempo, la pieza quedó aquí parada tanto tiempo, y por así, midiendo, sabiendo cuánto tiempo está haciendo enfocado para valor y cuánto tiempo para desperdicio. Una vez que detectar esos desperdicios tenés que empezar a ver en conjunto con tu equipo cómo se va a resolver y bueno, ahí hay que entrar la cultura de automatización, ¿no? Y bueno, también que viene del sistema de Toyota, que es el Hidoka. ¿Qué Hidoka significa automatización? Con un toque humano, no es simplemente automatización burra que está siempre automatizando, automatizando. Mimo estando mal equivocado, está ahí automatizando, automatizando, generando desperdicio, no. Tiene que tener un poco de toque humano. Entonces, por ejemplo, los test automatizados es exactamente lo que lo muestra bastante bien. O sea, tenés el otro, que está del otro lado de la máquina, que lo pasa automatizando y este que dice, pa, esto está equivocado, y este ahora está haciendo, esta persona es el overload. Esta persona ahora está sobrecargada con todas las, no solamente con hacer alguna cosa, sino que está ahí seleccionando y en fin, ¿no? Entonces, no es un trabajo muy en equipo. Entonces, lo que dice Hidoka es que vos tenés que tener una máquina y ya detecté un problema y paré. La línea entera. Todo el mundo se tiene que enfocar en eso, en resolver ese problema. Ahora, esa prioridad en este momento. Bueno, algunas herramientas para comenzar, Gitflow, Git Hooks para poder automatizar cuando haces un commit, por ejemplo. Tenés un pre-commit que lo que hace detecte corre algún tipo de proceso para detectar problemas en el código y ese tipo de cosas. Entonces, automatizados, antes de ir para repositorio. Build Scripts para generar los builds. Beanstalk, nosotros estuvimos usando. Tenés Acquia, Panteón, en fin, hay una cantidad. Estamos sacando foto, ¿eh? Bueno, nosotros usamos, ahora estamos usando Strider CD. Es una herramienta de Continuous Delivery, H&Hab Script, entonces es muy innovadora, hay muchos nuevos. Y tenés Sarko CI, que es bastante parecido con Strider CD, pero este es un proyecto opensource. Entonces, podés bajarlo, modificarlo, hacer plugins, podés salir de la, de la cura, ¿no? Codyship, también. Vagrant para poder automatizar tus ambientes. Ansible, como dije, Ubuntu Juju, que después voy a hablar un poco aquí sobre eso. Padums es uno de los productos que nosotros hicimos para hacer como comportamentales, usando, bueno, VDD, en fin, usamos Cocumber, como motor para eso. Y, bueno, tenés Behat, que es una versión de Cocumber, por ejemplo, pero en PHP. Algunas prácticas básicas para comenzar es tener algunos ambientes. Entonces, tenés tu ambiente local, que es considerado inestable, porque estás trabajando en él todo el tiempo, ¿no? Integraciones contantes, puede ser un ambiente de dev, donde todos los desarrolladores tienen ese ambiente en común para hacer las integraciones. ¿Qué ha? Que es un ambiente de validación, donde, bueno, hay una persona o algún tipo de proceso, automalizado, corre encima de ese ambiente para poder testar el último push que vino, por ejemplo. Stage es uno de los únicos ambientes, lo que hace es agarrar todo lo que está en producción y lo trae para ese ambiente stage y ahí se corren todos los tests y se hace todo el merge de toda esa aplicación. Lo que hacemos en ese momento con Stage es intentar prever un poco el futuro, o sea, intentar controlar un poco tu futuro. O sea, ¿qué va a pasar cuando ponga todas mis cosas nuevas en producción? ¿De forma será que vamos a tener algún problema con una otra future que no estábamos viendo? Porque vos tenés que entender que cuando estás sin producción tenés contextos que en otros ambientes a veces no los tenés. ¿No? Y no vas a estar llevando todo el banco de datos de producción para todos los ambientes, una locura es eso. Y bueno, ahí tenés el ambiente de producción, ¿no? Que es el ambiente más importante, o ella es un poco diferente y tenemos algunas otras columnas. Pero es más, simplemente para ustedes tienen una idea de cómo es un workflow donde haces desplodes diarios. No va a tener todas las cosas para hacer, los impedimentos, improgres, que las cosas que están siendo hechas, las cosas para tests, tests improgres, está resolvido, se va para el cliente. El cliente lo aprueba, lo aprueba automático. Entonces es una cosa que entra, entra otra y va, entra otra y va, ¿no? Y otra cosa importante son estos numeritos que es tener este límites. A veces, tener más de cuatro tests siendo hechas al mismo tiempo es una cosa muy mala a veces. Porque la gente no está focando sin resolver a veces un problema que es uno de los problemas una manguera de agua. Cuando vos pones el dedo, apretas un poco, limitas un poco, os sale más rápido. Es el mismo concepto. Bueno, entonces, un trae continuo diminuye mucho el riesgo. Entonces, este gráfico explica bastante bien una diferencia con Waterfall, que no es en cascata. Y bueno, entonces, cada vez que vos haces un deploy de aquí, estás diminuyendo un poco el riesgo porque estás viendo qué es lo que está pasando. En este momento, bueno, estás esperando una cantidad enorme de tiempo para ver exactamente qué es lo que está pasando. Cuanto más tiempo, más cosas tenés para poner en el aire. Entonces, más riesgos tenés. La cultura de monitoración, y bueno, como dije, si no tenés monitoraciones, es como ir dirigiendo de noche con el luce apagado. Simplemente es. O sea, no podés andar así. No podés tener tu ambiente de producción sin ningún tipo de monitoración. ¿Cómo está tu CPU? ¿Cómo está... se vea que está funcionando? ¿Jorrieron algún tipo de test en algún momento? ¿Dicieron algún tipo de verificación si todos están dando bien? ¿Capaz que tu site está en una caída libre? Bueno, no estás viendo. Te vas a dar cuenta a las 4 de la mañana cuando te llamen. Te digan, ah, mira, se cayó el portal porque hubo un pico de audiencia. Bueno, entonces, monitoración lo que... alguna de las cosas que usamos y utilizamos antes y utilizamos ahora también. Pingdom es uno bien básico. Server Check-In es uno muy bueno también, que fue hecho por una de las personas que hizo unos rows de Ansible, que son todos para Drupal. Lo recomiendo bastante. New Relic, Nashios, que es bastante conocido. Open Source, Sabix, Jmeter, para poder hacer test de carga. Blazimeter, que o sea, puedes hacer todos los tests automatizados en tu máquina, todos los tests automatizados, no todos los tests de carga automatizados con Jmeter en tu máquina, después los pasas para Blazimeter y Blazimeter se encarga de ejecutar todos los tests, de todos los tests de carga. Entonces, bueno, dependés de tu máquina, de la capacidad de tu máquina y ni de tu IP, porque si no te cortan. Y este estaba mandando un millón de requisiciones para el site, le voy a cortar. Y ahí se te cae el test por abajo. Blitz también es otro bien parecido a Blazimeter. También no conseguí encontrar bien cuál es la diferencia, pero en fin, nosotros usamos Blazimeter y funciona bastante bien. Google Analytics también sirve para eso, para poder medir. A veces vemos que en una área la gente no está usando y a veces de entrada dice, pa, esta área no tan ni funciona, por eso que no hay gente entrenando. Entonces, es importante también Google Analytics empezar puede ser una herramienta bastante buena. El Tracker es un producto que estamos lanzando ahora en febrero, que es para poder traquear tu usuario de una manera más fácil, sin tener que ir y programar aquí el código de Google Analytics para medir cuando la persona clica en un botón. La cultura de compartir, eso es súper importante. Porque todo el mundo en el equipo tiene casi la misma responsabilidad. ¿Por qué qué pasa? Todos tenemos que tener el mismo objetivo que es el suceso del proyecto. No es tipo, no, porque ya tengo la responsabilidad solamente de hacer esto, no. A veces tenés que abrir un poco la cabeza y decir, no, no, yo tengo tanta responsabilidad como el tipo que está en operaciones y el tipo de operaciones tiene que entender que yo también tengo la misma responsabilidad que él. Entonces, tenemos que compartir ese tipo de responsabilidad y entonces necesitamos tener una comunicación más constante. Necesitamos de integraciones constantes. Necesitamos hacer preprogramming, code review, cosas que unan más a los equipos, que se sientan más un equipo solo. Y coaching, coaching es súper importante. Bueno, para compartir código, en fin, tenés GitHub, Vinstog, APP también, es un repositorio, tenés la propia Acquia también. Acuerdos de trabajos en equipo, súper importante. Va a ser una diferencia absurda. Los acuerdos de trabajo en equipo son un día agarrás tu equipo de desarrollo, lo sentás, lo pones en una sala y decir, bueno, necesitamos hacer acuerdos. No precisan ser los mejores en ese momento, no precisan ser los definitivos para siempre. Es simplemente una manera de comenzar. Necesitamos acuerdos. Y esos acuerdos son, por ejemplo, cuando hago, antes de hacer push, tengo que hacer correr todos los tres automatizados. Ese es un tipo de acuerdo que tenés que hacer, ¿no? Bueno, y algunas herramientas para tener esa comunicación constante, tenés el Slack, HipShot, ahora estamos usando Hall y IRC. IRC funciona bastante bien. Yo le uso de hace muchos años. Notificaciones integradas también. Esas notificaciones integradas se integran con Slack. Esas son herramientas de chat. De comunicación. Son chats donde vos tenés salas por proyectos, en fin, ahí depende de cómo lo vas a organizar. Y el tema es que a veces, cuando alguien hace un push, ya en el mismo chat, aparece una notificación diciendo, falló tal, tal cosa. Y todo el mundo sabe, en ese momento, todo el mundo está sabiendo qué lo que pasó. Entonces todo el mundo puede decir, se quebró. Entonces todo el mundo puede ir y sentarse al lado y intentar ayudar y focarse en resolver ese problema. Bueno, allí de experiencia, voy a hablar un poco de la experiencia que yo tengo ahora. Es un poco del know-how que vinimos aprendiendo con el tiempo. Entonces una de las cosas es la confianza. Necesitamos confiar. Tu cliente tiene que confiar en ti y vos tenés confiar a veces, vos tenés confiar en tu equipo, tenés confiar en las personas. Por eso es que es muy importante los acuerdos. Porque los acuerdos es una manera de vos confiar y saber cuándo no confiar también. Porque si vos ves que él está quebrando todos los acuerdos, entonces no puedo confiar en esta persona. Porque no pueden cumplir un acuerdo. Entonces la confianza es muy importante. Ganar la confianza del cliente no es fácil. Te puedes llevar más de dos años, tres, cuatro años. Te puedes llevar mucho tiempo. Y esa confianza a veces se pierda por causa de esos equipos de operaciones que tienen esa paranoia de seguridad. Porque a veces pasa que no consiguieron resolver bien la seguridad. Ellos no saben exactamente cómo resolverla. Entonces mejor cortar, ¿viste? No, no, cosa nueva, no, vamos a cortar. Porque no sé, ¿viste? Yo qué sé. Entonces ya limitan, ¿viste? Desde antes de poner algo, de intentar algo juntos, ya te lo cortan. Entonces una seguridad más resolvida limita la innovación y genera paranoia necesaria. Uno de los procesos para poder ir avanzando y mejorando es el Kaizen y el Kaikaku. Voy a explicar un poco la diferencia. Bueno, existe lo que se llama la curva J. Cada vez que quieres hacer una implementación, tu capacidad va a bajar un poco. Vamos a suponer que adoptamos, vamos a adoptar Ansible, ahora. Ahora para hacer atomanciación de las configuraciones de los servidores, en fin. Y ahí tu equipo de la nada va a empezar a caer a la producción. Porque no sabe cómo usar, lo van a tener problemas, en fin. Es normal, va a tener esa curva J aquí. Y esto es más Kaikaku. Que Kaikaku es hacer una revolución, es un cambio muy grande. Vamos de un día para el otro, es un cambio tan grande que tu equipo ya no consigue ser más productivo. Porque es un cambio muy, muy, muy grande. Entonces Kaizen es un poco al contrario. Es hacer pequeños pasos. Entonces, cuando se pequeños pasos es como la entrega continua. Diminuces el riesgo. Entonces, tenés que medir un poco. O sea, a veces Kaikaku puede ser tu única solución en este momento. A veces necesitas un tipo, decir no, es una edición rotunda. Ahora necesitamos un cambio rotundo. No podemos más seguir así. Y no tenemos más tiempo. Necesitamos cambiar ahora. A veces eso te puede salvar la vida. Pero te puedes, no, estar acá. Y si estás acá, tu cliente no va a estar muy contento. Voy a volver un poco aquí. Opa. Bueno, uno de los desafíos que tenemos, Acquia, puedes sacar Acquia aquí. Puede ser cualquier tipo de cosa nueva que quieras implementar. Porque es uno de los mayores desafíos nuestros es ofrecerle Acquia a nuestros clientes. Es muy difícil. Porque ellos lo ven así. Es un cambio muy grande en la infraestructura de ellos. Porque es una cosa muy especializada. Porque nosotros trabajamos que Drupal es simplemente el site. Ellos tienen toda una infraestructura con la cantidad de otras cosas. Entonces para ellos es ir, pero voy a tener otro proveedor, otra cuenta, otras personas para tener que hablar. Del punto de vista de ellos es un poco malo. Pero es a veces porque no entienden. Entonces ellos dicen, es un cambio muy grande, con riesgo y puede ser muy caro. Y en verdad no. Puedes llevar un año. Y te puedes llevar más o menos un año a hacer toda la implementación de todas las mejores prácticas y procesos. Ese número es un número que hicimos un curso con Mary y Tom Popendick. Que fueron las personas que trajeron lín de la Toyota para desarrollo. Porque lo que acontece es que es muy grande con el lín de fabricación. En fabricación vos tenés el mismo producto y tenés que salir igual siempre. Si está diferente, hay un problema. Bueno, en nuestro caso es totalmente al contrario. Nosotros tenemos variaciones. Todo de Ploy es un poco diferente. Todo el tiempo estamos agregando cosas diferentes. Tenemos cambios constantes. Entonces, lo que hicieron fue entender todos los principios del proceso de Toyota y traer eso para la parte de desarrollo. Es un proceso más de exploración. Tenemos mucho riesgo. Y a veces, quién trabaja con Agil aquí si quiere implementar Agil con su cliente o está implementando. Puede ser que se encuentre en el mismo problema que cuando quiere implementar DevOps con su cliente. Es el mismo desafío. Es la misma lucha. Puede mostrarle, mostrarle mostrarle la visión, mostrarle números. ¿Por qué no confía en ti? Imagínate que está llegando a una empresa donde tiene años de mercado y ya les está haciendo todo mal. No es tan fácil. Entonces, por eso hay que calcular los pocos. Otra cosa importante es ir a your own food. Comer tu propia comida. ¿Cómo sabés si tu comida está bien? Tenés que comer a la vez. ¿Cómo está? Y eso pasa mucho cuando queremos ofrecer algún tipo de solución para nuestro cliente. Decimos, pues, ¿puedes instalar Ansible ahí o automachizar todo? Antes de decirle indicarle a tu cliente usarlo en tu empresa. ¿Dónde está mal? ¿Dónde está bien? ¿Dónde puedes mejorar? ¿Aprende un poco? ¿Tenés más experiencia ahí? Después que comiste tu propia comida agarrás y le ofreces. Un poco de mi visión sobre DevOps ¿A dónde estamos yendo? Es una revolución industrial. Y digo eso porque hay muchas personas, muchas personas, estoy hablando de a veces... me olvidé la palabra. ¿Pisos? Imagínate un edificio, a veces hay pisos y pisos y pisos de gente que están haciendo exactamente la misma cosa siempre. Son personas que son gurús, van y instan y configura y están siempre haciendo la misma cosa. Nosotros hoy podemos automachar todo eso y poner esas personas que están haciendo siempre lo mismo para crear algo, para hacer algo diferente para poder mejorar esos procesos. Y es parecido lo que pasó con una revolución industrial. Pusieron las máquinas para hacer cosas y tuvieron que sacar los humanos como una cosa mala, pero en verdad es una cosa buena. Porque ahora en vez de tener personas haciendo una cosa mecánica ahí, tienes una persona libre para poder hacer algo creativo. ¿No? Y es una revolución del intercambio de propiedad intelectual. O sea, utilizar Ansible por ejemplo, como le dije, es la configuración y instalación esa experiencia, es know-how que está en código. Y puedo agarrar eso y ponerlo Open Source, ponerlo en GitHub y otras personas pueden agarrar un libro de experiencia y usarlo dentro de sus propias empresas. Sin tener que saber todo aquel conocimiento. Sin tener que leer un libro entero de varnish o sin tener que leer un libro entero de red para ver cómo funciona y eso. Entonces, si nosotros podemos generar todo ese tipo de automatización y entregarlas de una manera fácil de usar todas esas personas no precisan entender todo. Y bueno, nosotros usamos Juju ahora. Hace un tiempo que estamos luchando ahí para dejarlo impecable. Y estamos trabajando con el equipo de Ubuntu para hacer el primer charm de Drupal que se ha recomendado por Ubuntu. ¿Y qué es lo que hay ahí adentro? Y ahí adentro tenés una cantidad de cosas. Tenés configuraciones de InginX con configuraciones de Perúcio. Tenés mejores prácticas para instalar y organizar tu Drupal. En fin, hay una cantidad de cosas que ya instalas Drupal con la versión exacta y lo puedes cambiar y lo puedes instalar con PES para quien usa SAS. En fin, hace una cantidad de cosas que uno tiene que hacer siempre. ¿No? Y bueno, como dije, es un producto de la Canonical junto con Ubuntu. Y tiene una interfaz que es muy buena. Entonces, esto es como una App Store donde tengo mis apps que en verdad son servicios. Y estos son los charms que son recetas. Y estas recetas son hechas por la comunidad y a veces por la Canonical o a veces por las personas que son especialistas en MongoDB. Entonces, estoy usando todas las técnicas y toda la experiencia de las personas que son especialistas en MongoDB en mis proyectos y saber cómo se funcionan exactamente. Y él tiene una arquitectura orientada a relaciones. Entonces, la relación entre MySQL y la relación entre un Drupal es siempre la misma. ¿Qué es lo que pasa cuando vos decidas voy a poner un MySQL y voy a poner un Drupal? Tiene que ir, crear un banco de datos, ponerle un usuario, señas, no sé qué, y después vas a Drupal, crear un archivo settings, ponerle los datos, siempre lo mismo. Entonces, este tipo de relación no se lo podemos automaxar. Entonces, cuando crea una relación con el otro charm, automáticamente ya sabe qué es lo que tiene que hacer. Y este charm no sabe qué es Drupal. Él solamente sabe de qué tiene una relación de banco de datos que precisa querer un banco de datos y entregarles esos datos. Y bueno, cuando queremos escalar, podemos agarrar y decirle, bueno, quiero más máquinas de este servicio. Esto es simplemente una representación de servicio. Entonces, tenés varias unidades en vertical. Varias unidades son varias máquinas, cuando querés escalar. Y todo eso se automatesado también. Y tenés, por ejemplo, si querés usar un varnish o algo así para poder escalar, para poder escalar de alguna manera. Es que depende de tipo de usuario que tenga, pero bueno, varnish es bastante conocido. Entonces, creas una relación de Drupal con varnish. Automáticamente ya sabe qué es lo que tiene que hacer, cómo configurar. Entonces, esto nos da un poco de libertad en la hora de elegir nuestro proveedor de infraestructura. ¿Por qué? Porque esto, creo que acabó mi batería. No, no, no. Sí, estaba casi, casi, casi. Voy a continuar. Bueno, entonces, puedes agarrar todo eso. Puedes agarrar todo eso que acabé de hacer. Y todo eso se exporta en YAMO, que es muy fácil de leer. Y puedo agarrar eso y ejecutar exactamente ese script que acabé de exportar. Puedes usar para Amazon o para HP Cloud o SoftLayer de IBM o puedo usar RockSpace, DigitalOcean. Puedes usar todo cualquier tipo de proveedor que use OpenStack, por ejemplo. Puedes usar Linux Containers, que es un nuevo paradigma. En fin, para que no conoce Linux Containers le vas a explotar la cabeza cuando sepa qué es lo que es. En verdad, Linux Containers posibilitó para nosotros tener toda la infraestructura de producción en nuestra máquina local. Y tener varios tipos de infraestructuras y tener todos en mi máquina local. Y tener los versionados y configurados y instalados, todos siempre de la misma manera. Entonces, eso me ahorra los problemas de diferencias de ambiente, por ejemplo. Y bueno, tenían otros slides aquí, pero bueno. No sé qué pasó. Bueno, voy a abrir por preguntas. La primera pregunta es cómo comparas el juicio que tiene un lindo interfaz. Pero, cómo comparas eso con hacer un sencillo playbook en Ansible y Chao? Esa es una pregunta que tengo. Dos, el diagrama del Kanban que había es ágil, pero yo me pregunto porque habla del testeo listo para testeo, etc. y hay unos estados. Pero hay un handoff entre la verificación interna, o sea, el testeo el testing. Y luego hay otro estado que es el CUA La primera, o sea La primera es simplemente para qué usar juicio si hago un playbook y listo. O sea, una pregunta así. Bueno juicio no es un sistema de configuración como Ansible. Juicio es un orchestrador es diferente pero es diferente porque Ansible yo puedo usarlo dentro de ese charm. Es más, el charm de Drupal que hay hoy utiliza Ansible y utiliza rows que fueron hechos especialmente para Drupal. Y tenemos, por ejemplo, el row que es la receta de Enginex o sea, fue la garrera de la comunidad no fui yo que la hice simplemente dije bueno este charm va a tener Enginex va a tener configuración de Perú y todo ese tipo de cosas y lo que fui fue seleccionando rows y los configuré todos y los puse dentro de un charm. Entonces al final del día en verdad lo que vos tenés es una selección de los mejores o de los más fáciles de utilizar y de los que nosotros nos sirvió bastante. Y es todo opensor puedes ir al charm y modificar puedo mostrar un poco aquí sobre donde están mis cosas Bueno, entonces dentro de charm, por ejemplo, de MySQL fue el equipo de MySQL y todas las personas especialistas en MySQL en Ubuntu hicieron una receta toda hecha en Python y bueno esa es la manera de ello hacerlo pero en el charm de Drupal que estamos haciendo, es todo utilizando Ansible Entonces perfectamente en vez de usar Ansible, podría usar poder usar Chef podría usar Bash podría usar cualquier tipo creo que es este cable y la otra la otra pregunta era sobre perfecto eso es un problema que estamos teniendo hoy que ya lo estamos resolviendo que es el de la siguiente manera ¿Qué pasa? Con Drupal es un poco difícil tener ese tipo de desarrollo todo testado, hacer TDD por ejemplo, TDD en Drupal es muy difícil pero no es difícil de hacerlo sino que es difícil porque demora una cantidad hacer el boot, entero de Drupal en fin, la producción comienza a caer Entonces en el mercado donde nosotros vivimos hoy no nos da la oportunidad de poder hacer todo el sistema todo testado por causa de la tecnología que estamos usando Entonces lo que nosotros estamos utilizando es BDD entonces el propio desarrollador tiene que crear todo el gherking para poder testarlo el propio desarrollador tiene que hacer el TDD ese es lo mejor digamos, es lo indicado es como mejor funciona pero el problema es que muchas veces tu desarrollador no sabe cómo hacer los TDD entonces necesitas a veces tener un ingeniero de que a que sabe cómo hacer los TDD es como pre-programming hasta que tu equipo se empiece a nivelar y todo el mundo sabe cómo hacer las cosas lo que nos pasa a nosotros fue más o menos eso tenemos dos personas que son encargados de KA tenemos otros equipos y ellos se encargan de ir a dejar van al equipo les muestro cómo es, hacen los primeros tests una vez que el equipo desarrolla ya está haciendo sus propios tests antes de si quiera pasar por una columna de KA ya está testado no precisa pero a veces tenés test exploratorios pero ahí ya es otro tipo de cosas porque ahí quien mide eso, quien mide ahí es otra es otra área al final si aquello que estamos haciendo es bueno si tienen que hacer antes desde antes, desde antes de hacer el backlog y bueno por eso tenés que monitorar si aquel por ejemplo el track que estamos haciendo es para poder monitorar si realmente aquello que hicimos realmente está dando valor voy a dar un ejemplo que es re común que la Globo lo que hace es un es un portal gigante de Brasil tiene un canal de televisión lo que hacen antes de si quiera mandar decirles al equipo de desarrollo cuánto que demora hacer esto lo que hacen lo mínimo posible que es un botón si quieren hacer una funcionalidad de imprimir todas las páginas ellos agarran y hacen un botón que no hace nada que lo único que hacen es medir el click miden el click, validen la hipótesis y ahí si si realmente vale la pena o no ahí lo hacen por eso que estoy hablando antes de entrar el backlog antes de entrar en producción para que los desarrolladores empiecen a desarrollar eso bueno más que nada, primero me encantó lo que dijiste de revolución industrial me parece una analogía muy apropiada y no sé qué tan apropiado sería para el caso decirle revolución servicial por el tipo de por el tipo de cosas que se están haciendo con esto de DevOps y todas toda esta revolución y la pregunta sería si han utilizado docker qué experiencia han tenido si es que lo han hecho o alguna recomendación al respecto bueno cuando supe sobre Linux containers o sea específicamente lxc ahí descubrí docker y empecé a usar docker desde antes de usar su su solo que me vi en un problema antes de utilizar docker que no existía una herramienta de orquestración para docker y eso para mí era un problema muy grande porque no podía andar cargando una cantidad de imágenes y después tener que andar orquestrando y hacer un script que significaba todo era un trabajo o más entonces empezamos a decir ah bueno vamos a hacer con docker y vamos a hacer un sistema de hooks que cuando relacionas un container al otro el sabe cómo hacer y ahí encontré su yo dije pa que mía voy a hacer si ya está pronto y ya tienen una grande experiencia sobre eso porque hacer un orquestrador no es fácil tener que imaginarte la parte de operaciones o sea por ejemplo redes lidar con redes es muy difícil a veces en fin utilizamos docker en algunas veces pero algunas veces es bien para cosas espontuales tipo más parada por ejemplo cuando trabajamos con Node con Node.js algo tipo Javascript docker es más más fácil para eso porque se integra muy bien con herramientas de continúes de libre porque yo agarro y le digo a veces vos correr todo el test de este build que acabé de hacer de este nuevo push o sea ahí es el push se genera un build y ese build se corre encima de una imagen que yo le especifico entonces instancia un container con una imagen que yo ya le especifico que ya está pronta solamente en poner la aplicación adentro y ahí a correr todos los test y todo ese tipo de cosas pero yo resuelvo bastante de nuestros problemas porque docker todavía está medio que no sabe bien dónde va a encajar en ese tipo de cosas y vos tengáis que entender que nuestros clientes también tienen un poco de de miedo porque imaginate que ellos tienen una incapacidad muy grande de crear máquinas a veces le decís que queremos una máquina para esto una máquina para esto y los clientes a veces que nos dicen que va a andar creando máquinas así como loco imaginate que tengo que dar mantenimiento de todas esas máquinas es una locura porque no saben que hiciste una cantidad de herramientas para automatizar ese tipo de cosas entonces imaginate implementar docker es muy difícil es un paso, es un caicaco es un paso muy grande entonces la experiencia que yo tuve con eso es que cada vez que llegaba con una cosa muy grande y tomaba todo peor entonces a veces hicieron un poquito más lento y eso entonces yu yu te da la libertad de vos usar líneas containers o vos usas una máquina virtual mismo o usas Amazon o usas lo que tú quieres o sea no importa dónde está el tema que docker es específico para containers en equipos de desarrollo distribuidos las configuraciones en muchos sistemas de datos y por lo menos en Drupal eso se está resolviendo en Drupal 8 con configuraciones en archivos en Laravel se resuelve con consola en fin pero hay otros sistemas en los que las configuraciones son todas en la base de datos hay alguna metodología o algún servicio de ops que nos ayude a compartir las configuraciones que yo tengo no te estoy preguntando digamos WordPress cualquier vaina me sacaron del Drupal con ya hay alguna metodología en DevOps que nos ayude a resolver eso para compartir mis configuraciones con otros desarrolladores en caso de Drupal específicamente hay varias charlas que van a ver por ejemplo la de Victor o la de Renato que sobre mejores prácticas de continuous deployment y eso que te van a aclarecer este tipo de cosas hoy mismo con Drupal 7 vos podés hacer eso puedes agarrar todas las configuraciones y ponerlas en código es más Victor hace por ejemplo un profile donde tenés todo es un build entero de tu Drupal necesitar tener un banco pronto antes que es lo que pasa generalmente andas cargando siempre un banco de datos para todos lados y eso es una cosa que no viene no es una cosa nueva es una idea muy vieja que es el tema de tener una aplicación stateless por ejemplo por qué es tan fácil hacer tes automatizado con no 10 tipos de cosas y manejar varias instancias y con Jave escribir porque es una aplicación sin estado ella no tiene un banco de datos ella es lo que tiene es un proceso automatizado para poder iniciar para poder construir hacer el build y no se date una respuesta así perfecta para eso porque es un problema que nosotros también venimos lidiando con eso pero nunca fuera Drupal y WordPress creo que nunca tuve que lidiar con este problema porque también nunca se algo tan cms así tanto que el banco de datos tengo configuraciones en el banco de datos y así tipo de cosas lo que te puedo decir es que trata de no hacerlo por ejemplo rules antes rules no era tan integrado con configuraciones management o con features entonces hacer rules a veces tenías lógica en el banco de datos tengo que andar con esa lógica para todos lados y ella no es mala aplicación y ahí es un poco más difícil a veces para darle mantenimiento y modificar las cosas porque a veces más rápido encontraron el código que encontraron un sistema todo de configuraciones como el que usa Drupal pero la buena práctica es poner todo en código de alguna manera porque te necesitas versionarlo, no puedes versionar un banco de datos es una locura gracias ¿Cuáles serían las mejores prácticas para nosotros desarrolladores o testers para anticipar problemas que puedan introducir sistemas de caché como varnish o memcache bueno y esa es una de los por qué estamos usando Shushu porque yo quiero tener casi exactamente el ambiente de producción dentro de mi máquina local o lo quiero tener en otro lado solamente lo quiero testar, quiero ver a ver qué es lo que pasa cuando haga este nuevo deploy a ver cómo se va a comportar con nuestras reglas de cache de varnish nosotros tuvimos ese tipo de problema y tenemos problemas con otras cosas como cdn y la mejor cosa que pudimos hacer es utilizar Shushu para mí orchestrar una topología tan grande de producción es una cosa que lo puedo dar cargando para todos lados no es una cosa justosa, lo hice una vez chau entonces Shushu es una de las por eso Shushu es tan importante ahora está siendo recomendado en varias empresas grandes y eso porque realmente estaba solucionando una cantidad de problemas hablando de Fuhu hoy voy a iniciar un hackathon para terminar ese charm de Drupal que funciona y eso pero el charm hace más de que simplemente hace un deploy de un Drupal o le puedes especificar un repositorio y el agarre te importa un proyecto dentro de las configuraciones de el charm entonces es muy fácil de iniciar un nuevo proyecto simplemente agarrar el proyecto de este repositorio y ya se arma toda la infraestructura y bueno voy a hacer hoy voy a hacer un hackathon sobre explicar más o menos cómo funciona para quien quiere saber y eso y el jueves hay jueves y jueves que va a ser solamente sprints y eso, ahí si no vamos a sentar y eso y vamos a tratar de terminar y voy a explicar cómo funciona mejor el charm específicamente y otra cosa que Ubuntu está patrocinando este evento exactamente por ese tipo de cosas que hay que incentivar a que a que todo ese conocimiento que nosotros tenemos de mejores prácticas para infraestructura que estén en un lugar donde todo el mundo pueda compartir eso y no quede, eso es un poco de mi visión es una cosa que andan diciendo por ahí es porque lo que pasa muchas veces es que nosotros trabajamos con Drupal y con Drupal si vos no trabajas de una manera preocupándote siempre por la calidad y por la performance y todo ese tipo de cosas, puedes perder un poco la línea y ahí vas a tener que recorrer a alguien que sepa cómo escalar tu aplicación o sepa dejarla rápida mismo que no esté performáticamente bien o que una cosa de tu aplicación se performática y otra cosa es tener un tiempo de respuesta rápido son cosas muy diferentes entonces por eso es que se generen esos cache absurdos es un HTML prácticamente entonces ese tipo de restricción que está pasando hoy de tipo que a veces sabe cómo hacer cómo dejar los sites súper rápidos y tener los redes y configurar cuál es la mejor configuración de redes para Drupal tener que salir buscando de alguien que dice hay varias páginas que dicen podríamos centralizar eso y automatizarlo y dejarlo en un lugar solo podemos generar una red de conocimiento por ejemplo cuál es la mejor configuración de MySQL hay uno o dos posts en Drupalor que hablan de eso por todos lados pero no hay algo que sea fácil de automatizar tenés que siempre agarrar el código, ponerlo y configurarlo tenés que hacerlo vos ¿como? no, no porque es muy exploratorio si si pero lo que pasa es que si si pero ese problema de tuning realmente cada vez que nosotros vendemos un servicio decimos nosotros te tunamos tu aplicación en Drupal, es un proceso totalmente exploratorio nuevo pero siempre sabemos más o menos a dónde tenemos que modificar la configuración y si yo te doy eso de una manera que es un formulario donde tenés unos campos donde vos vas y los modificas y te puedo hasta decir este es muy importante te estoy compartiendo ese tipo de conocimiento ¿entendés? entonces te facilita más ese tipo de tuning que ha creado específicamente para esa aplicación entonces por eso no te soluciona todo el problema pero es por eso que esa tomación con un toque humano, nunca va a ser perfecto y tampoco no es bueno ser todo automatizado ¿qué tan complejo es montar la metodología de DevOps en un grupo de trabajo que tiene diferentes infraestructuras digamos diferentes gustos a nivel de desarrollo no se, digamos que estamos hablando del caso de Juju no es propiamente de la plataforma Ubuntu pero digamos si se tiene Windows, Mac, Fedora ¿qué tan complejo sería llegar a tener una infraestructura completa? bueno cuando empecé con Juju en Tashere fue un caicaco yo llegué y dije, ah sé que ya estudié yo ya sabía cómo funciona de eso pero todo el equipo no sabía entonces fue un shock muy grande y eso hizo que no sabía exactamente cómo funcionaba no sabían como y algunas personas tenían Linux Mint otras personas tenían Ubuntu una versión no sé qué otras personas tenían Mac otras personas tenían Windows pero comenzamos a ir a los pocos entonces comenzamos por Vagrant por ejemplo comenzamos con Vagrant con Ansible no, empezamos con Vagrant Bash después con Ansible ahí todo el mundo empezó a entender cómo va, qué no sé qué existe todo un proceso de automatización que se puede qué es rápido de manusear después que salimos de eso ahora no, después que salimos de esa independencia del sistema operacional que vos estás usando en ese momento con Vagrant o sea, puedes tener un Linux el mismo Linux que todo tu equipo está trabajando en cualquier tipo de sistema operacional puedes trabajar en Windows, puedes trabajar en cualquier otro si vos usas Ubuntu Server de producción, vos tenés que hacer tu aplicación en aquel porque la aplicación es todo eso es la infraestructura imagínate una aplicación sin infraestructura no anda, cierto? y una infraestructura sola sin aplicación no es muy bueno también entonces ellos se complementan entonces tienen que andar juntos también bueno, entonces lo que hicimos fue usar Vagrant con Ansible y después ahora estamos usando Vagrant con una imagen que instala Shoo Shoo ya hace todo ese tipo de configuración