Boloro is a patented transaction authentication and mobile payment network. Their mission is to empower everyone, who owns and wants to pay by mobile phone, with access to secure financial services, improving quality of life and eliminating the hassles of cash.
Boloro had the infrastructure for their application hosted on their on-premises data center, which was causing them several issues since they were not capable of proceeding with the deploying to Production or Go Live.
Their Web Application consists of an NFT Marketplace, which as the name states, consists of a Marketplace to sell non-fungible token (NFT). Based on these issues, their urge to find a proper solution started to arise, turning them to the AWS Cloud and also to Magic Beans.
The project consisted of the migration and modernization of the whole infrastructure the previously mentioned NFT Marketplace. It was one of the customer’s main concern the possibility of having a highly-available, redundant and fault tolerant infrastructure. Based on this, Magic Bean has created the infrastructure on a Multi-Az and Multi-Region perspective.
Even though there are services which don’t support Multi-Region deployments, it was a client requirement to replicate the infrastructure on Ireland and Frankfurt regions. Due to the urge of having their Web Application Live and running due to internal matters, they required Magic Beans to implement the infrastructure in a short period of time.
Why AWS and Magic Beans?
Boloro chose Magic Beans as a partner, due to our knowledge, qualification and experience, believing we would bring added value to the project and that we are the ideal partner in their journey on the AWS Cloud.
In order to migrate the existing resources that were deployed on-premises into AWS, using AWS Native Services such as AWS Application Migration Services to migrate the Virtual Machines to EC2 Instances and AWS Database Migration Service to migrate the databases into Aurora PostgreSQL.The infrastructure takes advantages of services such as Aurora and DocumentDB as databases behind the Application. The Aurora is running on PostgreSQL as a Cluster, deployed on Multi-Az and Multi-Region, as a Global Database in order to create redundancy and high availability. As for the Document DB, it is used for the data persistency, and it’s also deployed in Multi-Az and Multi-Region.
Services such as EC2 and EBS are used for compute purposes, used for the Bastion Host, Kibana and Fluentd instances and the EKS Cluster nodes. The EKS Cluster is running on Kubernetes and it’s responsible for providing the application layer to the Marketplace, and it’s composed of eight EC2 instances with an Auto Scaling Group, which will allow the cluster to scale up to twelve instances based on the usage and load of the Web App. Alongside the Kuernetes Cluster in EKS, it was also deployed an Ingress Controller which serves as an Application Load Balancer.
The Kubernetes images that are deployed to EKS, are stored in ECR. As for the Web App assets that are shown in the marketplace, are stored in S3 Buckets as well as the static contents from the website. The Web App contents will be distributed by CloudFront Distributions in combination with AWS Certificate Manager in order to enforce the utilization of TLS and a custom domain. The CloudFront Distributions are protected by an AWS Web Application Firewall, which restricts the traffic coming in to AWS.
The encryption of the data at rest for most of the resources is done through the utilization of KMS AWS Managed Keys, with the exception of the KMS Key to the MSK Cluster. The MSK Cluster is based on Kafka and it was deployed to be a future replacement for SQS, which is currently the responsible tool for the queuing of requests to the application.
The usage of AWS Identity Centre was necessary in order to allow the access to both Magic Beans, Boloro team and a partner, since the infrastructure was deployed on an AWS Organization, it was necessary and simpler for the management of the platform. Aside from the SSO users, there was the need to use IAM in order to create IAM users for specific purposes as well as IAM roles in order to avoid having to hard code credentials. To guarantee the monitorization of the AWS platform both AWS CloudWatch and AWS CloudTrail were used.
Figure 1 - Boloro Control Tower
Finally, OpenSearch is used in order to allow the customer to ingest, secure, search, aggregate, view and analyse the data from their business activity. OpenSearch was also used alongside Kibana and Fluentd.
Figure 2 - Boloro Architecture
Based on the customer’s concerns regarding high availability, fault tolerance and security of their application, most of the services were deployed as Multi-Az and Multi-Region, and also taking advantage of a Warm Standby Disaster Recovery Strategy, it was possible to overcome most of these concerns.
Results and Benefits
Since this project consisted of a migration of a couple of resources that were deployed on-premises, there were a lot of improvements from on-premises into AWS. Taking in consideration the customer urgency and time constraints, the project was implemented in a very short period of time and complying with the respected timeline.
From the beginning, the infrastructure was designed taking into consideration big expectations for the usage of the platform from the client side, which throughout the project were possible to perform cost saving and optimizations actions. The cost saving and optimization actions were performed in order to obtain the best cost/performance infrastructure, and due to the gap of AWS knowledge, Boloro decided to delegate the management task of the AWS Infrastructure to Magic Beans’ Managed Services Team.
The Managed Services team is going to be responsible for maintaining the platform and infrastructure under control, as well as to keep the project below the defined budget, following the Cost Optimization Guidelines.
© Copyright - | magic beans | All Rights Reserved | Powered by: valkirias