Nunca ha habido un momento más esencial para asegurar que los equipos trabajen juntos y entreguen las características con rapidez y eficiencia.
La implementación de las prácticas de DevOps en sus flujos de trabajo le da a su negocio la estructura para una evolución constante, reduciendo los costos y optimizando la eficiencia.

Esto te garantiza que podrás crecer con la seguridad de que dispones de los mejores sistemas para apoyar tu desarrollo, utilizando procesos automatizados y una estrategia personalizada para crear un crecimiento resistente y a prueba de futuro.

Aquí están las 4 capas de DevOps para instituciones financieras:

1 | Infraestructura para Código

Es importante aclarar que la definición de “DevOps” se desvía de la definición bancaria tal vez más tradicional, que es una unión de personas de Desarrollo y personas de Operaciones, sino que es una combinación de personas de Desarrollo Técnico y personas de Operaciones de Maquinaria.
Los operadores de máquinas que normalmente habrían construido la infraestructura de computación física ahora trabajan en proyectos junto con los desarrolladores, convirtiéndose en un solo equipo.

Por lo tanto, los operadores de máquinas pueden ayudar a los desarrolladores a comprender cómo construir y codificar la infraestructura de sus aplicaciones para lograr eficiencia y longevidad. Esencialmente, recrear la infraestructura de potencia de procesamiento físico dentro del código.

2| Microservicios

Los microservicios son sobre la arquitectura del sistema. Son un fragmento de código que le da a cada función de una aplicación su propio “contenedor”. Las entradas y salidas de cada fragmento son estáticas.

Esto significa que podemos cambiar cualquier cosa en el código sin que afecte al resto del sistema, dándonos servicios de despliegue independiente, esto significa que no necesitaremos hacer una prueba completa del sistema o un análisis de impacto completo cada vez que queramos hacer un cambio.
Los beneficios de los microservicios pueden verse fácilmente en el sitio web más popular del mundo: Google.com, la imagen que se encuentra sobre la barra de búsqueda es un Microservicio.

Considera con qué frecuencia cambia esa imagen… Ahora compara eso con la frecuencia con la que has visto a Google quitar todo su sistema/sitio web para asegurarte de que la imagen va a funcionar para todo el mundo en la interminable variedad de dispositivos que visitan el sitio web.

Los microservicios pueden ser pequeños pero cuando están construidos apropiadamente en sus fragmentos, interconectados correctamente y construidos, los microservicios pueden hacer algunos de los sistemas más complejos del mundo.

Desde la gestión de garantías realizada enteramente en la web mediante microservicios hasta los sistemas de negociación de bonos y acciones, los microservicios se apalancan para ayudar a mantener sus sistemas funcionando en todo momento.

Los microservicios reducen la cantidad de pruebas que se tienen que hacer sustancialmente, y como muchos de ustedes saben, las pruebas a menudo consumen entre el 30% y el 50% de su presupuesto en cualquier proyecto bien gestionado.

3 | Construir para probar

Esto es un cambio de mentalidad. Solíamos escribir una especificación, hacer que un comité se sentara en ella y luego la firmara, ponerla bajo control de cambios, dársela a los desarrolladores para que la codificaran, y finalmente al equipo de pruebas de control de calidad.

Ahora, cuando usamos una colección de microservicios para satisfacer una necesidad del cliente, podemos construir para probar. Esto significa que el código puede ser construido dentro de la herramienta de pruebas, la ventaja de esto es la facilidad con la que podemos hacer cambios o probar elementos de un sistema, cambiando radicalmente el ritmo al que los modelos de pruebas tienen lugar.

A través de esto, al tener infraestructura para codificar, desarrollar en microservicios, y construir para probar (todo lo anterior), logramos lo que se conoce como CICD (Integración Continua, Despliegue Continuo), y eso significa que podemos poner en producción cambios de manera regular sin impactar la base de clientes, incluso mientras aún están usando el sistema. Entonces, ¿cómo codificamos esto realmente?

