Case: Evolving User Experience – A Three-Phase Banking Solution

Case: Evolving User Experience – A Three-Phase Banking Solution

 
Introduction:
The unprecedented impact of COVID-19 on several financial institutions reshaped user habits almost overnight. During lockdown, the surge in online banking showcased the unpreparedness of many portals to handle heavy workloads. While some lagged in adapting, others, like our client, a renowned Chilean financial institution with over 50 years of service and over a million users, swiftly began their digital transformation journey.
 
Phase 1: The Pandemic Response
During the peak of the pandemic, our client embarked on its initial digital transformation. They adopted the cloud to ensure their platforms remained stable, scalable, and secure. Consequently, they were able to introduce new functionalities, enabling users to execute tasks previously limited to physical branches. For this massive endeavor, they employed the Amazon Web Services (AWS) Cloud platform, paired with the expert guidance of a team of specialized professionals.
 
Phase 2: Post-Pandemic Enhancements
Post-pandemic, as users and businesses acclimated to online operations, our client entered the second phase of their transformation. This involved enhancing their architecture. Their first order of business was load testing to understand how concurrent online activity impacted their on-premises components. This was crucial in determining optimal configurations for AWS EKS and AWS API Gateway services.
 
Furthermore, as the business expanded its online offerings, new services were integrated. Security became paramount, prompting the institution to implement stricter validations and multi-factor authentication (MFA) for all users.
 
Phase 3: Continuous Improvements and Expansion
With more users adapting to online banking, the third phase saw the introduction of additional applications, enhancing the suite of services offered. The architecture was continuously revised and updated to cater to the ever-increasing demands of online banking.
 
Security was further tightened, and robust monitoring and traceability features were incorporated, providing deeper insights and ensuring system stability.

Proyectos Realizados

El Cliente, junto con sus áreas de Arquitectura, Desarrollo, Seguridad e Infraestructura, vio en AWS un aliado para llevar a cabo la construcción de un nuevo Portal, aprovechando las ventajas de la Nube como elasticidad, alta disponibilidad, conectividad y gestión de costos.

El proyecto concebido contempló la implementación de un frontend (Web y Mobile) junto con una capa de microservicios con integración hacia sus sistemas On-Premise vía consumo de servicios expuestos en su ESB que a su vez accede a sus sistemas legacy, formando así una arquitectura. híbrido.

En el marco de este proyecto, 3HTP Cloud Services participó activamente en el asesoramiento, definiciones e implementaciones técnicas de la infraestructura y soporte a los equipos de desarrollo y automatización, tomando como referencia los 05 pilares del marco bien arquitectónico de AWS.

La participación de 3HTP Cloud Services se centró en las siguientes actividades:

• Validation of architecture proposed by the client 
• Infrastructure as code (IaC) project provisioning on AWS 
• Automation and CI / CD Integration for infrastructure and micro-services  
• Refinement of infrastructure, definitions, and standards for Operation and monitoring
• Pruebas de estrés y carga para AWS y la infraestructura local

Outstanding Benefits Achieved

Our client’s three-phase approach to digital transformation wasn’t just an operational shift; it was a strategic masterstroke that propelled them to the forefront of financial digital innovation. Their benefits, both tangible and intangible, are monumental. Here are the towering achievements:

1. Unprecedented Automation & Deployment: By harnessing cutting-edge tools and methodologies, the client revolutionized the automation, management, and deployment of both their infrastructure and application components. This turbocharged their solution’s life cycle, elevating it to industry-leading standards.
2. Instantaneous Environment Creation: The ingeniousness of their automation prowess enabled the generation of volatile environments instantaneously, showcasing their technical agility and robustness.
3. Robustness Redefined: Their infrastructure didn’t just improve; it transformed into an impregnable fortress. Capable of handling colossal load requirements, both in productive and non-productive arenas, meticulous dimensioning was executed based on comprehensive load and stress tests. This was consistently observed across AWS and on-premises, creating a harmonious hybrid system synergy.
4. Dramatic Cost Optimization: It wasn’t just about saving money; it was about smart investing. Through astute utilization of AWS services, like AWS Spot-Aurora Server-less, they optimized costs without compromising on performance. These choices, driven by findings and best practices, epitomized financial prudence.
5. Achievement of Exemplary Goals: The institution’s objectives weren’t just met; they were exceeded with distinction. Governance, security, scalability, continuous delivery, and continuous deployment (CI/CD) were seamlessly intertwined with their on-premises infrastructure via AWS. The result? A gold standard in banking infrastructure and operations.
6. Skyrocketed Technical Acumen: The client’s teams didn’t just grow; they evolved. Their exposure to the solution’s life cycle made them savants in their domains, setting new benchmarks for technical excellence in the industry.

