PurePerformance - Perform 2020 en Español Sergio Hinojosa de Dynatrace

Episode Date: February 6, 2020

Nos encontramos con el amigo Sergio que nos platica de las novedades que tinene Dynatrace y ia eperiencia que se vive en la confrencia.

¡Cámara ahí! Coming to you from Dynatrace Perform in Las Vegas, it's Pure Performance! Traído a ustedes por la conferencia Perform the Dynatrace desde Las Vegas es Pure Performance. En español, en español, en español. Hola amigos, nos encontramos todavía aquí en Perform 2020 de Dynatrace con nuestro amigo Sergio Hinojosa, otro hermano latino que pudimos encontrar y mexicano también, que es parte aquí de la fuerza laboral que está generando esta herramienta tan padre. Y pues afortunadamente aceptaste aquí la entrevista, platicarnos un poquito.

Antes de entrar en todo lo que es lo de la conferencia y todo, a nuestra audiencia, a nuestros amigos, platícanos un poquito de ti. Quisiera también saber tu trayectoria, porque muchas veces triunfadores como tú, que ya están aquí, bueno, no aquí, están allá en Europa, bueno, spoilers. ¿Cómo has logrado? ¿Cómo has has avanzado, qué cosas en la vida, porque hay muchos hermanos en Latinoamérica que también quieren saber cuál es el secreto, ¿no? Entonces platícanos un poquito de ti y cómo llegaste a este lugar de éxito. A este lugar de éxito, bueno, ¿qué tal? Soy Sergio. Ya tengo 15 años viviendo en Alemania.

Yo, bueno, soy de Guadalajara. Yo creo que parte del truco fue que estudié en un colegio alemán. Y con el alemán eso me ayudó después de... La carrera la empecé en México, pero después de un intercambio estuve en Alemania y la terminé allá. O sea, ¿aprendiste alemán antes? Sí, yo ya sabía alemán.

Amigos, otro idioma. Ese sí es básico. Perdón, sigue. No, no, no, está bien. De hecho, estaba viendo. Es que no me escucho. Ah, no te preocupes. Acá nos están. Excelente. Sí, entonces terminé la carrera allá en una universidad alemana

y bueno, ya me quedé ahí. ¿En qué parte de Alemania llegaste? Primero estuve en Stuttgart. Ah, muy bonito Stuttgart. Terminé la carrera en Neslingen y bueno, ya me quedé ahí. ¿En qué parte de Alemania llegaste? Primero estuve en Stuttgart. Ah, muy bonito Stuttgart. Terminé la carrera en Neslingen y bueno, viví ahí como 13 años, 12 y ahorita tengo ya 3 años viviendo en Mónica. Oh, wow. Entonces, la verdad, idiomas abren puertas.

¿Qué tal la carrera? La carrera, bueno, estuve en ingeniería, ingeniería en software. Después fui consultor, trabajé, bueno, estuve en ingeniería, ingeniería en software. Después fui consultor, trabajé, bueno, estuve con Mercedes, estuve en IBM en el laboratorio. Y después en la consultoría. Durante la consultoría hice una maestría en negocios. Y ya fue cuando yo, bueno, quería hacerme negocio. Y fue cuando Dynatrace a través de una persona me contactó y me dijo, oye, vende con nosotros.

Y ahorita hago un poco los dos que me encantan. Hago mucha ingeniería, pero con un twist de negocios. Estoy encargado de ganar clientes. Así es, una muy buena mezcla. ¿Qué opinas de la fogueada, como le decimos en México,

la entrenada que te tocó siendo consultor? ¿Te ha ayudado? Si lo comparas con las fogueadas que tenemos en México de un trabajo normal, nada que ver. Sí. Nada que ver. Porque ahora, bueno.

Aprendizaje, crecimiento. El aprendizaje es muy bueno en consultoría. Yo creo que es donde puedes aprender más. Estás siempre con nuevos clientes, mucho cliente. Tienes que manejar mucha mano izquierda. Tienes que manejar situaciones críticas, ¿sabes? Entonces, eso yo creo que te forma mucho, aprendes muchas tecnologías, ¿sí? Que eso me ayudó mucho.

Entonces, fui como lo que llaman el full stack developer. Full stack developer. Ah, ahora sí me escucho, ¿ya ves? Había truco. Hay que acostarse en el micrófono. Exacto. Y, bueno, entonces, mi lenguaje de programación fue Java. Java, J-E-E, que era lo que era más corporate en ese entonces.

Hice después un poco de.NET. Y bueno, ahora a veces para automatizar cosas hago Python. Cuando hacías consultoría, ¿era pruebas, era performance, era desarrollo? ¿Qué hacías? Era más que nada desarrollo. Desarrollo. Era como, bueno, llega a tener muchos nombres. Era de Scrum Master a Lead Architect a Developer.

Todos los sabores pasaste por. Sí, te ponen diferentes nombres. Pero más que nada yo era de los que codeaban, ¿sabes? Me metí ahí en el código y había algún problema de producción, tenías que meterte a los servidores, checar los logs, ¿cuál era el problema? Yéndonos por una pequeña tangente, ¿tú qué opinas del conocimiento de developer para un tester?

No mucho, la verdad. Antes. Ahora sí está creciendo más porque se están empezando a romper silos. ¿Crees que le ayuda a un tester? ¿Que es necesario? Es importante. Absolutamente? Es importante conocer de desarrollo. De hecho, si te doy mi opinión personal, yo siento que los desarrolladores son los que tienen que hacer el test.

Y es lo que hacemos nosotros en Dynatrace. Sí, es el dog food, comer tu propia comida. No, y son porque en realidad son los que saben qué es lo que tienen que testear. Ellos mismos están haciendo el software y ellos qué es lo que tienen que testear. Ellos mismos están haciendo el software y ellos mismos saben lo que tienen que testear. Es el mismo cerebro que sabe. Si yo hago una función que me hace uno más uno,

