Hey, my name is Santhosh Nimmala, and I work as a Principal Consultant at Luxoft, leading Cloud and DevOps in the TRM space. In this series of articles, I will be discussing about various solutions for FSI usecases. In this article, we will delve into Migrating Banks Good old Monolith Architecture to Container-Based Microservices
Technology has a long-term relevance to business processes, customer delivery and maintaining data security in the banking industry. Many banks have been using "monolith" architectures for their applications for years. However, there seems to be a big shift in adopting "microservice" to modernize banking operations Let's take a look at what these terms mean and why the shift to microservices is becoming more popular.
Monolithic architecture is a Prefred approach to software development where the entire application is packaged as one sophisticated cohesive unit In banking, the term "tight integration" refers to integrating all components and components of a banking application into a single code base
Banks uses Monoliths over other for certain reasons :
1) Stability: Monoliths are well known for stability, for example, if you make modifications in one source code, this change may not affect other components often
2) Simplicity: All functionalities will be codified in the single code base, it would be easy to maintain a single repository rather than multiple.
3) Security: A centralized security paradigm can be provided by monoliths.
It is simpler to build and maintain because there is only one codebase.
Generally speaking, it is stable and less prone to issues.
It might be easier to manage a centralised security architecture.
Growth is constrained by the difficulty of horizontal scaling.
Less able to adjust to shifting demands or technologies.
Changes require cooperation and can take a while to implement.
Contrarily, a microservices architecture is a technique for segmenting an application into smaller, loosely coupled services, each of which is in charge of a certain business functionality. This implies that account administration, transactions, and customer support are created as separate, independent microservices in the context of banking.
Modern banking must quickly adapt to changing customer needs and developing technologies, among other dynamic issues. In this situation, microservices provide a number of benefits:
Banks can swiftly adjust to new technologies and shifting customer needs thanks to microservices.
Since each microservice may be scaled independently, resources can be allocated more effectively.
Development teams can work simultaneously on many microservices, accelerating the creation and updating of new features.
Issues in one microservice do not always affect others, increasing system resilience.
Makes it easier to adjust to changes and incorporate new technology.
efficient resources scaling for increased performance.
Individual services can be developed and deployed more quickly.
Issues that are isolated have a lower impact on the overall system.
Managing several services might be difficult.
Effective growth necessitates collaboration across several teams.
Microservices may necessitate additional infrastructure and operational costs.
let's see if that is the case how to Migrate and what services in AWS can help you to host a microservice-based application
This solution modernizes the bank's core systems. It uses a microservices architecture to rebuild previous applications, and it orchestrates containerized applications by using Amazon Elastic Kubernetes Service (Amazon EKS). Amazon DynamoDB tables are used as the persistence layer to store data for the different applications.
customers can access bank applications using mobiles, and desktops..etc
The bank applications are made available to customers through an internet gateway. An internet gateway is a horizontally scaled, redundant, and highly available virtual private cloud (VPC) component that allows communication between your VPC and the internet.
When a Kubernetes ingress is created, providing HTTP and HTTPS routes from outside a cluster to services within the cluster, an Application Load Balancer is also provisioned. Traffic routing is controlled by rules defined on the Ingress resource.
The Application Load Balancer distributes incoming traffic at the application layer (layer 7) across multiple targets, such as applications running on a Kubernetes cluster. After the load balancer receives a request, it evaluates the listener rules and directs traffic to the target microservices-based applications.
With a microservices architecture, an application is built as independent components that run each
application process as a service. Services are built for business capabilities, and each service performs a single function.
Developers may deploy their programmes and package them effectively using containers. Containers are small and portable software environments that enable applications to scale and run anywhere.
Container orchestration is carried out using Amazon Elastic Kubernetes Service (Amazon EKS), which aids in maintaining containers in the proper state. Service-level agreements (SLAs) are also maintained with the use of orchestration.
Kubernetes may be run on AWS and in on-premises data centers with the support of Amazon EKS, a fully managed solution. The Kubernetes control plane nodes in the cloud that are in charge of scheduling containers, managing application availability, storing cluster data, and other crucial functions are automatically managed by Amazon EKS for availability and scalability.
The application code, libraries, and any other dependencies are packaged by developers into a container image. The Amazon Elastic Container Registry (Amazon ECR) repository is where the container image is pushed.
A safe, scalable, and dependable container image registry service is Amazon ECR. This technique deploys the containerized application on the Amazon EKS cluster using a container image.
Amazon EKS helps pull and then run the container image, stored in Amazon ECR, to deploy applications in the Amazon EKS cluster. Microservices-based applications reside in containers and are managed by Amazon EKS.
The Application Load Balancer ingress service uses path-based routing to direct customer requests to different applications. For example, if the URL path includes /deposit at the end, requests are routed to the deposit application.
Persistent storage for the apps in this approach is provided by Amazon DynamoDB tables. A serverless, fully managed, key-value NoSQL database called DynamoDB is made to support high-performance software at any size.
While microservices are highly scalable, scalable, and quick to build, it is important to understand that they are not a universally effective answer for all applications It is important to choose a microservice framework after carefully reviewing business requirements only. For some applications, especially those with straightforward or limited access, a monolithic or hybrid architecture may be preferable to a microservice architecture Consider application size, complexity, scalability needs and organizational scalability and processing capabilities when determining whether microservices are a good fit Conclusion Microservices are a powerful tool, but their How well they align with a specific need will determine how effective they are.
Despite the historical success of unified solutions for banks, the drive to microservices stems from the need to be faster, more flexible and adaptable to changing market dynamics and customers in the face of expectations. Given the rapid advances in technology, banks need to scrutinize the architecture that best aligns with their long-term goals and vision for customers.