Muchas empresas todavía dudan de cómo plantear la migración de sus sistemas en datacenters tradicionales a infraestructuras de cloud público como AWS, Azure o Google Cloud. Aquí quiero comentar alguna de las lecciones aprendidas y de cómo ayudamos desde CloudSails a empezar esta transición.
Forma y transforma a tu equipo de administradores de sistemas
Mucha gente piensa, de forma equivocada, que mover sistemas a la nube implica eliminar a los técnicos de sistemas. Esto podría llegar a ser posible si todas nuestras aplicaciones fueran “serverless” pero la gran mayoría de la empresas continuarán con entornos “legacy” por algún tiempo y las operaciones de sistemas adaptadas a DevOps continuarán.
De lo que se trata es de transformar y hacer evolucionar al equipo de administradores de sistemas, realizando un cambio de filosofía de un mundo centrado en el hardware, la virtualización tradicional y los sistemas operativos hacia la automatización, gestionar la infraestructura como código, DevOps y lo que se conoce como Site Reliability Engineering
Si en tu equipo de IT dispones técnicos de sistemas y no tienes esta área subcontratada es importante que empiecen a practicar montando algún entorno de pruebas. Además será importante que realicen algún tipo de formación y si, es posible, que se certifiquen En nuestro caso hemos empezado con las formaciones de Cloud practitioner (online, gratuita en Amazon) y una de pago para conseguir la certificación de AWS Certified Solutions Architect – Associate. Más información en:
Es importante que tengas un equipo donde cada tipo de técnico (administrador Windows, Linux, DBA, networking, etc) entienda y adapte su forma de implantar sistemas y trabajar a la nube y también que se rompan los tradicionales silos de conocimientos para tener un equipo de administración más multidisciplinar, donde el técnico de comunicaciones puede complementar al DBA y viceversa.
Los costes de la infraestructura en la nube
Existe un temor fundamentado a que los costes en la nube de descontrolen y que superen a los costes de una infraestructura “on-premise” tradicional. Y esto puede llegar a ocurrir pero hay formas de evitarlo y explicar a tu director:
- De cara a hacer un “Business case” de on-premise versus cloud hay costes que nunca podres evaluar claramente como los beneficios que aporta el cloud público en cuanto automatización, rapidez de despliegues, etc. El poder provisionar sistemas y escalar dinámicamente en cuestión de minutos u horas para determinados modelos de negocio es impagable
- “Tagea” – identifica todos los servicios o sistemas de forma correcta y sistemática, por proyecto, servicio, etc. Es importante que todo el equipo siga una misma normativa para esto. Con los tags podrás informar del coste de cada sistema o servicio y tomar acciones al respecto.
- Si tienes periodos de no utilización de los sistemas no productivos automatiza el apagado y arranque de los recursos (por ejemplo durante la noche o los fines de semana), puedes llegar a tener ahorros importantes.
- Utiliza las herramientas de control de costes proporcionadas por el proveedor cloud o de terceros como por ejemplo Cloudyn
- Revisa el dimensionado de los recursos y redimensiona en función del consumo. El cloud se lleva mucho mejor con el escalado horizontal que con el vertical. Utilicemos los descuentos que ofrecen los proveedores al reservar recursos y realizar pagos por adelantado. Herramientas como Cloudyn nos pueden facilitar estas tareas
- Si movemos nuestros entornos legacy “on-premise” a la nube exactamente con la misma arquitectura (lo que se conoce como “lift & Shift”) es probable que tengamos costes iguales o superiores. Es por eso que es importante aprovechar el proyecto de migración para:
- Rehacer aplicaciones a serverless – A veces tenemos servidores corriendo aplicaciones que se pueden sustituir por funciones Lambda
- Hacer limpieza de datos y reducir el tamaño de bases de datos, almacenamiento etc. Utiliza los sistemas de archivado en la nube
- Por muchas estimaciones de costes que hagamos podemos desviarnos bastante y quizás sea mejor invertir más tiempo “prueba, mide/monitoriza, optimiza y vuelve a medir”.
- Informar de forma periódica a todo el equipo de IT y de negocio de los costes por servicio/sistema. Asegurarse que los equipos de desarrollo entienden que la responsabilidad de la optimización de los costes de infraestructura también son su responsabilidad y que forma parte de la transición a DevOps asumir esta responsabilidad de forma conjunta con el equipo de operaciones
Los costes de la administración en la nube
Como hemos comentado anteriormente, tengas personal propio de administradores de IT o subcontrates este servicio no de debemos olvidar el coste de la administración de sistemas en la nube. Esto no desaparece.
Si utilizas personal propio, una vez realizado el proyecto de migración podrán dedicar más tiempo a tareas de más valor para el negocio y reducir a unos cuantos clicks tareas como la provisión de servidores o la administración de las bases de datos.
En cambio, si tienes subcontratada la administración de sistemas seguramente deberás cambiar de proveedor de outsourcing para realizar la migración y posterior administración o que tu proveedor actual te demuestre su experiencia en la administración de sistemas en la nube. Posiblemente tendrás que renegociar el contrato y costes unitarios habituales en sistemas “on-premise” como administración basada en tamaño o tipología de servidores (S/M/X/XL, Sistema operativo, Servidores de base de datos, de aplicaciones, etc) ya no son válidos en un entorno cloud (imagínate que un proveedor te quisiera cobrar por número de servidores, cuando en el cloud tienes grupos de autoescalado y granjas de cientos de servidores). Cómo te presente los costes de administración el proveedor puede demostrar en parte su madurez en ofrecer estos servicios.
Por nuestra experiencia, pocos proveedores tenían un preciario de servicios maduro adaptado al cloud y presentaban ofertas al estilo tradicional basado en número de servidores, FTEs, etc. Especialmente los proveedores de datacenter y outsourcing tradicionales son los que van más retrasados estaban en hacer esta transición al mundo de cloud híbridos con sistemas on-premise y en la nube. Sin embargo en los últimos años los proveedores tradicionales se han puesto las pilas y han mejorado en cuanto su experiencia y capacidades de migración al cloud.
Consigue un buen partner para ayudarte en la transición
Tanto si tienes personal de IT propio como si utilizas la subcontratación es importante contar con la ayuda de un buen partner con experiencia en realizar este tipo de migraciones. Seguramente después de la migración además podrás contar con el partner para ayudarte también en la administración de sistemas.
Considero lo más importante que el partner te proporcione referencias reales con las que puedas contactar y conocer su experiencia con el proveedor en este tipo de proyectos.
Otra forma de evaluar al partner es confirmar las certificaciones que dispone, y qué experiencia tiene las personas que estarán involucradas en el proyecto y en el servicio. Para AWS se pueden comprobar las certificaciones en : https://aws.amazon.com/es/partners/find-a-partner/ , especialmente revisar que se dispone de las certificaciones / programas de AWS “Managed Service Provider” y “Cloud Migration Services”.
Los grandes proveedores tradicionales de datacenters on-premise y outsourcing, al menos en España, todavía van retrasados respecto a proveedores más pequeños y “de nicho” que han nacido con la revolución cloud y destacan por su agilidad y experiencia de las tecnologías Cloud. Sin embargo, de cara a la selección, no despreciemos a los grandes por la posibilidad de ofrecer administración de infraestructuras híbridas, metodologías, reducción de número de proveedores y contratos de soporte, gobernanza IT, etc.
Por supuesto también te recomiendo comparar precios. Hay diferencias importantes entre proveedores pero sobre todo valora la experiencia del proveedor para asegurar al máximo el éxito del proyecto.
Involucra e informa a tu proveedor “on-premise” en la migración
Salvo que decidas que tu proveedor actual de servicios de datacenter “on-premise” vaya a ser el mismo que realice la migración al cloud es comprensible esperar cierta o mucha resistencia de tu proveedor, ya que perderá negocio.
Una conversación honesta y sincera con tu proveedor actual es necesaria. Igualmente involucrarle durante el proyecto de migración y considerar el impacto que puede tener en recursos por su parte.
Establece un “roadmap” de migración
Muchos factores pueden condicionar la duración del plan de migración pero, como casi siempre, fijarse objetivos alcanzables ayuda a preparar un plan creíble teniendo en cuenta:
- La complejidad de los sistemas a migrar, empezando por los más sencillos y menos críticos, asegurando quick-wins a corto plazo y ganando experiencia en el Cloud
- Las ventanas de negocio para poder realizar migraciones
- El impacto en otros equipos y en otros proyectos.
Involucra a los equipos de desarrollo / funcionales
También es fundamental involucrar en el proyecto de migración a los equipos de desarrollo. Muy probablemente tengan su propia cartera de proyectos y prioridades quizás alejadas de la urgencia de la migración a la nube. Por eso es importante evaluar con ellos, aplicación por aplicación, el impacto y dedicación que tendrá en sus equipos realizar estas migraciones: Si hacemos una migración sin apenas transformación (= “lift & Shift”) el impacto en estos impactos puede ser mínimo, pero aun así es importante contar con los equipos de aplicaciones. En cambio si tenemos que adaptar aplicaciones o hacer una reingeniería, obviamente el impacto puede ser muy importante.
CloudSails 