me tiene que dar dos. Así que el tester, de hecho, es más eficiente. El tester no tiene que leer, oye, uno más uno, ¿cuánto te da dos? No. Yo lo estoy haciendo, yo sé lo que tengo que recibir. Sí, así de ahí. ¿Y por qué estamos usando esta fórmula que estamos tratando? ¿Por qué?

Exactamente. ¿Lo sé? ¿Lo programo?? ¿Por qué? Exactamente. ¿Lo sé? ¿Lo programo? ¿Lo automatizo? Exactamente. ¿Lo que se necesite? Perdón por la tangente, pero también es un tema que ha salido mucho la necesidad de saber, de entender, de poder hacer, porque la capacidad de automatizar pruebas va a veces

muy de la mano. Por muy que pongas la herramienta drag and drop y paradomies, a veces hay de la mano. Por muy que pongas la herramienta drag and drop y paradomies, a veces hay que tener ese entendimiento de qué estás haciendo detrás del escenario con la herramienta. Y me llamó la atención porque también los que estamos

involucrados en la performance, de un modo u otro, tenemos historial de desarrollo, de entender o base de datos, o conexión,ión o networking o todas las anteriores. Bueno, entrando un poquito ya en materia de lo que es la conferencia, ¿cuántas conferencias has venido de Dynatrace Perform? De Perform, esta es mi primera en Las Vegas. ¿En Las Vegas?

En Las Vegas, sí. He estado en Barcelona y he estado, bueno, en muchos eventos de Red Hat, de Development, de DevOps, cosas así. ¿A cuántas has ido en Barcelona? La del año pasado, ahí estuve. Hemos tenido tres y he estado en una la pasada. Ah. Sí, y es que antes de tener el rol que tengo ahora como manager, antes estaba más en el field de ventas.

Ahorita, bueno, lo sigo haciendo, pero ya operando de una forma más estratégica. Ya doble tarea, como mencionabas. Sí, o sea, ya soy como parte manager. O sea, no es manager de tener que controlar gente, sino es manager estratégico, por los conocimientos que tengo, ayudar en key accounts. Oye, de que a ver, ¿cómo podemos hacer esto?

¿Cómo ayudar acá? O parte de mi trabajo ahora es lo que es el Autonomous Cloud. Ayudarles a las empresas a ir a lo que es el Autonomous Cloud. Muy bien. Te diviertes por todos lados. Es un poquito impresionante. Ahorita,

hablando de las conferencias, por eso te preguntaba un poco de la anterior, de la actual, ¿qué novedades podrías decir que hay o que a ti te ha impactado? Digo, más que impactado, pues tú las estás ayudando a producir, ¿no? ¿Qué es lo que más te emociona que hay en esta conferencia? ¿Qué temas que puedas hablar? Porque a lo mejor hay una que otra cosa muy top secret que todavía no se puede.

No, bueno, lo que estamos presentando aquí obviamente es público, ¿no? Estamos a la vista de reporteros, de analistas, todo eso. Somos una empresa pública. Sabes que salimos en IPO el año pasado. Sí, sí, las acciones de Dynatrace. Y vamos bien. Bueno, el viaje que ha sido con Dynatrace, tengo con ellos cinco años ya, ha sido excelente.

Del producto que estamos generando, la plataforma, es más, los clientes no nos ven como un vendedor de software, Así de excelente. Del producto que estamos generando, la plataforma es más. Los clientes no nos ven como un vendedor de software, sino ya nos ven como partners estratégicos. Van con nosotros y dicen, oye, ¿sabes qué? Tenemos este cloud, tenemos esto, ¿qué hacemos? ¿Cómo podemos manejar todo esto?

Porque ellos saben que nosotros hemos avanzado tanto porque aplicamos nuestra misma tecnología con nosotros mismos. El eat your own food or drink your own champagne. Por eso nos ayuda a avanzar tanto. Entonces, si te digo lo que cada año hay, es más, te digo algo que acabo de escuchar. Uno de las sessions de un product manager tiene problemas en presentar todo el producto que hemos hecho. Dices que, oye, solo en lo que es rum,

es tanto lo que hemos hecho, no lo puedo presentar en una hora. Ni el resumen. Para que te des una idea. Es una herramienta muy robusta. Claro. Y bueno, tenemos no solo DevOps, sino tenemos lo que hacemos el NoOps o el ACE. Que ya tenemos todo automatizado.

Entonces tenemos miles de deployments al día. Tenemos todo automatizado. El delivery pipeline, delivery testing todo eso y production deployments o releases cada dos semanas cada dos semanas nuestros clientes reciben software nuevo software nuevo con zero downtime entonces ellos tienen un cluster de high available

que siempre está funcionando y ellos reciben nuevo software sin darse cuenta es transparente obviamente bueno pueden ver lo que reciben nuevo software sin darse cuenta. Es transparente. Es transparente. Obviamente, bueno, pueden ver lo que reciben, pero no tienen que detener su negocio.

Porque nosotros nos enfocamos a ayudarle a él a mejorar su negocio. Es un poquito, haciendo un ejemplo un poco burro, pero que la mayoría tienen esa más experiencia. Facebook, que no te das cuenta. O sea, Facebook también mete versiones a cada rato. Claro, y utilizan lo que es feature flagging, todo eso. Entonces, a través de feature flagging pueden tener diferentes releases en producción sin hacer impacto a los usuarios.

O mínimo un impacto controlado. Que sabes que tengo el 10% o el 1%, lo pruebo con estos usuarios en esta zona y mi plataforma sigue funcionando. Ig igual que Google. Y ahorita me sale una duda. ¿Ustedes tienen liberaciones controladas? Totalmente. Es decir, de nuevo al ejemplo de Facebook,

¿a quién no le ha pasado que de repente tu interfaz es diferente, pero tu novia, amigo, hermano sigue siendo la anterior? Es como de, oye, yo extraño ese que era antes, ¿no? Pero sí es también crucial en este release de garantizar que no haya downtime, que no falle el servicio, ¿no? Pero, y te voy a poner un poquito en la esquina aquí para acorralar un poquito. ¿Qué, y acabas de decirlo, no es tan grande, hay tantas cosas en la solución,

