INTRODUCCIÓN
En la entrada de hoy queremos contaros cómo hemos migrado a la nube sin casi darnos cuenta.
No va a ser una entrada donde os expliquemos cómo hemos migrado a la nube desde un punto de vista técnico sino más bien un relato de cómo, a veces, las cosas van sucediendo por sí solas.
No os vamos a mentir explicándoos que fuimos pioneros. Lo cierto es que, quien esto escribe, era al principio bastante receloso. Básicamente receloso respecto a los cortes de comunicación y a la facilidad de acceso a los ficheros.
Sin embargo el tiempo ha ido acabando poco a poco con esos recelos.
NUESTRA INFRAESTRUCTURA
Nuestra infraestructura estaba formada por cuatro servidores físicos que albergaban varias máquinas virtuales con los diferentes servicios que usábamos además de servidores que sólo empleábamos para cursos e investigación.
Esos servicios eran el correo (Exchange), ficheros (Sharepoint), bases de datos (SQL Server), gestión de proyectos y código (TFS, DevOps), ERP, relaciones con los clientes (CRM), copias de seguridad (DPM), VPN (RRAS), red (Active Directory, DNS, DHCP). Poco a poco fueron siendo sustituidos por sus equivalentes en la nube; en nuestro caso en Azure / Microsoft 365.
EL CORREO FUE EL PRIMERO
Como en casi todos los casos, en el nuestro, lo primero que se fue de nuestras instalaciones fue el correo. Hace tiempo que prescindimos de Exchange por un proveedor ISP ya que aunque Exchange proporcionaba más prestaciones que muchos servidores de correo, debido a su complejidad de administración y requisitos de hardware nos venía grande.
El proceso fue el habitual: guardamos el correo antiguo de Exchange en un fichero PST de Outlook y configuramos este para que comenzase a usar la nueva cuenta POP3 de nuestro ISP.
Cuando comenzamos a trabajar con Microsoft 365 la cosa no fue tan directa pero para nada fue compleja. Microsoft tiene prevista la convivencia con su servicio Exchange Online de otras cuentas de correo y proporciona herramientas para configurar esa convivencia. En esencia, si nuestro dominio es gestionado por terceros, nos da una serie de registros DNS que ese tercero deberá incluir en sus servidores.
Nosotros, en un primer momento, no prescindimos de los buzones en nuestra cuenta ISP y configuramos un reenvío de correo desde esta a nuestra cuenta Microsoft 365. Más tarde ya sí, matamos los buzones de la cuenta ISP y cambiamos los registros DNS para que nuestro correo se entregase directamente a la cuenta Microsoft 365.
MICROSOFT 365 Y ACTIVE DIRECTORY
Este fue sin duda el paso clave y el que ya nos mantuvo en la idea de seguir migrando a la nube. En principio sólo buscábamos tener nuestro Office disponible y actualizado además de nuestros ficheros personales disponibles tanto en la oficina como en casa. Sin embargo Microsoft 365 ofrecía otras características de las cuales no queríamos prescindir; Exchange (del que ya he hablado) y Sharepoint eran las principales. Otras, no menos interesantes, no formaban parte de Microsoft 365 pero se hallaban “al lado” en la plataforma Azure.
Antes de que cada uno descargase su Office y se lo instalase, eran necesarios dos pasos previos; asociar nuestro dominio DNS con nuestra cuenta Microsoft 365 y dar de alta a nuestros usuarios. Lo primero lo hicimos usando el asistente de nuestro portal Microsoft 365 añadiendo a los servidores DNS los registros que se nos indicaron, tal y como ya he dicho.
Para lo segundo usamos la herramienta Azure AD Connect; un conector, ligero, gratuito y fácil de instalar y configurar que “copió” nuestro Active Directory local a nuestro Azure Active Directory y lo mantiene sincronizado. De esta manera, además, nuestras credenciales son las mismas localmente y en Azure/Microsoft 365.
SHAREPOINT Y LOS FICHEROS CORPORATIVOS
Aunque Sharepoint es la parte más delicada, Microsoft proporciona también la herramienta Sharepoint Migration Tool que, si no hemos personalizado en exceso nuestro Sharepoint local, nos permitirá subir directamente a Sharepoint 365 los sitios, bibliotecas, listas ficheros y páginas que deseemos.
Igualmente, si tenemos una masa de ficheros corporativos guardados directamente en Windows, disponemos de otra herramienta para subirlos; el Migration Manager Agent. Esta aplicación, también sencilla de instalar y configurar, se instala localmente allí donde pueda acceder al recurso compartido donde se hallen nuestros ficheros. Luego, desde el propio portal de administración de Sharepoint 365, crearemos un trabajo para subir nuestros ficheros usando el agente. Así lo hicimos y así lo explicamos en otra entrada de este blog.
MÁQUINAS VIRTUALES
A pesar de que lo ideal sería olvidarnos de las máquinas virtuales, a veces no queda más remedio que conservar alguna. En nuestro caso conservamos dos.
La primera la creamos en Azure y en ella instalamos un servidor DevOps para mantener nuestros proyectos y su código. Podríamos haber llevado los proyectos a Azure DevOps Services; la versión Software as a Service de DevOps pero como lo empleamos aún para mostrar ejemplos reales en nuestros cursos y hay algunas diferencias de funcionamiento, decidimos mantener el nuestro.
La otra máquina es la de nuestro ERP. La organización de la BD que emplea es los bastante diferente de la de Dynamics 365 como para que no nos valiese la pena el esfuerzo de realizar la migración sin ningún tipo de ayuda. Adoptamos el mismo enfoque; un día creamos una máquina virtual en Azure, instalamos el ERP y traspasamos los datos. En una mañana estaba todo listo.
LA INFRAESTRUCTURA
A medida que las cosas iban subiendo a la nube y desaparecían de nuestras instalaciones, se iban haciendo más patentes las ventajas. Las copias de seguridad eran más rápidas y ocupaban menos espacio. Además su complejidad se vio bastante reducida al no ser necesarios agentes para BBDD, Hyper-V, Sharepoint, etc.
Por supuesto, para la información ya subida a la nube, empleábamos Azure Backup pero tan sólo había que configurarlo.
Las BBDD necesarias para muchos servicios, habían “desaparecido” y las BBDD de aplicaciones pudieron crearse fácilmente usando Azure SQL Database. Al final, nuestro servidor SQL Server quedó vacío de contenido y su máquina virtual se eliminó.
Los servicios de red como DNS y DHCP fueron configurados a un router SOHO más por comodidad que por necesidad ya que tan sólo quedaban algunas estaciones de trabajo y una máquina física para pruebas ocasionales.
A esa máquina física, se le instaló un servidor SSH que se publicó al exterior y así se pudo prescindir de RRAS.
Y ENTONCES LLEGÓ LA PANDEMIA…
… y con ella adoptamos a Teams.
El día que nos confinamos, hace ya un año, no imaginábamos lo sencillo que sería seguir con nuestro trabajo. Aunque Teams no es el programa más intuitivo, funciona bien y nos permitió mantener el contacto no sólo laboral sino también lúdico.
Hoy puedo decir que si alguien aún tiene algún recelo a pasarse a la nube con armas y bagajes puede abandonarlo tranquilamente. Las grandes empresas seguro que tienen personal que sabrá planificarlo y llevarlo a cabo con eficiencia. Las empresas más pequeñas pueden adoptar nuestro enfoque digamos de proverbio chino: un viaje de mil leguas empeiza con un pequeño paso.
¡Hasta la próxima!