Servicios realizados por 3HTP Cloud Services: Validación inicial de la arquitectura

La institución ya contaba con una primera arquitectura de adopción en la nube para su portal de cliente, por ello, como equipo multidisciplinario, comenzamos con un diagnóstico de la situación actual y la propuesta realizada por el cliente; De este diagnóstico y evaluación se obtuvieron las siguientes recomendaciones relevantes para la arquitectura:

• Separación de arquitecturas para entornos productivos y no productivos
• El uso de Infraestructura como código para crear entornos volátiles, por proyectos, por unidad de negocio, etc.
• Implementación de CI / CD para automatizar la creación, gestión y despliegue tanto de Infraestructura como de microservicios.

Arquitectura del entorno productivo

• Esta arquitectura se basa en el uso de tres zonas de disponibilidad (AZ), además, las instancias Bajo demanda se utilizan para los trabajadores de AWS EKS y el uso de instancias reservadas para la base de datos y la memoria caché con alta disponibilidad 24×7.

Se define la cantidad de instancias que se utilizarán para el clúster de Redis.

Diagrama productivo

Arquitectura de entorno no productivo

Considerando que los ambientes no productivos no requieren un uso 24/7, pero si es necesario que tengan al menos una arquitectura similar a la de producción, se definió una arquitectura aprobada, que permite ejecutar los diferentes componentes en alta disponibilidad y al mismo tiempo permite minimizar costes. Para ello se definió lo siguiente:

• Reducción de zonas de disponibilidad para entornos no productivos, permaneciendo en dos zonas de disponibilidad (AZ)
• Uso de instancias puntuales para minimizar los costos de los trabajadores de AWS EKS
• Configuración de encendido y apagado de recursos para su uso en horario comercial.
• Using Aurora Serverless 

Las instancias a utilizar se definen considerando que solo hay dos zonas de disponibilidad, la cantidad de instancias para entornos de No Producción es simplemente 4.

Diagrama de entornos de no producción

Infraestructura como código

Para lograr la creación de las arquitecturas de manera dinámica adicionalmente que los entornos pudieran ser volátiles en el tiempo, se definió que la infraestructura debe ser creada mediante código. Para ello, Terraform se definió como la herramienta principal para lograr este objetivo.

Como resultado de este punto se crearon 2 proyectos Terraform totalmente variables los cuales son capaces de crear las arquitecturas mostradas en el punto anterior en cuestión de minutos, cada ejecución de estos proyectos requiere el uso de un Bucket S3 para poder almacenar la estados creados por Terraform.

Además, estos proyectos se ejecutan desde Jenkins Pipelines, por lo que la creación de un nuevo entorno está completamente automatizada.

Automation and CI / CD Integration for infrastructure and micro-services 

 Implementación de microservicios en EKS

Ayudamos a la entidad financiera a desplegar los microservicios asociados a su solución empresarial en el Clúster de Kubernetes (AWS EKS), para ello se realizaron varias definiciones con el fin de poder llevar a cabo el despliegue de estos microservicios de forma automatizada. forma, cumpliendo así con el proceso Complete DevOps (CI y CD).

Canal de implementación

 A Jenkins pipeline was created to automatically deploy the micro-services to the EKS cluster.

Tareas ejecutadas por la canalización:

En resumen, los pasos del pipeline:

1. Obtener código de microservicio de Bitbucket
2. Compilar código
3. Crea una nueva imagen con el paquete generado en la compilación
4. Enviar imagen a AWS ECR
5. Crear manifiestos de Kubernetes
6. Aplicar manifiestos en EKS

Refinement and definitions and standards to be used on the infrastructure 

Endurecimiento de la imagen

Para la institución y como para cualquier empresa, la seguridad es crítica, para ello, se creó una imagen exclusiva de Docker, la cual no tenía vulnerabilidades conocidas ni permitía la elevación de privilegios por parte de las aplicaciones, esta imagen se utiliza como base para microservicios, Para este proceso, el Área de Seguridad de la Institución realizó PenTest concurrente hasta que la imagen no reportó vulnerabilidades conocidas hasta entonces.

Configuraciones de AWS EKS

Para poder utilizar los clústeres EKS de manera más productiva, se realizaron configuraciones adicionales en él:

