Cómo pasar de una arquitectura local a una arquitectura SAAS
00¿Sabe Cómo pasar de una arquitectura local a una arquitectura SAAS? Las empresas grandes y pequeñas se están moviendo a un modelo de negocio y entrega de software como servicio (SaaS). Los beneficios de SaaS son claros tanto para las compañías que compran software como para las compañías que fabrican software. Gran parte del software empresarial creado en las últimas tres décadas utiliza una arquitectura local, pero compañías como Salesforce, Microsoft y Adobe han demostrado que es rentable pasar a un modelo de negocio SaaS.
La otra ventaja clave de los productos SaaS es que su arquitectura permite que los productos se repitan más rápido.
A medida que ha crecido su negocio a nivel mundial, las soluciones de software implementadas en cada región se han fragmentado cada vez más. Cada división regional ha realizado personalizaciones para cumplir con los requisitos del cliente, lo que ha disminuido su tasa de innovación y capacidad para implementar nuevas funciones a nivel mundial. Para resolver problemas centrales como el funcionamiento sin una infraestructura común, tener que reescribir el código e implementar características personalizadas para cada región, y la implementación lleva mucho tiempo con el sistema actual, recomendamos mover todas las divisiones a una arquitectura común que se implemente en una infraestructura común.
¿Cuáles son los desafíos involucrados en la consolidación de múltiples versiones de plataformas de diferentes países?
Existe la transferencia de conocimiento que tomará unas buenas 2-6 semanas y se recomienda una sesión de descubrimiento en persona de 1-2 semanas para transferir la mayor cantidad de conocimiento posible al equipo técnico y de UI / UX.
Si parte de su documentación técnica está escrita en un idioma diferente al inglés, es posible que deba traducir la documentación.
Hemos trabajado con clientes que han perdido documentación o conocimiento de dominio sobre cómo funciona su software existente, por lo que existe el riesgo de que algunas características no se desarrollen simplemente porque no están documentadas adecuadamente, pero se encontrará con este mismo problema si decide construir la nueva plataforma internamente. Para reducir este riesgo, le recomendamos que realice el proceso de documentar todas las funciones de cada versión de su plataforma existente en inglés para que el equipo de a bordo pueda comenzar a ejecutar.
Casi una década de ayudar a las empresas de software locales y con licencia a través de la transición a «Algo como un servicio», ya sea Software (SaaS), Infraestructura (IaaS), Plataforma (PaaS) o Analytics (AaaS) nos ha dado bastante perspectiva única sobre las diferentes fases a través de las cuales estas empresas hacen la transición. Desde nuestra experiencia en la primera línea de muchas transiciones, hemos reducido el proceso de migración a 9 pasos generales.
1. Comience evaluando su entorno
Haga una lista completa de sus aplicaciones e infraestructura locales. Cualquier empresa a punto de lanzarse a una migración de SaaS primero debe analizar detenidamente su producto actual y determinar qué no vale la pena llevar a cabo con el producto heredado. ¿Cada parte de la funcionalidad actual sigue siendo relevante y realmente se está utilizando? Audite su infraestructura existente y haga un balance de los niveles actuales de costos y recursos. Evaluar el estado de cada aplicación. ¿Será necesario refactorizar para un entorno de nube o es amigable con la nube? En ocasiones, el esfuerzo necesario para migrar es mayor que el valor de salida. No vale la pena actualizar todos los sistemas.
Mapear las relaciones entre aplicaciones. Este mapeo de análisis le permite identificar sistemas que no deberían moverse sin otro y aquellos que pueden combinarse. Actuar de acuerdo después de identificar dependencias significa una interrupción mínima de los procesos. El siguiente paso es analizar la infraestructura utilizada por estas aplicaciones una vez que haya identificado las aplicaciones para mover. Esto incluye la cantidad de almacenamiento necesario, análisis, datos generados, redes y SLA esperado (acuerdo de nivel de servicio). Considere el dinero gastado en la administración del servidor, los costos ocultos involucrados y los servidores físicos. Un análisis en profundidad de los costos y la infraestructura puede ayudarlo a identificar cómo optimizar las aplicaciones para una mejor eficiencia después de migrar las aplicaciones.
2. Seleccione el entorno de la nube
La primera decisión que debe tomar es qué tipo de nube es adecuada para sus aplicaciones. La nube pública es casi igual a un servidor externo común. Es conveniente de usar, rentable ya que es un modelo de pago por uso, administrado por un tercero en una ubicación remota, flexible y altamente escalable y también existe la redundancia geográfica. La nube privada ofrece una solución de un solo ocupante para una empresa. Es específico de la compañía, viene con un mejor control y confiabilidad y se puede personalizar. Sin embargo, la empresa incurre en costos de mantenimiento y necesita competencia interna de TI. La nube híbrida es una mezcla de los dos. Necesita hipervisor y capas de software en la nube. Es ideal para cargas de trabajo dinámicas, y es posible la explosión de la nube.
3. Elija el proveedor de nube correcto
El siguiente paso es definir la arquitectura requerida para la migración después de seleccionar el tipo de nube. Defina los componentes que necesitará y haga una lista de las aplicaciones que migrará. Considere el poder de cómputo, los requisitos de almacenamiento, etc. Dado que la nube y las aplicaciones tradicionales no se portan bien entre sí todo el tiempo, hay posibilidades de que, incluso si se portan, no obtengan lo mejor de ellas. Debe verificar si su alojamiento requiere equilibradores de carga, equivalentes de clúster subcontratados o replicación de la base de datos para evitar dificultades en el futuro. Luego seleccione el proveedor de la nube que cumpla con todos sus requisitos. Considere todos los factores al elegir el proveedor. No olvide considerar un servicio al cliente rápido, el SLA asegurado, mejores comentarios, etc.
4. Prepare sus aplicaciones en la nube
Es necesario modular la arquitectura de la aplicación monolítica para que sea más fácil de usar con servicios nativos en la nube para migraciones heredadas exitosas. Cuando mueve una aplicación a la nube desde un centro de datos local, hay dos formas de migrar su aplicación: una integración en la nube profunda o una integración en la nube superficial.
Durante el proceso de migración, modifica su aplicación para aprovechar las capacidades cruciales de la nube para una integración profunda en la nube. Esto podría no ser nada más avanzado que el equilibrio dinámico de carga y el uso del escalado automático, o podría ser tan sofisticado como el uso de capacidades informáticas sin servidor para partes de la aplicación como AWS Lambda. También podría ser necesario utilizar un almacén de datos específico de la nube, como DynamoDB o Amazon S3.
Para una integración de “elevac
ión y cambio” o una nube superficial, mueve la aplicación local a la nube y realiza cambios limitados, o ningún cambio, en los servidores que instancia en la nube para ejecutar la aplicación. No utiliza servicios únicos en la nube. Para que se ejecute en el nuevo entorno, cualquier cambio en la aplicación es suficiente. También pasa por levantar y cambiar a medida que la aplicación se levanta «intacta» y se desplaza, o se mueve a la nube.
5. Despliegue
Ya ha preparado casi todo cuando llega a este paso y está listo para el proceso de migración. Cuando se trata de la migración a la nube, un error común es que es un viaje de una sola vez. Sin embargo, la realidad es que el proceso de migración de la infraestructura de datos a la nube debe ocurrir gradualmente. Para que el trabajo no se vea interrumpido, una migración exitosa debería sentirse lo más fluida posible para la organización. El objetivo aquí es asegurarse de que todo se haga paso a paso cuando se planifica una importante migración de datos, mientras se minimiza el tiempo de inactividad y las interrupciones para los usuarios. Así que prepárese para un proceso de migración que puede llevar desde varios meses hasta un año.
Debe realizar una copia de seguridad de los servidores y datos existentes antes de la migración. Almacene sus datos de forma segura y asegúrese de que puedan recuperarse fácilmente. Luego configure el entorno de la nube. Realice el aprovisionamiento, las conexiones y las pruebas de todos los componentes individuales por separado.
6. Realice la refactorización necesaria
Antes de migrarlos, es posible que desee realizar otro trabajo en sus aplicaciones y servicios para que funcionen de la manera más eficiente y efectiva posible en la nube. Por ejemplo, es posible que desee refactorizar su aplicación para que funcione bien con una variable no. de instancias en ejecución para permitir el escalado dinámico. Potencialmente, esto puede ahorrarle dinero en costos de servicio en la nube. Además, es posible que desee refactorizar su aplicación para que la utilización de sus recursos haga un mejor uso de las capacidades de la nube dinámica, en lugar de asignar recursos estáticamente con anticipación. Puede optar por des-asignar dinámicamente y asignar recursos según sea necesario. También puede mover más fácilmente los servicios individuales a la nube para pasar a una arquitectura más orientada a los servicios antes de la migración.
7. Migración de datos.
Migre los datos actuales a la nube después de la implementación. Este proceso puede requerir algunos cambios para adaptarse y llevará tiempo. Asegúrese de que funcionan correctamente después de probar todas las conexiones.
Comenzar con los servicios que tienen menos dependencias tiene más sentido. Aquí, hará un seguimiento de sus servicios más externos, generalmente los más cercanos a sus clientes después de migrar primero sus servicios más internos. La probabilidad de realizar pruebas en un entorno de vida se abre migrando gradualmente a los usuarios. Elija aplicaciones más simples que no manejen datos altamente confidenciales, con una alta probabilidad de éxito para comenzar. A medida que lance de forma incremental, es mejor encontrar pequeños problemas en la aplicación que encontrar grandes problemas en el inicio.
La primera funcionalidad básica de una organización, desde nuestra experiencia, al realizar el cambio a la nube suele ser la infraestructura de análisis. Dado que no es el núcleo absoluto, pero es un componente importante de la infraestructura de datos de una organización, se convierte en un objetivo de migración menos riesgoso e ideal. Además, hay varios equipos de análisis de datos en cada organización, y será más fácil comenzar con un grupo pequeño e innovador para liderar el cambio. Encuentre este grupo y trabaje con ellos para configurar una herramienta de BI que funcione con su almacén de datos en la nube.
8. Eliminar la base de datos local
Utilice un mecanismo de sincronización bidireccional entre su nube y las bases de datos locales. Elimine la base de datos local una vez que haya movido todos los usuarios de los datos a la nube. Permita que los consumidores se conecten solo a la versión local utilizando una base de datos local con sincronización unidireccional a una base de datos basada en la nube. Deshabilite el acceso a la versión local y permita que los usuarios basados en la nube accedan a la nueva base de datos cuando esté listo para que la versión basada en la nube se convierta en la base de datos principal. Al igual que los disponibles en Microsoft Azure y Amazon Web Services, use un servicio de migración de datos en la nube. No subestime la complejidad de la planificación de la migración de datos. Antes de comenzar una migración a la nube, no prestar mucha atención a su plan de migración de datos podría hacer que las migraciones no cumplan con las expectativas o que fallen por completo.
9. Cambiar de producción
Cambia la producción de la solución heredada local a la nueva versión en la nube basada en la arquitectura y la complejidad de su aplicación, y especialmente la arquitectura de sus almacenes de datos y datos. Hay dos enfoques comunes. Puedes hacerlo todo a la vez. Mueva toda la aplicación o servicio a la nube. Valide que funciona allí. Luego cambie el tráfico a la pila de la nube desde la pila local. O hazlo un poco a la vez. Pruebe que las cosas siguen funcionando después de trasladar a algunos clientes y luego traslade algunos clientes más. Siga haciendo esto hasta que haya trasladado a todos sus clientes a la aplicación basada en la nube.
Intentar migrar un producto licenciado en las instalaciones a una solución SaaS (XaaS) de ingresos recurrentes es probablemente la tarea más laboriosa que una empresa puede asumir. El cambio a un modelo basado en SaaS para una empresa de productos exige un cambio crucial en el ADN de la empresa. Las ventajas son enormes, y los vendedores que se enfrentan a los cambios en su sector prosperarán. Los proveedores que tardan en mudarse a SaaS han visto disminuir el crecimiento y el valor de su empresa. Los proveedores con visión de futuro están cambiando agresivamente al modelo SaaS con resultados alentadores. Pero es crucial hacer las correcciones necesarias mientras se monitorea la progresión con las métricas apropiadas.
Leer también:Automatizar la infraestructura como servicio;Explicación De IaaS: Cómo Usar IaaS Para Hacer Crecer Su Negocio; Arquitectura del centro de datos, data center