¿cuál es la que a ti más te emociona? Tú estás así de, wow, esto viene a ser. Es que yo creo que no lo puedes poner en un feature.

¿Sí? Pues, sí, no, yo no lo puedo poner en un feature. Yo lo que sí puedo poner lo que más,

digo, lo más importante o una de las cosas que me, bueno, serían dos. Uno, la automatización, que tú para monitorear no tienes que monit... Bueno, serían dos. Uno, la automatización.

Que tú para monitorear no tienes que monitorear, no tienes que configurar nada. Haces el deployment del OneAgent y automáticamente todo. Es más, tienes un cluster con mil microservicios, automáticamente todo está monitoreado. Todos tus pods, todo monitoreado. Y lo más importante, está monitoreado por fuera y por dentro. Todas tus transacciones a través de todos los servicios,

monitoreado. Y lo mejor aún, que esado por fuera y por dentro. Todas tus transacciones a través de todos los servicios, monitorado. Y lo mejor aún, que es lo que yo digo a mis clientes, lo que importa es tu end user. Entonces, todo lo que es real user monitoring, o sea, todo lo que es dónde le picó, por qué le picó, a dónde está viendo, cuál es la experience, tiene alguna aplicación lenta, o es más, usability problems, rage clicks, todo eso nos damos cuenta automático y los problemas los detectamos automático.

Así que el cliente no tiene que configurar nada, ningún threshold, y nuestro AI, Davis, se da cuenta del problema y le dice, oye, ¿sabes qué? Tienes 20 usuarios con mal performance en Japón porque tienes un CPU problem en el servidor 23. ¡Wow! Automático.

Eso es lo que a mí te digo. Entonces es difícil ponerlo en un feature porque son muchas patentes, es mucho trabajo, pero es el core de nuestro software. Me parece ahorita lo que... Echaste tantas cosas que estoy un poco... Tengo la pantalla azul en la cara de... No sabía que detectaban

el Rage Click. Para los que no sepan en la audiencia, es cuando de repente no te responde la aplicación y te alocas. Exactamente. El clásico, si no sirvió la primera, si le pico 10 veces, a lo mejor sí sirve. Claro, claro. Y sobresatura la aplicación.

Claro. Ese tipo de detección es importantísimo. O los flujos y utilizaciones en negocio, que también se ha hablado mucho durante el día en otras entrevistas que, de nuevo, no es que yo sea muy fan de Facebook, pero cumplen con

muchos de esos detalles. Ellos saben qué estás picando, qué vas a picar. Poder desarrollar esa... No sé, los que veían los undercuts, ver más allá de lo evidente. No, no solo eso, es entender el mercado. Hay algo que se llama el path of least resistance, no sé si lo conoces.

Sí, sí, el happy path, el camino fácil, digamos en español. Sí, o el path de menos resistencia. ¿Resistencia por qué? Porque si tú quieres comprar algo, no voy a decir ningún proveedor, pero quieres comprar algo y la página no funciona, ya no te vas a tomar el tiempo, sobre todo los nuevos millennials de mandarle un mail o de

hablarle a alguien, oye tu página no funciona no, te vas con la próxima con la próxima meten y nomás cambian la URL y cambian la próxima y esa persona, ese negocio está perdiendo a lo mejor millones, porque no sabe que su página está abajo y es lo que, son los problemas

que suelve Danynatrace. Si sabes que, oye, tienes problemas, gente con experiencia mala, que están con Rage Click o que está muy lento, tienen errores, JavaScript, todo eso, arréglalo, porque si no, y puedes ver con Dynatrace cómo está bajando el revenue, o sea, el dinero de la empresa.

Ese es uno que me encanta, creo que sí tienen uno donde monetizan los eventos, las cosas que suceden. Es que van correlacionadas. O sea, el performance y usability con todo lo que es la ganancia y el user engagement en alguna aplicación. Es crucial porque en especial hoy en día que, salvo por uno que otro monopolio que hay ahí, todos los usuarios tienen una opción y llegan a tu página, a tu sistema y se tarda tantito

te choca, no vuelves a ir porque de inmediato como dices, cambias el URL y ya me fui a empresa2.com y ya estoy sacando que ellos a lo mejor, no ni siquiera necesitan ser perfectos, necesitan solo funcionar un poquito mejor que tú y el cliente no ni siquiera necesitan ser perfectos, necesitan solo funcionar un poquito mejor que tú. Claro.

Y el cliente no va a volver. Jamás vuelves a entrar a esa página. Sí, es la competencia. Es lo que le llamamos el digital transformation. ¿Sabes? Sí, es. Y me gusta mucho porque a veces para management, el lenguaje del dinero es el que los convence.

Y que tengan ese indicador de, oye, acabas de perder un millón de dólares. Es lo que sí genera mucho impacto. Creo que lo que he visto con su competencia, como dices, ustedes también están cuidando su negocio, es algo que no he visto en otro lado. Ese del impacto financiero me encanta porque yo como delivery o como consultor, a veces me es difícil que el management vea por qué un mal performance, un servicio abajo, caído o con detalles puede afectarle a su empresa.

Y no lo ven. Incluso el tema en la nube también. Claro. Donde no están conscientes cuánto está consumiendo con un mal performance. Sí. Y eso se está resolviendo yo creo que orgánicamente. Porque un management que no se da cuenta del poder

de los desarrolladores va a empezar a perder negocio y se van a estar limpiando sus management. Porque un buen CIO se da cuenta del poder del desarrollo. Que los problemas empiezan desde el desarrollo y no en la producción. Y un problema de producción no solo es de producción,

sino es un problema del código que empezó desde un inicio. Entonces, es importante tener toda la cadena desde el development, staging hasta producción, todo alineado. No, y cuando no sabes desde desarrollo atrás cómo se ha ido degradando, qué ha ido fallando. La solución de muchos en management era, voy a traducirlo un poco feo, pero aviéntale fierros,

