WEBVTT 00:00:07.500 --> 00:00:09.722 Muy buenas tardes, Toni. ¿Qué tal estás? 00:00:10.680 --> 00:00:15.440 ¿Qué tal? Muy bien, muy contento y muy agradecido por tu invitación. 00:00:15.620 --> 00:00:21.020 La verdad que es un gustazo estar aquí y poder compartir un rato contigo, Javi, y con 00:00:21.020 --> 00:00:23.980 la comunidad. ¡Qué bien! ¿Un cafecito? 00:00:24.140 --> 00:00:27.080 Vamos a tomarnos un cafecito y vamos a hablar de Multicloud. 00:00:27.120 --> 00:00:35.120 Nos vimos en la convención de SPU y ya 00:00:35.120 --> 00:00:37.280 entonces, en septiembre, ya fechamos más o menos. 00:00:37.320 --> 00:00:41.820 Para enero hablamos de Multicloud en el podcast. 00:00:42.520 --> 00:00:47.940 Correcto, correcto. Sí, sí, sí, te empiezo contando, vamos a ponernos en contexto. 00:00:48.620 --> 00:00:54.780 Oracle Cloud World en septiembre en una de las Keynotes sale Larry Ellison con el Satya 00:00:54.780 --> 00:01:01.820 Nadella de Microsoft diciendo, amigos para siempre, ya no vamos a estar solos, el 00:01:01.820 --> 00:01:08.640 futuro en una sola cloud es totalmente imposible de concebir, es decir, tiene que ser 00:01:08.640 --> 00:01:11.480 el futuro multicloud sí o sí. 00:01:11.480 --> 00:01:17.580 Y no solo eso, sino que se pusieron a hablar de que vamos a ser vecinos y hicieron el 00:01:17.580 --> 00:01:25.040 comentario de, y podemos decir incluso que hay más velocidad, es decir, hay una 00:01:25.040 --> 00:01:32.260 comunicación mucho más fluida entre los data centers de OCIC con Azure 00:01:32.260 --> 00:01:35.840 que entre data centers de diferentes regiones. 00:01:35.840 --> 00:01:43.660 Es muy interesante que los vecinos o los cuatro grandes vecinos estemos juntos 00:01:43.660 --> 00:01:49.860 y arrancó así y todo el mundo se quedó con el culo torcido. 00:01:51.420 --> 00:01:57.240 Totalmente. Al final, haciendo un pequeño símil, los seres humanos somos animales sociales 00:01:57.240 --> 00:02:01.110 y qué mejor si podemos compartir experiencias juntos. 00:02:01.110 --> 00:02:07.840 Entonces, haciendo el símil con el cloud, cada proveedor cloud, cada IP de HyperSkyler, 00:02:07.880 --> 00:02:15.700 tiene sus fortalezas y sus debilidades y si entre ellos pueden trabajar juntos, sin 00:02:15.700 --> 00:02:18.867 duda a las empresas y a los usuarios nos irá mucho mejor. 00:02:19.720 --> 00:02:27.040 ¡Qué grande, no? Sí, sí. Dime, dime, yo quiero decir, esto es algo 00:02:27.040 --> 00:02:29.400 como bastante novedoso, ¿no? 00:02:29.420 --> 00:02:37.490 Es algo así como, dejamos de ser competidores para ser co -competidores, ¿no? 00:02:37.510 --> 00:02:40.490 Hacer una competencia colaborativa, ¿no? 00:02:40.770 --> 00:02:45.250 Es algo totalmente... Sí, es algo completamente novedoso. 00:02:45.890 --> 00:02:52.940 Además, desde el punto de vista de Oracle es incluso un cambio de estrategia muy 00:02:52.940 --> 00:02:59.860 interesante y que yo estoy convencido que sin duda a las empresas nos va a traer unos 00:02:59.860 --> 00:03:07.070 enormes beneficios. Azure tiene unas enormes fortalezas Oracle tiene una tradición Empresarial 00:03:07.070 --> 00:03:14.130 brutal Que todos conocemos perfectamente En el mundo Cloud Han sido de los 00:03:14.130 --> 00:03:21.200 cuatro Grandes Los últimos en estar ahí De hecho, bueno, este Si no me 00:03:21.200 --> 00:03:28.260 falla la memoria Creo que han sido por fin ascendidos En el cuadrante de Gartner Al cuadrante 00:03:28.260 --> 00:03:35.260 de líderes Por primera vez lo que se ve como como los vecinos se cada vez están 00:03:35.260 --> 00:03:42.330 más juntitos y La necesidad de que estén juntos en región, que eso también es como muy 00:03:42.330 --> 00:03:46.790 sorprendente, es decir, no sólo vamos a dejar, entre comillas, de hacernos de competencia 00:03:46.830 --> 00:03:53.910 hostil, ¿no?, o en pensar quién le va a comprar la nube al al otro, sino 00:03:53.940 --> 00:04:02.060 vamos vamos a estar juntos y vamos a mostrar esas alianzas de 00:04:02.100 --> 00:04:08.500 cara al público, ¿no?, vamos a decir que él es bueno y yo también soy bueno, correcto, 00:04:08.500 --> 00:04:13.380 la ciudad es bueno, a dobles es bueno, vamos a nombrar cuáles son los cuatro grandes, 00:04:13.380 --> 00:04:20.460 esos cuatro grandes vecinos, como decías tú, en lo que hemos estado un poquito 00:04:20.460 --> 00:04:22.380 hablando, ¿no?, Hyperscaler. 00:04:22.480 --> 00:04:26.980 Tendríamos que poner un botón de cada palabrejo raro definirlo. 00:04:28.740 --> 00:04:30.407 Hyperscaler, proveedor grande. 00:04:31.620 --> 00:04:34.453 Aquí estamos hablando de los cuatro grandes, que es 00:04:35.380 --> 00:04:42.680 Microsoft con Azure, Google con GCP, con Google Cloud y Amazon con AWS, 00:04:43.280 --> 00:04:50.940 que fue el primero, además, en empezar en el mundo del cloud con los 00:04:50.940 --> 00:04:58.200 hyperscalers y por último y no menos importante por supuesto oracle con ozzy y 00:04:59.760 --> 00:05:04.520 Los cuatro grandes están dispuestos ya están están dispuestos a ser vecinos o solamente 00:05:04.560 --> 00:05:12.160 solamente Microsoft con Oracle o los 00:05:12.160 --> 00:05:19.170 otros ya han dicho en el caso En el caso de la vecindad física, es 00:05:19.170 --> 00:05:26.170 cierto que entre Oracle y Microsoft hay unos acuerdos muy potentes 00:05:26.170 --> 00:05:35.130 que simplifican mucho a los clientes la integración entre los dos hyperscalers, 00:05:35.230 --> 00:05:41.650 pero también es cierto que físicamente, por ejemplo, en España, somos un país que somos 00:05:41.650 --> 00:05:48.700 unos afortunados. En el sentido de que los cuatro han 00:05:48.700 --> 00:05:54.760 abierto o van a abrir muy próximamente regiones en España, o en Madrid o en Zaragoza. 00:05:55.180 --> 00:06:03.060 Lo que desde el punto de vista de conectividades y latencias es brutal las capacidades 00:06:03.060 --> 00:06:08.920 que eso abre. Y en otras partes del mundo, como Latinoamérica, estamos viendo como Oracle 00:06:08.920 --> 00:06:15.920 está redoblando la apuesta, desplegando prácticamente regiones en 00:06:15.920 --> 00:06:21.280 cada país. Recientemente, si no me falla la memoria, en Colombia. 00:06:22.920 --> 00:06:28.140 ¿Y van a estar juntos, juntos, juntos, en la misma región los cuatro? 00:06:28.540 --> 00:06:32.000 Es decir, ¿vamos a tener ese vecindario real, físico? 00:06:37.170 --> 00:06:39.570 Vamos a ver, juntos pero no revueltos. 00:06:41.190 --> 00:06:47.850 Bueno, es que es lo que dijo Oracle, dijo tenemos el datacenter de Microsoft y el de 00:06:47.850 --> 00:06:52.970 Oracle lo tenemos puerta con puerta de forma que tiramos un cable y nos va más rápido 00:06:52.970 --> 00:06:59.050 eso que hablar con el resto de regiones si, eso es cierto en el caso de Madrid sí que 00:06:59.050 --> 00:07:00.570 están físicamente muy cerca 00:07:02.980 --> 00:07:12.710 En España además, además, hay un tema que es muy importante, que es que Oracle va a 00:07:12.710 --> 00:07:18.210 abrir una segunda región con lo que le llaman región soberana. 00:07:18.290 --> 00:07:25.320 Esto significa que Las cuatro empresas de las 00:07:25.320 --> 00:07:31.080 que estamos hablando son empresas que son americanas, que dependen de una manera u otra 00:07:31.080 --> 00:07:32.660 bajo legislación americana. 00:07:32.660 --> 00:07:36.382 Hablamos, por ejemplo, de la Patriot Act en un momento determinado. 00:07:36.760 --> 00:07:38.482 ¿Qué significa región soberana? 00:07:38.540 --> 00:07:45.690 Significa que tú vas a poder tener tus cargas en una región que 00:07:45.880 --> 00:07:50.800 está amparada 100 % sobre empresas europeas y sobre legislación europea. 00:07:51.470 --> 00:07:56.730 Entonces, estos sectores altamente regulados tienen unas capacidades también muy potentes. 00:07:59.760 --> 00:08:07.720 Incluso estamos hablando desde el punto de vista de las empresas que gestiona 00:08:07.720 --> 00:08:14.750 esa región, los técnicos están en Europa y desde el punto de 00:08:14.750 --> 00:08:17.570 vista legal están amparados 100 % sobre leyes europeas. 00:08:17.610 --> 00:08:26.140 Lo que comentabas de físicamente en el mismo edificio, si es cierto, de 00:08:26.140 --> 00:08:32.800 hecho uno de los puntos que se anunció en el Cloud World es, bueno, hasta el Cloud World 00:08:32.800 --> 00:08:40.000 de este año había un acuerdo donde tú podías tener un entorno multicloud, 00:08:40.100 --> 00:08:47.740 ahora que es Microsoft, Bueno, con una consola multicloud y que utilizando 00:08:47.740 --> 00:08:53.800 ExpressRoot y FastConnect, entre los dos hiperescalers tenías unas latencias de 2 -3 00:08:53.800 --> 00:09:00.100 milis dentro de la misma región y podías tener, por ejemplo, tu autónomo database en 00:09:00.100 --> 00:09:06.300 OCI y tu parte de aplicación en Azure con esas latencias de 2 -3 milis. 00:09:06.300 --> 00:09:14.260 El salto importante de este año es que vas a poder tener tus exa -datas en 00:09:15.090 --> 00:09:20.590 el datacenter de Azure, con latencias inferiores a un milisegundo. 00:09:20.750 --> 00:09:27.940 Lo que en aplicaciones super críticas y muy sensibles a latencias es un salto 00:09:27.940 --> 00:09:29.980 también cualitativo y cuantitativo. 00:09:30.490 --> 00:09:35.350 Además que refleja muy bien la alianza y otro punto que en mi opinión también refleja 00:09:35.350 --> 00:09:39.170 muy bien la alianza es, no sé si visteis la noticia que Microsoft 00:09:40.470 --> 00:09:45.790 Está utilizando OCI para todos los procesos de 00:09:46.750 --> 00:09:48.250 inteligencia artificial con 00:09:49.310 --> 00:09:56.550 Con Copilot y con Bing Lo que es lo que da 00:09:56.550 --> 00:10:01.130 un mensaje muy importante al mercado, es decir la propia Microsoft que tiene Azure, Azure 00:10:01.170 --> 00:10:05.970 está utilizando OCI para los procesos de inteligencia artificial de Bing. 00:10:08.110 --> 00:10:10.750 Yo entiendo que también hay mucho marketing ahí detrás, ¿no? 00:10:10.790 --> 00:10:17.950 Es decir, da un golpe de efecto en que tú utilizas mi tecnología 00:10:17.950 --> 00:10:23.370 y yo también diré que utilizo Azure en otra cosa, ¿no? 00:10:26.410 --> 00:10:29.950 Sí, evidentemente seguro que hay una parte de marketing, si no, aunque se hiciera, no 00:10:29.990 --> 00:10:37.400 se diría. Eso es, esto es evidente, pero también es 00:10:37.400 --> 00:10:42.820 cierto que Oracle por ejemplo ha hecho una apuesta, ha redoblado la apuesta. 00:10:44.560 --> 00:10:48.120 Comprando toda la producción de NVIDIA del año 2024. 00:10:50.540 --> 00:10:54.880 Ah, si es verdad, es verdad, si, si me había comprado todo 00:10:57.200 --> 00:11:02.300 Que nos van a dejar sin tarjetas gráficas para poder jugar al GTA VI, ¿veis? 00:11:02.720 --> 00:11:05.580 Sí, no, y ya no miramos Bitcoin. 00:11:08.340 --> 00:11:12.530 Totalmente, totalmente. ¡Qué bueno! 00:11:13.490 --> 00:11:16.230 Vamos a hablar, si te parece, aparte del multicloud. 00:11:16.270 --> 00:11:20.970 Mira, a mí es una de las cosas más interesantes de multicloud y sobre todo derivado también 00:11:21.010 --> 00:11:22.750 de la charla que nos dio en el 00:11:24.030 --> 00:11:26.990 SPU Saipen Umuru. Bueno, y también 00:11:28.070 --> 00:11:30.410 Rubén nos dio una charla también. 00:11:30.470 --> 00:11:33.230 Hicieron los dos también charlas sobre FinOps. 00:11:34.050 --> 00:11:39.410 Es importante e interesante que se esté planteando también desde un punto de vista de 00:11:39.410 --> 00:11:46.640 una certificación oficial de FinOps y toda una cultura de FinOps de forma 00:11:46.640 --> 00:11:51.800 abierta en el que todos, todos los jugadores están reconociendo, es que quizá para lo 00:11:51.800 --> 00:11:59.220 que yo hago no soy el más barato al cien por cien en todos los componentes pero sí puedo 00:11:59.220 --> 00:12:05.300 ser barato en ciertos componentes que necesitas y en otros componentes, por eso es buscar 00:12:05.300 --> 00:12:12.980 ese coste efectivo, no tenerlos en una en una cláusula al lado, no tener ciertos 00:12:12.980 --> 00:12:18.800 ciertas cosas en el suro en aws y ciertas cosas en oracle si podemos hacer una configuración, 00:12:18.800 --> 00:12:23.880 no una una Una configuración a medida personalizada en el cual a nivel financiero, con 00:12:23.880 --> 00:12:27.840 toda esta cultura de FinOps, te salga más barato. 00:12:27.940 --> 00:12:31.760 Es decir, el retruque te salga barato a todos los efectos. 00:12:32.590 --> 00:12:36.970 Entonces, ¿tú cómo ves este tema de FinOps con el multicloud? 00:12:37.730 --> 00:12:40.119 ¿Está afinado la gente? ¿Está concienciada? 00:12:40.310 --> 00:12:44.850 Esto ya es chafardería, es curiosidad. 00:12:44.850 --> 00:12:50.250 ¿Sabes de gente que se ha pegado un batacazo por no haber controlado bien temas así de 00:12:50.250 --> 00:12:57.530 de finops y de finanzas no finops estamos hablando de la finanza en operaciones 00:12:57.530 --> 00:13:03.070 o al revés de esa gente que ha dicho bueno es que si Te montas una configuración de esta 00:13:03.070 --> 00:13:06.430 en que tanto lo tienes sonará que tanto 35 tanto tenéis en el sur donde es una doble 00:13:06.470 --> 00:13:09.550 s te puedes ahorrar en la mitad del el presupuesto. 00:13:10.550 --> 00:13:12.370 ¿Sabes tú? ¿Tienes cositas así? 00:13:12.450 --> 00:13:13.650 ¿Tienes conocimiento de...? 00:13:13.690 --> 00:13:20.960 Vamos a ver, conozco casos de que cuando tú haces una migración 00:13:20.960 --> 00:13:28.020 hacia cloud hay ciertos costes, no denominaría costes ocultos, 00:13:28.020 --> 00:13:33.650 pero a lo mejor sí que hay ciertos gaps que hacen hacen que luego los costes se puedan 00:13:33.650 --> 00:13:40.660 ir. Y aquí, bueno, y esto es un buen diseño de una landing zone, 00:13:40.720 --> 00:13:42.500 hace que los costes puedan ser más contenidos. 00:13:42.540 --> 00:13:47.760 Hablo, por ejemplo, de un gap que hay habitualmente, que es cuando tú estás trabajando 00:13:47.760 --> 00:13:53.110 en on -prem, los costes de comunicaciones, no tienes costes por tráfico. 00:13:53.270 --> 00:14:00.270 Tú pagas canuto y de entrada salía internet Y el tráfico 00:14:00.270 --> 00:14:06.670 que hay entre máquinas, más allá de los propios costes de electrónica de red, no suele 00:14:06.800 --> 00:14:08.189 tener un coste adicional. 00:14:09.100 --> 00:14:17.160 Cuando tú, por ejemplo, en algún otro hyperscaler, el tráfico atraviesa VPCs, 00:14:17.420 --> 00:14:21.100 los euros empiezan a caer. 00:14:21.100 --> 00:14:26.040 O cuando atraviesa suscripciones entonces 00:14:27.240 --> 00:14:34.280 Un buen diseño sobre eso es clave dicho esto en el caso de el 00:14:34.280 --> 00:14:41.500 reto más grande cuando tú tienes un escenario ya de per se un reto 00:14:41.500 --> 00:14:49.240 que cuando tú haces tu primer movimiento hacia cloud es 00:14:49.240 --> 00:14:56.460 bueno Bueno, yo creo mi cuenta, abro cloud .oracle .com, meto mi correo, 00:14:56.460 --> 00:15:02.980 meto mi tarjeta de crédito o hablo con el equipo comercial de Oracle que me facilita 00:15:02.980 --> 00:15:05.290 unos créditos y empiezo a trabajar. 00:15:05.290 --> 00:15:12.460 Pero en empresas más pequeñas 00:15:12.460 --> 00:15:14.700 se suele empezar así. ¿Qué es lo que pasa? 00:15:14.740 --> 00:15:22.450 ¿No tienes en cuenta temas como pueden ser temas de gobierno, temas de seguridad, temas 00:15:22.450 --> 00:15:29.710 de networking para hacer una topología hub and spoke que te permita, desde 00:15:29.710 --> 00:15:33.210 el punto de vista de gestión de costes, tenerlo más organizado? 00:15:34.050 --> 00:15:40.100 Entonces esa parte Toda inicial que la haces así con un poco de prisa corriendo porque 00:15:40.100 --> 00:15:44.920 quieres empezar a trabajar, sobre todo aquellas empresas que empezamos a trabajar con 00:15:44.920 --> 00:15:46.698 Cloud hace muchos años cuando no 00:15:47.620 --> 00:15:50.620 Ni siquiera el concepto de landing zone existía mucho. 00:15:52.560 --> 00:15:58.900 De repente te das cuenta que de tus costes, tus costos de infraestructura subyacente 00:15:58.900 --> 00:16:02.860 se te han disparado, y ahí es cuando empiezas a pensar, vale, ¿cómo le doy una vuelta 00:16:02.900 --> 00:16:06.178 a esto? Para conseguir que el cloud no se me vaya de madre. 00:16:07.620 --> 00:16:11.460 Y entonces empiezas a aplicar diferentes estrategias. 00:16:11.580 --> 00:16:14.358 Esto en un cloud, si ya tenemos diferentes clouds, 00:16:15.840 --> 00:16:19.820 Donde ya tienes que aplicar políticas de gobierno entre diferentes clouds, tienes que 00:16:19.860 --> 00:16:27.120 aplicar políticas de tal impasse, que es un elemento clave para el correcto manejo 00:16:27.120 --> 00:16:33.640 de FinOps. Bueno, es un aprendizaje, en el fondo es un aprendizaje continuo. 00:16:35.320 --> 00:16:36.709 No sé si me he explicado. 00:16:36.810 --> 00:16:41.930 Sí, sí, sí yo el primer batacazo lo veía en coste de CPU. 00:16:42.270 --> 00:16:47.250 Es algo que cuando tú estás en on -premise das por supuesto que tú ya tienes la máquina 00:16:47.250 --> 00:16:53.510 comprada y si tienes, imagínate, 16 CPUs, le lances lo que le lances, eso no va a escalar 00:16:53.510 --> 00:16:57.170 automáticamente y te va a dar un susto. 00:16:57.190 --> 00:17:02.070 Es decir, todo es sobre CPU que ya tienes a lo que te organizes o a lo que distribuyes, 00:17:02.130 --> 00:17:09.810 ahí no hay ningún impacto, pero en ciertas configuraciones de auto scale ostras 00:17:09.940 --> 00:17:17.060 de pronto lanzas una ejecución que se va de una burra de procesos y empieza a consumir 00:17:17.060 --> 00:17:24.240 recursos y empieza el ocia a auto proveer aumentar cpu si a provisionar 00:17:24.240 --> 00:17:31.800 se estos yo creo que tampoco se tiene en cuenta cuando uno hace el cuadro 00:17:31.800 --> 00:17:37.040 de me voy a ir a me voy voy a ir a cloud, porque dice tengo 16 CPUs pues pagaré 16 CPUs 00:17:37.040 --> 00:17:41.360 en cloud no tiene esa visión de que eso de pronto 00:17:42.340 --> 00:17:44.360 se puede ir de madre a nivel de 00:17:45.260 --> 00:17:51.240 costes correctos y cuando se da una situación de ese tipo y esto varía mucho en cada 00:17:51.240 --> 00:17:55.518 hiper -skiller, a veces tienes que tomar una decisión entre la mala y la peor 00:17:55.720 --> 00:18:00.720 Imagina que tú estás lanzando un proceso, me lo invento, un cierre mensual de facturación. 00:18:01.900 --> 00:18:06.100 Que por un fallo de código de repente te ha pasado a consumir 10 veces más de recursos, 00:18:06.140 --> 00:18:12.660 eso. Compren, tardará más, tardará menos, pero el coste es fijo en 00:18:14.170 --> 00:18:19.910 Cloud que haces le pones un soft limit de manera que te lanzó un warning diciendo oye 00:18:19.910 --> 00:18:26.490 que esto se está yendo de madre y te has pasado la previsión de presupuesto para esta 00:18:26.490 --> 00:18:32.750 para esta para este entorno y el proceso sigue o le aplicas un hard limit que para el 00:18:32.750 --> 00:18:37.710 proceso y Y que a lo mejor te quedas sin el cierre de facturación. 00:18:38.450 --> 00:18:41.050 Me ha gustado eso de entre la mala y la peor. 00:18:41.970 --> 00:18:45.026 Tienes que tener una decisión mala o una decisión peor. 00:18:49.910 --> 00:18:51.799 Yo la veo un poco así, pero bueno. 00:18:52.190 --> 00:18:54.523 Sí, sí, sí, pero es que es la pura verdad. 00:18:54.750 --> 00:18:59.180 Es la pura verdad. Claro, yo creo que esto... 00:18:59.180 --> 00:19:00.620 ¿Tú cómo ves la situación? 00:19:00.660 --> 00:19:04.720 Yo veo que la gente sigue siendo... 00:19:05.200 --> 00:19:08.940 Esto de que todo el mundo se haya ido a la nube ya, no todo el mundo se ha ido a la nube, 00:19:08.980 --> 00:19:14.480 todo el mundo tiene su reticencia y yo creo que también el escoger entre cuatro, en el 00:19:14.480 --> 00:19:20.260 que estamos hablando del multi -cloud, también hace que la gente tarde más o se tenga 00:19:20.260 --> 00:19:23.520 que pensar mucho más cuál es la configuración. 00:19:25.870 --> 00:19:33.040 Porque, claro, es decir, entre diferentes fabricantes va a haber diferentes casuísticas 00:19:33.040 --> 00:19:39.660 o diferentes problemas heredados de comunicaciones o de implantaciones. 00:19:40.480 --> 00:19:46.000 ¿Cómo se hace ese estudio previo sin revelar ningún dato confidencial? 00:19:46.120 --> 00:19:52.160 ¿Cómo se hace ese estudio previo de ver lo que tiene alguien montado y pensar, vale, 00:19:52.320 --> 00:19:58.500 venga, pues por aquí vamos a ahorrar, por aquí vamos a ganar más, por aquí vamos a perder. 00:19:58.820 --> 00:20:02.100 ¿Cómo lo enfocas tú cuando haces esto? 00:20:04.240 --> 00:20:06.560 Primero, entendiendo las preferencias del cliente. 00:20:06.600 --> 00:20:08.460 Y aquí es un punto importante. 00:20:09.780 --> 00:20:14.860 Hay clientes que tienen preferencias por A, otros por B, otros por C y otros por D. 00:20:16.530 --> 00:20:20.090 Independientemente de que la solución técnica que pueda dar uno u otro sean mejores, 00:20:20.130 --> 00:20:27.810 a veces hay, por confianza, falta de confianza, por acuerdos marco, 00:20:27.810 --> 00:20:33.140 por el motivo que sea, que un hyperscriber se cae de la ecuación. 00:20:35.940 --> 00:20:41.940 Hecho ese primer cribado, el segundo es: ¿qué cargas de trabajo voy a mover a cloud? 00:20:43.330 --> 00:20:45.610 Y ver qué tiene más sentido. 00:20:45.610 --> 00:20:52.880 Y dentro del que tiene más sentido, si estamos hablando de una empresa, vamos 00:20:52.880 --> 00:20:59.850 a hacer un escenario hipotético de una empresa que quiere mover unas bases de datos Oracle, 00:21:00.150 --> 00:21:05.030 que tiene una parte de middleware con WebLogic, que tiene unas máquinas virtuales como 00:21:05.030 --> 00:21:08.150 en torno a Windows y que tiene además unos SQL Server. 00:21:08.150 --> 00:21:14.170 Vamos a inventarnos un caso, un ejercicio de ese tipo, entonces tú empiezas a pensar 00:21:15.420 --> 00:21:18.200 ¿Dónde tiene más sentido que mueva mis bases de datos Oracle? 00:21:18.240 --> 00:21:21.018 ¿Dónde tiene más sentido que mueva mis SQL Server? 00:21:21.500 --> 00:21:28.900 A priori claro, aquí a priori esto es fácil, esto es fácil, esto es fácil ya ves que 00:21:28.900 --> 00:21:35.110 he ido a algo fácil Entonces, pues de primeras empiezas a intentar orientar las cargas 00:21:35.110 --> 00:21:43.320 a lo que Tiene más sentido desde el punto de vista de negocio, incluso buscando 00:21:43.320 --> 00:21:52.000 una posterior una posterior transformación cuando te planteas un journey to cloud y tú 00:21:52.540 --> 00:21:58.260 y tú partes de una infraestructura una infraestructura tradicional donde tienes en máquinas 00:21:58.260 --> 00:22:05.320 virtuales que entre buenos servidores que entre todos ellos componen un 00:22:05.320 --> 00:22:07.680 nuevo servicio a una aplicación, ¿cómo 00:22:08.610 --> 00:22:09.950 vas a hacer esa migración hacia cloud? 00:22:09.990 --> 00:22:13.510 Vamos a hacer migración, vamos a hacer un defensive. 00:22:15.050 --> 00:22:20.640 Defensive significa cojo los servidores que tengo en un premio y los pongo a funcionar 00:22:20.640 --> 00:22:26.100 en cloud. O bien planteo escenarios más o menos transformadores. 00:22:27.390 --> 00:22:34.480 Y un ejemplo de un escenario, a lo mejor no 00:22:34.480 --> 00:22:41.400 muy transformadores, es, yo tengo mi base A2 alrededor de aquel 19C que en un premio 00:22:41.400 --> 00:22:46.670 la tengo sobre un rack, ¿a dónde me la llevo? 00:22:46.910 --> 00:22:53.270 La despliego en OCI y la despliego sobre un Autonomous, una del CS 00:22:56.450 --> 00:23:00.210 Entonces, en el momento que tú haces eso, tú ya has hecho una transformación de algo 00:23:00.250 --> 00:23:08.320 que era infraestructura en tu entorno en premio a base de datos como servicio, ya 00:23:08.320 --> 00:23:12.240 se ha hecho una transformación, pero todo el resto de los elementos de la aplicación 00:23:12.280 --> 00:23:17.980 tienes que o transformarlos o migrarlos con una estrategia de defense shift de ese servidor. 00:23:20.330 --> 00:23:21.719 ¿Cómo haces este estudio? 00:23:23.030 --> 00:23:24.919 Aplicación, aplicación en el fondo 00:23:27.050 --> 00:23:29.190 Por mucho de que la gente de 00:23:30.170 --> 00:23:31.948 infraestructura a veces pensemos 00:23:32.440 --> 00:23:39.400 en servidores, en redes redes, en máquinas virtuales, en firewalls y cosas de estas, 00:23:40.250 --> 00:23:45.150 en el fondo lo que al negocio le importa son las aplicaciones y lo que tenemos que pensar 00:23:45.190 --> 00:23:52.250 es, tengo la aplicación Discord, la aplicación Discord, ¿qué 00:23:52.380 --> 00:23:53.780 elementos requiere para funcionar? 00:23:53.820 --> 00:24:00.940 Vale, pues requiere unos balanceadores, requiere unos contenedores de 00:24:00.940 --> 00:24:06.780 cavernets, requiere una base de datos o un Oracle o un Mongo me lo estoy inventando 00:24:08.260 --> 00:24:12.640 Vale, veamos con cada uno de esos servicios, cuál es la mejor estrategia. 00:24:14.040 --> 00:24:18.360 O incluso a veces no es la mejor estrategia, la estrategia viable para hacer una migración 00:24:18.400 --> 00:24:23.390 dentro de la ventana de cambio que podemos tener, y luego 00:24:24.520 --> 00:24:29.240 esto en día cero y en paralelo, y esto es uno de los puntos clave cuando tú migras a 00:24:29.240 --> 00:24:34.740 cloud, tenemos que empezar a pensar qué transformaciones vamos a hacer si queremos hacer 00:24:34.740 --> 00:24:41.380 que la migración a cloud sea realmente efectiva en coste en el sentido de que 00:24:42.730 --> 00:24:47.510 Si nos planteamos que una migración hacia cloud vamos a coger nuestra infraestructura 00:24:47.510 --> 00:24:52.300 en un premio y la vamos a poner a funcionar en cloud y per se vamos a ahorrar dinero 00:24:53.030 --> 00:24:59.900 lo normal es que nos haga algo muy bien cuenta cuéntame más 00:25:04.060 --> 00:25:11.140 Por ese camino Que no salga muy bien en el sentido de 00:25:11.140 --> 00:25:15.960 que bueno si tú tienes unos costes de una 00:25:17.460 --> 00:25:24.480 Infraestructura que a lo mejor tienes ciertos y ciertos ratios de configuración de CPU 00:25:24.480 --> 00:25:29.860 en un entorno virtual, vamos a hablar de VMware, y pasas a hablar de un entorno cloud 00:25:29.860 --> 00:25:35.480 donde esos ratios de CPU no existen porque en el caso, por ejemplo, de OCI una CPU es 00:25:35.480 --> 00:25:39.240 una CPU física con las ventajas que ello conlleva 00:25:40.150 --> 00:25:44.830 y tú te planteas que tú tienes una aplicación, me la invento, que está corriendo una 00:25:44.830 --> 00:25:46.941 máquina virtual con una base de datos. 00:25:48.660 --> 00:25:55.840 Con Oracle más una máquina virtual con WebLogic, ambas bases de datos con 30 00:25:55.840 --> 00:26:02.840 gigas de RAM y 50 teras de discos por si 00:26:02.840 --> 00:26:06.960 acaso, porque en on -prem muchas veces dimensionas por si acaso para el crecimiento futuro 00:26:07.000 --> 00:26:12.160 porque no tienes la flexibilidad que te da el cloud y tú haces ese movimiento, le das 00:26:12.160 --> 00:26:18.220 cifras hacia cloud ese por si acaso que tú en on -prem lo tienes para crecimiento futuro, 00:26:18.440 --> 00:26:25.740 en cloud a priori ya lo estás pagando entonces cuando no lo necesitas yo en eso estoy 00:26:25.740 --> 00:26:32.260 de acuerdo en que yo además conozco clientes que han hecho una migración a cloud pero 00:26:32.260 --> 00:26:36.740 no es una migración tal cual es lo que han hecho es decir y siguen gestionando en las 00:26:36.780 --> 00:26:43.780 infraestructuras como se gestionarán en hombre no por ejemplo tienen disco libre disco 00:26:43.780 --> 00:26:51.140 libre que no usan ni van a usar durante meses y no lo desalojan por ejemplo No sé 00:26:51.140 --> 00:26:57.160 si es un tema muy habitual y bueno, esa es la parte más básica, pero luego está la parte 00:26:57.160 --> 00:27:03.280 de desplegue de infraestructura, desplegarla de manera tradicional, la gestión del ciclo 00:27:03.280 --> 00:27:08.280 de vida de la infraestructura, hacerlo de manera tradicional, la gestión del ciclo de 00:27:08.280 --> 00:27:13.740 vida de la aplicación, hacerlo de manera tradicional en lugar de transicionar hacia un 00:27:13.740 --> 00:27:21.570 modelo de box. Y aquí, bueno, igual nos salimos un poco del scope de nuestro café 00:27:23.600 --> 00:27:29.640 Pero al final son todo derivadas de que 00:27:31.160 --> 00:27:38.100 En mi opinión el salto hacia el cloud no es el fin del camino, es el principio de un 00:27:38.100 --> 00:27:45.240 nuevo camino uff Bueno, y además como una nueva 00:27:45.240 --> 00:27:51.260 forma de conceptualizarlo todo, porque es como decías, es decir, antes en el hombre tú 00:27:51.260 --> 00:27:58.260 estás entendiendo una Filosofía de en casa tengo todo 00:27:58.260 --> 00:28:03.540 es decir yo tengo como tengo tengo mi garaje con todas mis piezas con todas mis herramientas 00:28:03.540 --> 00:28:10.160 y con todo con todo lo que lo que necesito y no tengo ninguna sorpresa pero claro transicionar 00:28:10.160 --> 00:28:14.900 al cloud uno puede transicionar con bar y metal todo venga pues Pues para hacerlo igual 00:28:14.940 --> 00:28:21.520 a lo que tengo, venga, pues máquinas dedicadas, sistemas dedicados, disco... 00:28:22.080 --> 00:28:27.140 Correcto, eso tiene que ir a una filosofía de voy a compartir, voy a compartir espacio, 00:28:27.520 --> 00:28:34.650 voy a... Claro, tú te puedes plantear en día cero de migración, pues 00:28:35.030 --> 00:28:41.550 mantengo el escenario actual, pero pensando ya en las transformaciones posteriores, si 00:28:41.550 --> 00:28:45.750 realmente quieres una reducción de costes, pero sobre todo más allá de la reducción de 00:28:45.790 --> 00:28:49.512 costes si quieres aprovechar todas las ventajas que te da el cloud. 00:28:49.920 --> 00:28:53.753 Desde el punto de vista de estabilidad, de escalabilidad de seguridad 00:28:55.340 --> 00:29:01.680 Sino al final lo que has cambiado son las cargas de sitio, pero no, todos los servicios 00:29:01.680 --> 00:29:09.260 maravillosos que te puede ofrecer el cloud no los estás aprovechando 00:29:09.260 --> 00:29:16.320 ni diría que incluso disfrutando y tus usuarios aprovechándose 00:29:16.320 --> 00:29:21.990 de dichas ventajas. Esta parte es muy interesante. 00:29:22.910 --> 00:29:29.270 ¿Tú cuánto crees que se tarda en llegar, partiendo que a lo mejor es un poco una quimera, 00:29:29.330 --> 00:29:34.490 ese escenario ideal o esa arquitectura totalmente optimizada? 00:29:35.050 --> 00:29:38.770 Ese journey to cloud es un poco como seguir el horizonte, que a medida que cuanto más 00:29:38.810 --> 00:29:44.070 vas avanzando, el horizonte más lejos va estando, quizá, pero ¿cuánto dirías que se tarda 00:29:44.070 --> 00:29:49.410 entre una empresa media contando que no haya cosas extrañas? 00:29:49.410 --> 00:29:50.910 Ahora te pondré un ejemplo. 00:29:52.150 --> 00:29:57.490 En migrar a Cloud y en el momento que llega al día cero, el día de migración no es el 00:29:57.490 --> 00:30:04.410 final, como dices tú al principio ¿cuánto tarda en asentarse y en decir, vale pues cuenta 00:30:04.410 --> 00:30:06.854 que a lo mejor en los dos primeros años esto 00:30:08.030 --> 00:30:12.530 Vas a perder más que que ganar y a partir del segundo año ya has optimizado la plataforma? 00:30:12.570 --> 00:30:14.681 ¿Cuánto tiempo crees que la gente está 00:30:16.320 --> 00:30:21.670 En esa transición? Es una pregunta difícil. 00:30:23.370 --> 00:30:27.970 Y... en general, según tu experiencia, que nos estamos tomando un café, que no somos 00:30:28.010 --> 00:30:30.110 de Oracle. Sí, no, no, no sé. 00:30:33.110 --> 00:30:37.470 Por eso la pregunta, la respuesta tiene que tener un cierto sentido. 00:30:41.110 --> 00:30:48.890 Es difícil porque, para llegar a aprovechar todo eso, hay mucho impacto en las aplicaciones, 00:30:48.990 --> 00:30:56.490 en los equipos de TI, que incluso se generen proyectos para esa transformación; no 00:30:57.160 --> 00:31:03.920 sé, a lo mejor estamos hablando de que un proyecto de migración, una empresa media, pues 00:31:03.920 --> 00:31:11.020 a lo mejor te puede llevar un año, un año y medio, y, por lo otro, tanto de hacer optimizaciones 00:31:11.020 --> 00:31:13.740 que supongan ventajas significativas. 00:31:14.300 --> 00:31:16.411 Ahora bien, ¿cuándo termina el camino? 00:31:17.180 --> 00:31:22.450 Yo, si hay algo que he aprendido en informática, es que cuanto más sé, menos sé. 00:31:24.510 --> 00:31:31.850 Y creo que el camino de la optimización y del cloud en este momento un 00:31:31.850 --> 00:31:38.150 poco se desalina, que es cuando tú crees que has llegado con el grado de, aún cuando 00:31:38.150 --> 00:31:42.930 tú has llegado al punto que te habías marcado en 2022 y estás en 2024, ya has llegado, 00:31:42.930 --> 00:31:49.880 han sacado, han salido los supercracks de oro, que lo de Asur, y han dicho, oye, mira, 00:31:49.880 --> 00:31:55.960 pues que hemos sacado este nuevo servicio que te proporciona X ventajas y que además 00:31:55.960 --> 00:32:00.380 te puedes ahorrar es este que es dinero, entonces de repente el camino se ha, ha hecho 00:32:00.420 --> 00:32:08.300 más largo. Entonces es como el aprendizaje informática que nunca, nunca termina, que 00:32:09.580 --> 00:32:16.700 No sé si es ilusionador o es bueno, yo como el mito de Sísifo, esto es 00:32:16.700 --> 00:32:21.280 subir a la montaña y cuando llegas arriba vuelve a tirar la piedra abajo y a verla rodar, 00:32:21.320 --> 00:32:27.040 porque hay que volver a empezar otro ciclo de utilización, la vuelta de tuerca otra. 00:32:27.040 --> 00:32:33.440 No, yo, yo, yo tengo la teoría de que los que, los que trabajamos en esto y además llevamos 00:32:33.440 --> 00:32:40.640 ya años, es que en el fondo nos gusta la marcha, somos masoquistas totalmente, 00:32:40.640 --> 00:32:48.300 bueno. Y que pasa con los sistemas legacy yo tengo 00:32:48.300 --> 00:32:55.000 un cliente que está aún en oracle 10 y me consta que cuando hablo con gente me dicen 00:32:55.000 --> 00:33:02.710 bueno pues no está tan mal pero Pero a 00:33:03.100 --> 00:33:10.120 esa gente, es decir, empresas que tengan entornos aún muy, digamos, muy 00:33:10.120 --> 00:33:14.960 legacy, ¿tú cómo ves? ¿Qué experiencia tienes haciendo ese journey to cloud? 00:33:15.180 --> 00:33:21.060 Al momento cero de su vida y después al momento de transformación. 00:33:21.120 --> 00:33:27.350 ¿Cómo lo ves? Ahí es complejo Ahí es especialmente complejo Porque cuando tú tienes una 00:33:27.350 --> 00:33:33.530 base de datos Por ejemplo, la que acabas de comentar Un Oracle 10, un Oracle 9 Un 817 00:33:33.530 --> 00:33:40.610 Una cosa así Consolera. El problema no es la base 00:33:40.610 --> 00:33:43.554 de datos, el problema es seguro que es la aplicación. 00:33:44.970 --> 00:33:48.650 Si yo te contara. Es un report. 00:33:48.650 --> 00:33:52.830 Es un report que me pasaron el report 6. 00:33:54.380 --> 00:34:00.220 ¿Vale? Report 6, estamos hablando año 99, y el Report 6 al intentar abrir los reports 00:34:00.220 --> 00:34:04.998 decía: no puedo abrir esta versión del report porque es una versión demasiado antigua. 00:34:05.930 --> 00:34:07.610 Imagínate, y eso sigue funcionando aún. 00:34:07.650 --> 00:34:12.030 Sí, sí, sí, lo conozco perfectamente. 00:34:13.290 --> 00:34:20.290 El punto ahí es la aplicación, tú quieres actualizar la base de datos, pero si la aplicación 00:34:20.290 --> 00:34:27.570 no Probablemente no hace un upgrade y, si está una seta tan antigua, requiere cambios 00:34:27.570 --> 00:34:30.580 importantes por debajo, no puedes hacer nada. 00:34:32.110 --> 00:34:36.890 Entonces ahí tienes dos opciones, o se hace un proyecto de modernización de la aplicación, 00:34:36.930 --> 00:34:40.350 o se busca una aplicación que la sustituya, o 00:34:41.470 --> 00:34:50.450 cuando haces la migración a cloud de esa aplicación tienes que tratarla prácticamente 00:34:50.450 --> 00:34:55.290 como una seta. De manera que decir, oye, pues el problema, insisto, no es la base de 00:34:55.290 --> 00:35:02.020 datos. En este caso estamos hablando, cuando nosotros lo llevamos a cloud, no es que 00:35:02.020 --> 00:35:08.440 el Oracle 10 no esté soportado ya por nadie, sino que el sistema operativo sobre el que 00:35:08.440 --> 00:35:15.130 corre ese Oracle 10 a lo mejor ni siquiera es capaz de correr de manera nativa en un 00:35:15.130 --> 00:35:22.490 EPScaler. Entonces ahí la cosa se empieza a complicar, se empieza a complicar en el sentido 00:35:22.490 --> 00:35:24.330 de que a lo mejor tienes que 00:35:26.170 --> 00:35:29.850 Me lo vuelvo a inventar, imaginemos que esa base de datos está corriendo sobre un VMware 00:35:29.890 --> 00:35:36.590 y la alternativa que te queda es desplegar VMware en cloud y mueves esa máquina virtual 00:35:36.590 --> 00:35:39.750 tal cual la tienes y no puedes hacer mucho más. 00:35:41.340 --> 00:35:43.960 Salvo que haya una actualización 00:35:46.590 --> 00:35:53.950 Que Que es algo que hay en una actualización que permite actualizarse 00:35:53.950 --> 00:35:56.339 a base de datos. Sí, eso es lo que decimos. 00:35:56.490 --> 00:36:01.870 Yo, a lo que me encuentro con ese tipo de migraciones, no me encuentro mucho problema 00:36:01.870 --> 00:36:07.710 en las estructuras, que pueden ser estructuras obsoletas, porque es muy fácil convertirlas. 00:36:08.460 --> 00:36:13.940 Pero es como tú dices muchas veces es la aplicación la que la que va a dar problema es 00:36:13.940 --> 00:36:20.940 hace datos 10 y con un export data pumping por data pump de la subeste la subes a un 00:36:20.940 --> 00:36:27.380 autónomos a un autónomos y sin problemas pero lo que sí suele ser más problemático y 00:36:27.380 --> 00:36:32.480 lo que sí suele dar más la lata no es que no es a lo mejor que tengan una columna long 00:36:32.480 --> 00:36:39.140 vale no no no es eso o dicción o tengo el space gestionados por el diccionario no suele 00:36:39.140 --> 00:36:46.240 ser pues eso en cómo te llevas un unos reports antiguos unos forms que están 00:36:46.240 --> 00:36:53.280 antiguos también y lo conectas y toda la conectividad con todo lo demás incluso 00:36:53.540 --> 00:36:59.920 que cuando tú haces la actualización de un motor tan antiguo un motor motor moderno, 00:36:59.940 --> 00:37:02.829 pues a lo mejor que tenga regresiones de rendimiento 00:37:04.040 --> 00:37:07.850 Tiene su impacto Sí, sí, sí. 00:37:08.510 --> 00:37:11.430 Sí, sí, y tanto, claro. Es un cambio 00:37:12.970 --> 00:37:19.500 De escena. No hemos hecho la alerta palabra, no sé, si alguien en la audiencia tiene 00:37:19.500 --> 00:37:25.220 alguna pregunta de algún palabra raro que digamos puede decirnoslo y los que estáis en 00:37:25.220 --> 00:37:29.620 directo, si queréis uniros a nosotros y preguntarnos algo que sea, podéis dar la mano 00:37:29.660 --> 00:37:34.620 y y subir. Recuerdo que estamos grabando esto, lo estamos grabando y lo subiremos al 00:37:34.620 --> 00:37:38.160 podcast, así que los que estáis ahora, los que estáis escuchando en directo podéis partir 00:37:38.200 --> 00:37:42.400 para si queréis y los que no pues en el podcast subiremos y 00:37:43.840 --> 00:37:48.120 Será un episodio más y podéis escuchar ahí cualquiera de los que os hayáis perdido y 00:37:48.160 --> 00:37:52.280 este también una segunda vez por si por si algo. 00:37:54.340 --> 00:37:58.500 Se os escapa oye, súper interesante lo del tema este, ¿no? 00:37:59.320 --> 00:38:04.320 Lo del multicloud Pero, ¿tú cómo ves que está impactando? 00:38:04.540 --> 00:38:06.560 Es decir, ¿está generando...? 00:38:06.560 --> 00:38:09.120 Estamos en la fase en la que la gente... 00:38:09.120 --> 00:38:14.600 Porque una de las cosas que tenía apuntadas aquí para comentar contigo es todo el tema 00:38:14.600 --> 00:38:19.420 de nuevos errores que suceden en el paso a... 00:38:20.520 --> 00:38:26.980 Yo tengo la sensación, por eso te quería preguntar, ¿cómo ves tú cómo ha ido todos estos 00:38:26.980 --> 00:38:29.260 journeys, cómo se han desarrollado? 00:38:29.260 --> 00:38:34.820 Pero yo tengo la sensación que on -premise, digamos, el tema de, que alguien me dirá, 00:38:34.880 --> 00:38:37.120 no, pero siempre hay bugs nuevos y siempre hay follones y tal. 00:38:37.160 --> 00:38:45.160 Sí, sí, sí pero en OCI, entre diferentes fabricantes y diferentes, son diferentes arquitecturas 00:38:45.160 --> 00:38:51.890 de cloud, ¿no? El conocimiento que tengo es errores, errores de colectividad, errores 00:38:51.890 --> 00:39:01.200 nuevos de cosas que, como el escenario es totalmente distinto, hay todo un nuevo surtido 00:39:01.200 --> 00:39:08.280 de errores, problemas, crashes, toda esta 00:39:08.310 --> 00:39:12.470 integración. Con GoldenGate se integra todo. 00:39:12.650 --> 00:39:17.410 Puedes tener un origen en una plataforma de post, lo pasas a Oracle y luego los tipos 00:39:17.410 --> 00:39:19.410 de datos pueden reventar por dentro. 00:39:19.630 --> 00:39:22.710 ¿Tú cómo ves el tema? Voy concretando la pregunta. 00:39:23.850 --> 00:39:25.970 ¿Accidentes, errores, trompazos? 00:39:26.010 --> 00:39:27.530 Es decir, vamos a migrar y de pronto ¡pam! 00:39:27.570 --> 00:39:32.470 Un crash tenemos que parar porque algo ha reventado. 00:39:32.470 --> 00:39:36.248 Ha reventado un proceso, De pronto revienta la migración o de pronto 00:39:36.450 --> 00:39:41.560 la conectividad nos rinde, errores ¿Qué experiencia tienes? 00:39:41.660 --> 00:39:45.993 ¿Te has encontrado con mucho problema o ves que eso está ya bastante madurito? 00:39:46.150 --> 00:39:48.500 Yo creo que tiene un buen grado de madurez. 00:39:48.540 --> 00:39:55.580 Evidentemente todo falla y además en entornos tan 00:39:55.580 --> 00:40:02.580 complejos. Pero no recuerdo yo grandes 00:40:02.580 --> 00:40:05.100 problemas en los últimos tiempos. 00:40:05.100 --> 00:40:10.520 Si recuerdo, mira, voy a poner un ejemplo de hace muchos años, bueno, 00:40:11.740 --> 00:40:14.600 Muchos años, no sé, cuatro, cuatro o cinco años. 00:40:15.460 --> 00:40:17.040 Bueno, pues muchos o pocos. 00:40:22.140 --> 00:40:30.270 Era un entorno que tenía un firewall forti gate en cloud y 00:40:30.560 --> 00:40:36.230 cuando cuando el tráfico entrante pasaba a través del firewall de manera aleatoria a 00:40:36.230 --> 00:40:42.500 veces iba bien y a veces iba mal no sé nosotros Nosotros inicialmente le abrimos caso 00:40:42.500 --> 00:40:49.600 a Oracle, el support al principio costó 00:40:49.600 --> 00:40:56.680 que le dieran cariño al caso, pero en el momento que empezamos a trabajar 00:40:56.680 --> 00:41:03.990 en serio en él, empezamos a revisar, empezamos a hacer pruebas con 00:41:03.990 --> 00:41:09.130 TCP Dams y tal, vimos que el tráfico UDP pasaba como un cañón a través del firewall, 00:41:09.350 --> 00:41:16.630 el tráfico TCP en función del tamaño del paquete pasaba 00:41:16.630 --> 00:41:23.820 mejor o peor Y la gente ahora que le dice, no, no, esto no es nuestro, esto es de Forti 00:41:23.820 --> 00:41:28.660 y yo les decía a ellos, esto es imposible que sea de Forti porque es el tráfico sin más 00:41:28.660 --> 00:41:35.880 no sabes y esto no al final hicimos una decisión conjunta entre 00:41:35.880 --> 00:41:40.000 ahora que el forte en este caso había sido yo y 00:41:40.900 --> 00:41:48.150 era un bug súper concreto que afecta a una versión muy concreta de forti o ese no 00:41:48.150 --> 00:41:54.790 reconozco también el back que hacía que la que el tráfico se degradará de manera aleatoria 00:41:57.290 --> 00:41:59.390 Qué difícil es ese tipo de cosas. 00:41:59.390 --> 00:42:07.170 Sí, había sido una incidencia muy compleja, de hecho había entrado el principal 00:42:07.170 --> 00:42:11.559 arquitecto de Estados Unidos, de Oracle, de todo lo que había escalado el tema. 00:42:13.010 --> 00:42:18.066 Pero en el momento que empezamos a trabajar en serio, en cuatro horas estaba diagnosticada. 00:42:19.830 --> 00:42:25.840 Y con Walker Ramos Lo que es brutal el punto es 00:42:27.770 --> 00:42:31.570 Esto hubiera podido pasar, a lo mejor esta incidencia no, pero hubiera pasado una incidencia 00:42:31.610 --> 00:42:39.060 parecida donde tienes otros elementos de red o lo que sea y tienes una incidencia del 00:42:39.060 --> 00:42:43.580 estilo. La parte buena del 00:42:45.260 --> 00:42:52.080 Del escenario actual, si te fijas y si ves los listados de caídas de los hyperscalers, 00:42:52.080 --> 00:42:57.040 a ver, evidentemente hay caídas, hay degradaciones, pero hay un, hay un buen grado de 00:42:57.040 --> 00:43:04.050 madurez, y es más, te diría más, hay un gran grado de madurez a 00:43:04.590 --> 00:43:08.230 pesar de la cantidad de cambios que se meten todos los días añadiendo nuevos servicios, 00:43:08.270 --> 00:43:16.040 funcionalidades. Es una pasada lo bien que se está trabajando, que 00:43:17.930 --> 00:43:24.230 Grande, vamos a hacer, te parece, a ver, aparte de lo obvio de decir, por ejemplo, vega, 00:43:24.230 --> 00:43:28.270 si tienes asistentes Oracle meterlas en Office y tienes cosas de datos Microsoft, mételas 00:43:28.310 --> 00:43:35.230 en Azure. ¿Cuál es, hablando también de los otros competidores, qué es lo que consideras 00:43:35.230 --> 00:43:38.730 que cada uno es lo que hace bien o hace mejor? 00:43:39.170 --> 00:43:43.210 Para decir, como a cada uno vamos a tener que estudiar, es decir, cada vez que tengamos 00:43:43.250 --> 00:43:47.110 que emigrar, tendremos que estudiar a lo mejor en una situación multicloud. 00:43:47.150 --> 00:43:48.650 ¿Qué servicios ponemos en un sitio? 00:43:48.690 --> 00:43:50.230 ¿Qué servicios ponemos en otro? 00:43:50.270 --> 00:43:52.610 ¿Y cuánto nos va a costar tenerlos en un sitio? 00:43:52.650 --> 00:43:54.010 ¿Cuánto nos va a costar tener en el otro? 00:43:54.050 --> 00:43:59.750 Y proximidades de regiones y alianzas que tengan, en este caso Microsoft y Oracle están 00:43:59.750 --> 00:44:02.861 muy juntitos, pero a lo mejor con otros están más lejos. 00:44:03.850 --> 00:44:10.570 Vamos a decir qué hace o qué pondríamos preferiblemente en cada una de ellas si tuviésemos 00:44:10.570 --> 00:44:17.190 que utilizar un match en Brawa de las cuatro, de las cuatro regiones, de los cuatro y 00:44:17.190 --> 00:44:23.340 tres que hay. Bueno, base de datos ya te digo yo, base de datos solo que lo vamos a dejar 00:44:23.340 --> 00:44:27.500 de Sanofi porque da igual, si ahí tenemos mogollón de 00:44:29.500 --> 00:44:34.167 Autónomos los de B -Systems hasta tener las máquinas virtuales y tener ahí el hierro 00:44:34.900 --> 00:44:37.240 correcto base de datos sí, ahora que 00:44:39.400 --> 00:44:45.160 Y pongo un asterisco y con el nuevo acuerdo que anunciaron Larry y Nata 00:44:46.520 --> 00:44:53.400 Azure también pasa a ser una opción porque hasta ese momento en el único donde podías 00:44:53.400 --> 00:44:57.340 tener una base de datos con RAC era OC pero ahora ya no 00:44:59.020 --> 00:45:06.120 Sí, y además habían dicho que no se iban a cargar costes extra en ese tipo 00:45:06.120 --> 00:45:09.953 de servicios es decir, si tú lo comprabas en Microsoft no iba a haber 00:45:11.300 --> 00:45:18.240 Costes, y lo mismo Oracle decía lo mismo de SQL Server no iban a cargarle un plus a la 00:45:18.240 --> 00:45:21.260 licencia de SQL Server y tal. 00:45:21.320 --> 00:45:27.200 Van a respetarse, digamos, una transparencia, digamos, de darle al otro enteramente el 00:45:27.200 --> 00:45:30.840 crédito y el valor, ¿no?, de cada producto. 00:45:33.300 --> 00:45:35.911 Correcto vale, base de datos ya lo hemos dicho. 00:45:36.420 --> 00:45:44.000 Toda la parte de Azure AD, bueno, ya he dicho el hyperscaler, para 00:45:44.000 --> 00:45:50.380 mí Microsoft tiene un valor diferencial y además es el único que pueden dar ese tipo 00:45:50.380 --> 00:45:57.740 de servicio. Entonces, toda la parte de afuera de gestión de identidad, con 00:45:57.740 --> 00:46:02.518 la parte de servicios de IA, con toda la parte de Copilot, lo están haciendo muy bien. 00:46:02.960 --> 00:46:04.860 Microsoft tiene un punto fuerte. 00:46:05.940 --> 00:46:12.540 Ah, te iba a decir, temas de NoSQL y, pues a lo mejor, Postgres y otro tipo de bases 00:46:12.540 --> 00:46:17.460 de datos, pues de tener, no sé, de tener Kafka o MongoDB. 00:46:19.500 --> 00:46:21.460 ¿Dónde lo pondrías? ¿A WS? 00:46:21.960 --> 00:46:24.940 Pues yo probablemente en WS, sí. 00:46:25.000 --> 00:46:27.540 En WS o en Google probablemente en WS. 00:46:29.940 --> 00:46:31.200 ¿Y en Google qué pondríamos? 00:46:31.240 --> 00:46:38.780 La parte de data y de analítica, que lo que tienen con BigQuery y Vertex 00:46:38.780 --> 00:46:45.060 es bastante potente. ¿Y habría algo que diríamos, oye, esto no, porque esto aquí es prohibitivo? 00:46:46.620 --> 00:46:52.040 Vamos a ver, el tema de máquina virtual Windows es un tema delicado. 00:46:54.170 --> 00:47:00.450 Si nos acercas de Azure, sur la cosa que empieza por 00:47:01.540 --> 00:47:05.400 tema del licenciamiento y tal Microsoft no ayuda demasiado. 00:47:07.410 --> 00:47:11.970 A mí esa sería una, en la medida posible lo intentaría llevar hacia sur. 00:47:13.210 --> 00:47:20.420 Otros puntos que son muy importantes a la hora de tener en cuenta cuando tú te migras 00:47:20.420 --> 00:47:25.660 servicios a un hyperscale, sobre todo cuando vas hacia servicios nativos, es definir 00:47:25.660 --> 00:47:29.160 correctamente en el minuto cero las estrategias de salida. 00:47:31.910 --> 00:47:39.390 No vaya a ser que luego la salida de ese hyperscaler 00:47:39.390 --> 00:47:43.390 sea extremadamente compleja o directamente imposible. 00:47:43.710 --> 00:47:46.321 Es que esa era otra pregunta que tenía para ti. 00:47:46.810 --> 00:47:53.930 Era, ¿nos damos la vuelta y nos vamos para atrás o hacemos una huida hacia 00:47:53.930 --> 00:48:00.260 adelante? En caso de que algo se nos vaya de madre o algo no esté funcionando como debiera 00:48:00.260 --> 00:48:07.440 o en caso de que los costes hay empresas que han dado un paso hacia atrás 00:48:09.600 --> 00:48:12.433 Probablemente porque no han podido o no han querido 00:48:13.700 --> 00:48:18.740 Hacer esa transformación de la que hablaba antes que hace que los números a lo mejor 00:48:18.740 --> 00:48:26.540 no salen como tú esperabas o esos costes ocultos de landing zone que tú 00:48:26.570 --> 00:48:32.110 a priori no conoces de repente hacen que los costes de cloud se te disparen y 00:48:33.100 --> 00:48:37.820 hay empresas que han dado un paso hacia atrás de la misma manera y lo cambio un poco 00:48:37.820 --> 00:48:44.400 de tercio hubo un caso muy llamativo hace unos meses que fue Netflix que desmontaba parte 00:48:44.400 --> 00:48:47.567 de su arquitectura de microservicios y volvía al monolito 00:48:49.120 --> 00:48:54.940 Y hubo un revuelo en redes sociales brutal diciendo la vuelta al monolito estamos todos 00:48:54.940 --> 00:49:01.340 locos Al final hay que ver las cosas en perspectiva y entender bien el caso de uso y 00:49:01.340 --> 00:49:07.220 sobre todo tener la apertura de mente necesaria para decir que no hay una solución única 00:49:07.220 --> 00:49:09.942 sino la solución que se adapta a tus necesidades. 00:49:11.180 --> 00:49:17.900 Sí, de hecho, el volver a on -premise a veces no me parece a mí muchas veces un ir hacia 00:49:17.900 --> 00:49:22.700 atrás, un volver hacia atrás, sino a veces una evolución hacia adelante, es decir, vale, 00:49:22.740 --> 00:49:29.000 tengo todos estos servicios en la nube y estos ciertos tres servicios quiero traerlos, 00:49:29.040 --> 00:49:33.984 quiero evolucionarlos a un, o sea, a lo mejor una nueva infraestructura, pero en mi casa. 00:49:34.120 --> 00:49:35.898 Esto quiero que esté en mi casa. 00:49:36.030 --> 00:49:39.530 El punto es el por qué y el para qué. 00:49:40.850 --> 00:49:45.170 Y tener claro los riesgos y los beneficios. 00:49:45.650 --> 00:49:50.610 Y cuando hablo, por ejemplo, de los riesgos, la cantidad de medidas de seguridad, de 00:49:50.610 --> 00:49:57.010 accesos físicos, de redundancia de cada uno de los elementos de una infra que tiene un 00:49:57.010 --> 00:49:58.890 hyperscaler, o eres una empresa 00:50:00.160 --> 00:50:04.380 Muy potente o en un prem no vas a poder pagarlo 00:50:05.380 --> 00:50:11.800 o no vas a querer pagar bueno, lo sacrificas, digamos se está sacrificando claro, pero 00:50:11.800 --> 00:50:16.600 eso pasa a ser un por eso mismo es un tema que hay que poner en perspectiva, es decir, 00:50:16.640 --> 00:50:24.280 oye voy a simplificarlas al absurdo es decir, yo estoy en cloud, tengo servidores 00:50:24.280 --> 00:50:26.224 que en caso de fallo de un servidor 00:50:26.720 --> 00:50:33.880 pues Puedo Hacer un failover hacia otro, puedo escalar, puedo hacer 00:50:33.880 --> 00:50:40.540 no sé qué, y en on -prem me he comprado una Raspberry que me ha costado 50 euros 00:50:41.940 --> 00:50:44.780 Donde corro mi aplicación. 00:50:44.920 --> 00:50:45.940 ¿Estamos hablando de lo mismo? 00:50:45.980 --> 00:50:53.980 Evidentemente no. ¿Que la Raspberry para ti es 00:50:53.980 --> 00:50:56.400 suficiente? Pues oye, mira, perfecto. 00:50:58.710 --> 00:51:03.432 Pero Pero por eso mismo hablaba antes de que no hay solución única, sino caso de uso. 00:51:05.270 --> 00:51:06.990 ¡Oh! ¡Qué frase más grande! 00:51:09.960 --> 00:51:14.100 No hay soluciones buenas o soluciones malas, sino casos de uso existentes. 00:51:15.100 --> 00:51:19.280 Muy bien, muy bien los que estéis en la audiencia, si queréis preguntarnos algo, si queréis 00:51:19.320 --> 00:51:25.520 preguntarle algo a Toni, es un lujazo tomarse un café con él y poder hablar de esos temas 00:51:25.520 --> 00:51:32.940 sin que la corporación Oracle que está dirigiendo sus pasos a sus palabras estamos hablando 00:51:32.940 --> 00:51:39.820 aquí como tomándose un café de veas si queréis participar es seis bienvenidos a subir 00:51:39.820 --> 00:51:46.930 al escenario y en el chat pues escribiros alguna pregunta y la y la comentamos 00:51:46.930 --> 00:51:54.040 pues oye hemos hemos hecho un barrido bastante interesante de toda la situación de multicloud 00:51:54.040 --> 00:52:02.170 todo el escenario actual no sé yo creo que hemos hecho hecho una buena foto es decir, 00:52:02.270 --> 00:52:06.214 aquí estamos en un momento tecnológico súper atractivo, súper cambiante 00:52:07.230 --> 00:52:14.800 Que además, bueno el tema de IA generativa ha venido para poner de patas arriba no tanto 00:52:14.800 --> 00:52:19.820 el cloud pero sí los casos de uso que a su vez de una manera u otra 00:52:20.920 --> 00:52:28.400 te van a llevar hacia el cloud en la mayor parte de los casos y 00:52:28.560 --> 00:52:33.100 tenemos que estar muy atentos y vigilantes para aprovechar todas las ventajas que nos 00:52:33.140 --> 00:52:40.860 ofrece la tecnología Sí, sí, sí Pues oye, ¿cómo ves a partir de ahora el 00:52:40.860 --> 00:52:44.970 escenario desde el punto de vista laboral? 00:52:45.130 --> 00:52:52.290 ¿Ves que los proyectos están como muy, están muy localizados o crees que va a haber un 00:52:52.290 --> 00:52:59.410 boom de pasos a Claudio o va a haber una nueva necesidad o que va 00:52:59.410 --> 00:53:05.910 a haber más necesidad de informáticos en cloud y de lo que hay ahora? 00:53:06.170 --> 00:53:10.030 ¿Crees que ahora mismo todo el mundo que está migrando a cloud está haciéndolo? 00:53:10.070 --> 00:53:14.190 ¿Tú qué crees? ¿Que hay oportunidad ahí o ya más o menos se está cubriendo? 00:53:14.230 --> 00:53:15.650 ¿Qué sensación tienes tú? 00:53:15.990 --> 00:53:18.350 Que siga habiendo mucha demanda. 00:53:21.400 --> 00:53:28.840 Ha habido mucha demanda de profesionales de arquitectos cloud o de cloud 00:53:28.840 --> 00:53:31.340 engineers o perfiles más de DevOps 00:53:33.020 --> 00:53:38.820 Y durante los próximos años yo creo que va a seguir en la línea por lo que comentaba 00:53:38.820 --> 00:53:40.764 antes porque aunque ya las empresas 00:53:41.540 --> 00:53:46.380 Se plantean el salto hacia cloud luego hay que empezar las transformaciones hay que empezar 00:53:46.420 --> 00:53:52.860 las optimizaciones y eso es un ciclo de vida al final es gestionar el ciclo de vida y 00:53:52.860 --> 00:53:59.360 ahí nos queda yo espero que quede trabajo suficiente hasta que me pueda jubilar, o me 00:53:59.360 --> 00:54:00.860 toque la lotería ¿tú crees? 00:54:01.220 --> 00:54:09.060 O nos toque la lotería para la lotería hay que jugar mira, tenemos, voy a subir al escenario 00:54:09.060 --> 00:54:15.900 están hablando en el chat sobre en post SQL, Mixed Feelings AWS trae lo de Aurora es 00:54:15.900 --> 00:54:20.520 muy interesante, pero Microsoft Microsoft tiene Citus, que da la capacidad Multimaster, 00:54:20.560 --> 00:54:27.960 no sé Cuéntanos Muy buenas, saludos a Tony y Javier, un gusto platicar 00:54:27.960 --> 00:54:30.720 con ustedes Más que nada, para las comunidades 00:54:32.020 --> 00:54:39.220 Vamos a decirle que ustedes siguen ahí en la localidad de Europa Yo siempre veo, por 00:54:39.220 --> 00:54:41.460 ejemplo, que Microsoft tiene mucha 00:54:42.460 --> 00:54:49.520 penetración en Europa tal vez más que otros En el tiempo que estuve yo por ahí un 00:54:49.520 --> 00:54:57.060 rato, veía eso. Y otra, una pregunta específica sería, ¿qué nube 00:54:57.060 --> 00:55:04.560 piensan ustedes que dan las mejores posibilidades para que tú te prepares y te certifique? 00:55:07.370 --> 00:55:10.203 Vamos a decir, sí, te recojas las habilidades, ¿no? 00:55:13.270 --> 00:55:17.103 Gracias vamos a ver, por empezar por la segunda pregunta, yo creo que 00:55:18.340 --> 00:55:26.400 En estos momentos Bueno, ahora que el año pasado hizo un esfuerzo brutal con el 00:55:26.400 --> 00:55:32.040 Road to Certification, ese fue muy grande esa oportunidad, no sé si la tomaste pero era 00:55:32.040 --> 00:55:38.400 era grandiosa porque no solo era certificación de OCI te regalaban exámenes de certificación 00:55:38.400 --> 00:55:40.122 de otras cosas que tú quisieras 00:55:41.500 --> 00:55:47.160 Esa fue una oportunidad fantástica, de hecho ahora que la he extendido para partners 00:55:47.160 --> 00:55:54.240 hasta el 15 de diciembre Y no sé si la voy a extender Google también 00:55:54.240 --> 00:55:59.540 tiene una apuesta de formación bastante interesante con muchas formaciones gratuitas 00:56:02.610 --> 00:56:10.750 A Microsoft y AWS no los tengo yo tan ubicados en ese sentido a menos de lo que 00:56:10.750 --> 00:56:12.139 asumir de manera pública. 00:56:12.920 --> 00:56:17.160 AWS sacó también en verano algunas certificaciones gratis. 00:56:18.140 --> 00:56:25.620 Yo entiendo que las básicas, las de foundations y todas estas, todas las cubren y 00:56:25.620 --> 00:56:28.160 para multiclouds sí que hay que ir con esas. 00:56:29.520 --> 00:56:33.200 En OCI, claro, estaban gratuitas también las de 00:56:34.240 --> 00:56:39.740 multiclouds, en el que se toca también la integración con otras con otras clouds. 00:56:41.420 --> 00:56:44.480 Correcto lo que pasa es que luego hay un punto que es importante, que es, por ejemplo, 00:56:44.520 --> 00:56:48.120 el nivel de la certificación. 00:56:49.820 --> 00:56:59.080 En mi opinión, por ejemplo, yo soy AWS 00:56:59.080 --> 00:57:06.820 Cloud Architect Associate o el Cloud Professional y OCI Professional, las 00:57:07.110 --> 00:57:14.190 de arquitectos. Y por ejemplo la de AWS siendo la SoCit es 00:57:14.190 --> 00:57:21.610 mucho más compleja que por ejemplo la de OCI y la de Google, la de GCP es 00:57:23.290 --> 00:57:31.490 A ver es compleja pero para ser una profesional trabajándola bien es es 00:57:31.490 --> 00:57:38.240 asequible pero por ejemplo Amazon sí que es muy exigente en ellas pero evidentemente 00:57:38.240 --> 00:57:45.020 Tener la oportunidad de certificarse en cada una de ellas y que el fabricante te lo apoye 00:57:45.020 --> 00:57:49.480 es fantástico. Por ejemplo, la que comentabas tú ahora, Javi, la de Multiplier Cloud 00:57:49.520 --> 00:57:56.540 de OCI, es una certificación extrema, es sencillita porque al 00:57:56.540 --> 00:58:03.680 final, teniendo una mínima base, podemos estar hablando de una foundation 00:58:03.680 --> 00:58:06.800 de Azure más una foundation de OCI, 00:58:08.790 --> 00:58:14.730 En tener un poco el concepto de multicloud de Oracle es una certificación muy asequible. 00:58:14.890 --> 00:58:18.810 De hecho, creo que recordar que eran como 20 -25 preguntas. 00:58:19.390 --> 00:58:20.890 El examen no daba para más. 00:58:22.980 --> 00:58:29.760 Claro voy a compartir el enlace también de otra certificación que creo que es muy interesante 00:58:29.760 --> 00:58:36.000 tener independientemente de a qué nivel te certifiques en cada una de las de las cuatro 00:58:36.000 --> 00:58:43.100 grandes que es la certificación de FINOPS, esto está contando Sai Permuru ¿vale? 00:58:43.520 --> 00:58:50.800 De la India, nos estaba contando en Madrid que es Es un asset 00:58:50.800 --> 00:58:57.860 muy interesante. Independientemente del nivel que tengas, tener o demostrar una certificación 00:58:57.860 --> 00:59:04.600 de las dos que hay de FinOps, que son muy interesantes. 00:59:05.080 --> 00:59:07.240 Sí, sin duda es interesante. 00:59:08.280 --> 00:59:13.880 Es que te toca de lleno en el punto de dolor grandísimo que es el tema de los costes 00:59:16.000 --> 00:59:21.080 El máximo dolor de decir, vale, tú eres muy arquitecto, sí, profesional, sí ¿cuánto me 00:59:21.080 --> 00:59:24.413 va a costar esto? Dices, no, espera, pero es que también soy 00:59:25.020 --> 00:59:30.240 certificado en FinOps y luego, porque de manera subyacente tener una certificación de 00:59:30.240 --> 00:59:32.351 FinOps y yo, por ejemplo, no las tengo 00:59:33.560 --> 00:59:41.300 De manera subyacente eso significa que tú entiendes exactamente cómo funcionan cómo 00:59:41.300 --> 00:59:47.410 optimizar perfectamente el cloud lo que implica un conocimiento profundo de cuáles son 00:59:47.410 --> 00:59:49.521 los puntos donde más le duele al cloud 00:59:54.970 --> 01:00:02.030 Pero ustedes creen que sería más 01:00:02.030 --> 01:00:09.130 que sería lo mejor especializarse hacia prácticamente en una o ir cogiendo 01:00:09.130 --> 01:00:12.590 un poquito, por ejemplo sacarse todas las fundacionals 01:00:14.110 --> 01:00:16.030 ¿qué le tienes en ese sentido? 01:00:18.140 --> 01:00:22.300 Es una respuesta difícil y es un consejo difícil de dar depende un poco de 01:00:23.660 --> 01:00:29.380 Yo creo que mi opinión depende un poco de de tu perfil y de tus inquietudes 01:00:34.480 --> 01:00:39.360 Probablemente teniendo un buen perfil de especialización a un upper skilling hacia arriba 01:00:39.400 --> 01:00:46.720 arriba te puede proporcionar la posibilidad de que tengas proyectos más 01:00:46.720 --> 01:00:53.770 potentes pero Por otro lado tenerla al menos 01:00:53.800 --> 01:01:01.740 la fundación al de dos o tres y prescindir más una certificación hacia arriba de alguno 01:01:01.740 --> 01:01:05.880 de ellos en pensar en esta estrategia multicloud que estábamos hablando antes y donde 01:01:05.920 --> 01:01:10.420 los clientes ya no normalmente ya no piensan solamente en un cloud yo al menos con con 01:01:10.460 --> 01:01:12.793 los clientes con los que estoy trabajando, 01:01:13.420 --> 01:01:20.340 el que menos tiene, tiene dos, pero normalmente tienen tres y muchos de ellos están pensando 01:01:20.340 --> 01:01:27.610 en el cuarto. Entonces, tener la capacidad de tener un discurso multicloud, yo 01:01:27.680 --> 01:01:30.220 creo que aporta también valor. 01:01:30.220 --> 01:01:37.900 Sí, yo diría eso los foundations de todas, sí, entendiendo las 01:01:37.900 --> 01:01:45.320 disciplinas o la forma de cada una de ellas, e intentar asegurarlas, las associate, 01:01:45.690 --> 01:01:51.330 alguna profesional de la que tú te consideras que tienes más dominio, es decir, si tienes 01:01:51.330 --> 01:01:57.330 más dominio en Oracle, pues iría a asegurar el profesional de esa y, como he puesto ahí 01:01:57.330 --> 01:01:59.719 en el enlace, y la certificación de FinOps. 01:02:00.660 --> 01:02:04.820 Porque yo es que tengo la sensación esta también de que esa certificación se va a valorar 01:02:04.860 --> 01:02:12.040 muy positivamente, se defiende mucho mejor, es decir, se defiende que es una certificación 01:02:12.040 --> 01:02:17.440 orientada al coste y al entender, tiene como una doble, es decir, entiendo como decía 01:02:17.440 --> 01:02:24.200 Toni, toda la disciplina de Cloud y de MultiCloud y también los costes asociados y soy 01:02:24.200 --> 01:02:30.020 un profesional que va a cuidar que este proyecto no despatarre en coste. 01:02:30.040 --> 01:02:31.820 Por decirlo de alguna forma. 01:02:32.220 --> 01:02:36.060 Esa sería un poco mi estrategia, pero vuelvo a decir, es muy personal esto, también es 01:02:36.100 --> 01:02:43.340 cada uno como vaya. Si trabajas ya para un cliente, si estás empleado, quizá lo 01:02:43.340 --> 01:02:49.280 interesante podría ser del cliente que tienes empezar por esas. 01:02:49.560 --> 01:02:55.500 Si no utilizan Google, por ejemplo, pues déjate esa para después, por curiosidad. 01:02:55.500 --> 01:03:02.820 Bueno, puedes tener la estrategia contraria, que es, si no utilizan Google, pero se 01:03:02.820 --> 01:03:06.780 ha escuchado por ahí entre los pasillos y tienes 20 compañeros que están certificados 01:03:06.820 --> 01:03:12.040 en Azure, haz el diferente y posiciónate en el diferente. 01:03:13.770 --> 01:03:16.270 Es que esto es muy difícil de aconsejar, ¿eh? 01:03:17.680 --> 01:03:24.770 Sí, sí, completamente. Bueno, y otra sería aprovechar las olas o las oportunidades de 01:03:24.770 --> 01:03:26.670 certificaciones gratuitas. 01:03:27.430 --> 01:03:34.870 Cuando salió la de Oracle yo dije a los de la auditoría dije, a saco, a saco id a sacaros 01:03:34.870 --> 01:03:40.310 ahora es decir, lo demás, dejároslo para después, aprovechad ahora, porque además cada 01:03:40.310 --> 01:03:44.810 vez que te sacabas una certificación, ahora que te daba un exámen de crédito para cualquier 01:03:44.850 --> 01:03:46.750 otra cosa, para el OCP o para 01:03:47.930 --> 01:03:55.700 cualquier otra certificación, digamos ya de de Onpreviz la de optimización 01:03:55.700 --> 01:04:02.240 o la de la de tuning o la de data guardo es decir pero pero a saco saco aprovechar esa 01:04:03.820 --> 01:04:08.160 Esas promociones adicionales durante dos meses todas las certificaciones de tal las vamos 01:04:08.200 --> 01:04:15.340 a poner gratis son por las primeras pues aprovechar esa ola de oportunidad sería mi consejo 01:04:15.340 --> 01:04:23.040 totalmente Tony, nos estamos yendo de tiempo un placer 01:04:23.040 --> 01:04:30.800 por terminar muchísimas gracias a ti Javi y a todos los oyentes por dedicar 01:04:30.800 --> 01:04:34.620 este tiempo a hablar de Multitodals y de 01:04:36.180 --> 01:04:41.940 Represcarers y nada, un fuerte saludo muchas gracias, cuento contigo para otra vale, 01:04:42.080 --> 01:04:45.700 cuenta con ello un abrazo muy fuerte de Toni. 01:04:45.840 --> 01:04:48.080 Otro, hasta ahora chao, hasta pronto.