4 | Metodologías Ágiles

Aquí es donde se produce el cambio cultural de la mente. Esta capa consistirá en 3 elementos.

El primero es la forma en que llevamos a cabo nuestros requerimientos comerciales. En lugar de tener analistas de negocios altamente calificados sentados y consultando con los usuarios sobre cómo se hacen las cosas, qué tal si ahora los usuarios pueden simplemente “contar una historia”.
Tal vez podrían decir algo como “Llegué esta mañana y me senté en mi escritorio y puse mi dedo en el lector de huellas dactilares y me dio una lista de cosas que tengo que hacer hoy”. Ese es un ejemplo de una “historia de usuario”.

Para todos los técnicos que lean esto: ¿pueden imaginar lo que estarían codificando si recibieran esa historia?

Permítanme elaborar, sería algo así: “Necesitaría reconocimiento de huellas digitales, por lo tanto, biometría. Entonces la aplicación necesita abrirse automáticamente al ser reconocida y en el lado derecho el usuario debería ver una lista de acciones que necesita tomar hoy”.

Construyendo conductos enteros de historias de usuarios que satisfagan las necesidades de cada usuario específico, podemos describir sistemas complejos en términos que cualquier usuario pueda describir.

Estos luego van a las escuadras, el 2º elemento, que consiste en alrededor de 7-12 personas. Cada escuadra recibirá un número de historias de usuarios.
¿Qué es una brigada?

Una brigada tiene roles definidos, está compuesto por un Propietario de Producto, un Scrum Master o un Entrenador Ágil y un número de roles técnicos y de prueba.

Para que estas escuadras sean altamente productivas necesitan cooperar plenamente a lo largo del día. Pero para aquellos que están deslocalizando de este a oeste, o viceversa, ¿cómo pueden ser productivos sus escuadrones cuando hay una diferencia de tiempo de hasta 10 horas y media? Pero si se deslocalizan de norte a sur, habrá una o dos horas de diferencia horaria como mucho, entonces se pueden empezar a ver escuadras muy productivas que estarán todas despiertas al mismo tiempo.

Ahora el tercer y último elemento, a los equipos se les darán cajas de tiempo, normalmente de 2 a 3 semanas, y se sentarán y crearán lo que se llama un plan de sprint mirando el número de historias de usuarios que tienen, el tamaño de su equipo, cuántas pueden hacer en 2 o 3 semanas, y planificarán quizás las próximas 3 o 4 cajas de tiempo.

A medida que pasan por el proceso de desarrollo, prueba y puesta en producción pueden necesitar hacer ajustes para cumplir con ese período de 2 a 3 semanas, ya sea adelantando algunas si lo están haciendo bien y antes de lo previsto o retrasando un par para el siguiente sprint si ha habido un retraso.
Este método nos permite tener definidos los resultados que pueden ser fácilmente cambiados.

Ahora, ¿por qué es eso valioso? Pregúntese – ¿cuántas veces ha esperado que el presupuesto del año siguiente se cambie después de 3 meses, o 6 meses, o 9 meses? ¿Cuántas veces te ha pasado eso en el pasado?
Usando estos métodos ágiles, la habilidad de cortar y cambiar significa que puedes controlar mejor tus presupuestos en un mundo muy volátil, y afrontémoslo, el mundo ha cambiado.

Tus clientes no pueden esperar 6 meses para las nuevas características, con DevOps, los ciclos de vida de desarrollo se reducen drásticamente, la aplicación en producción es mucho más estable, el tiempo de inactividad se reduce en más de 5 veces y el tiempo de recuperación se reduce en más de 96 veces.
A mi equipo le encantaría tener la oportunidad de discutir esto más a fondo con usted, por favor reserve una consulta gratuita en cpqi.com o envíenos un correo electrónico a info@cpqi.com para obtener una propuesta sin compromiso sobre cómo DevOps puede ser aprovechado en su negocio.