avienta hardware y hazlo crecer porque, pues, claro, es el clásico porque les falta visibilidad. Saben que está lento y ellos piensan, si está lento, ¿qué hago? ¿Pongo más CPU? ¿Pongo más memory?

Para arreglar el problema de software. Lo tratan de arreglar con hardware. Y lo único que va a pasar es como ponerle un band-aid, ¿sabes? Una curita. Están poniendo curitas, curitas, curitas, pero no saben que ya tiene dos piernas rotas. Entonces, oye, no vas a arreglar una pierna rota con curitas, ¿no? Es un poco...

Yo pongo el ejemplo de un carro con un hoyo en el tanque de gasolina. Le podrás poner llantas más grandes, un tanque más grande que aguante más tiempo, pero sigues tirando gasolina. Es porque no tienen como un, y Dynatrace en esa analogía sería como un X-Ray. Haces el X-Ray y ves exactamente todo. Entonces, oye, mejor arreglo aquí, le doy mejor alimento, hago esto, y ya tienes la máquina funcionando bien. Tal cual en el ejemplo de carros, ¿no?

Ellos tienen un monitor donde enchufas el sensor, te agarra todo y ya sabes que estás tirando gasolina. Y es algo... Ahora, esto es cuando avientas hardware, cuando tienes esa... Digamos, los que tienen todavía on-prem en sus oficinas, en sus locaciones. ¿Qué haces con la nube?

¿Cómo lo están manejando cuandoQué haces con la nube? ¿Cómo lo están manejando cuando hay mal performance en la nube? Y no se siente. O sea, antes era de, está lento, tenemos que meter más fuerza, bla, bla. ¿Cómo le ayuda Dynatrace a transferir esto? De hecho, desde el inicio,

antes de que se vayan a la nube, a los clientes, le digo, ¿sabes qué? Puedes monitorear desde este momento ya tu aplicación y cuando la mueves a la nube, de hecho Des, le digo, ¿y sabes qué? Puedes monitorear desde este momento ya tu aplicación y cuando la mueves a la nube, de hecho, Dynatrace se da cuenta que es la misma aplicación. Y si tú te das cuenta en el SmartScape, si yo tengo mi aplicación corriendo, se va a dar cuenta que mi servicio está load balance,

una instancia está en mi on-prem y la otra está en mi nube. Puede ser ABS, puede ser Azure, y es la misma. Entonces, lo que es el cluster y el load balancing es automáticamente detectado. Y tú puedes medir y puedes hasta diferenciar las instancias. Dices, a ver, quiero ver el response time de la nube y el response time de la máquina de acá.

Entonces eso es todo automático. Entonces, oye, aparte, para moverte la nube, yo le digo a mis clientes, oye, la nube te va a costar. Y lo mejor que tienes que hacer es utilizar bien tus recursos. Que tengas, porque de hecho, tener un CPU alto en la nube te va a costar. Y lo mejor que tienes que hacer es utilizar bien tus recursos. Que tengas porque, de hecho, tener un CPU alto en la nube es algo bueno.

Significa que estás utilizando optimalmente tus recursos. Pero para eso tienes que tener visibilidad como lo estás utilizando. On-prem no les daba igual. Bueno, tengo mis servidores, ahí cargas lo que quieras. Pero acá ya no porque les cuesta. Entonces le digo, si quieres tener algo óptimo, ten visibilidad para que sepas porque son costos. De hecho, es un muy, un válido use que es para nosotros.

Es decir, ¿sabes qué? Vete a la nube, pero con visibilidad. Y así haces este recorte de costos. Acabas de describir, yo creo que el best practice, las mejores prácticas, ¿se dice? Sí, mejores prácticas. Donde es esa evolución,

¿no? Empiezas de, luego lo metes en una máquina física y después lo trepas a la nube y tienes control en cada paso.

Sí. ¿Cómo le hacemos con los que se van derechito a la nube? Bueno, la decisión ya la tomaron. Si ya están en la nube,

lo mejor es que pongan Dana 3. Sí, sí. ¿Por qué? Porque ya van a está en la nube, lo mejor es que pongan Dynatrace. ¿Por qué? Porque ya van a ver por qué está lento. Porque lo que va a pasar, yo creo que es solo una. Si la aplicación tiene errores on-prem, los va a tener en la nube. Simplemente se va a caer más rápido. Porque son máquinas mejor optimizadas.

Pero sigue siendo una máquina, sigue siendo un Linux, sigue siendo una plataforma. Lo único que va a hacer es que se va a caer más rápido, igual se va a reiniciar porque está en una plataforma orquestada, pero se va a seguir cayendo y va a tener problemas. Son problemas de software. Sí, detectas más bien inestabilidades. Exacto.

Hay el consumo excesivo tal vez, esos procesos gordos o feos, pesados, que porque en la nube son unos maquinones, así unas cosas, no lo notas, pero tienes el CPU al 100 con 5 usuarios en lugar de 5,000 que deberías. Esas son cosas que también muchos se avientan a la nube,

ah, sí, Azure me lo checa, ah, sí, Amazon tiene su... Pero no puedes ver con la profundidad. No ven la visibilidad, claro. Y lo que pasa es que dicen, bueno, mi problema es de tiempo de respuesta están resueltos. Lo que no saben es que para obtener ese tiempo de respuesta la nube automáticamente escala

imágenes, escala, por ejemplo, en ABS sería Easy To Machine, algo que se llama Auto Scaling, y le va a poner un ejército de máquinas para una aplicación que está súper ineficiente para llegar a alcanzar un cierto tiempo de respuesta con súper CPU con un montón de instancias

y les va a costar muchísimo dinero y ya no tienen el control de los costos para algo que pueden controlar desde antes No, incluso me ha tocado experiencia de primera mano empresas que quiebran o que casi quiebran porque su negocio depende de una aplicación que tienen en la nube

y van a generar dinero en esta aplicación. Es un negocio. Y de repente la cuenta de la nube les llega más alta de lo que le están cobrando a los clientes precisamente porque no tienen este cuidado. No sé si a ti te ha tocado ver algo similar, pero yo ya pasé dos veces por eso y es algo que clientes, por favor,

