1 00:00:07,500 --> 00:00:09,722 Muy buenas tardes, Toni. ¿Qué tal estás? 2 00:00:10,680 --> 00:00:15,440 ¿Qué tal? Muy bien, muy contento y muy agradecido por tu invitación. 3 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 4 00:00:21,020 --> 00:00:23,980 la comunidad. ¡Qué bien! ¿Un cafecito? 5 00:00:24,140 --> 00:00:27,080 Vamos a tomarnos un cafecito y vamos a hablar de Multicloud. 6 00:00:27,120 --> 00:00:35,120 Nos vimos en la convención de SPU y ya 7 00:00:35,120 --> 00:00:37,280 entonces, en septiembre, ya fechamos más o menos. 8 00:00:37,320 --> 00:00:41,820 Para enero hablamos de Multicloud en el podcast. 9 00:00:42,520 --> 00:00:47,940 Correcto, correcto. Sí, sí, sí, te empiezo contando, vamos a ponernos en contexto. 10 00:00:48,620 --> 00:00:54,780 Oracle Cloud World en septiembre en una de las Keynotes sale Larry Ellison con el Satya 11 00:00:54,780 --> 00:01:01,820 Nadella de Microsoft diciendo, amigos para siempre, ya no vamos a estar solos, el 12 00:01:01,820 --> 00:01:08,640 futuro en una sola cloud es totalmente imposible de concebir, es decir, tiene que ser 13 00:01:08,640 --> 00:01:11,480 el futuro multicloud sí o sí. 14 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 15 00:01:17,580 --> 00:01:25,040 comentario de, y podemos decir incluso que hay más velocidad, es decir, hay una 16 00:01:25,040 --> 00:01:32,260 comunicación mucho más fluida entre los data centers de OCIC con Azure 17 00:01:32,260 --> 00:01:35,840 que entre data centers de diferentes regiones. 18 00:01:35,840 --> 00:01:43,660 Es muy interesante que los vecinos o los cuatro grandes vecinos estemos juntos 19 00:01:43,660 --> 00:01:49,860 y arrancó así y todo el mundo se quedó con el culo torcido. 20 00:01:51,420 --> 00:01:57,240 Totalmente. Al final, haciendo un pequeño símil, los seres humanos somos animales sociales 21 00:01:57,240 --> 00:02:01,110 y qué mejor si podemos compartir experiencias juntos. 22 00:02:01,110 --> 00:02:07,840 Entonces, haciendo el símil con el cloud, cada proveedor cloud, cada IP de HyperSkyler, 23 00:02:07,880 --> 00:02:15,700 tiene sus fortalezas y sus debilidades y si entre ellos pueden trabajar juntos, sin 24 00:02:15,700 --> 00:02:18,867 duda a las empresas y a los usuarios nos irá mucho mejor. 25 00:02:19,720 --> 00:02:27,040 ¡Qué grande, no? Sí, sí. Dime, dime, yo quiero decir, esto es algo 26 00:02:27,040 --> 00:02:29,400 como bastante novedoso, ¿no? 27 00:02:29,420 --> 00:02:37,490 Es algo así como, dejamos de ser competidores para ser co -competidores, ¿no? 28 00:02:37,510 --> 00:02:40,490 Hacer una competencia colaborativa, ¿no? 29 00:02:40,770 --> 00:02:45,250 Es algo totalmente... Sí, es algo completamente novedoso. 30 00:02:45,890 --> 00:02:52,940 Además, desde el punto de vista de Oracle es incluso un cambio de estrategia muy 31 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 32 00:02:59,860 --> 00:03:07,070 enormes beneficios. Azure tiene unas enormes fortalezas Oracle tiene una tradición Empresarial 33 00:03:07,070 --> 00:03:14,130 brutal Que todos conocemos perfectamente En el mundo Cloud Han sido de los 34 00:03:14,130 --> 00:03:21,200 cuatro Grandes Los últimos en estar ahí De hecho, bueno, este Si no me 35 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 36 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 37 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 38 00:03:42,330 --> 00:03:46,790 sorprendente, es decir, no sólo vamos a dejar, entre comillas, de hacernos de competencia 39 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 40 00:03:53,940 --> 00:04:02,060 vamos vamos a estar juntos y vamos a mostrar esas alianzas de 41 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, 42 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, 43 00:04:13,380 --> 00:04:20,460 esos cuatro grandes vecinos, como decías tú, en lo que hemos estado un poquito 44 00:04:20,460 --> 00:04:22,380 hablando, ¿no?, Hyperscaler. 45 00:04:22,480 --> 00:04:26,980 Tendríamos que poner un botón de cada palabrejo raro definirlo. 46 00:04:28,740 --> 00:04:30,407 Hyperscaler, proveedor grande. 47 00:04:31,620 --> 00:04:34,453 Aquí estamos hablando de los cuatro grandes, que es 48 00:04:35,380 --> 00:04:42,680 Microsoft con Azure, Google con GCP, con Google Cloud y Amazon con AWS, 49 00:04:43,280 --> 00:04:50,940 que fue el primero, además, en empezar en el mundo del cloud con los 50 00:04:50,940 --> 00:04:58,200 hyperscalers y por último y no menos importante por supuesto oracle con ozzy y 51 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 52 00:05:04,560 --> 00:05:12,160 solamente Microsoft con Oracle o los 53 00:05:12,160 --> 00:05:19,170 otros ya han dicho en el caso En el caso de la vecindad física, es 54 00:05:19,170 --> 00:05:26,170 cierto que entre Oracle y Microsoft hay unos acuerdos muy potentes 55 00:05:26,170 --> 00:05:35,130 que simplifican mucho a los clientes la integración entre los dos hyperscalers, 56 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 57 00:05:41,650 --> 00:05:48,700 unos afortunados. En el sentido de que los cuatro han 58 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. 59 00:05:55,180 --> 00:06:03,060 Lo que desde el punto de vista de conectividades y latencias es brutal las capacidades 60 00:06:03,060 --> 00:06:08,920 que eso abre. Y en otras partes del mundo, como Latinoamérica, estamos viendo como Oracle 61 00:06:08,920 --> 00:06:15,920 está redoblando la apuesta, desplegando prácticamente regiones en 62 00:06:15,920 --> 00:06:21,280 cada país. Recientemente, si no me falla la memoria, en Colombia. 63 00:06:22,920 --> 00:06:28,140 ¿Y van a estar juntos, juntos, juntos, en la misma región los cuatro? 64 00:06:28,540 --> 00:06:32,000 Es decir, ¿vamos a tener ese vecindario real, físico? 65 00:06:37,170 --> 00:06:39,570 Vamos a ver, juntos pero no revueltos. 66 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 67 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 68 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 69 00:06:59,050 --> 00:07:00,570 están físicamente muy cerca 70 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 71 00:07:12,710 --> 00:07:18,210 abrir una segunda región con lo que le llaman región soberana. 72 00:07:18,290 --> 00:07:25,320 Esto significa que Las cuatro empresas de las 73 00:07:25,320 --> 00:07:31,080 que estamos hablando son empresas que son americanas, que dependen de una manera u otra 74 00:07:31,080 --> 00:07:32,660 bajo legislación americana. 75 00:07:32,660 --> 00:07:36,382 Hablamos, por ejemplo, de la Patriot Act en un momento determinado. 76 00:07:36,760 --> 00:07:38,482 ¿Qué significa región soberana? 77 00:07:38,540 --> 00:07:45,690 Significa que tú vas a poder tener tus cargas en una región que 78 00:07:45,880 --> 00:07:50,800 está amparada 100 % sobre empresas europeas y sobre legislación europea. 79 00:07:51,470 --> 00:07:56,730 Entonces, estos sectores altamente regulados tienen unas capacidades también muy potentes. 80 00:07:59,760 --> 00:08:07,720 Incluso estamos hablando desde el punto de vista de las empresas que gestiona 81 00:08:07,720 --> 00:08:14,750 esa región, los técnicos están en Europa y desde el punto de 82 00:08:14,750 --> 00:08:17,570 vista legal están amparados 100 % sobre leyes europeas. 83 00:08:17,610 --> 00:08:26,140 Lo que comentabas de físicamente en el mismo edificio, si es cierto, de 84 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 85 00:08:32,800 --> 00:08:40,000 de este año había un acuerdo donde tú podías tener un entorno multicloud, 86 00:08:40,100 --> 00:08:47,740 ahora que es Microsoft, Bueno, con una consola multicloud y que utilizando 87 00:08:47,740 --> 00:08:53,800 ExpressRoot y FastConnect, entre los dos hiperescalers tenías unas latencias de 2 -3 88 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 89 00:09:00,100 --> 00:09:06,300 OCI y tu parte de aplicación en Azure con esas latencias de 2 -3 milis. 90 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 91 00:09:15,090 --> 00:09:20,590 el datacenter de Azure, con latencias inferiores a un milisegundo. 92 00:09:20,750 --> 00:09:27,940 Lo que en aplicaciones super críticas y muy sensibles a latencias es un salto 93 00:09:27,940 --> 00:09:29,980 también cualitativo y cuantitativo. 94 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 95 00:09:35,350 --> 00:09:39,170 muy bien la alianza es, no sé si visteis la noticia que Microsoft 96 00:09:40,470 --> 00:09:45,790 Está utilizando OCI para todos los procesos de 97 00:09:46,750 --> 00:09:48,250 inteligencia artificial con 98 00:09:49,310 --> 00:09:56,550 Con Copilot y con Bing Lo que es lo que da 99 00:09:56,550 --> 00:10:01,130 un mensaje muy importante al mercado, es decir la propia Microsoft que tiene Azure, Azure 100 00:10:01,170 --> 00:10:05,970 está utilizando OCI para los procesos de inteligencia artificial de Bing. 101 00:10:08,110 --> 00:10:10,750 Yo entiendo que también hay mucho marketing ahí detrás, ¿no? 102 00:10:10,790 --> 00:10:17,950 Es decir, da un golpe de efecto en que tú utilizas mi tecnología 103 00:10:17,950 --> 00:10:23,370 y yo también diré que utilizo Azure en otra cosa, ¿no? 104 00:10:26,410 --> 00:10:29,950 Sí, evidentemente seguro que hay una parte de marketing, si no, aunque se hiciera, no 105 00:10:29,990 --> 00:10:37,400 se diría. Eso es, esto es evidente, pero también es 106 00:10:37,400 --> 00:10:42,820 cierto que Oracle por ejemplo ha hecho una apuesta, ha redoblado la apuesta. 107 00:10:44,560 --> 00:10:48,120 Comprando toda la producción de NVIDIA del año 2024. 108 00:10:50,540 --> 00:10:54,880 Ah, si es verdad, es verdad, si, si me había comprado todo 109 00:10:57,200 --> 00:11:02,300 Que nos van a dejar sin tarjetas gráficas para poder jugar al GTA VI, ¿veis? 110 00:11:02,720 --> 00:11:05,580 Sí, no, y ya no miramos Bitcoin. 111 00:11:08,340 --> 00:11:12,530 Totalmente, totalmente. ¡Qué bueno! 112 00:11:13,490 --> 00:11:16,230 Vamos a hablar, si te parece, aparte del multicloud. 113 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 114 00:11:21,010 --> 00:11:22,750 de la charla que nos dio en el 115 00:11:24,030 --> 00:11:26,990 SPU Saipen Umuru. Bueno, y también 116 00:11:28,070 --> 00:11:30,410 Rubén nos dio una charla también. 117 00:11:30,470 --> 00:11:33,230 Hicieron los dos también charlas sobre FinOps. 118 00:11:34,050 --> 00:11:39,410 Es importante e interesante que se esté planteando también desde un punto de vista de 119 00:11:39,410 --> 00:11:46,640 una certificación oficial de FinOps y toda una cultura de FinOps de forma 120 00:11:46,640 --> 00:11:51,800 abierta en el que todos, todos los jugadores están reconociendo, es que quizá para lo 121 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 122 00:11:59,220 --> 00:12:05,300 ser barato en ciertos componentes que necesitas y en otros componentes, por eso es buscar 123 00:12:05,300 --> 00:12:12,980 ese coste efectivo, no tenerlos en una en una cláusula al lado, no tener ciertos 124 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, 125 00:12:18,800 --> 00:12:23,880 no una una Una configuración a medida personalizada en el cual a nivel financiero, con 126 00:12:23,880 --> 00:12:27,840 toda esta cultura de FinOps, te salga más barato. 127 00:12:27,940 --> 00:12:31,760 Es decir, el retruque te salga barato a todos los efectos. 128 00:12:32,590 --> 00:12:36,970 Entonces, ¿tú cómo ves este tema de FinOps con el multicloud? 129 00:12:37,730 --> 00:12:40,119 ¿Está afinado la gente? ¿Está concienciada? 130 00:12:40,310 --> 00:12:44,850 Esto ya es chafardería, es curiosidad. 131 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 132 00:12:50,250 --> 00:12:57,530 de finops y de finanzas no finops estamos hablando de la finanza en operaciones 133 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 134 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 135 00:13:06,470 --> 00:13:09,550 s te puedes ahorrar en la mitad del el presupuesto. 136 00:13:10,550 --> 00:13:12,370 ¿Sabes tú? ¿Tienes cositas así? 137 00:13:12,450 --> 00:13:13,650 ¿Tienes conocimiento de...? 138 00:13:13,690 --> 00:13:20,960 Vamos a ver, conozco casos de que cuando tú haces una migración 139 00:13:20,960 --> 00:13:28,020 hacia cloud hay ciertos costes, no denominaría costes ocultos, 140 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 141 00:13:33,650 --> 00:13:40,660 ir. Y aquí, bueno, y esto es un buen diseño de una landing zone, 142 00:13:40,720 --> 00:13:42,500 hace que los costes puedan ser más contenidos. 143 00:13:42,540 --> 00:13:47,760 Hablo, por ejemplo, de un gap que hay habitualmente, que es cuando tú estás trabajando 144 00:13:47,760 --> 00:13:53,110 en on -prem, los costes de comunicaciones, no tienes costes por tráfico. 145 00:13:53,270 --> 00:14:00,270 Tú pagas canuto y de entrada salía internet Y el tráfico 146 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 147 00:14:06,800 --> 00:14:08,189 tener un coste adicional. 148 00:14:09,100 --> 00:14:17,160 Cuando tú, por ejemplo, en algún otro hyperscaler, el tráfico atraviesa VPCs, 149 00:14:17,420 --> 00:14:21,100 los euros empiezan a caer. 150 00:14:21,100 --> 00:14:26,040 O cuando atraviesa suscripciones entonces 151 00:14:27,240 --> 00:14:34,280 Un buen diseño sobre eso es clave dicho esto en el caso de el 152 00:14:34,280 --> 00:14:41,500 reto más grande cuando tú tienes un escenario ya de per se un reto 153 00:14:41,500 --> 00:14:49,240 que cuando tú haces tu primer movimiento hacia cloud es 154 00:14:49,240 --> 00:14:56,460 bueno Bueno, yo creo mi cuenta, abro cloud .oracle .com, meto mi correo, 155 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 156 00:15:02,980 --> 00:15:05,290 unos créditos y empiezo a trabajar. 157 00:15:05,290 --> 00:15:12,460 Pero en empresas más pequeñas 158 00:15:12,460 --> 00:15:14,700 se suele empezar así. ¿Qué es lo que pasa? 159 00:15:14,740 --> 00:15:22,450 ¿No tienes en cuenta temas como pueden ser temas de gobierno, temas de seguridad, temas 160 00:15:22,450 --> 00:15:29,710 de networking para hacer una topología hub and spoke que te permita, desde 161 00:15:29,710 --> 00:15:33,210 el punto de vista de gestión de costes, tenerlo más organizado? 162 00:15:34,050 --> 00:15:40,100 Entonces esa parte Toda inicial que la haces así con un poco de prisa corriendo porque 163 00:15:40,100 --> 00:15:44,920 quieres empezar a trabajar, sobre todo aquellas empresas que empezamos a trabajar con 164 00:15:44,920 --> 00:15:46,698 Cloud hace muchos años cuando no 165 00:15:47,620 --> 00:15:50,620 Ni siquiera el concepto de landing zone existía mucho. 166 00:15:52,560 --> 00:15:58,900 De repente te das cuenta que de tus costes, tus costos de infraestructura subyacente 167 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 168 00:16:02,900 --> 00:16:06,178 a esto? Para conseguir que el cloud no se me vaya de madre. 169 00:16:07,620 --> 00:16:11,460 Y entonces empiezas a aplicar diferentes estrategias. 170 00:16:11,580 --> 00:16:14,358 Esto en un cloud, si ya tenemos diferentes clouds, 171 00:16:15,840 --> 00:16:19,820 Donde ya tienes que aplicar políticas de gobierno entre diferentes clouds, tienes que 172 00:16:19,860 --> 00:16:27,120 aplicar políticas de tal impasse, que es un elemento clave para el correcto manejo 173 00:16:27,120 --> 00:16:33,640 de FinOps. Bueno, es un aprendizaje, en el fondo es un aprendizaje continuo. 174 00:16:35,320 --> 00:16:36,709 No sé si me he explicado. 175 00:16:36,810 --> 00:16:41,930 Sí, sí, sí yo el primer batacazo lo veía en coste de CPU. 176 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 177 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 178 00:16:53,510 --> 00:16:57,170 automáticamente y te va a dar un susto. 179 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, 180 00:17:02,130 --> 00:17:09,810 ahí no hay ningún impacto, pero en ciertas configuraciones de auto scale ostras 181 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 182 00:17:17,060 --> 00:17:24,240 recursos y empieza el ocia a auto proveer aumentar cpu si a provisionar 183 00:17:24,240 --> 00:17:31,800 se estos yo creo que tampoco se tiene en cuenta cuando uno hace el cuadro 184 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 185 00:17:37,040 --> 00:17:41,360 en cloud no tiene esa visión de que eso de pronto 186 00:17:42,340 --> 00:17:44,360 se puede ir de madre a nivel de 187 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 188 00:17:51,240 --> 00:17:55,518 hiper -skiller, a veces tienes que tomar una decisión entre la mala y la peor 189 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. 190 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, 191 00:18:06,140 --> 00:18:12,660 eso. Compren, tardará más, tardará menos, pero el coste es fijo en 192 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 193 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 194 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 195 00:18:32,750 --> 00:18:37,710 proceso y Y que a lo mejor te quedas sin el cierre de facturación. 196 00:18:38,450 --> 00:18:41,050 Me ha gustado eso de entre la mala y la peor. 197 00:18:41,970 --> 00:18:45,026 Tienes que tener una decisión mala o una decisión peor. 198 00:18:49,910 --> 00:18:51,799 Yo la veo un poco así, pero bueno. 199 00:18:52,190 --> 00:18:54,523 Sí, sí, sí, pero es que es la pura verdad. 200 00:18:54,750 --> 00:18:59,180 Es la pura verdad. Claro, yo creo que esto... 201 00:18:59,180 --> 00:19:00,620 ¿Tú cómo ves la situación? 202 00:19:00,660 --> 00:19:04,720 Yo veo que la gente sigue siendo... 203 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, 204 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 205 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 206 00:19:20,260 --> 00:19:23,520 que pensar mucho más cuál es la configuración. 207 00:19:25,870 --> 00:19:33,040 Porque, claro, es decir, entre diferentes fabricantes va a haber diferentes casuísticas 208 00:19:33,040 --> 00:19:39,660 o diferentes problemas heredados de comunicaciones o de implantaciones. 209 00:19:40,480 --> 00:19:46,000 ¿Cómo se hace ese estudio previo sin revelar ningún dato confidencial? 210 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, 211 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. 212 00:19:58,820 --> 00:20:02,100 ¿Cómo lo enfocas tú cuando haces esto? 213 00:20:04,240 --> 00:20:06,560 Primero, entendiendo las preferencias del cliente. 214 00:20:06,600 --> 00:20:08,460 Y aquí es un punto importante. 215 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. 216 00:20:16,530 --> 00:20:20,090 Independientemente de que la solución técnica que pueda dar uno u otro sean mejores, 217 00:20:20,130 --> 00:20:27,810 a veces hay, por confianza, falta de confianza, por acuerdos marco, 218 00:20:27,810 --> 00:20:33,140 por el motivo que sea, que un hyperscriber se cae de la ecuación. 219 00:20:35,940 --> 00:20:41,940 Hecho ese primer cribado, el segundo es: ¿qué cargas de trabajo voy a mover a cloud? 220 00:20:43,330 --> 00:20:45,610 Y ver qué tiene más sentido. 221 00:20:45,610 --> 00:20:52,880 Y dentro del que tiene más sentido, si estamos hablando de una empresa, vamos 222 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, 223 00:21:00,150 --> 00:21:05,030 que tiene una parte de middleware con WebLogic, que tiene unas máquinas virtuales como 224 00:21:05,030 --> 00:21:08,150 en torno a Windows y que tiene además unos SQL Server. 225 00:21:08,150 --> 00:21:14,170 Vamos a inventarnos un caso, un ejercicio de ese tipo, entonces tú empiezas a pensar 226 00:21:15,420 --> 00:21:18,200 ¿Dónde tiene más sentido que mueva mis bases de datos Oracle? 227 00:21:18,240 --> 00:21:21,018 ¿Dónde tiene más sentido que mueva mis SQL Server? 228 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 229 00:21:28,900 --> 00:21:35,110 he ido a algo fácil Entonces, pues de primeras empiezas a intentar orientar las cargas 230 00:21:35,110 --> 00:21:43,320 a lo que Tiene más sentido desde el punto de vista de negocio, incluso buscando 231 00:21:43,320 --> 00:21:52,000 una posterior una posterior transformación cuando te planteas un journey to cloud y tú 232 00:21:52,540 --> 00:21:58,260 y tú partes de una infraestructura una infraestructura tradicional donde tienes en máquinas 233 00:21:58,260 --> 00:22:05,320 virtuales que entre buenos servidores que entre todos ellos componen un 234 00:22:05,320 --> 00:22:07,680 nuevo servicio a una aplicación, ¿cómo 235 00:22:08,610 --> 00:22:09,950 vas a hacer esa migración hacia cloud? 236 00:22:09,990 --> 00:22:13,510 Vamos a hacer migración, vamos a hacer un defensive. 237 00:22:15,050 --> 00:22:20,640 Defensive significa cojo los servidores que tengo en un premio y los pongo a funcionar 238 00:22:20,640 --> 00:22:26,100 en cloud. O bien planteo escenarios más o menos transformadores. 239 00:22:27,390 --> 00:22:34,480 Y un ejemplo de un escenario, a lo mejor no 240 00:22:34,480 --> 00:22:41,400 muy transformadores, es, yo tengo mi base A2 alrededor de aquel 19C que en un premio 241 00:22:41,400 --> 00:22:46,670 la tengo sobre un rack, ¿a dónde me la llevo? 242 00:22:46,910 --> 00:22:53,270 La despliego en OCI y la despliego sobre un Autonomous, una del CS 243 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 244 00:23:00,250 --> 00:23:08,320 que era infraestructura en tu entorno en premio a base de datos como servicio, ya 245 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 246 00:23:12,280 --> 00:23:17,980 tienes que o transformarlos o migrarlos con una estrategia de defense shift de ese servidor. 247 00:23:20,330 --> 00:23:21,719 ¿Cómo haces este estudio? 248 00:23:23,030 --> 00:23:24,919 Aplicación, aplicación en el fondo 249 00:23:27,050 --> 00:23:29,190 Por mucho de que la gente de 250 00:23:30,170 --> 00:23:31,948 infraestructura a veces pensemos 251 00:23:32,440 --> 00:23:39,400 en servidores, en redes redes, en máquinas virtuales, en firewalls y cosas de estas, 252 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 253 00:23:45,190 --> 00:23:52,250 es, tengo la aplicación Discord, la aplicación Discord, ¿qué 254 00:23:52,380 --> 00:23:53,780 elementos requiere para funcionar? 255 00:23:53,820 --> 00:24:00,940 Vale, pues requiere unos balanceadores, requiere unos contenedores de 256 00:24:00,940 --> 00:24:06,780 cavernets, requiere una base de datos o un Oracle o un Mongo me lo estoy inventando 257 00:24:08,260 --> 00:24:12,640 Vale, veamos con cada uno de esos servicios, cuál es la mejor estrategia. 258 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 259 00:24:18,400 --> 00:24:23,390 dentro de la ventana de cambio que podemos tener, y luego 260 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 261 00:24:29,240 --> 00:24:34,740 cloud, tenemos que empezar a pensar qué transformaciones vamos a hacer si queremos hacer 262 00:24:34,740 --> 00:24:41,380 que la migración a cloud sea realmente efectiva en coste en el sentido de que 263 00:24:42,730 --> 00:24:47,510 Si nos planteamos que una migración hacia cloud vamos a coger nuestra infraestructura 264 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 265 00:24:53,030 --> 00:24:59,900 lo normal es que nos haga algo muy bien cuenta cuéntame más 266 00:25:04,060 --> 00:25:11,140 Por ese camino Que no salga muy bien en el sentido de 267 00:25:11,140 --> 00:25:15,960 que bueno si tú tienes unos costes de una 268 00:25:17,460 --> 00:25:24,480 Infraestructura que a lo mejor tienes ciertos y ciertos ratios de configuración de CPU 269 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 270 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 271 00:25:35,480 --> 00:25:39,240 una CPU física con las ventajas que ello conlleva 272 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 273 00:25:44,830 --> 00:25:46,941 máquina virtual con una base de datos. 274 00:25:48,660 --> 00:25:55,840 Con Oracle más una máquina virtual con WebLogic, ambas bases de datos con 30 275 00:25:55,840 --> 00:26:02,840 gigas de RAM y 50 teras de discos por si 276 00:26:02,840 --> 00:26:06,960 acaso, porque en on -prem muchas veces dimensionas por si acaso para el crecimiento futuro 277 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 278 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, 279 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 280 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 281 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 282 00:26:36,780 --> 00:26:43,780 infraestructuras como se gestionarán en hombre no por ejemplo tienen disco libre disco 283 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é 284 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 285 00:26:57,160 --> 00:27:03,280 de desplegue de infraestructura, desplegarla de manera tradicional, la gestión del ciclo 286 00:27:03,280 --> 00:27:08,280 de vida de la infraestructura, hacerlo de manera tradicional, la gestión del ciclo de 287 00:27:08,280 --> 00:27:13,740 vida de la aplicación, hacerlo de manera tradicional en lugar de transicionar hacia un 288 00:27:13,740 --> 00:27:21,570 modelo de box. Y aquí, bueno, igual nos salimos un poco del scope de nuestro café 289 00:27:23,600 --> 00:27:29,640 Pero al final son todo derivadas de que 290 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 291 00:27:38,100 --> 00:27:45,240 nuevo camino uff Bueno, y además como una nueva 292 00:27:45,240 --> 00:27:51,260 forma de conceptualizarlo todo, porque es como decías, es decir, antes en el hombre tú 293 00:27:51,260 --> 00:27:58,260 estás entendiendo una Filosofía de en casa tengo todo 294 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 295 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 296 00:28:10,160 --> 00:28:14,900 al cloud uno puede transicionar con bar y metal todo venga pues Pues para hacerlo igual 297 00:28:14,940 --> 00:28:21,520 a lo que tengo, venga, pues máquinas dedicadas, sistemas dedicados, disco... 298 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, 299 00:28:27,520 --> 00:28:34,650 voy a... Claro, tú te puedes plantear en día cero de migración, pues 300 00:28:35,030 --> 00:28:41,550 mantengo el escenario actual, pero pensando ya en las transformaciones posteriores, si 301 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 302 00:28:45,790 --> 00:28:49,512 costes si quieres aprovechar todas las ventajas que te da el cloud. 303 00:28:49,920 --> 00:28:53,753 Desde el punto de vista de estabilidad, de escalabilidad de seguridad 304 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 305 00:29:01,680 --> 00:29:09,260 maravillosos que te puede ofrecer el cloud no los estás aprovechando 306 00:29:09,260 --> 00:29:16,320 ni diría que incluso disfrutando y tus usuarios aprovechándose 307 00:29:16,320 --> 00:29:21,990 de dichas ventajas. Esta parte es muy interesante. 308 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, 309 00:29:29,330 --> 00:29:34,490 ese escenario ideal o esa arquitectura totalmente optimizada? 310 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 311 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 312 00:29:44,070 --> 00:29:49,410 entre una empresa media contando que no haya cosas extrañas? 313 00:29:49,410 --> 00:29:50,910 Ahora te pondré un ejemplo. 314 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 315 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 316 00:30:04,410 --> 00:30:06,854 que a lo mejor en los dos primeros años esto 317 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? 318 00:30:12,570 --> 00:30:14,681 ¿Cuánto tiempo crees que la gente está 319 00:30:16,320 --> 00:30:21,670 En esa transición? Es una pregunta difícil. 320 00:30:23,370 --> 00:30:27,970 Y... en general, según tu experiencia, que nos estamos tomando un café, que no somos 321 00:30:28,010 --> 00:30:30,110 de Oracle. Sí, no, no, no sé. 322 00:30:33,110 --> 00:30:37,470 Por eso la pregunta, la respuesta tiene que tener un cierto sentido. 323 00:30:41,110 --> 00:30:48,890 Es difícil porque, para llegar a aprovechar todo eso, hay mucho impacto en las aplicaciones, 324 00:30:48,990 --> 00:30:56,490 en los equipos de TI, que incluso se generen proyectos para esa transformación; no 325 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 326 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 327 00:31:11,020 --> 00:31:13,740 que supongan ventajas significativas. 328 00:31:14,300 --> 00:31:16,411 Ahora bien, ¿cuándo termina el camino? 329 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é. 330 00:31:24,510 --> 00:31:31,850 Y creo que el camino de la optimización y del cloud en este momento un 331 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 332 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, 333 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, 334 00:31:49,880 --> 00:31:55,960 pues que hemos sacado este nuevo servicio que te proporciona X ventajas y que además 335 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 336 00:32:00,420 --> 00:32:08,300 más largo. Entonces es como el aprendizaje informática que nunca, nunca termina, que 337 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 338 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, 339 00:32:21,320 --> 00:32:27,040 porque hay que volver a empezar otro ciclo de utilización, la vuelta de tuerca otra. 340 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 341 00:32:33,440 --> 00:32:40,640 ya años, es que en el fondo nos gusta la marcha, somos masoquistas totalmente, 342 00:32:40,640 --> 00:32:48,300 bueno. Y que pasa con los sistemas legacy yo tengo 343 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 344 00:32:55,000 --> 00:33:02,710 bueno pues no está tan mal pero Pero a 345 00:33:03,100 --> 00:33:10,120 esa gente, es decir, empresas que tengan entornos aún muy, digamos, muy 346 00:33:10,120 --> 00:33:14,960 legacy, ¿tú cómo ves? ¿Qué experiencia tienes haciendo ese journey to cloud? 347 00:33:15,180 --> 00:33:21,060 Al momento cero de su vida y después al momento de transformación. 348 00:33:21,120 --> 00:33:27,350 ¿Cómo lo ves? Ahí es complejo Ahí es especialmente complejo Porque cuando tú tienes una 349 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 350 00:33:33,530 --> 00:33:40,610 Una cosa así Consolera. El problema no es la base 351 00:33:40,610 --> 00:33:43,554 de datos, el problema es seguro que es la aplicación. 352 00:33:44,970 --> 00:33:48,650 Si yo te contara. Es un report. 353 00:33:48,650 --> 00:33:52,830 Es un report que me pasaron el report 6. 354 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 355 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. 356 00:34:05,930 --> 00:34:07,610 Imagínate, y eso sigue funcionando aún. 357 00:34:07,650 --> 00:34:12,030 Sí, sí, sí, lo conozco perfectamente. 358 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 359 00:34:20,290 --> 00:34:27,570 no Probablemente no hace un upgrade y, si está una seta tan antigua, requiere cambios 360 00:34:27,570 --> 00:34:30,580 importantes por debajo, no puedes hacer nada. 361 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, 362 00:34:36,930 --> 00:34:40,350 o se busca una aplicación que la sustituya, o 363 00:34:41,470 --> 00:34:50,450 cuando haces la migración a cloud de esa aplicación tienes que tratarla prácticamente 364 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 365 00:34:55,290 --> 00:35:02,020 datos. En este caso estamos hablando, cuando nosotros lo llevamos a cloud, no es que 366 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 367 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 368 00:35:15,130 --> 00:35:22,490 EPScaler. Entonces ahí la cosa se empieza a complicar, se empieza a complicar en el sentido 369 00:35:22,490 --> 00:35:24,330 de que a lo mejor tienes que 370 00:35:26,170 --> 00:35:29,850 Me lo vuelvo a inventar, imaginemos que esa base de datos está corriendo sobre un VMware 371 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 372 00:35:36,590 --> 00:35:39,750 tal cual la tienes y no puedes hacer mucho más. 373 00:35:41,340 --> 00:35:43,960 Salvo que haya una actualización 374 00:35:46,590 --> 00:35:53,950 Que Que es algo que hay en una actualización que permite actualizarse 375 00:35:53,950 --> 00:35:56,339 a base de datos. Sí, eso es lo que decimos. 376 00:35:56,490 --> 00:36:01,870 Yo, a lo que me encuentro con ese tipo de migraciones, no me encuentro mucho problema 377 00:36:01,870 --> 00:36:07,710 en las estructuras, que pueden ser estructuras obsoletas, porque es muy fácil convertirlas. 378 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 379 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 380 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 381 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 382 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 383 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 384 00:36:46,240 --> 00:36:53,280 antiguos también y lo conectas y toda la conectividad con todo lo demás incluso 385 00:36:53,540 --> 00:36:59,920 que cuando tú haces la actualización de un motor tan antiguo un motor motor moderno, 386 00:36:59,940 --> 00:37:02,829 pues a lo mejor que tenga regresiones de rendimiento 387 00:37:04,040 --> 00:37:07,850 Tiene su impacto Sí, sí, sí. 388 00:37:08,510 --> 00:37:11,430 Sí, sí, y tanto, claro. Es un cambio 389 00:37:12,970 --> 00:37:19,500 De escena. No hemos hecho la alerta palabra, no sé, si alguien en la audiencia tiene 390 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 391 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 392 00:37:29,660 --> 00:37:34,620 y y subir. Recuerdo que estamos grabando esto, lo estamos grabando y lo subiremos al 393 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 394 00:37:38,200 --> 00:37:42,400 para si queréis y los que no pues en el podcast subiremos y 395 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 396 00:37:48,160 --> 00:37:52,280 este también una segunda vez por si por si algo. 397 00:37:54,340 --> 00:37:58,500 Se os escapa oye, súper interesante lo del tema este, ¿no? 398 00:37:59,320 --> 00:38:04,320 Lo del multicloud Pero, ¿tú cómo ves que está impactando? 399 00:38:04,540 --> 00:38:06,560 Es decir, ¿está generando...? 400 00:38:06,560 --> 00:38:09,120 Estamos en la fase en la que la gente... 401 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 402 00:38:14,600 --> 00:38:19,420 de nuevos errores que suceden en el paso a... 403 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 404 00:38:26,980 --> 00:38:29,260 journeys, cómo se han desarrollado? 405 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á, 406 00:38:34,880 --> 00:38:37,120 no, pero siempre hay bugs nuevos y siempre hay follones y tal. 407 00:38:37,160 --> 00:38:45,160 Sí, sí, sí pero en OCI, entre diferentes fabricantes y diferentes, son diferentes arquitecturas 408 00:38:45,160 --> 00:38:51,890 de cloud, ¿no? El conocimiento que tengo es errores, errores de colectividad, errores 409 00:38:51,890 --> 00:39:01,200 nuevos de cosas que, como el escenario es totalmente distinto, hay todo un nuevo surtido 410 00:39:01,200 --> 00:39:08,280 de errores, problemas, crashes, toda esta 411 00:39:08,310 --> 00:39:12,470 integración. Con GoldenGate se integra todo. 412 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 413 00:39:17,410 --> 00:39:19,410 de datos pueden reventar por dentro. 414 00:39:19,630 --> 00:39:22,710 ¿Tú cómo ves el tema? Voy concretando la pregunta. 415 00:39:23,850 --> 00:39:25,970 ¿Accidentes, errores, trompazos? 416 00:39:26,010 --> 00:39:27,530 Es decir, vamos a migrar y de pronto ¡pam! 417 00:39:27,570 --> 00:39:32,470 Un crash tenemos que parar porque algo ha reventado. 418 00:39:32,470 --> 00:39:36,248 Ha reventado un proceso, De pronto revienta la migración o de pronto 419 00:39:36,450 --> 00:39:41,560 la conectividad nos rinde, errores ¿Qué experiencia tienes? 420 00:39:41,660 --> 00:39:45,993 ¿Te has encontrado con mucho problema o ves que eso está ya bastante madurito? 421 00:39:46,150 --> 00:39:48,500 Yo creo que tiene un buen grado de madurez. 422 00:39:48,540 --> 00:39:55,580 Evidentemente todo falla y además en entornos tan 423 00:39:55,580 --> 00:40:02,580 complejos. Pero no recuerdo yo grandes 424 00:40:02,580 --> 00:40:05,100 problemas en los últimos tiempos. 425 00:40:05,100 --> 00:40:10,520 Si recuerdo, mira, voy a poner un ejemplo de hace muchos años, bueno, 426 00:40:11,740 --> 00:40:14,600 Muchos años, no sé, cuatro, cuatro o cinco años. 427 00:40:15,460 --> 00:40:17,040 Bueno, pues muchos o pocos. 428 00:40:22,140 --> 00:40:30,270 Era un entorno que tenía un firewall forti gate en cloud y 429 00:40:30,560 --> 00:40:36,230 cuando cuando el tráfico entrante pasaba a través del firewall de manera aleatoria a 430 00:40:36,230 --> 00:40:42,500 veces iba bien y a veces iba mal no sé nosotros Nosotros inicialmente le abrimos caso 431 00:40:42,500 --> 00:40:49,600 a Oracle, el support al principio costó 432 00:40:49,600 --> 00:40:56,680 que le dieran cariño al caso, pero en el momento que empezamos a trabajar 433 00:40:56,680 --> 00:41:03,990 en serio en él, empezamos a revisar, empezamos a hacer pruebas con 434 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, 435 00:41:09,350 --> 00:41:16,630 el tráfico TCP en función del tamaño del paquete pasaba 436 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 437 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 438 00:41:28,660 --> 00:41:35,880 no sabes y esto no al final hicimos una decisión conjunta entre 439 00:41:35,880 --> 00:41:40,000 ahora que el forte en este caso había sido yo y 440 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 441 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 442 00:41:57,290 --> 00:41:59,390 Qué difícil es ese tipo de cosas. 443 00:41:59,390 --> 00:42:07,170 Sí, había sido una incidencia muy compleja, de hecho había entrado el principal 444 00:42:07,170 --> 00:42:11,559 arquitecto de Estados Unidos, de Oracle, de todo lo que había escalado el tema. 445 00:42:13,010 --> 00:42:18,066 Pero en el momento que empezamos a trabajar en serio, en cuatro horas estaba diagnosticada. 446 00:42:19,830 --> 00:42:25,840 Y con Walker Ramos Lo que es brutal el punto es 447 00:42:27,770 --> 00:42:31,570 Esto hubiera podido pasar, a lo mejor esta incidencia no, pero hubiera pasado una incidencia 448 00:42:31,610 --> 00:42:39,060 parecida donde tienes otros elementos de red o lo que sea y tienes una incidencia del 449 00:42:39,060 --> 00:42:43,580 estilo. La parte buena del 450 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, 451 00:42:52,080 --> 00:42:57,040 a ver, evidentemente hay caídas, hay degradaciones, pero hay un, hay un buen grado de 452 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 453 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, 454 00:43:08,270 --> 00:43:16,040 funcionalidades. Es una pasada lo bien que se está trabajando, que 455 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, 456 00:43:24,230 --> 00:43:28,270 si tienes asistentes Oracle meterlas en Office y tienes cosas de datos Microsoft, mételas 457 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 458 00:43:35,230 --> 00:43:38,730 que cada uno es lo que hace bien o hace mejor? 459 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 460 00:43:43,250 --> 00:43:47,110 que emigrar, tendremos que estudiar a lo mejor en una situación multicloud. 461 00:43:47,150 --> 00:43:48,650 ¿Qué servicios ponemos en un sitio? 462 00:43:48,690 --> 00:43:50,230 ¿Qué servicios ponemos en otro? 463 00:43:50,270 --> 00:43:52,610 ¿Y cuánto nos va a costar tenerlos en un sitio? 464 00:43:52,650 --> 00:43:54,010 ¿Cuánto nos va a costar tener en el otro? 465 00:43:54,050 --> 00:43:59,750 Y proximidades de regiones y alianzas que tengan, en este caso Microsoft y Oracle están 466 00:43:59,750 --> 00:44:02,861 muy juntitos, pero a lo mejor con otros están más lejos. 467 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 468 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 469 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 470 00:44:23,340 --> 00:44:27,500 de Sanofi porque da igual, si ahí tenemos mogollón de 471 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 472 00:44:34,900 --> 00:44:37,240 correcto base de datos sí, ahora que 473 00:44:39,400 --> 00:44:45,160 Y pongo un asterisco y con el nuevo acuerdo que anunciaron Larry y Nata 474 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 475 00:44:53,400 --> 00:44:57,340 tener una base de datos con RAC era OC pero ahora ya no 476 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 477 00:45:06,120 --> 00:45:09,953 de servicios es decir, si tú lo comprabas en Microsoft no iba a haber 478 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 479 00:45:18,240 --> 00:45:21,260 licencia de SQL Server y tal. 480 00:45:21,320 --> 00:45:27,200 Van a respetarse, digamos, una transparencia, digamos, de darle al otro enteramente el 481 00:45:27,200 --> 00:45:30,840 crédito y el valor, ¿no?, de cada producto. 482 00:45:33,300 --> 00:45:35,911 Correcto vale, base de datos ya lo hemos dicho. 483 00:45:36,420 --> 00:45:44,000 Toda la parte de Azure AD, bueno, ya he dicho el hyperscaler, para 484 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 485 00:45:50,380 --> 00:45:57,740 de servicio. Entonces, toda la parte de afuera de gestión de identidad, con 486 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. 487 00:46:02,960 --> 00:46:04,860 Microsoft tiene un punto fuerte. 488 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 489 00:46:12,540 --> 00:46:17,460 de datos, pues de tener, no sé, de tener Kafka o MongoDB. 490 00:46:19,500 --> 00:46:21,460 ¿Dónde lo pondrías? ¿A WS? 491 00:46:21,960 --> 00:46:24,940 Pues yo probablemente en WS, sí. 492 00:46:25,000 --> 00:46:27,540 En WS o en Google probablemente en WS. 493 00:46:29,940 --> 00:46:31,200 ¿Y en Google qué pondríamos? 494 00:46:31,240 --> 00:46:38,780 La parte de data y de analítica, que lo que tienen con BigQuery y Vertex 495 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? 496 00:46:46,620 --> 00:46:52,040 Vamos a ver, el tema de máquina virtual Windows es un tema delicado. 497 00:46:54,170 --> 00:47:00,450 Si nos acercas de Azure, sur la cosa que empieza por 498 00:47:01,540 --> 00:47:05,400 tema del licenciamiento y tal Microsoft no ayuda demasiado. 499 00:47:07,410 --> 00:47:11,970 A mí esa sería una, en la medida posible lo intentaría llevar hacia sur. 500 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 501 00:47:20,420 --> 00:47:25,660 servicios a un hyperscale, sobre todo cuando vas hacia servicios nativos, es definir 502 00:47:25,660 --> 00:47:29,160 correctamente en el minuto cero las estrategias de salida. 503 00:47:31,910 --> 00:47:39,390 No vaya a ser que luego la salida de ese hyperscaler 504 00:47:39,390 --> 00:47:43,390 sea extremadamente compleja o directamente imposible. 505 00:47:43,710 --> 00:47:46,321 Es que esa era otra pregunta que tenía para ti. 506 00:47:46,810 --> 00:47:53,930 Era, ¿nos damos la vuelta y nos vamos para atrás o hacemos una huida hacia 507 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 508 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 509 00:48:09,600 --> 00:48:12,433 Probablemente porque no han podido o no han querido 510 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 511 00:48:18,740 --> 00:48:26,540 no salen como tú esperabas o esos costes ocultos de landing zone que tú 512 00:48:26,570 --> 00:48:32,110 a priori no conoces de repente hacen que los costes de cloud se te disparen y 513 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 514 00:48:37,820 --> 00:48:44,400 de tercio hubo un caso muy llamativo hace unos meses que fue Netflix que desmontaba parte 515 00:48:44,400 --> 00:48:47,567 de su arquitectura de microservicios y volvía al monolito 516 00:48:49,120 --> 00:48:54,940 Y hubo un revuelo en redes sociales brutal diciendo la vuelta al monolito estamos todos 517 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 518 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 519 00:49:07,220 --> 00:49:09,942 sino la solución que se adapta a tus necesidades. 520 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 521 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, 522 00:49:22,740 --> 00:49:29,000 tengo todos estos servicios en la nube y estos ciertos tres servicios quiero traerlos, 523 00:49:29,040 --> 00:49:33,984 quiero evolucionarlos a un, o sea, a lo mejor una nueva infraestructura, pero en mi casa. 524 00:49:34,120 --> 00:49:35,898 Esto quiero que esté en mi casa. 525 00:49:36,030 --> 00:49:39,530 El punto es el por qué y el para qué. 526 00:49:40,850 --> 00:49:45,170 Y tener claro los riesgos y los beneficios. 527 00:49:45,650 --> 00:49:50,610 Y cuando hablo, por ejemplo, de los riesgos, la cantidad de medidas de seguridad, de 528 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 529 00:49:57,010 --> 00:49:58,890 hyperscaler, o eres una empresa 530 00:50:00,160 --> 00:50:04,380 Muy potente o en un prem no vas a poder pagarlo 531 00:50:05,380 --> 00:50:11,800 o no vas a querer pagar bueno, lo sacrificas, digamos se está sacrificando claro, pero 532 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, 533 00:50:16,640 --> 00:50:24,280 oye voy a simplificarlas al absurdo es decir, yo estoy en cloud, tengo servidores 534 00:50:24,280 --> 00:50:26,224 que en caso de fallo de un servidor 535 00:50:26,720 --> 00:50:33,880 pues Puedo Hacer un failover hacia otro, puedo escalar, puedo hacer 536 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 537 00:50:41,940 --> 00:50:44,780 Donde corro mi aplicación. 538 00:50:44,920 --> 00:50:45,940 ¿Estamos hablando de lo mismo? 539 00:50:45,980 --> 00:50:53,980 Evidentemente no. ¿Que la Raspberry para ti es 540 00:50:53,980 --> 00:50:56,400 suficiente? Pues oye, mira, perfecto. 541 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. 542 00:51:05,270 --> 00:51:06,990 ¡Oh! ¡Qué frase más grande! 543 00:51:09,960 --> 00:51:14,100 No hay soluciones buenas o soluciones malas, sino casos de uso existentes. 544 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 545 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 546 00:51:25,520 --> 00:51:32,940 sin que la corporación Oracle que está dirigiendo sus pasos a sus palabras estamos hablando 547 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 548 00:51:39,820 --> 00:51:46,930 al escenario y en el chat pues escribiros alguna pregunta y la y la comentamos 549 00:51:46,930 --> 00:51:54,040 pues oye hemos hemos hecho un barrido bastante interesante de toda la situación de multicloud 550 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, 551 00:52:02,270 --> 00:52:06,214 aquí estamos en un momento tecnológico súper atractivo, súper cambiante 552 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 553 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 554 00:52:20,920 --> 00:52:28,400 te van a llevar hacia el cloud en la mayor parte de los casos y 555 00:52:28,560 --> 00:52:33,100 tenemos que estar muy atentos y vigilantes para aprovechar todas las ventajas que nos 556 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 557 00:52:40,860 --> 00:52:44,970 escenario desde el punto de vista laboral? 558 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 559 00:52:52,290 --> 00:52:59,410 boom de pasos a Claudio o va a haber una nueva necesidad o que va 560 00:52:59,410 --> 00:53:05,910 a haber más necesidad de informáticos en cloud y de lo que hay ahora? 561 00:53:06,170 --> 00:53:10,030 ¿Crees que ahora mismo todo el mundo que está migrando a cloud está haciéndolo? 562 00:53:10,070 --> 00:53:14,190 ¿Tú qué crees? ¿Que hay oportunidad ahí o ya más o menos se está cubriendo? 563 00:53:14,230 --> 00:53:15,650 ¿Qué sensación tienes tú? 564 00:53:15,990 --> 00:53:18,350 Que siga habiendo mucha demanda. 565 00:53:21,400 --> 00:53:28,840 Ha habido mucha demanda de profesionales de arquitectos cloud o de cloud 566 00:53:28,840 --> 00:53:31,340 engineers o perfiles más de DevOps 567 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 568 00:53:38,820 --> 00:53:40,764 antes porque aunque ya las empresas 569 00:53:41,540 --> 00:53:46,380 Se plantean el salto hacia cloud luego hay que empezar las transformaciones hay que empezar 570 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 571 00:53:52,860 --> 00:53:59,360 ahí nos queda yo espero que quede trabajo suficiente hasta que me pueda jubilar, o me 572 00:53:59,360 --> 00:54:00,860 toque la lotería ¿tú crees? 573 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 574 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 575 00:54:15,900 --> 00:54:20,520 muy interesante, pero Microsoft Microsoft tiene Citus, que da la capacidad Multimaster, 576 00:54:20,560 --> 00:54:27,960 no sé Cuéntanos Muy buenas, saludos a Tony y Javier, un gusto platicar 577 00:54:27,960 --> 00:54:30,720 con ustedes Más que nada, para las comunidades 578 00:54:32,020 --> 00:54:39,220 Vamos a decirle que ustedes siguen ahí en la localidad de Europa Yo siempre veo, por 579 00:54:39,220 --> 00:54:41,460 ejemplo, que Microsoft tiene mucha 580 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 581 00:54:49,520 --> 00:54:57,060 rato, veía eso. Y otra, una pregunta específica sería, ¿qué nube 582 00:54:57,060 --> 00:55:04,560 piensan ustedes que dan las mejores posibilidades para que tú te prepares y te certifique? 583 00:55:07,370 --> 00:55:10,203 Vamos a decir, sí, te recojas las habilidades, ¿no? 584 00:55:13,270 --> 00:55:17,103 Gracias vamos a ver, por empezar por la segunda pregunta, yo creo que 585 00:55:18,340 --> 00:55:26,400 En estos momentos Bueno, ahora que el año pasado hizo un esfuerzo brutal con el 586 00:55:26,400 --> 00:55:32,040 Road to Certification, ese fue muy grande esa oportunidad, no sé si la tomaste pero era 587 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 588 00:55:38,400 --> 00:55:40,122 de otras cosas que tú quisieras 589 00:55:41,500 --> 00:55:47,160 Esa fue una oportunidad fantástica, de hecho ahora que la he extendido para partners 590 00:55:47,160 --> 00:55:54,240 hasta el 15 de diciembre Y no sé si la voy a extender Google también 591 00:55:54,240 --> 00:55:59,540 tiene una apuesta de formación bastante interesante con muchas formaciones gratuitas 592 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 593 00:56:10,750 --> 00:56:12,139 asumir de manera pública. 594 00:56:12,920 --> 00:56:17,160 AWS sacó también en verano algunas certificaciones gratis. 595 00:56:18,140 --> 00:56:25,620 Yo entiendo que las básicas, las de foundations y todas estas, todas las cubren y 596 00:56:25,620 --> 00:56:28,160 para multiclouds sí que hay que ir con esas. 597 00:56:29,520 --> 00:56:33,200 En OCI, claro, estaban gratuitas también las de 598 00:56:34,240 --> 00:56:39,740 multiclouds, en el que se toca también la integración con otras con otras clouds. 599 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, 600 00:56:44,520 --> 00:56:48,120 el nivel de la certificación. 601 00:56:49,820 --> 00:56:59,080 En mi opinión, por ejemplo, yo soy AWS 602 00:56:59,080 --> 00:57:06,820 Cloud Architect Associate o el Cloud Professional y OCI Professional, las 603 00:57:07,110 --> 00:57:14,190 de arquitectos. Y por ejemplo la de AWS siendo la SoCit es 604 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 605 00:57:23,290 --> 00:57:31,490 A ver es compleja pero para ser una profesional trabajándola bien es es 606 00:57:31,490 --> 00:57:38,240 asequible pero por ejemplo Amazon sí que es muy exigente en ellas pero evidentemente 607 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 608 00:57:45,020 --> 00:57:49,480 es fantástico. Por ejemplo, la que comentabas tú ahora, Javi, la de Multiplier Cloud 609 00:57:49,520 --> 00:57:56,540 de OCI, es una certificación extrema, es sencillita porque al 610 00:57:56,540 --> 00:58:03,680 final, teniendo una mínima base, podemos estar hablando de una foundation 611 00:58:03,680 --> 00:58:06,800 de Azure más una foundation de OCI, 612 00:58:08,790 --> 00:58:14,730 En tener un poco el concepto de multicloud de Oracle es una certificación muy asequible. 613 00:58:14,890 --> 00:58:18,810 De hecho, creo que recordar que eran como 20 -25 preguntas. 614 00:58:19,390 --> 00:58:20,890 El examen no daba para más. 615 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 616 00:58:29,760 --> 00:58:36,000 tener independientemente de a qué nivel te certifiques en cada una de las de las cuatro 617 00:58:36,000 --> 00:58:43,100 grandes que es la certificación de FINOPS, esto está contando Sai Permuru ¿vale? 618 00:58:43,520 --> 00:58:50,800 De la India, nos estaba contando en Madrid que es Es un asset 619 00:58:50,800 --> 00:58:57,860 muy interesante. Independientemente del nivel que tengas, tener o demostrar una certificación 620 00:58:57,860 --> 00:59:04,600 de las dos que hay de FinOps, que son muy interesantes. 621 00:59:05,080 --> 00:59:07,240 Sí, sin duda es interesante. 622 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 623 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 624 00:59:21,080 --> 00:59:24,413 va a costar esto? Dices, no, espera, pero es que también soy 625 00:59:25,020 --> 00:59:30,240 certificado en FinOps y luego, porque de manera subyacente tener una certificación de 626 00:59:30,240 --> 00:59:32,351 FinOps y yo, por ejemplo, no las tengo 627 00:59:33,560 --> 00:59:41,300 De manera subyacente eso significa que tú entiendes exactamente cómo funcionan cómo 628 00:59:41,300 --> 00:59:47,410 optimizar perfectamente el cloud lo que implica un conocimiento profundo de cuáles son 629 00:59:47,410 --> 00:59:49,521 los puntos donde más le duele al cloud 630 00:59:54,970 --> 01:00:02,030 Pero ustedes creen que sería más 631 01:00:02,030 --> 01:00:09,130 que sería lo mejor especializarse hacia prácticamente en una o ir cogiendo 632 01:00:09,130 --> 01:00:12,590 un poquito, por ejemplo sacarse todas las fundacionals 633 01:00:14,110 --> 01:00:16,030 ¿qué le tienes en ese sentido? 634 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 635 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 636 01:00:34,480 --> 01:00:39,360 Probablemente teniendo un buen perfil de especialización a un upper skilling hacia arriba 637 01:00:39,400 --> 01:00:46,720 arriba te puede proporcionar la posibilidad de que tengas proyectos más 638 01:00:46,720 --> 01:00:53,770 potentes pero Por otro lado tenerla al menos 639 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 640 01:01:01,740 --> 01:01:05,880 de ellos en pensar en esta estrategia multicloud que estábamos hablando antes y donde 641 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 642 01:01:10,460 --> 01:01:12,793 los clientes con los que estoy trabajando, 643 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 644 01:01:20,340 --> 01:01:27,610 en el cuarto. Entonces, tener la capacidad de tener un discurso multicloud, yo 645 01:01:27,680 --> 01:01:30,220 creo que aporta también valor. 646 01:01:30,220 --> 01:01:37,900 Sí, yo diría eso los foundations de todas, sí, entendiendo las 647 01:01:37,900 --> 01:01:45,320 disciplinas o la forma de cada una de ellas, e intentar asegurarlas, las associate, 648 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 649 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í 650 01:01:57,330 --> 01:01:59,719 en el enlace, y la certificación de FinOps. 651 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 652 01:02:04,860 --> 01:02:12,040 muy positivamente, se defiende mucho mejor, es decir, se defiende que es una certificación 653 01:02:12,040 --> 01:02:17,440 orientada al coste y al entender, tiene como una doble, es decir, entiendo como decía 654 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 655 01:02:24,200 --> 01:02:30,020 un profesional que va a cuidar que este proyecto no despatarre en coste. 656 01:02:30,040 --> 01:02:31,820 Por decirlo de alguna forma. 657 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 658 01:02:36,100 --> 01:02:43,340 cada uno como vaya. Si trabajas ya para un cliente, si estás empleado, quizá lo 659 01:02:43,340 --> 01:02:49,280 interesante podría ser del cliente que tienes empezar por esas. 660 01:02:49,560 --> 01:02:55,500 Si no utilizan Google, por ejemplo, pues déjate esa para después, por curiosidad. 661 01:02:55,500 --> 01:03:02,820 Bueno, puedes tener la estrategia contraria, que es, si no utilizan Google, pero se 662 01:03:02,820 --> 01:03:06,780 ha escuchado por ahí entre los pasillos y tienes 20 compañeros que están certificados 663 01:03:06,820 --> 01:03:12,040 en Azure, haz el diferente y posiciónate en el diferente. 664 01:03:13,770 --> 01:03:16,270 Es que esto es muy difícil de aconsejar, ¿eh? 665 01:03:17,680 --> 01:03:24,770 Sí, sí, completamente. Bueno, y otra sería aprovechar las olas o las oportunidades de 666 01:03:24,770 --> 01:03:26,670 certificaciones gratuitas. 667 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 668 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 669 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 670 01:03:44,850 --> 01:03:46,750 otra cosa, para el OCP o para 671 01:03:47,930 --> 01:03:55,700 cualquier otra certificación, digamos ya de de Onpreviz la de optimización 672 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 673 01:04:03,820 --> 01:04:08,160 Esas promociones adicionales durante dos meses todas las certificaciones de tal las vamos 674 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 675 01:04:15,340 --> 01:04:23,040 totalmente Tony, nos estamos yendo de tiempo un placer 676 01:04:23,040 --> 01:04:30,800 por terminar muchísimas gracias a ti Javi y a todos los oyentes por dedicar 677 01:04:30,800 --> 01:04:34,620 este tiempo a hablar de Multitodals y de 678 01:04:36,180 --> 01:04:41,940 Represcarers y nada, un fuerte saludo muchas gracias, cuento contigo para otra vale, 679 01:04:42,080 --> 01:04:45,700 cuenta con ello un abrazo muy fuerte de Toni. 680 01:04:45,840 --> 01:04:48,080 Otro, hasta ahora chao, hasta pronto.