The benefits are clear: less cost, agile nature of Cloud solutions, more straightforward maintenance than traditional data centres, global availability, and to cope with the highly dynamic nature of the industry.

Financial services companies are rapidly heading into the Cloud as an alternative to housing everything on-site. However, making this strategic shift requires working through the complexities of the Cloud environment. To take full advantage of this new paradigm, companies need to build effective distributed applications (software solutions that improve the speed, security, and operability of applications) in the Cloud.

As a cloud-based SaaS solution provider, 2C2P uses Amazon Web Services (AWS) to host our solutions. In this article, we will show how 2C2P’s EMV ACS (Europay, MasterCard, and Visa, Access Control Server) solution architecture helps to overcome the challenges of distributed scalable services.

Scalable Infrastructures

Achieving true elasticity requires the orchestration of multiple components within the data centre or Cloud. Infrastructures are an essential part of solutions architecture as it determines the baseline for solutions.

The first step is a comprehensive infrastructure that includes load balancing, DNS (Domain Name System) routing services, container orchestration, and configuration storage.

In this section, we will explain our choices of AWS services for the EMV ACS (Access Control Server) solution.

Load Balancers

Load Balancer (LB) is a system component that faces incoming traffic and efficiently distributes requests between application services behind it.

LB also optimises the response time and prevents the overloading of servers when other servers are idle. This ensures the high availability and reliability of the overall processing system by automatically scaling to the vast majority of workloads.

AWS provides several LB services, and each of them is used for differing cases:

• Application Load Balancer (ALB) is the most advanced LB service from AWS that works on Layer 7 (Application layer of OSI or Open Systems Interconnection model) and supports HTTP-based routing. This includes routing based on URL path and HTTP headers. It is also easily integrated with Container Orchestration services from AWS, like ECS/EKS (Elastic Container Service/Elastic Kubernetes Service).
  
• Network Load Balancer is a high-performance load balancer for extreme loads and handles millions of requests per second. However, it works only on Layer 4 (Transport layer of OSI model), which means that some sophisticated features are not supported.
  
• Elastic Load Balancer is a traditional load balancer well integrated with EC2 (Amazon Elastic Compute Cloud) to distribute traffic between virtual server instances. However, it is considered to be an obsolete service and is not well-integrated with new services.
  

ALB distributes traffic between application services in EKS and performs health checks.

It was critical for 2C2P to have path-based routing for our ACS solutions to ensure HTTPS offload in the load balancer and integration with container orchestration service. As a result, we decided to select ALB for our solution.

DNS (Route 53)

Route 53 routes clients to the ALB in the closest region to minimise latency based on geolocation.

Route 53 is an advanced Amazon DNS service that routes traffic based on the user’s geolocation, the system’s health, and the latency of responses. To put it simply, it provides an IP address or alias domain for the corresponding field in the URL.

It has been designed to give developers and businesses a reliable and cost-efficient solution to manage how end-users are routed to the desired application’s endpoints.

Route 53 is used as our DNS service for our ACS solution, which helps with disaster recovery. If the entire region of AWS becomes unavailable, Route 53 will redirect loads to another designated area to ensure business continuity. For instance, it will direct clients to the Japan load balancer if the Singapore region becomes unavailable.

Container Orchestration (ECS/EKS)

Amazon Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS) are two popular container orchestration services from AWS that manage units of an application service, which are packed into single Docker containers. These services monitor the health of components, auto-failovers, auto-recoveries, auto-scaling, and deployment of updates.

As a result, they are faster, more portable, use less memory than virtual machines, and are crucial in contributing to the success of a Cloud environment.

We initially started with the more straightforward use of the ECS service for our ACS solution. However, it has lower customisation possibilities and functions slower than the EKS. As our business scaled, we switched over to EKS seamlessly and efficiently.

Configuration Storage (Secrets Manager)

Configuration Storage is a system used as a centralised store for the configuration of services. For a scalable system, it is critical to manage configuration from a single point, as it would be difficult to log in to each server and update it manually.

In addition, Secrets Manager helps to protect secrets needed to access a business’ static secret data, such as database credentials and proxy credentials. It helps your business meet security and compliance requirements by encrypting secrets with encryption keys and enabling safe rotation without code deployments.

Logging/Monitoring (CloudWatch/Elasticsearch+Kibana)

Monitoring and logging storage is critical to maintain and analyse distributed applications. There are a multitude of solutions for logging and monitoring. For our ACS solutions, we use CloudWatch as the default long-term logging storage. It is well-integrated with other AWS services and used by default for ECS services, whereby all application default output is automatically published to CloudWatch.

We also send recent data to the ElasticSearch cluster, which provides convenient search and filtering. This allows us to visualise live transactions data with Kibana and monitor issues and data through different application instances via a single dashboard.

. . .

That’s it for now! Stay tuned for part 2 of this article where we explain more about the typical issues encountered when building scalable application services.


Interested in 2C2P’s payment services? Drop a note to our friendly team here.