si no escarmientan, tienen que poder ver qué está pasando, ¿no? Claro. Y un tema que pasa mucho es prácticamente como andar manejando a ciegas. O sea, traes el carro, no sabes a qué velocidad vas, cuánta gasolina te queda en qué velocidad tienes la marcha

qué qué repercusiones has visto ¿has llegado alguna vez a un donde ya todo está en llamas? sin decir nombres claro, no puedo hablar de pero varía mucho de los verticales sin decir nombres claro no puedo hablar de mucho pero varía mucho

de los verticales hay empresas que si son mucho más ágiles que tienen invierten más en tecnología que ves

los operadores la gente mucho más más hábiles en general como manejan las máquinas el tipo de sistemas

el tipo de lenguaje bueno ahí no es tanto en tecnología es en el recurso humano gente que es capaz de también pero de lenguaje, de todo lo que me lo dejan. Bueno, ahí no es tanto en tecnología, es en el recurso humano, gente que es capaz de... También, pero es que es un poco de todo.

O sea, es gente que invierte en sus desarrolladores, que tienen buen sueldo, que tienen buenas máquinas, porque mucha gente piensa también, bueno, yo pago a mis desarrolladores, pero les doy unas máquinas con 500 de Ramón, yo qué sé, ¿sí? Sí, sí, un Pentium II ahí. Sí, exactamente. Entonces, y luego se preocupan que por qué tarda tanto el desarrollo, que por qué tarda tanto y tiene a toda la gente

frustrada, ¿no? Entonces, yo creo que es un poco de cómo piensa la cultura. Si tú te das cuenta de empresas como Google, que también chiquean, se puede decir, a los desarrolladores que les pagan, les dan desayuno, comida, hasta cervezas. Todo es gratis dentro de las empresas.

Entonces, yo creo que es mucha parte cultura y yo creo que nunca es tarde de entrar a lo que es en performance porque al final de cuentas es lo que más importa es el usuario. No, y algo que he mencionado

en veces, yo traigo esa guerra. Performance no es pruebas de carga. Y eso es algo que pasa muchísimo. Que todos quieren conocer sus métricas a través de pruebas de carga. Y también no sé si hayas tenido experiencias

donde yo lo primero que digo, necesitas conocerte antes de querer pegarle a tu sistema, ¿sabes? No sé, un carro, ¿sabes si tienes las llantas ponchadas? ¿Sabes si tiene gasolina? ¿Por qué me estás pidiendo que lo meta en una carrera de NASCAR? No sé. Es parte de...

Bueno, parte de mi trabajo también es ayudar a los clientes, cómo empezar, porque una vez que ven con Dynatrace y ven todo esto, me dicen, oye, yo pensé que tenía esta cantidad de problemas y mi deuda es mucho mayor con Dynatrace. Y yo, ¿cómo que es mayor? Me dicen, es que yo veo más problemas de los que pensaba que tenía. Ahora, la ventaja es de que ya teniendo visibilidad, uno ya es conocimiento y puedes priorizar.

Entonces, con Dynatrace te ayuda a ver exactamente dónde tienes el mayor problema de desempeño. Si yo tengo una transacción, veo que el 80% se me va en este servicio, pues optimizo eso y de 10 segundos ya a lo mejor tengo 3 segundos. No, y ya 20 mil usuarios ya los optimizaste. Exactamente. Entonces, ahora te das cuenta y priorizar. Entonces, todo eso tú lo puedes categorizar, lo creas con tu sistema de ticket, con Jira o algo así. Y puedes estar priorizando y a ver, ¿cómo le hago con mi desarrollo para optimizar? Para tener a corto plazo mejor.

Beneficios grandes. Mejor impacto, exactamente. Sí, sobre todo para mis clientes. Porque creo que es un poco como te decía, de cambio de cultura de toda la empresa. De romper silos y de saber cuáles features tienen que ir con mi usuario, que ellos no tengan problemas y cuáles features tienen que ir con mi usuario, que ellos no tengan problemas y cuáles features tengo que dar para mejorar mi negocio.

Sí, es lo que dice lo de los silos. Creo que voy a sonar un poco fuerte un cáncer en muchas empresas donde ni siquiera sabes otra área desarrolló un módulo o algo y confías en él y no sabes que es tu cuello de botella, no sabes que le está pegando a la organización. Y como no se comunica uno con otro, y desde arriba menos se va a ver el management, se vuelve un agujero negro de recursos. Impresionante.

Y en especial, como dices, sin visibilidad estamos ahí con un palo nada más como una persona ciega te doy razón primero tienen que conocer su aplicación lo que es un load test siento que es importante porque un load test es como en realidad

conoces los límites de tu sistema tienes que saber los límites de tu sistema para poderte mantener como un deployment óptimo. Oye, mi aplicación, pues yo sé que con esta máquina puedes soportar así en 200, 300 usuarios concurrentes.

O sea, ni siquiera usuarios en general, sino concurrent, que están 300 en línea ahora. ¿Conoces la resiliencia de tu sistema? Exactamente. ¿Pero sería tu primer paso? No, mi primer paso, bueno bueno, primero después de instalar Dynatrace, ver las transacciones con los usuarios que le empiezan a aplicar y ver todo de inicio a fin

y a mi me parece maravilloso con Dynatrace APMs en general, digo, estamos aquí hablando del producto pero por quitar un mal concepto del mercado, yo creo que el primerísimo paso es saber eso, cuáles son tus transacciones que están teniendo problemas.

Conocer la aplicación. Y enfócate a esos. Antes de querer correr carga, antes de ver si pasan cualquier otra cosa, si los usuarios, bla, bla, tunea a esos que generan el mayor impacto, como dices. Exactamente. Y es un mundo de diferencia. Yo creo que, de nuevo, aquí en la audiencia de Perfides Español,

