¿Lo local tiene futuro?

¿Se acabaron los días de alquilar una habitación en un centro de datos, comprar servidores y tener ingenieros cerca para resolver posibles problemas? Mientras que la construcción de una infraestructura local solía llevar semanas (o meses), ahora lleva horas. Con precios cada vez más bajos, la pregunta es simple: ¿tiene futuro la infraestructura local?

Un problema de gestión de habilidades.

La computación en la nube ha establecido estándares para implementar software, comenzando con EC2, S3 o Kubernetes. Los ingenieros no solo entienden y dominan muy bien estas tecnologías (después de todo, han aprendido estas tecnologías durante su experiencia profesional o durante proyectos personales), sino que su uso en plataformas de computación en la nube se facilita con herramientas maduras y bien respaldadas.

Por el contrario, cuando implementa su propia infraestructura, se vuelve necesario desarrollar herramientas específicas para administrar sus servidores y la implementación del software. Entonces se convierte en un trabajo de tiempo completo que requiere la contratación de ingenieros. Además, esta herramienta específica estará menos madura que su equivalente disponible para la nube y, por lo tanto, ralentiza a la empresa en el desarrollo de su infraestructura y sus aplicaciones.

Por lo tanto, la elección es simple: al usar la nube para construir su infraestructura, puede tener acceso a una plataforma madura y candidatos en funcionamiento desde el primer día. Elegir on-premise significa un largo período de instalación del hardware, pero también la contratación de ingenieros que definirán los métodos de implementación del software y la implementación de las herramientas.

Rendimiento cada vez mayor, costos cada vez más bajos

Con un crecimiento de la adopción del 30 % trimestre tras trimestre, los jugadores de computación en la nube ahora tienen una base de usuarios tan grande que pueden optimizar su infraestructura ellos mismos y brindar a sus clientes servicios cada vez más eficientes a costos cada vez más bajos.

El ejemplo perfecto es el desarrollo de Graviton por parte de Amazon Web Services, un procesador que ofrece un rendimiento superior al de los procesadores Intel a un costo menor. Por supuesto, esta tecnología está limitada a los clientes de Amazon Web Services. Al desarrollar su propio hardware, AWS puede eliminar todos los costos que no agregan valor y enfocarse en desarrollar un producto exitoso para sus clientes. Estas optimizaciones se aplican a toda la infraestructura implementada en la nube. Este procesador no solo se utiliza para implementar instancias de su software, sino también para alojar su base de datos u orquestar su infraestructura. Estas optimizaciones están lejos de ser insignificantes con un rendimiento superior del 25 % al 40 % y una reducción de costos del 5 % al 10 %. Elegir permanecer en las instalaciones también significa rechazar estas posibles optimizaciones.

Seguridad: un argumento de espantapájaros

Un argumento que a menudo se plantea contra la computación en la nube es la seguridad potencial de los datos. Los proveedores de computación en la nube se consideran infraestructuras inseguras y el uso de una infraestructura local garantizaría la seguridad de los datos. Una simple consulta en Google muestra que la seguridad es lo más importante cuando se trata de computación en la nube.

Sin embargo, pensar que lo local es más seguro que la nube es como pensar que conducir un automóvil es más seguro que viajar en avión porque tenemos el control. Sin embargo, la gran mayoría de los problemas de seguridad en la nube provienen del uso. Los problemas de configuración son innumerables (por ejemplo, depósitos S3 configurados incorrectamente como públicos o configuraciones incorrectas de enrutadores y balanceadores de carga). Pero estos son problemas fáciles de solucionar. Muchos servicios están disponibles para escanear una infraestructura implementada en la nube y encontrar posibles problemas de seguridad (lo cual es mucho más complicado de hacer para una infraestructura local).

Muchas empresas con limitaciones de seguridad utilizan la nube en la actualidad. Capital One (banco establecido en Estados Unidos) ha migrado su infraestructura a la nube. Incluso el gobierno de los EE. UU. utiliza hoy en día la computación en la nube con servicios dedicados a ellos (y esta tendencia no va a detenerse desde que el Pentágono anunció hace unos meses un nuevo contrato para desarrollar su infraestructura en la nube).

El argumento de la seguridad es solo un pretexto, una barrera psicológica que algunos tomadores de decisiones utilizan para no cambiar el statu quo pero que expone a su empresa a ser menos innovadora en los próximos años.

¿Qué futuro para las instalaciones?

No hay duda: las instalaciones locales se convertirán en un nicho de mercado en los próximos diez años y surgirán nuevos proveedores de computación en la nube. Sin embargo, todavía existen algunas barreras menores que pueden obligar a las empresas a permanecer en las instalaciones.

Primero, la inercia de las empresas antiguas que tienen una infraestructura local bien establecida. Estas empresas ya cuentan con locales (y contratos de alquiler en centro de datos) y servidores y no están dispuestos a cambiar la forma en que administran su infraestructura, citando que su infraestructura actual está tan bien perfeccionada que cambiar a la nube les costará demasiado. Sin embargo, al mantener este antiguo enfoque, terminarán pagando mucho más por el costo de desarrollar y mantener su infraestructura (ingenieros dedicados a administrar la infraestructura y sus herramientas) y la brecha de costo y rendimiento entre la nube y las instalaciones seguirá aumentando. crecer.

En segundo lugar, una garantía de poder cambiar de proveedor de servicios. Muchas soluciones en la nube son específicas del proveedor (por ejemplo, el uso de una base de datos de Amazon Aurora en AWS no garantiza la conmutación por error a Google Cloud Services o Azure). Este es un problema real que se puede evitar fácilmente: al usar soluciones genéricas e interoperables, es fácil poder cambiar de proveedor de servicios. En lugar de usar ECS para implementar contenedores Docker, tiene más sentido usar Kubernetes; en lugar de usar Amazon Aurora para su base de datos, tiene más sentido usar MySQL o PostgreSQL. Para evitar este problema, muchas empresas ahora facilitan la implementación y la migración entre proveedores de servicios.

Finalmente, un problema de soberanía. En otras palabras, dónde se encuentran físicamente sus datos. Este es un punto crítico para Europa, donde ningún proveedor de computación en la nube puede reclamar una calidad de servicio igual a Amazon Web Services o Azure. Si bien esto no afecta a las pequeñas y medianas empresas, sin embargo, es un punto crítico para las grandes empresas o instituciones públicas. Desafortunadamente, las iniciativas europeas que intentaron copiar a su contraparte estadounidense terminaron en fracaso. (¿quién se acuerda de Quaero?). Sin embargo, las habilidades técnicas están ahí, desarrollar una nube europea digna de ese nombre es solo una cuestión de voluntad política y financiera.