En la actualidad las empresas se enfrentan a cambios constantes o procesos de transformación e innovación tecnológica, las necesidades actuales cambian para adaptarse al futuro, deben de crecer, adentrarse en nuevos territorios.
Por estos motivos es necesario disponer de infraestructuras y aplicaciones modernas apoyadas en nuevos paradigmas de construcción que permitan desarrollar aplicaciones seguras y escalables rápidamente, que den soporte a los nuevos productos y servicios.
La transformación a Cloud Native permite a las empresas enfrentarse a estos escenarios cambiantes y en constante evolución y proporciona grandes beneficios aunque también es cierto que plantea una serie de desafíos que se deben de tener en consideración lo antes posible, para tomar la mejor decisión en cada momento.
El proceso de transformación no siempre se culmina consiguiendo los objetivos deseados, es necesario una correcta gestión de la expectativa.
Si la transformación no se completa con éxito no es debido a los recursos tecnológicos disponibles, que son de una enorme potencia y dan unas capacidades muy superiores a las disponibles hasta hace poco. El fracaso viene dado porque es un proceso de transformación complejo, tanto en su definición como en su ejecución, que obliga a un cambio de paradigma. Es fundamental comprender que el verdadero valor de la transformación a Cloud Native radica en aprovechar el ecosistema existente de la forma más apropiada para cada caso.
Para que el proceso se culmine de una forma satisfactoria se debe elaborar un Viaje al Cloud (J2C), definiendo las etapas mínimas necesarias, e identificando los beneficios, desafíos y bloqueadores que pueden surgir a lo largo del proceso de transformación. En cada etapa se dan una serie de recomendaciones que servirán de orientación a la hora de elaborar un viaje al cloud propio.
Como llevar a cabo el viaje a Cloud
La transformación a Cloud Native permite alcanzar uno o varios de los siguientes objetivos.
- Tiempo de puesta en el mercado más rápido
- Mayor disponibilidad
- Seguridad mejorada
- Reducir costes.
El principal cambio que se produce en el proceso de adopción Cloud desde el punto de vista de la empresa es como adquiere y usa los recursos tecnológicos. Las organizaciones que siguen un modelo tradicional asumen la propiedad y la responsabilidad en todos los aspectos de la tecnología, desde la infraestructura al software.
Junto a este cambio es necesario afrontar cambios más profundos para la puesta en producción de aplicaciones Cloud Native, que requieren crear un sistema interdependiente y distribuido, para lo que es recomendable seguir un estilo moderno de construcción de aplicaciones, existiendo arquitecturas (por ejemplo, microservicios), tecnologías (por ejemplo, contenedores), directrices (por ejemplo, 12-Factors) y buenas prácticas y principios que pueden ayudar en el proceso (DevOps).
En la mayoría de los casos implica modificar la forma de identificar las necesidades de negocio, definir tecnológicamente como dar solución y poner en práctica dicha propuesta, este cambio suele ser el más costoso debido a que incide en los propios flujos de comunicación dentro de la empresa, el modo de realizar las diversas tareas, en las responsabilidades y formación de los equipos, y en muchos casos es donde reside el motivo de los fracasos o de no conseguir todos los objetivos planteados, contar con una empresa como atSistemas que ayude a detectar estos riesgos y poner las medidas correctivas necesarias es un factor que facilitará la consecución del éxito.
Cuanto más lejos se encuentre la organización de poder poner en práctica todos estos puntos, más difícil será la transformación. Sin embargo, los beneficios obtenidos al adoptar el paradigma Cloud Native de construcción y puesta en servicio de aplicaciones son considerables, mejorando la eficiencia de sus procesos e incrementando la seguridad de su plataforma.
Viaje a Cloud (J2C)
El viaje a Cloud (J2C) es el conjunto de procesos de adopción de servicios en Cloud y migración o transformación de activos desde las instalaciones al Cloud. No es una tarea fácil, pero contando con atSistemas que dispone de una amplia experiencia en este proceso de transformación, y conocimiento de los diversos desafíos y bloqueadores a los que hay que enfrentarse a lo largo del proceso, finalmente se alcanzarán los objetivos de una forma totalmente satisfactoria.
Como todo viaje del que esperamos que la experiencia sea lo mejor posible, debemos de tener claro el punto de partida, definir los criterios que se deben de cumplir para considerar que el destino al que llegamos es satisfactorio, y con esta información elaborar el camino que nos permita realizar el viaje de la mejor forma posible.
Se compone de una serie de etapas que son necesarias para adelantarse a los problemas que puedan surgir, a continuación identificamos las que es necesario que se lleven a cabo.
Conocer beneficios, desafíos y bloqueadores
Conocer, aceptar y estar de acuerdo con los beneficios, desafíos y detectar los posibles bloqueadores existentes.
En esta primera etapa es necesario entender los beneficios obtenidos del proceso de transformación, entender el esfuerzo necesario para llevarlo a cabo, y valorar si se está en disposición de afrontarlos, para comenzar el proceso de transformación.
Típicos desafíos que se encontrará la organización están relacionados con la transformación que debe de realizarse en el propio modo de trabajo, así como la formación y cambio de competencias de los equipos de trabajo.
Es muy importante entender que pueden existir bloqueadores que impidan el cumplimiento de algún objetivo y estar alerta para la detección de los mismos lo antes posible. Un ejemplo de bloqueador común es el cumplimiento normativo de residencia de determinados datos, ya sea porque es necesario mantenerlos en un CPD local, o en un determinado país o región, lo cual puede imposibilitar o dificultar su traslado a Cloud.
Definir la estrategia a seguir
Si se acepta iniciar el proceso, hay que evaluar el proceso de transformación que debe de realizar la organización, dentro de este punto se encuentra entre otros la posible necesidad de formar los equipos necesarios para guiar y ejecutar el proceso de transformación.
Es necesario conocer que el proceso de transformación completo requiere un esfuerzo, y que es posible alcanzar los objetivos planteados llegando a un compromiso en el que se mantienen activos tal cual están, se migran otros, y se modernizan y transforman otra parte
Este puede ser un buen punto de partida, y una vez completado y alcanzada la madurez suficiente, reevaluar la situación y comprobar si se quiere completar la transformación de los activos que se mantuvieron o migraron.
AS-IS
Entender la situación inicial. Una fase imprescindible es evaluar la situación de los activos existentes los cuales se deben de clasificar para decidir:
- Cuáles se mantienen como están (Retain)
- Cuáles se migran (Rehost)
- Cuáles se modernizan (Refactor o Rearchitect)
- Cuáles se descartan (Retire)
- Y qué activos serán sometidos a una transformación completa (Replace o Rebuild)
Es muy importante definir y detectar las relaciones entre los diferentes activos para poder elaborar el roadmap completo del proceso de viaje a Cloud.
TO-BE
Es necesario clarificar los objetivos necesarios del proceso de transformación para poder definir un plan que los de cobertura, es recomendable que la transformación se realice por iteraciones para realizar ajustes en el plan, y evitar un big bang, se puede elaborar el TO-BE de la primera iteración o de todas ellas. Estos objetivos pueden ser uno o varios de los siguientes:
- Mejorar el tiempo de puesta en el mercado de nuevas aplicaciones
- Mejorar la disponibilidad
- Aumentar la seguridad
- Permitir adaptar escalabilidad a las oscilaciones de la demanda
- Prescindir del CDP On-premise
- Reducir costes
- Otros
Plan de adopción Cloud
Esta fase es realmente la que definirá el proceso de adopción cloud, en ella se debe:
- Indicar el plan de vitalidad del propio plan para definir el proceso para incorporar modificaciones
- Identificar el equipo del que se dispone y detectar necesidades de formación
- Decidir tipo de cloud al que se realizará la transformación (pública, privada, híbrida)
- En el caso de pública o privada, si se seguirá un modelo multicloud o de un único proveedor, y seleccionar el proveedor cloud que ofrecerá el servicio
- Elaborar el gobierno Cloud el cuál debe de ser enfocado desde dos ámbitos, a nivel de organización y a nivel de aplicación
- Elaborar el roadmap a seguir
Nivel de organización
Es necesario definir:
- Si existe algún tipo de agrupación de aplicaciones, por ejemplo unidad de negocio, dominio funcional etc.
- La organización dentro de la Cloud seleccionada, es decir definir como residen los activos de la organización en función del proveedor seleccionado. Hay varias estrategias para estructurar la organización:
- Por entorno de trabajo (Desarrollo, Pruebas, Producción).
- Tomando en consideración el modelo de agrupación decidido en el punto anterior (por unidad de negocio, o por otro tipo de agrupación).
- Por cada entidad de facturación.
- A nivel de organización hay que tomar una serie de decisiones que serán aplicadas en el nivel de aplicación, por poner algunos ejemplos:
- Los servicios se aprovisionarán de forma individual por aplicación o de forma colectiva para varias aplicaciones, cada una de las opciones tiene sus ventajas e inconvenientes. La mejor decisión es llegar a un compromiso y optar por los dos modos, determinadas aplicaciones ya sea por volumen, por estrategia o por otro motivo dispongan de infraestructura propia, y otras usen la infraestructura disponible dentro de la unidad de negocio, dominio funcional o agrupación a la que pertenezca.
- Se debe decidir si se hará uso de todo el catálogo de servicios disponibles por el proveedor Cloud. La mejor solución es optar por una hibrido, por ejemplo limitar el uso de Bases de datos disponibles o elementos de proceso, pero permitir el uso de servicios avanzados IoT, Machine learning etc.
- Las políticas que se aplicaran a las aplicaciones, dentro de las políticas se pueden definir controles de seguridad, cuotas de presupuesto, limitaciones de niveles de servicio o recursos.
- El uso de redes, es decir si las redes se contemplan a nivel de organización, de aplicación, de unidad de negocio, de dominio funcional o de la agrupación que se considere. Identificar la arquitectura de red que se va a ejecutar.
- El uso de los elementos de proceso, de los servicios de integración, servicios de almacenamiento, bases datos y gobierno del dato, criterios de seguridad, aplicación de directivas.
- Definir itinerarios de pruebas según los diferentes tipos de aplicación.
Nivel de aplicación
Se debe de definir:
- El ciclo de vida y flujo de creación de aplicaciones, si es necesario informar a otros equipos a cuáles y en que momento.
- Qué modelos de referencia se estará obligado a seguir en su diseño y si existen arquitecturas recomendadas.
- La seguridad que se debe de cumplir:
- Se darán recomendaciones para la gestión de las subredes.
- Se definirán procedimientos para la recuperación ante fallos.
- Cómo identificar la disponibilidad requerida.
- Parámetros para definir la escalabilidad.
- Itinerario de pruebas que debe de ejecutar.
Implementar el plan
Todos los equipos que participarán en el proceso ejecutarán el plan definido, el plan tal como se ha indicado puede requerir adaptaciones según se ejecuta, se seguirá el plan de vitalidad definido.
Valorar los resultados de ejecución
Se debe de valorar si se han conseguido los objetivos fijados si no se ha conseguido es necesario, detectar cuál es el motivo, para poder modificar el plan si es necesario, para sucesivas etapas. Es necesario verificar:
- Los tiempos de inactividad, y si cumplen los objetivos.
- Verificar si la configuración de los servicios es correcta y si admite mejora.
- Revisar posibilidades de agrupación o de disgregación.
- Decidir si se continua con la aplicación del plan.
Gobierno y Operación en Cloud
La operación de las aplicaciones en Cloud se convierte en un requisito fundamental para lograr el éxito de la modernización. No comprender la operación necesaria es arriesgado porque puede comprometer el éxito de la transformación.
Es necesario realizar periódicamente las revisiones que se plantean en la fase anterior, para poder mejorar de forma continua el entorno Cloud.
Dentro del Gobierno Cloud recae el tener que comprobar si es necesario realizar ajustes o cambios en el plan seguido, y mantener la vigilancia y control necesario para asegurar que una vez completado el viaje a Cloud, se siga manteniendo como foco principal el que las aplicaciones de la organización sean Cloud Native.