Si bien la nube está comenzando a dominar el gasto en tecnología de la información, la mayoría de los directores de tecnología aún supervisan un stack de tecnología que comenzó con una arquitectura tradicional: bastidores de servidores, almacenamiento y equipo de red alojados en un centro de datos -su propia instalación autogestionada y especialmente diseñada-; o una parte de un sitio de ubicación conjunta con diversos grados de autogestión y soporte subcontratado.
Tal vez incluso diseñó cuidadosamente su entorno heredado y supervisó estrictamente la evolución de sus componentes. Lo más probable es que apareciste en tu primer día en el nuevo concierto y heredaste un desayuno de perros de elementos que funcionaron más o menos en concierto para hacer el trabajo de la organización (pregúntame cómo lo sé).
Depende de usted, como CTO, respaldar los requisitos comerciales en constante crecimiento con una arquitectura y un plan de tecnología de la información (TI) enfocados en el futuro. Y eso casi siempre significa pensar mucho sobre el movimiento a la nube: no “si”, sino “cuándo” y “cómo”.
Sin embargo, incluso cuando un CTO tiene una visión coherente del futuro y está totalmente comprometido con una migración a la nube, la realidad se entromete: los proveedores de tecnología aumentan y disminuyen, las mejoras prometidas no funcionan o una serie de adquisiciones deben integrarse rápidamente. y lo más económico posible. En palabras del gran pensador de la gestión, Mike Tyson, “Todos tienen un plan hasta que les dan un puñetazo en la boca”. Independientemente de los giros y vueltas que enfrente, es imperativo que continúe con su migración planificada para que su organización no se quede atrás.
Para mantenerse motivados y garantizar que la migración a la nube sea una prioridad de la empresa, los CTO deben comprender sus beneficios críticos:
Aproveche la inversión en seguridad de los hiperescaladores
Los proveedores de nube de hiperescala (hiperescaladores) han realizado inversiones considerables en su seguridad física, por tanto, los activos trasladados allí deberían estar más seguros que en su centro de datos actual.
Los hiperescaladores también han realizado grandes inversiones en herramientas de ciberseguridad para detección, prevención, aislamiento, reparación y recuperación. Tomará algo de trabajo integrar herramientas y procesos de hiperescala. También puede requerir una inversión en productos y servicios opcionales (es decir, plataforma como servicio o PaaS), pero pasar a niveles más altos de seguridad, que en la nube es relativamente fácil.
La conmutación por error multisitio mejora la disponibilidad
Suponga que ejecuta su propia infraestructura con tecnología heredada. En ese caso, está acostumbrado a pensar en sitios de recuperación (fríos, tibios o calientes) y el baile complejo requerido para “declarar un desastre” y luego invocar su “libro de recetas de recuperación de desastres” para cambiar las operaciones a un sitio alternativo.
La arquitectura de hiperescala difiere fundamentalmente de la arquitectura heredada en que admite el movimiento de la carga de trabajo, sobre la marcha y con una interrupción mínima, desde los sitios principales a los sitios alternativos. Este movimiento puede ser casi invisible y automático si está ejecutando aplicaciones de software como servicio (SaaS) o componentes “sin servidor” de PaaS. Estará mucho más involucrado si está ejecutando sus propios componentes en infraestructura como servicio (IaaS).
La conmutación por error multisitio no es gratuita: pagará por la conmutación por error local, regional o global. Y tendrá que rediseñar algunas o todas sus aplicaciones hasta cierto punto para aprovechar al máximo la conmutación por error de la carga de trabajo. Pero sus usuarios deberían ver menos interrupciones, y su equipo de TI ahorrará mucho tiempo manteniendo y probando sus “libros de recetas de recuperación ante desastres (DR)”.
Las arquitecturas de nube de hiperescala permiten al CTO diseñar lo que yo llamo DAC (capacidad activa distribuida) en cargas de trabajo. Con DAC, la carga de trabajo de producción se aloja en varias ubicaciones, por lo que una falla en cualquier sitio no cierra la carga de trabajo. En el peor de los casos, una fracción de los componentes deja de funcionar, por lo que las cosas se ralentizan hasta que se realizan las reparaciones. Con la escalabilidad inherente de la hiperescala, puede contratar una capacidad de “ráfaga” temporal que se activa casi instantáneamente según sea necesario, para que los usuarios vean poca o ninguna interrupción.
Nota Bene: independientemente de las estadísticas de tiempo de actividad del hiperescalador súper altas (99,999%), cuando un hiperescalador falla, generalmente falla espectacularmente (millones de usuarios afectados en una amplia área geográfica). Un CTO inteligente siempre se prepara para el peor de los casos, incluso cuando la nube está involucrada.
Maneje picos de carga con mayor escalabilidad
La promesa original de la nube hiperescala era: “Puedes comprar todo por bebida”. Si necesita una base de 10 servidores todos menos un día al mes, o necesita 20, no hay problema. O si tiene picos y valles estacionales, está cubierto. Incluso las cargas máximas intradiarias o intrahorarias pueden ser manejadas por la nube (y si está ejecutando SaaS o sin servidor, piensa en las transacciones o los usuarios y se olvida de la escalabilidad).
Lo que muchos clientes de hiperescala aprendieron a través de amargas experiencias fue que la escalabilidad es una espada de dos filos. Como la mayoría de los otros recursos que alguien compra y mantiene para vender, cuanto más predecible sea su uso, mejor precio obtendrá. Por lo tanto, la mejor práctica es contratar su línea de base (o algún porcentaje, como el 80%) como una cantidad mínima a un costo fijo. Luego, contrate por tramos variables (o “ráfaga”) por separado (el primer 20% por encima del valor de referencia se necesitará el 50% de las veces; el siguiente 20% se requerirá el 5% de las veces; todo lo que supere el 40% será necesario).
Otra desventaja de la fácil escalabilidad es la “expansión de la nube”: dado que los usuarios pueden activar una instancia de la nube en segundos durante unos minutos u horas según sea necesario (por ejemplo, para un entorno de prueba unitaria) en lugar de mantener muchos entornos locales adicionales, lo que parecía ahorrativo. Pero los clientes descubrieron que muchos recursos de la nube (de costo variable) se dejaban en funcionamiento, con cargos acumulados por actividad, lo que generaba sobrecostos financieros por el uso de aplicaciones en la nube.
Soporte de crecimiento y cargas de trabajo en ráfagas
Si es un CTO, el término “margen” es un lenguaje común. Son los recursos informáticos que se reservan para adaptarse al crecimiento del negocio, necesidades de pruebas variables, capacidad adicional, cargas de trabajo “rápidas” e incluso necesidades de fusiones y adquisiciones. Mi regla general ha sido permitir un 40% de espacio libre en todo el entorno.
Eso significa que usted adquiere, instala, enciende, enfría y mantiene el 40% del hardware de repuesto y la capacidad de la red para minimizar las ralentizaciones y las interrupciones. Los entornos de nube IaaS y PaaS no necesitan ninguna capacidad adicional no utilizada porque agregarán recursos según sea necesario en segundos o minutos. Si el CTO paga solo por la capacidad utilizada y “explota” según sea necesario, el costo de referencia puede ser mucho más bajo de lo que podría suponer simplemente “elevar y cambiar”.
Existe el mito de que la “nube convierte los costos fijos en costos variables”. No exactamente. A medida que la computación en la nube se generalizó y consumió una mayor parte del presupuesto de TI, renunciar a la adquisición de activos (CapEx) en favor de la concesión de licencias (OpEx) estaba distorsionando los estados financieros. Entonces, el FASB (Junta de Normas de Contabilidad Financiera) niveló el campo de juego con una serie de ASU (Actualizaciones de Normas de Contabilidad) comenzando con ASU 2018-15 y agregando más aclaraciones . ( No soy un CPA, y esto no es un consejo financiero; hable con sus auditores).
Reduzca la deuda técnica, confíe en otros para mantenerse actualizado
Como los lectores sabrán, este es mi tema favorito: la deuda técnica (esto es lo que dije al respecto en el Wall Street Journal), específicamente la mitigación de la deuda técnica a través de la migración a la nube a hiperescala. Versión corta: transferir la responsabilidad del hardware, las redes y el software de bajo nivel a un proveedor de la nube (IaaS), herramientas IaaS más (PaaS) o aplicaciones completas (SaaS) significa que otra persona mantiene su tecnología actualizada, alguien que lo hace regularmente y para millones de usuarios.
Una vez más, el CTO no puede lavarse las manos de la responsabilidad por la deuda técnica, pero el trabajo pesado puede subcontratarse a expertos en hiperescala.
Pensamientos finales
Para la mayoría de las organizaciones, la nube brinda beneficios tan significativos (escalabilidad, disponibilidad, integración, acceso a herramientas, mitigación de la deuda técnica, por nombrar algunos) que es hora de pasar de las plataformas heredadas a la nube. Eso no quiere decir que el viaje será rápido, barato o fácil para los CTO cargados con stacks de TI complejas y poco documentadas. Pero cuanto más espere, más deuda técnica se acumula y más complejo se volverá su entorno.
Así que ahora es el momento de construir un plan reflexivo y debidamente financiado; obtenga la aceptación de su C-suite (y quizás de la junta directiva); y trate esta migración como un importante programa de gestión de cambios empresariales con informes y controles acordes. Lo mejor de las migraciones a la nube es que las licencias son increíblemente granulares: puede comenzar con una inversión incremental muy pequeña y sin compromisos a largo plazo.
Si aún tiene dudas, recuerde los útiles consejos disponibles en línea. Aquí en Acceleration Economy, hemos publicado cientos de artículos, la mayoría de los cuales fueron escritos por personas como usted, que “han estado allí y han hecho eso”.
¡Comience con la nube para comenzar a generar valor para sus equipos y sus clientes!
Autor: Wayne Sadin
Artículo original aquí