hemos platicado un poquito de Pareto, donde haces unas cuantas cosas que pueden tener un impacto grandísimo y lo están aplicando tal cual, que me parece también algo no se había mencionado hasta el momento, es solucionar lo que tenga el mejor impacto o lo que tenga el peor performance, digamos.

Pues sí, es en realidad poder categorizar. ¿Qué es lo que puedes? Si tienes muy buena visibilidad con algún producto, por no decir nada, es poder categorizar. Pero es poder categorizar. Aquí estamos, no hay problema. Pero es poder categorizar, número uno.

Categorizar el impacto. ¿Cuál es lo que me está haciendo más daño? Si tú me dices, o sea, el ejemplo que me dices, está quemando, bueno, ¿qué es lo que está quemando más? El impacto categorizado, primero en usuarios, ¿puedo hacer mi negocio?

¿Puedo implicar a la aplicación y hacer la transacción. Si vendo zapatos, pues bueno, los puedo vender y seleccionar y vender. Será el número uno. Y una vez que arregle eso, ¿cuál es el siguiente y el siguiente? Porque dicho es algo continuo. Es continuous operations, continuous delivery. Y yo creo que el consejo que puedo dar,

automatizar. Tratar de automatizar todo. Tener testing y no solo load test, sino unit testing. Desde un inicio es muy importante. ¿Por qué? Cualquier cambio que haga, saber que no estoy rompiendo algo con mi nueva funcionalidad. En ese momento.

Exactamente. En el momento del cambio. Tiene que ser todo automatizado, todo. Desde que si yo hago un git commit, automáticamente, las herramientas ya están dispuestas. De hecho, desde Open Source. Tenemos nuestro proyecto, no sabes, de Keptan, que estamos en el Cloud Native Foundation.

Y automáticamente tienes Continuous Delivery, Continuous Testing, Continuous Operations. Todo automático, que es la idea. Entonces, si tienes todo automático, pues te ayuda a avanzar en el desarrollo. No, es un flujo directo, seguro, porque sabes que lo que arranca en desarrollo va por

pruebas, va por la producción. Y yo le digo un poco de experiencia, porque en mi tiempo de desarrollo siempre hay la mentalidad de que no tengo tiempo de hacer testing. Yo hago desarrollo, yo soy aquí de los buenos y yo no tengo tiempo de hacer testing. ¿Cuándo has visto algún doctor que diga, no tengo tiempo de lavarme las manos,

voy a operar el cliente así? Es el mismo problema. Me encanta esa analogía. Me la voy a piratear, perdón, pero me la voy a piratear. Es que es la verdad. Y no vuelves a ir con ese doctor si te enteras. No, es que tenemos la responsabilidad ya, algún desarrollador,

de tener esa mentalidad. Porque nuestros sistemas, o cualquier sistema que está desarrollado, tiene ya la responsabilidad ya, algún desarrollador, de tener esa mentalidad. Porque nuestros sistemas, o cualquier sistema que está desarrollado, tiene ya la responsabilidad de tener un impacto en la sociedad. O sea, porque todo ya es informática. Entonces, sistemas de electricidad, de bancos, de todo es informática. De aviones. De aviones. Y tuvimos el ejemplo.

Sí. Entonces, tenemos que tener esa mentalidad de tener una seguridad en el código, una seguridad en la ejecución. Porque algún error puede ser no solo un impacto en la pantalla de que se vea algo feo, sino un impacto. Puede ser hasta de vidas. También, exactamente. Suena un poco, alguien quiere pensar en los niños, pero sí. Pero lamentablemente no hay código de conducta de un desarrollador.

O sea, no prometemos de que, bueno, no voy a hacer un código feo para no hacer lástima a alguien. Digo, recordando días de desarrollador, así es de, ¿funciona? No entiendo al 100% por qué y no lo voy a mover. Y no entiendo por qué funciona. Y así lo meto a producción. Y nomás no lo toques porque si lo tocas se rompe. Odio admitirlo.

Yo llegué a mandar cosas así a producción. Y así de, ok, lo logré. No sé por qué funcionó, pero está muy mal. Y hoy ya un poco más. Claro, pero ya hay mucha metodología. Nosotros utilizamos también lo que es el code review. Todo lo que se comita tienes también gente. Y no solo dos ojos, sino cuatro o dos personas que hacen code review.

Y siempre se están alternando. No solo para verificarse entre ellas, sino para aprender, aprender, o sea, si yo hago un code review del departamento uno, luego lo hago del departamento dos, y así aprendo mejor la plataforma, y aprendo cómo codean los otros, y a lo mejor aprendo como algún truco de otro, y es

siempre estar mejorando, ¿no? Y con eso, también es otro tip, acabas de abrir otra mega caja de Pandora aquí, de cosas padres, porque la Pandora no era tan padre, que puede ayudar y logras que toda tu organización o todos tus developers, todo tu equipo, al final con ese culture, acaben más o menos al mismo nivel, todos entienden qué hace uno, qué hace otro Y la sinergia se vuelve increíble. Exacto, lo que le llaman el pair programming. Entonces pones algún experto con alguien nuevo para que vaya aprendiendo y las best practices y todo eso. Si no se matan los primeros días porque también... De arranque cuando no estás acostumbrado es un poquito difícil.

Pero es parte de la cultura de la empresa, ¿no? De saber que no están el uno contra el otro, sino que son un equipo. Es la parte equipo. Ese es lo más importante. Ahora, retomando un poquito que no todo mundo en Latinoamérica está tan familiarizado, platícanos rápido

qué es Keptan. ¿Qué es Keptan? Bueno, ¿sabes lo que es Kubernetes? Bueno, a ver, sí, porque hay algunos de la audiencia que no han usado Kubernetes, contenedores, cosas... Exactamente, bueno. Vamos un poquito para atrás.

Vamos un poquito para atrás y lo resolvemos un poquito rápido. Hay algo que se llama Docker. Ajá. Que salió hace, ¿cuándo fue lanzado? ¿Ya tendrá 10 años? Sí, 2004, 2006. Y bueno, fueron los contenedores, donde simplemente agarras el concepto de la máquina virtual, el VM,