• Uso de Kyverno: Herramienta que nos permite crear diversas políticas en el clúster para llevar a cabo el cumplimiento de la seguridad y las buenas prácticas en el clúster (https://kyverno.io/)
• Instalación de Metrics Server: Este componente se instala para poder trabajar con Horizontal Pod Autoscaler en los microservicios posteriormente
• Radiografía: Se habilita el uso de rayos X en el clúster para tener un mejor seguimiento del uso de microservicios
• Escalador automático de clúster: Este componente está configurado para tener un escalado elástico y dinámico sobre el clúster.
• Malla de aplicaciones de AWS: Se lleva a cabo una prueba de concepto del servicio AWS App Mesh, utilizando algunos microservicios específicos para esta prueba.

Definición de objetos de Kubernetes

En implementación:

• Límite de uso de recursos:para evitar desbordamientos en el clúster, la primera regla que debe cumplir un microservicio es la definición del uso de recursos de memoria y CPU tanto para el inicio del Pod como para la definición de su crecimiento máximo. Los microservicios de cliente se clasificaron según su uso (Bajo, Medio, Alto) y cada categoría tiene valores predeterminados para estos parámetros.
• Uso de la sonda de preparación: Es necesario evitar la pérdida de servicio durante el despliegue de nuevas versiones de microservicios, es por eso que antes de recibir una carga en el clúster necesitan realizar una prueba del microservicio.
• Uso de Liveness Probe: Cada microservicio a desplegar debe tener configurada una prueba de vida que permita comprobar el comportamiento del microservicio

Servicios

Se definió el uso de 2 tipos de servicios de Kubernetes:

• ClusterIP: Para todos los microservicios que solo utilizan la comunicación con otros microservicios dentro del clúster y no exponen las API a clientes o usuarios externos.
• NodePort: Para ser utilizados por servicios que exponen API a clientes o usuarios externos, estos servicios se exponen posteriormente a través de un equilibrador de carga de red y API Gateway.

ConfigMap / Secretos

Los microservicios deben traer sus configuraciones personalizables en archivos secretos o de configuración de Kubernetes.

Horizontal Pod Autoscaler (HPA) 

Cada microservicio que debe implementarse en el clúster de EKS requiere el uso de HPA para definir el número mínimo y máximo de réplicas requeridas.

Los microservicios del cliente se clasificaron según su uso (Bajo, Medio, Alto) y cada categoría tiene un valor predeterminado de réplicas a utilizar.

Pruebas de carga y estrés para AWS y la infraestructura local

Uno de los grandes desafíos de este tipo de arquitectura (Híbrida) donde el backend y el core del negocio son On-Premise y las capas de Frontend y lógica están en nubes dinámicas elásticas, es definir hasta qué punto la arquitectura puede ser elástica sin afectar la Servicios locales y heredados relacionados con la solución.

Para resolver este desafío, se realizaron pruebas de carga y estrés en el entorno, simulando cargas pico de negocio y cargas normales, este, se realizó un seguimiento en las diferentes capas relacionadas con la solución completa a nivel de AWS (CloudFront, API Gateway, NLB , EKS, Redis, RDS) a nivel local de ESB, heredado, redes y enlaces.

Como resultado de las diversas pruebas realizadas, fue posible definir los límites de elasticidad mínimos y máximos en AWS, (N° Worker, N° Replicas, N° Instances, Types of Instances, entre otros), a nivel On-Premise (N° Worker, Bandwidth, etc).

 

Conclusión

Navigating the labyrinth of hybrid solutions requires more than just technical know-how; it mandates a visionary strategy, a well-defined roadmap, and a commitment to iterative validation.
Our client’s success story underscores the paramount importance of careful planning complemented by consistent execution. A roadmap, while serving as a guiding light, ensures that the course is clear, milestones are defined, and potential challenges are anticipated. But, as with all plans, it’s only as good as its execution. The client’s commitment to stick to the roadmap, while allowing flexibility for real-time adjustments, was a testament to their strategic acumen.
However, sticking to the roadmap isn’t just about meeting technical specifications or ensuring the system performs under duress. In today’s dynamic digital era, users’ interactions with applications are continually evolving. With each new feature introduced and every change in user behavior, the equilibrium of a hybrid system is tested. Our client understood that the stability of such a system doesn’t just rely on its technical backbone but also on the real-world dynamic brought in by its users.
Continuous validation became their mantra. It wasn’t enough to assess the system’s performance in isolation. Instead, they constantly gauged how new features and shifting user patterns influenced the overall health of the hybrid solution. This holistic approach ensured that they didn’t just create a robust technical solution, but a responsive and resilient ecosystem that truly understood and adapted to its users.
In essence, our client’s journey offers valuable insights: A well-charted roadmap, when paired with continuous validation, can drive hybrid solutions to unprecedented heights, accommodating both the technological and human facets of the digital landscape.