Handbook

Infrastructure

The rest of mx51’s product that doesn’t run inside a merchant’s shop runs on a public cloud. The cloud side of the mx51 product is sometimes referred to by the narrower meaning of MSP.

The infrastructure layer provides capability for the needs of the application layer, such as hosting, deploying and scaling applications, databases, file systems, messaging services etc. The application layer implements most of the business logic.

The product infrastructure is written as code (Infrastructure as Code / IaC) using Terraform. This makes the standing up of new tenancies and maintenance of existing ones more robust and cost effective. Currently, a tenant’s cloud infrastructure can be deployed to AWS, but portability is a consideration.

For each tenancy, up to two cloud accounts are created, whose access is segregated:

  • Main account, where the bulk of components and applications run
  • CDE (Cardholder Data Environment) account – for hosting components that see PCI card data. Not all tenants will have this module turned on

In each tenant cloud account, for each environment there is a VPC (Virtual Private Cloud) set up to segregate the network.

A Kubernetes cluster is deployed in each VPC using EKS on EC2 nodes. Application developers deploy microservices as Docker containers to the Kubernetes cluster.

  • For relational databases, PostgreSQL is deployed using RDS
  • For volatile in-memory caching, Redis is used using Elasticache
  • For Cloud Storage, S3 is used
  • For Queues, SQS is leveraged
  • For SFTP servers, AWS Transfer is leveraged
  • SES is used for sending emails, and Twilio for outbound SMS
  • For secrets management, KMS is used
  • For asset web servers, such as for the front-ends, S3 is used

Portability

Total cloud portability at the push of a button is very rarely feasible. AWS is the preferred cloud vendor for mx51 tenancies, and unless a tenant has a strong preference otherwise, the tenancy will be deployed out-of-the-box to AWS.

However, technical design decisions are made with portability in mind, and if a future tenant did require the tenancy to be run on a different cloud vendor, such as Azure or GCP, there would still be a path to achieve this with known project based effort and without the need to re-architect the platform.

Here are some case-in-point technical choices:

  • Kubernetes
  • Terraform
  • PostgreSQL
  • Various application-level abstractions for peripheral capabilities such as queues and disk that would allow the development of adapter components that can be easily switched without changing application business logic

Support

For the few cross-tenant product components, the infrastructure team maintains a separate cloud account. Similarly, a separate cloud account is used to host supporting infrastructure operations tools such as for observability and CI/CD.