Hola, muchas gracias a todos, quisiera ocuparos poco tiempo pero tengo una duda respecto a la implementacion del cloud computing y trasladar servidores a la nube, en concreto mi duda viene a ser lo referente a la migracion de estos entornos a las nuevas nubes de computacion, los chips de servidor en la nube, tienen una arquitectura variada, que puede ser tanto ARM como x86..., sin embargo, para cargas de trabajo dedicadas para servidor, la arquitectura ARM es una arquitectura mucho mejor que X86 en cuestion de coste por W utilizado y mas eficientes en general, siendo realmente eficientes para la tarea que desempeñan la computacion en la nube, ya que los beneficios en la nube se deben entre otras cosas, en centralizar y agrupar los costes TI y los costes de servidores de las empresas y personas,, en un servidor grupal, aprovechando los recursos computacionales cuando no son requeridos en instancias de trabajo, (por ejemplo, nuestros PC mientras dormimos es un hadware infrautilizado).
Una parte importante de la computacion empresarial y personal actual en nubes privadas estan bajo mucho sotfware de Microsotf, con SaaS Dynamics 365, Windows, Microsoft server SQL y Office 365,
Estos software fueron programados desde inicio por microsoft, bajo arquitecturas de procesador x86 , a diferencia de otros sotfware base de servidor u OS como puede ser Linux, ya que microsoft han estado trabajando desde siempre, con optimizarse a dicha arquitectura.
Mi pregunta viene a ser, ¿si la computacion en la nube adopta una arquitectura central a base de chips ARM debido a su eficiencia manifiesta y dan de lado a arquitecturas X86... significaria que el SaaS de Microsotf al mismo tiempo que sus sotfware optimizados para entornos de Windows o Windows Server, trabajarian con peor eficiencia bajo chips ARM, que otros sotfware de servidor u OS, que si esten optimizados desde inicio para arquitecturas de ARM ? es decir, por poner un ejemplo, en la computacion en la nube con ARM, ¿funcionara mejor un SaaS o PaaS optimizado para Linux u optimizados para ARM, que un SaaS o PaaS para windows, trabajando para ARM?
El Sotfware de Microsotf podria ser ineficiente o tener un coste de cambio muy grande, tanto en SaaS como en Windows o PaaS, base de datos y entornos de servidor, si con el tiempo, toda la computacion se traslada a la nube, y toda la nube es principalmente de chips basados en ARM ? . O por el contrario es facil que optimicen Windows y sus sotfware propios para chips ARM ?
Esa es mi pregunta, y muchas gracias por las respuestas.
Una parte importante de la computacion empresarial y personal actual en nubes privadas estan bajo mucho sotfware de Microsotf, con SaaS Dynamics 365, Windows, Microsoft server SQL y Office 365,
Estos software fueron programados desde inicio por microsoft, bajo arquitecturas de procesador x86 , a diferencia de otros sotfware base de servidor u OS como puede ser Linux, ya que microsoft han estado trabajando desde siempre, con optimizarse a dicha arquitectura.
Mi pregunta viene a ser, ¿si la computacion en la nube adopta una arquitectura central a base de chips ARM debido a su eficiencia manifiesta y dan de lado a arquitecturas X86... significaria que el SaaS de Microsotf al mismo tiempo que sus sotfware optimizados para entornos de Windows o Windows Server, trabajarian con peor eficiencia bajo chips ARM, que otros sotfware de servidor u OS, que si esten optimizados desde inicio para arquitecturas de ARM ? es decir, por poner un ejemplo, en la computacion en la nube con ARM, ¿funcionara mejor un SaaS o PaaS optimizado para Linux u optimizados para ARM, que un SaaS o PaaS para windows, trabajando para ARM?
El Sotfware de Microsotf podria ser ineficiente o tener un coste de cambio muy grande, tanto en SaaS como en Windows o PaaS, base de datos y entornos de servidor, si con el tiempo, toda la computacion se traslada a la nube, y toda la nube es principalmente de chips basados en ARM ? . O por el contrario es facil que optimicen Windows y sus sotfware propios para chips ARM ?
Esa es mi pregunta, y muchas gracias por las respuestas.