A finales de 2022, un estudio de 451 Research reveló que, en los últimos doce meses, el 54% de las organizaciones encuestadas había trasladado cargas de trabajo o datos fuera de la nube pública, citando cuestiones como la seguridad de la información y la soberanía de los datos como principales preocupaciones. Además, un porcentaje significativo de estas organizaciones había cancelado más de la mitad de sus despliegues basados en la nube, evidenciando un movimiento significativo hacia la llamada repatriación, o cloud repatriation.
Las razones detrás de este cambio, del que se lleva hablando desde hace ya más de tres años, incluyen no solo la seguridad de la información, sino también problemas administrativos de localización de datos, costes imprevistos y dificultades en la gestión del gasto en la nube. A pesar de la promesa de escalabilidad, eficiencia y ahorro de costes que inicialmente atrajo a las empresas hacia los servicios en la nube, muchas parecen estar reconsiderando su conveniencia y, en algunos casos, volviendo a soluciones de infraestructura privada dedicada o a centros de datos propios.
Aunque el cloud computing ofrece, en principio, beneficios de muchos tipos para compañías de todos los tamaños, requiere también un importante cambio de mentalidad y una adaptación si se quiere hacer de manera razonablemente optimizada, y no son pocas las empresas que encuentran que los costes aumentan con el tiempo debido a la complejidad de las cargas de trabajo, de unas transferencias de datos cada vez más grandes, y del coste de los servicios en la nube. Además, muchas empresas a menudo se quejan de que los proveedores de cloud computing les aplican tarifas ocultas después de cambiar a la nube. Por otro lado, la creciente dependencia de las empresas en los servicios de cloud computing ha comenzado a revelar, además de esos costes crecientes, algunos problemas de seguridad y de cortes en el servicio. Empresas de todos los tamaños que habían confiado sus sistemas digitales a proveedores de cloud computing grandes afirman estar reconsiderando su estrategia debido a costes inesperados, problemas de seguridad y a la poca influencia que pueden ejercer en las decisiones sobre la tecnología utilizada.
La decisión de repatriar cargas de trabajo de la nube de nuevo a infraestructuras propias no debería ser tomada a la ligera. Las organizaciones tienen que evaluar cuidadosamente sus necesidades específicas, considerando tanto los beneficios como los desafíos de la repatriación. El control sobre los datos, la seguridad, el cumplimiento normativo y el coste son factores críticos en esta decisión: mientras algunas empresas descubren ventajas en la flexibilidad y el control que ofrece la infraestructura dedicada, otras pueden encontrar que una estrategia híbrida, combinando servicios en la nube pública con soluciones locales, se ajusta mejor a sus necesidades operativas y estratégicas.
En la práctica, tan malo pudo ser hacer una migración a la nube mal optimizada, y que por tanto, no sirvió para obtener costes significativamente más bajos – o incluso los encareció – como tratar ahora de volver atrás, después de haber relajado muchos de los factores de seguridad o, sobre todo, de problemas con el hardware, a terceras compañías. De hecho, esa razón, y no el coste, suele ser una de las razones más potentes argumentadas por los CIOs que llevaron a cabo la migración a la nube: que los problemas de hardware dejaban de ser suyos y pasaban a ser de otros, y a regirse por un acuerdo de nivel de servicio (SLA).
La repatriación de la nube refleja seguramente un cambio hacia una mayor autonomía y control por parte de las empresas sobre sus cambiantes necesidades de infraestructuras tecnológicas, algo que sin duda subraya la evolución constante de las estrategias en la era digital. Pero podría también ser una tendencia envenenada, que supone volver a una era en la que todas las responsabilidades caían en un departamento que, por simple escala, nunca va a estar tan actualizado en políticas de seguridad, de actualización o de optimización de recursos como puede estarlo un proveedor específicamente especializado en ello. Algunas tendencias, como el edge computing – tendencia a situar el procesamiento de los datos cerca de las fuentes de éstos, con el fin de mejorar la latencia – apuntan al desarrollo de infraestructuras mixtas, y de hecho, es muy posible que lo que termine ocurriendo sea precisamente eso: que la verdad esté en algún punto intermedio.
En tecnología, resulta bastante habitual encontrarnos con este tipo de movimientos pendulares, y nunca están exentos de complicaciones. Como nota mental para aquellos CIOs que estén planteándose decisiones de este calibre, sería recomendable que no interpretasen las tendencias como quien observa la moda: no siempre lo que una empresa afirma que le funciona bien sirve como guía para otras. Los argumentos que sirvieron para llevar a cabo la transición a la nube siguen ahí, y aunque muchos proveedores de cloud computing hayan aprovechado la coyuntura, que sin duda lo han hecho, para subir precios o fijar cláusulas abusivas, hablamos de un movimiento que tenía y tiene mucho sentido.
This article is also available in English on my Medium page, «How the cloud turned out to be pie in the sky for a growing number of companies«
Kubernetes y DevOps.
Una cosa es la nube pública, de proveedores IaaS, y otra diferente volver a una tecnología anterior cliente-servidor.
Gurú de tendencias y saber de algo son cosas distintas. Las tendencias salen caras si pones el dinero ahí.
–
Se sigue usando el cloud computing, no hay ningún movimiento pendular. Simplemente ha evolucionado a una tecnología más moderna. Y la tendencia es la infraestructura como código (IaC).
A nadie se le ocurre usar servidores baremetal, bueno, salvo los jubilados.
Lo que traducido, significa que en España se aumentará la brecha digital y su retraso respecto a otos países porque los salarios de ingenieros son psicológicamente inasumibles por las Pymes de este país. No son competitivas.
Y ya no vale con un FP o con un recién graduado cobrando 2000€.
–
«Taking a new step, uttering a new word, is what people fear most.»
Cuando cruzas los límites de la humanidad, para lo bueno o lo malo, asumes las consecuencias. No hay irresponsables.
Dostoyevski
Todo depende del qué y el para qué se debe utilizar un proveedor cloud y sobre todo, se debe conocer qué nivel de responsabilidad compartida queremos tener para ahorrar costes.
Es muy importante para los DevOps hacer un cálculo del volumen de responsabilidad compartida para poder estimar los costes del servicio. No es lo mismo contratar un servicio IaaS, PaaS o SaaS.
En mi caso: trabajo como DevOps para una consultora y configuro productos de museística, no es casualidad que utilicemos servidores On Premise para configurar clústers de Kubernetes en las instalaciones del cliente debido al volumen de datos que se manejan y su tamaño.
Los DevOps optaremos por tener el menor volumen de responsabilidad compartida posible por nuestra parte, pero cuando se trata de transferencia de TBs de información diaria, se debe de estimar muy bien esos costes si no queremos tener sustos en la facturación.
Ya. Por eso se contrata a otras consultoras para realizar análisis de costos, porque la transferencia de datos se reduce considerablemente y los servidores on premises son también un coste oculto en adquisición, gestión, mantenimiento, escalado y actualización, conceptos que facturan las consultoras.
Gastos importantes, que resultan triviales en un sistema gestionado en IaaS.
Financieramente es un error, porque esos servidores on premises suponen un pasivo en los libros y no desgravan ni un euro, mientras que el alquiler de infraestructura es deducible.
Por eso existen otras consultoras que recurren a CFO’s externos, para lo que ahora se llama FinOps y replatforming.
Normalmente, un análisis con Infracost, Opencost o Kubecost corta el gasto un 45% o 50% lo que permite negociar acuerdos ventajosos con los proveedores.
Luego hay servicios nativos que son más económicos que el lanzamiento de contenedores con las mismas aplicaciones; microservicios, apps serveless, azure functions, lambda, etc.
Pero claro, de eso se ocupa el management, no las consultoras que han diseñado el proyecto.
Ya estaríamos hablando de Black Ops financiero.
Lo de la responsabilidad compartida suena bien, es como la custodia y pensión de manutención en los divorcios. —
Sin entrar en mucho detalle.
–
«All, everything that I understand, I understand only because I love.»
Tolstói.
Creo que estás equivocado con tu planteamiento financiero, on premises, ya que supone un activo en los libros, y además desgravan en IS, no como gasto pero sin como inversión. Y también creo que los jubilados pueden ser una fuente de conocimiento a los que tener en cuenta, en lugar de un motivo de desprecio.
Un equipo tecnológico desactualizado siempre es un pasivo, no genera ningún beneficio por sí mismo, y conlleva un coste de renovación elevado.
Hay gente en este sector que ha decidido jubilarse a los 40 años. No es una frase.
Si tú crees que alguien que se dedica a esto puede anclar a su empresa en el pasado, porque no hay ninguna renovación de la tecnología o refresco de plantilla a causa del coste laboral que supone, pues es una forma de vida, pero nada elogiable.
Hay personas a los 35 que ya lo están planificando.
Todos conocemos a gente que ha estado vegetando en el departamento de informática durante décadas porque la dirección no sabía qué hacer con ellos.
Puedes alardear de virtudes, pero la realidad es que hay una generación de jóvenes pagando esa factura, sin empleo y sin ser valorados.
Una cosa es ser una persona mayor y con experiencia vital y otra un jubilado.
Ahora mismo los pensionistas en este país cobran más que ningún joven. Es obsceno, sencillamente.
–
Técnicamente y para despejar dudas, el deterioro del inmovilizado material dejo de ser deducible en 2015 (Art.13.2.a) Ley 27/2014) por lo que dada la cada vez más corta vida útil de los equipos y su coste financiero, experimentan una perdida de valor constante, añadida a su coste financiero, mucho antes de su amortización.
Ese mismo equipo alquilado, deja de suponer un problema.
Un bien inmovilizado sometido a un gasto de mantenimiento, administración y reemplazo, no suele considerarse un activo, en términos financieros, aunque sí figure en ese capítulo contable.
La suma es negativa.
–
Esa ley que mencionas no es aplicable a si desgrava o no. Habla del deterioro del inmovilizado material. No tiene que ver con la amortización de bienes que planteas que no es aplicable. Por lo tanto, mantengo que es un activo y se desgrava siempre al 100%. La diferencia es que como gasto lo desgravas en el año y como activo en el periodo que le corresponda según PGC.
Creo que en una empresa que fabrica lápices ,por ejemplo, el objetivo de su dpto de IT, no es disponer de la última tecnología y más puntera ni de más y mejores técnicos, sino de aprovechar al máximo la tecnología a la que se tiene acceso, para conseguir su objetivo, que será comprar fabricar y vender lo mejor posible su producto y obtener el máximo beneficio. Si ese dpto consigue gastar la mitad o cuarta parte y mantener la máxima productividad, yo creo que es muy elogiable.
Todos conocemos gente que ha dirigido los dptos de IT, siempre gastando los recursos económicos de las empresa (empresas con beneficios, lógicamente) sin obtener un resultado productivo mejor, apoyándose en estar a la última, y aprovechándose de una dirección que delega en ellos ya que no entienden de lo que se les habla.
Creo que utilizas mal la palabra jubilado. Una persona que deja de trabajar a los 40 o 35 no es un jubilado, es un tío con mucha suerte, pero no ha cotizado para ser un jubilado o pensionista…
También matizar que los pensionistas cobran más que los jóvenes, porque les corresponde según las leyes que nos rigen, ya que han cotizado por ello .
Y por otro lado, no se a que viene lo de la generación de jóvenes que no tienen empleo, en un sector que tiene una demanda desorbitada de puestos y con sueldos muy por encima de la media … ¿?
Lo obsceno no es que haya jubilados que cobren mucho.
Lo obsceno es que haya jóvenes que cobren TAN POCO.
Quizá por no haber tenido apenas nunca experiencia comercial y mucho menos empresarial (a menos que al ejercicio autónomo pueda considerársele tal) desconfío mucho de la externalización de servicios: es ponerse en manos de terceros. Si mis abuelos (ambos comerciantes) supieran con qué alegría entregan las grandes -y no tan grandes- empresas la gestión de su fondo de comercio -es decir: el trato con la clientela– a terceros que emplean para ello a empleados poco o nada cualificados en condiciones absolutamente cutres, volverían a morirse de un parraque.
Lo de la nube creo que es muy positivo para PYMEs a las cuales les es muy gravoso todo lo que supone el almacenamiento local: costes adquisición y actualización de maquinaria, de gestión y mantenimiento pero, sobre todo, de seguridad. Y más ahora, con la moda del ransomware, entre otras posibles lacras. Pero, para las empresas grandes, la nube invierte el juego de ventajas e inconvenientes, en comparación con las medianas o pequeñas.
Por tanto, creo que es un problema de aquilatamiento, no veo que para este tema haya una solución universal.
La moda del Cloud Computing está pasando, los precios de almacenamiento y procesamiento en AWS son delirantes y otros proveedores son parecidos. Si te paras a hacer números por el precio que te cuesta una simple máquina virtual en AWS, te montas un servidor físico propio en un Centro de Datos con diez veces más capacidad de cómputo de RAM y cientos de veces más de almacenamiento.
Pero por otro lado te tienes que encargar tú del resto y eso también cuesta, pero por lo general es más barato.
No es tan sencillo, al frente de ese «servidor físico propio en un Centro de Datos con diez veces más capacidad de cómputo de RAM y cientos de veces más de almacenamiento», tienes que poner unos técnicos y unos equipos auxiliares como un SAI, no precisamente baratos que te aseguren un funcionamiento 24/7/365, como la que te da AWS.
Claro que sí… te ahorras costes por un lado y tienes otros por otro, pero para ciertos proyectos sale positivo.
Claro si tienes un IASS no necesitas técnicos que lo administren, bastionen u protejan.
La Cloud para ciertas cosas si, pero como otras tendencias tiene una gran carga de bluf y de burbuja.
Donde esté tu sistema a la vista viendo lo que has pagado y pudiendo alargar su vida útil.
Opino como JAVIER CUCHÍ, si tu externalizas procesos de tu empresa, puedes tener teóricos ahorros, puesto que los hace alguien que mueve un mayor volumen de operaciones al sumar las tuyas a las similares de otros clientes que tenga.
Pero para empresas grandes, que generan ellas solas una cantidad de movimientos masivo, es difícil reducir aun mas los gastos de gestión de los mismos, porque ya lo han hecho ellos. Por tanto, los proveedores de servicio tampoco podrán cobrarte por su trabajo, muy por debajo de tus costes y con mucha frecuencia, este teórico ahorro no compensa las dificultades inevitables que genera la externalización.
Y como CUCHÍ, opino que lo difícil, es valorar el punto de equilibrio entre hacer uno mismo una gestión o externalizarla.
Las ventajas de la nube ahí están y ahí seguirán. Pero no todo son ventajas, para una empresa que tiene una carga de trabajo estable y que gestiona el sistema productivo desde sus propias oficinas no se porque tiene que alojar sus datos a cientos o miles de kilómetros para perder velocidad de acceso, procesamiento y encima pagar por este movimiento de datos más aún si puedes implementar en tu centro de trabajo las ventajas de la virtualización. Sobre todo si eres una hormiga que compites con los grandes del Ibex, como clientes para que no abusen de ti las grandes multinacionales de la tecnología.
No conozco otra forma de gastar tanto haciendo un clik en una www
Migrar a la.nube con sistemas obsoletos tiene como consecuencia altos costes, es vital para las empresas que quieran extender sus cargas a la nube, cambiar antes la arquitectura de sus sistemas a cloud native, es la única forma que pueda obtener los beneficios de la computación distribuida, y poder implementar el multicloud.
Cada vez más de mis clientes me preguntan por la licencis OnPrem.
Curiosamente no es para tener metal en la oficina, sino para migrar a la infraestructura a una propia más barata, normalmente en Azure.
Y lo entiendo, muchos de los proveedores también usan Azure (con lo cual deben agregar su plus de gestion tambien) o a otro proveedor que no puede competir.
El otro motivo son las integraciones: Si tienes todas tus plataformas unidas hablamos de velocidades extremadamente altas.
Aun así, ya alguno se ha llevado el susto de tener todos los huevos en la misma cesta y perder todos los servicios juntos (ADFS, Emails, Apps, Teams…)
A mi, lo que más me gusta de Azure y Microsoft Drive es el control de versiones.
Apple, con iCloud, está a años luz del trabajo colaborativo en nube.
La nube no es más que el “ordenador” de otro. Asumiendo todas las ventajas… yo no metería un pie a menos que:
• no esté absolutamente claro lo que vas terminar pagando -por no decir cómo eventualmente cambiarias de proveedor o como saldrías de la nube-
• los HSMs seas tú el que los sigas gestionando on prem
• sepas (o puedas) refactorizar las aplicaciones y/o servicios que necesites correr en el cloud para que no te sangren