786-347-6469 info@gsgtech.com

Empieza pequeño
Cuando una organización está tratando de introducir computación en la nube, pequeños experimentos deberían ser conducidos primero. En nuestro trabajo de consultoría en OpenCredo a menudo recomendamos la creación de una simple prueba de concepto (POC) basada en un subconjunto de la funcionalidad de negocio, que debe llevarse a cabo por separado de las actividades de “business as usual” o negocio usual (BAU). También hemos recomendado el uso de ‘hack days’ (o una ‘hack week’, dependiendo del alcance) donde un equipo de desarrollo de TI o software tiene el reino libre para experimentar con la nueva tecnología disponible.
Criterios para POC
Funcionalidad limitada a un solo departamento. Esto limita el “overhead” de la comunicación y gobierno. Por.ej. Un nuevo servicio de pago
La funcionalidad requerida puede ser proporcionada como una aplicación ‘vertical’ (autónoma) con puntos de integración externos mínimos. Por ej. Sitio web/ página de registro de nuevos clientes

Comparta metas con el equipo responsable del trabajo
El objetivo clave de esta etapa dentro del plan es que el equipo de TI se familiarice con el paradigma de la nube (por ejemplo, todavía vemos con frecuencia el aspecto de asombro cuando los desarrolladores se dan cuenta de que pueden girar y acceder a hardware potente en cuestión de segundos) Lo cual pavimenta el camino para que el resto del negocio se adapte al paradigma de la nube (por ejemplo, diferentes mecanismos de facturación y procesos de aprobación) y permite la evaluación de las distintas plataformas cloud en relación con los casos de uso típicos dentro del negocio.

Todas las nubes no son iguales – Elija sabiamente
Cada plataforma en la nube tiene propiedades inherentes, fortalezas y debilidades. El principal objetivo de esta etapa de una migración de nube es determinar y catalogar los casos de uso primarios que se implementarán dentro de los seis a doce meses de trabajo iniciales y luego asignar estos requisitos a las ofertas de los distintos proveedores de nube.

Sea consciente de la geografía
El rango geográfico de la nube es a menudo un habilitador clave. La expansión en un nuevo mercado geográfico lleva años de planificación y negociación de contratos de infraestructura. Ahora, simplemente seleccionamos una “región” diferente de la interfaz de usuario de nuestro proveedor de la nube, desplegamos nuestro empaquetado de soluciones requerido y estamos listos para hacerlo. El reverso de esta facilidad de despliegue es que hay que tener cuidado con respecto a dónde fluye el flujo de datos y se almacena en reposo. La soberanía de los datos suele ser un componente crítico de muchas operaciones empresariales y el envío accidental de datos a través de fronteras internacionales para el procesamiento de la información puede violar las regulaciones y los mandatos de cumplimiento.
Cualquier plan para migrar aplicaciones a la nube debe incluir un acercamiento a la “debida diligencia” de los requisitos de datos, las restricciones legales y regulatorias deben ser claramente comunicadas al equipo de TI y a través del negocio. Además, el despliegue de aplicaciones a través de múltiples regiones geográficas y zonas de disponibilidad es altamente recomendable para mitigar el riesgo de indisponibilidad y pérdida de datos.

Aplicaciones a la nube
Mucho se está escribiendo actualmente sobre las ventajas de crear sistemas del software como racimos de microservices (IoT). Independientemente de cuán pequeños sean sus servicios, cualquier software que se despliegue en la nube se beneficiará de adherirse a muchos con los mismos objetivos técnicos, mejor codificados como aplicaciones de Doce-Factores. Obviamente, no todas las aplicaciones existentes se pueden migrar a este formato, El requisito de las aplicaciones “sin estado”, en particular es problemático para muchas aplicaciones escritas antes del advenimiento de las tecnologías en la nube. Sin embargo, el hecho de que casi todos los componentes dentro de una nube se comunicarán a través de una red significa que los desarrolladores se deberían familiarizar con los principios fundamentales y avanzados de la distribución en computación.
La finalización de esta etapa dentro de un plan de migración de la nube debe resultar en un catálogo de aplicaciones que se migrarán (o crearán) y los asociados técnicos, requerimientos “no funcionales” claramente enumerados.. La validación de todos los requisitos funcionales y no funcionales debe incluirse dentro de un pipeline automatizado. En relación con la sección anterior de este artículo, vale la pena prestar especial atención a las aplicaciones que se comunican a través de las “zonas de disponibilidad” (esencialmente los centros de datos) a través de las regiones geográficas. Lo que puede aparecer como una pequeña brecha en un diagrama de arquitectura puede agregar latencia significativa o potencial de falla.
No Olvidar la Organización (y a la gente!)
La segunda parte del artículo analiza los retos organizacionales que a menudo vemos cuando se está llevando a cabo una migración de la nube.

Diseño organizacional y transformación
A menudo, el primer signo de las luchas de diseño de organización aparecen como un equipo que pasa de la prueba de concepto (POC) a la fase de implementación. Tan pronto como la implementación de migración de nube se expande más allá de un equipo, entonces la complejidad de las interacciones aumenta. Esto a menudo puede ser desafiante a nivel técnico, pero casi siempre es desafiante a nivel organizacional. Buscamos banderas rojas como colas de trabajo, largos retrasos o firmas en el trabajo mientras se mueve alrededor de una organización y equipos halando en direcciones diferentes (o usando tecnologías competitivas).
A menudo trabajamos con el nivel C de la gerencia superior dentro de las organizaciones, ya que, a menos que se logre alineación y aceptación a este nivel, ningún cambio realizado dentro del resto de la organización puede desentrañar fácilmente.
La Importancia de DevOps
Aunque el término DevOps se ha vuelto algo excesivo (y todavía no está definido de verdad), creemos que los conceptos detrás de él como una (1) comprensión y responsabilidad compartida a través del desarrollo y las operaciones, (2) la automatización, con principios y prácticas manejando herramientas, no al revés, y (3) la creación de señales de retroalimentación rápida, son vitales para el éxito dentro de una arquitectura de nube. Como el número de componentes de la aplicación suele ser más alto dentro de una aplicación basada en la nube (en comparación con las plataformas más tradicionales) a menudo vemos surgir problemas rápidamente donde los equipos están desalineados con los objetivos, resolviendo el mismo problema de múltiples maneras o el uso incorrecto de herramientas de DevOps y una ausencia de percepción consciente de lo necesario.
Hemos visto implementaciones de DevOps crear miedo dentro de las organizaciones, y también hemos visto procesos no óptimos siendo automatizados(falla automatizada sigue siendo una falla!). Creemos que los conceptos y objetivos detrás del movimiento ‘DevOps’ son vitales en el contexto empresarial más amplio y el clima económico actual, donde el tiempo de salida al mercado y la velocidad de la innovación son claras ventajas competitivas.

Referencias:
ITCIO
Este artículo aparece en la nueva Guía de DZone para crear y desplegar aplicaciones en la nube.

Ivan Nava

Manager Sales Cloud Solutions|Iaas|Saas|DR&BC|High Speed Connectivity|MPLS|HPBX|File Sharing|VM| at Birch Communications