y haces un nivel más de abstracción donde vas a poner tu proceso, tu Java. Y esa Java siempre va a funcionar. Tiene que funcionar tal como cual. No vas a tener, resuelves el problema de que, ah, es que mi servidor de aplicación aquí funcionaba, pero en el Windows no, y tengo otra versión, otra biblioteca, no. Ese problema ya está resuelto con el

token. El contenedor aislado es un universito. Exactamente. Y ahí corre porque corre. Exactamente. Está aislado y lo puedes versionar. Entonces, siempre tienes diferentes versiones. Y empiezas a resolver ahí con eso ya muchos problemas. Número uno. Y luego dijimos, bueno, tenemos el problema de la aplicación monolita. Ajá.

Sí. Y el problema de la monolita era de que si tienes más carga, uy, tengo que iniciar otra monolito más grande. Y era otro monolito más grande. Apagar todo, downtime, construir, bla. Y era muy caro. Entonces decimos, oye, ¿por qué no rompemos el monolito en pocos pequeños servicios? Y fue como nacieron los

microservicios. Que es un concepto que va muy bien con Docker. Dicen, ¿sabes qué? Pues estos microservicios los ponemos en procesos pequeños, en pequeños contenedores. Entonces, ese problema ya está resuelto y dices, órale, ya rompió el monolito en pequeños servicios que están corriendo en pequeños dockers. Y son mucho más efectivos y más fáciles de arreglar. Se rompe algo y yo sé exactamente cuál de los pequeños servicios está rompiendo.

Y bueno, después aparece Kubernetes. ¿Por qué? Porque para iniciar carga tienes que levantar los dockers manuales. Y Kubernetes es una plataforma de orquestación. Así como la orquesta del teatro, imagínate que esta plataforma a través de la carga automáticamente te levanta los servicios. Entonces, si tú tienes muchos login, los contenedores de login solo son los que van a crecer. Entonces, tienes una optimización de login solo son los que van a crecer. Entonces tienes una optimización de recursos óptima. Podría decirse que Kubernetes es como un termostato

que te dice, oye, tu casa se está enfriando un poco, está haciendo mucho frío y necesitas que haga un poquito más de calor con los contenedores. Kubernetes tú lo puedes imaginar. De hecho, la analogía es como si fuera un barco. Tienes barcos con contenedores. Exactamente.

Y tú tienes los brazos mecánicos y te están poniendo los contenedores en diferentes barcos. Y lo que pasa con estos barcos, ¿cómo lo complemento? Es que depende la carga, empiezan a aparecer nuevos barcos. Sí, necesitas más cajas en el barco. Exactamente.

Se dan cuenta de la carga. O sea, la carga me refiero a la carga de la carga, empiezan a aparecer nuevos barcos. Sí, necesitas más cajas en el barco. Exactamente, se dan cuenta de la carga. O sea, la carga me refiero a la carga de usuarios, de transacciones, de utilización. Y automáticamente suben y bajan servicios. Entonces, eso de un punto de vista operativo es excelente. Ya no me tengo que ocupar de esto. Ahora, Keptan entra a jugar aquí porque es como un, bueno, sí dice service mesh. Disculpa mi mezcla del pochismo muy feo.

Es difícil, lo entiendo. No hablo mucho español últimamente. El service mesh es como una, estamos desarrollando un framework donde, imagínate, tú tienes tu servicio y se lo das a Keptan. ¿Te das cuenta? Un ejemplo. Administrarlo. Sí, lo que tu servicio sería un carrito de compras, ¿no? Tú tienes tu pequeño carrito de compras de tus microservicios y se lo das a Keptan.

Y le dices a Keptan, oye, quiero tener tres stages. Development, testing y producción. ¿Sí? Automáticamente te crea los stages y te va a mover tu servicio automáticamente del development al staging, a te va a mover tu servicio automáticamente del development al staging a producción a través de puertas de calidad. Y automáticamente te va a hacer

los tests. Entonces tú le dices a Keptan, oye, quiero que me hagas este test de carga y de funcionabilidad también, donde tú los defines, por ejemplo, con JMeter o puedes tener diferentes. Aquí tenemos un partner que se llama Netsys, y defines tus test de carga,

y defines también qué es lo que vas a validar. Tiempo de respuesta, conexiones a la base de datos, tu CPU, memoria, real user experience también, puedes hacer test de Selenium, y validar todo eso automático. Entonces, una vez que ya tengas tus test, le dice a Keptan, ahora sí hazme el deployment y automáticamente te lo va a mover

de un ambiente en ambiente automático, validando y moviendo el otro ambiente. Es el potencial que tiene. Exactamente. Entonces, imagínate, cada feature, cada cosa que haces, haces el check-in, lo avientas a Keptan y él te hace los test

y si se rompe algo, te dice Keptan de regreso o Dynatrace de regreso oye, tu tiempo de respuesta ya no es como antes arréglalo la dirección es muy fuerte exactamente, y esos son los problemas que resuelve y todo está versionado y ahora tiene todavía más

si tú tienes algún problema en la producción se te olvidó algo, pasas los tiempos de calidad, pero. Si tú tienes algún problema en la producción, se te olvidó algo, pasas los tiempos de calidad, pero en la producción tienes un problema, Danetri se da cuenta automático y le dice a Keptan, oye, tu servicio tiene un problema. Entonces, por ejemplo, le puedes decir, pues, lo más fácil, hazme un rollback.

Porque yo sé que la versión 2 funcionaba mejor que la 3. No me tengo que levantar a las 3 de la mañana. Y todo. En lo que yo llego y me tomo el café. Exactamente. Está la versión 2 y ya veo qué pasa con la 3. Y con la 3 puedes ver las transacciones de ayer, antier, a nivel de código. Entonces, por eso puede ser post-mortem análisis. Y tú pudiste dormir a gusto. Y no tienes que levantarte a las 3 de la mañana.

No se muere el negocio. Exactamente. Eso es. Y es como pones tu IT en autopiloto. Es impresionante y las organizaciones que han logrado asimilar

