Sugerencias de Arquitectura de MicroServicios para comenzar a ser Bimodal

Qué hacer para pasar a Microservicios

Conversamos sobre la arquitectura de tres niveles (post) y cómo debería evolucionar a una arquitectura de microservicios. Ahora veremos unas sugerencias para poder tener una buena transición de tres niveles a servicios.

• Establecer un programa de innovación que permita a todo el equipo de arquitectura comenzar a experimentar con Arquitectura de Microservicios. (Permiso)
• Investigación para desarrollar las habilidades necesarias para desplegar soluciones con la nueva infraestructura que pueda soportar "Entrega Continua" y Microservicios. Ya se conocen empresas que han desplegado soluciones con código abierto. (Inversión)
• Debe iniciar con una aplicación existente en tres niveles y buscar refactorizar para lograr tener multiniveles de adaptación a otros entornos o aplicaciones. (Piloto)
• Se recomienda comenzar con una aplicación de bajo riesgo y que no bloquee algún proceso de negocio crítico en su negocio. (Criterio)
• Con el cambio en proceso, deberá experimentar con los niveles de servicio y operación. A nivel de servicio, debe medir si está generando disrupción frente a tres capas de manera total o fragmentada. Para no afectar la solución, deberá crear funcionalidades, satélites, de servicios pequeños y que se encuentren proporcionando información a la solución tradicional. A nivel de operación, debe trabajar con herramientas que le permitan gestionar todo el ciclo de vida del servicio por ejemplo monitoreo y comunicación. (Sustento)
• Con la experiencia obtenida en uno o más servicios, deberá comenzar a encargar a Arquitectura que defina estándares, gobierno, métricas para lograr el éxito con la Arquitectura de Microservicios. (Madurez)
• Finalmente, prepare un plan para avanzar en la transformación digital. Se tiene que evaluar el catálogo de aplicaciones y se debe identificar las críticas para asegurar el éxito. Y recuerde siempre acompañe su solución a un caso de negocio para justificar la reestructuración. (Meta)

Ahora recuerde que pasar a una Arquitectura de Servicios es una buena práctica de segmentar mejor la comunicación entre aplicaciones externas de tipo Big Data, IoT, SaaS, B2B con tus aplicaciones internas dentro de tu Gobierno IT. Es clave para Arquitectura reducir el índice que tiene la deuda técnica y deuda por seguridad, tanto para desarrollos internos como aplicaciones de terceros, por ese motivo el enfoque de arquitectura es importante para la gestión de servicios porque es la pauta que define como enfocar trabajar tus servicios en modo 1 o 2 (Bimodal).

Es requisito tener una buena Arquitectura para ser Bimodal

El impulso de los negocios digitales ha llevado a que muchas empresas quieran evolucionar rápidamente, llamándose a esto "Transformación Digital", pero lo primero es saber que hacer, por ejemplo qué nuevas prácticas y tecnologías adoptar. Sin embargo, estos cambios rápidos en el negocio han creado que la empresa tenga IT Bimodal, comenzado a ser negocios exploratorios lo que comúnmente denominan Modo 2.

Los proyectos de Modo 2 implican cambios en los modelos de Arquitectura - Infraestructura IaaS y Servicios SaaS - que adicionado a desarrollo ágil de aplicaciones más integración con DevOps para las operaciones logrando cambiar los enfoques de seguridad y tecnología. Ahora porque es importante estos temas, pues todos los que gestionan proyectos saben que la deuda técnica es un factor negativo para cualquier implementación que sumado con la deuda de la seguridad de información pueden hacer fracasar nuestros proyectos en Modo 2.

La arquitectura es un requisito importante para ser Bimodal, pero antes de pasar a concluir, expliquemos en líneas general lo que significa modo 1 y 2:

• Modo 1 - predictibilidad y estabilidad. Se utiliza mejor cuando los requisitos son bien comprendidos, y puede identificarse mediante un proceso de análisis.
• Modo 2 - exploratorio. En este caso, los requisitos no son bien entendidos. Este modo es el más adecuado para las áreas en las que una organización no puede elaborar un plan preciso y detallado porque no se conoce lo suficiente sobre lo que se quiere. Los esfuerzos del Modo 2 no suponen predecir el futuro, pero permiten que el futuro se evidencie en pequeños entregables. Este trabajo a menudo comienza con una hipótesis que se demuestra, descarta o evoluciona durante un proceso.

Ambos enfoques pueden dar entender que se contradicen, pero comparten algo en común que es la arquitectura de la solución en su conjunto. El beneficio de una empresa es que un enfoque IT Bimodal genera valor al negocio que permite agilizar la entrega de los servicios para incrementar ventas, producción y colaboración.

Publicare otro contenido dirigido a Bimodal para cubrir mayores alcances.

Gracias.

Saludos.