esto, ¿qué mejoras has visto? ¿Qué podrías decir? Pues muchísimas. De hecho, están aquí hablando sobre lo que han hecho. Como Carnival o como Citrix, SAP, ¿sí? Hay un ejemplo de SAP que

bueno, monitoreó 50 mil servidores, máquinas, automáticamente y todo, bueno, con código porque la instalación del One Engine es muy sencilla, pero en 50 mil servidores, diferentes clientes,

diferentes data centers, diferentes clusters y todo automatizado. Entonces ellos pueden ver en un panel 3,000 clientes diferentes. En el instante me imagino que ese panel se ha de ver iluminado como árbol de Navidad. Sí. Si nunca había estado.

Pero tienen ya un equipo. Es que cambian su forma de ver ya la tecnología y cambian la forma de operar entonces la gente cuando ven a Adanatrix igual pueden tener miedo es que voy a perder mi trabajo de hacer mis dashboards y de operations, pues no, es que ya mejoras tu trabajo, te vas a enfocar a la innovación

y a mejorar tu producto en vez de estar atrás del monitoreo de configurar xml y a configurar tus dashboards, porque ya no lo necesitas. No perder tanto tiempo revisando. Exactamente. Cosas que a lo mejor ni siquiera necesitas revisar.

Exactamente. O hacer suposiciones. Es que yo creo que si veo esto aquí y hago mi correlación, no, es que ya no tienes que conocer correlación. Cuando pasa, lo sabes, está enfocado. Exactamente, porque tiene la mejor calidad de datos. Total eficiencia. Es impresionante lo que puede llegar a hacerse con Keptn. Le recomiendo a la audiencia echar un ojo.

Que lo prueben. Bueno, Keptn está en sus pasos iniciales. Es open source, si no me equivoco. Es open source, sí. Keptn es un proyecto open source. Acabamos de hacer la, queremos entrar o entramos ya a CNCF, que es el Cloud Native Foundation.

Y estamos dentro del rubro de Continuous Delivery y Continuous Integration. Y bueno, estamos todavía en beta. Pero invito a todos que lo intenten. Sí, sí. En la página es Keptn.sh

Y, o sea, K-E-P-T-N que lo intenten. Sí, sí, sí. En la página es Keptn.sh Ok. Y, o sea, K-E-P-T-N Keptn.sh Y, bueno, hay tutorials y también están los links a GitHub,

los links a integraciones, el download y, bueno, está el link también con Dynatrace. En Dynatrace también hay un free trial que pueden intentar

y ver lo que Dynatrace ofrece. Excelente. Bueno, ya, y sé que nos podemos pasar horas y horas aquí platicando. Claro, pero bueno, igual lo podemos hacer cuando esté en Múnich ahí otro día, hacemos otra pequeña plática. Hay que dar un RAN2, RAN3, vamos a dar mucho seguimiento de todo lo que se está aprendiendo aquí

porque estoy seguro que acá nuestros amigos que nos escuchan a lo mejor ya echamos tanta cosa que están así de espera, déjame masticar un poquito. Ahorita nada más para cerrar, primero, hermanos de Latinoamérica, dales una recomendación basada en tu experiencia

o lo que te gusta para, no sé, ser mejor vez personas, crecer, llegar lejos, llegar a Berlín, ¿qué les recomendarías? ¿En cuestión de desarrollo de tecnología o de... Bueno, si estamos ahorita hablando en cuestión de tecnología aquí en Pure Performance,

sería que aprendan nuevas tecnologías, que aprendan Kubernetes. Kubernetes es ahorita el número uno de adopción, de conseguir trabajos a nivel mundial. Es donde está ahora sí que la pasta, ¿no? Sí a nivel mundial. Es donde está la pasta. Sí, bueno, es lo que es la plataforma donde las empresas corporativas

van a correr sus aplicaciones número uno. Entonces, que aprendan Kubernetes, que aprendan lo que son los microservicios, que se dejen de la idea de que un desarrollo no tiene que ser test. Sí, o sea, es... ¿De dónde salió esa leyenda o esa cosa?

No me lo explico pero no sé cómo hemos pasado si no saben inglés que lo aprendan yo creo que es lo número uno igual no es necesario el alemán para trabajar en alemán es un muy buen programador en algún tiempo será necesario

para adaptarse a la comunidad y a la cultura pero que sepan inglés y que aprendan Kubernetes. Así es. Como sea, cualquier detalle, otro idioma, te abre infinidad de puertas. Exactamente.

Inglés es muy importante, el más hablado del mundo, creo, bla, bla, bla. Bueno, el chino. Pero siempre tener más puertas, más posibilidades. Sergio, si la audiencia quiere contactarte mandar preguntas ¿tienes presencia en redes? sí, bueno de hecho tengo una cuenta de Twitter he estado un poco flojo por ser sincero

nos pasa todo he estado trabajando mucho pero sí, creo que de hecho mi handle creo que es arroba sergioinojosa o checoinojosa ok, dale una buscada le doy una buscada y lo posteas en su página. Estás en LinkedIn, Facebook.

En LinkedIn también, claro. Sergio Hinojosa. Sergio Hinojosa en LinkedIn de Dynatrace. Así es. También. Solo hay uno. Si tienen alguna duda, preguntas o quieren pasarle algo a Diego, ahí lo pueden encontrar.

Y pues, Diego, de momento, muchas gracias. Sergio, perdón. Están tantos ahorita números., perdóname, no te preocupes Sergio pues yo creo que ahorita ya la dejamos ahí, te agradezco muchísimo el venir a la verdad ñoñear un poco porque

no gracias por la invitación que a mi soy ñoño de corazón y eres de los más apasionados que he visto en la conferencia. Estoy impresionado. Y ojalá que todos nuestros amigos tengan este empuje. Gracias. Te brillan los ojos cuando lo veo.

Está excelente. Me gusta. Me gusta la informática. Me da mucho gusto. Gracias. Muchas gracias. Y pues nos estamos escuchando. Gracias.

Muchas gracias.