INSTILAB

Why?

There are about 80,000 Alexa Skills in January 2021 and 18,826 Google Actions in December 2020. The Discovery and retention of smart speaker functions and voice applications have been challenging for smart speaker users. In a research study with 38 older adults, some participants mentioned the need to learn more about what Amazon Echo could do, and many mentioned that the lack of time, support, and desire to find essential use cases limited their Amazon Echo use. The dramatic growth of smart speaker functions and voice apps also makes it more difficult for users to memorize the keywords or commands to access the functions or applications. Therefore, most users settled to use a few voice apps and did not try new ones. Recent studies showed that the usage of smart speakers in people with disabilities and older adults is different than that of able-bodied individuals. For example, older adults often asked for more health-related information such as nutrition, medication, and illness symptoms. People with disabilities need special functions or voice apps to assist with daily activities such as recognizing an object for people with visual impairments. Although users may receive suggestions of new functions or voice apps from emails or mobile applications, these suggestions are mostly based on the usage data collected and reviewed from able-bodied individuals, and may not fit the needs of people with disabilities. With the smart speakers becoming increasingly prevalent, helping people with disabilities to discover functions or voice apps that might be useful to support their needs is increasingly important.

Project Description (What?)

The INSTILAB (Inclusive Smart Technology and Innovation Lab) web application that acts as a voice assistance hub for smart speakers that aims to engage people with disabilities, their families or caregivers, and professionals who will suggest, test, and review the functions and voice apps of smart speakers to determine if they are appropriate and useful to support the everyday living of people with disabilities.

How?

AWS Architecture

Explanation

The web application is a three-tier application consisting of the Frontend Website, Backend Server and Database. The web application was developed using the Python Django Framework and the Database is MySQL.

Networking Infrastructure

A new VPC (Virtual Private Cloud) was created with three subnets: * 1). 2 public subnets for DMZ (this was used to deploy the resources running on the network boundary like AWS Elastic Loadbalancers, WAF) * 2). 2 private subnets for deploying the web servers * 3). 2 private subnets for deploying the database servers

Domain Name:

The domain was purchased and registered using Route 53 A wildcard SSL certificate was created using AWS Certificate Manager

Reverse Proxy

Nginx was used as a proxy to intercept the requests based on hostname and route them to the respective web application servers. Ex: requests to instilab.org would route to the Django application running on port 3000, and the requests to api.instilab.org would route to the API server The proxy was installed on the web servers but can be installed on a separate EC2 instance

Backend Web Servers

• 1). The web servers were run on EC2 instances
• 2). T4g instances powered by Arm-based AWS Graviton2 processors were chosen for their higher performance, number of cores, and lower cost when compared to the previous generation AWS Nitro based instances
• 3). The t4g medium instance size was used as it satisfies the requirements for running Django Framework

Database Servers

An RDS database MySQL instance was used, the general-purpose with burstable support T4g was used a the instance will need a baseline performance but occasionally need a burst to handle increased traffic

Load balancers

• 1). The AWS Application Load Balancer was used to balance the load between the multiple web servers
• 2). A target group consisting of the web servers was created along with health check URLs
• 3). HTTP and HTTPS listeners were configured; HTTP was redirected to HTTPS
• 4). Web Application Firewall was attached to the load balancer to protect our application from common web exploits

DNS (Domain Naming System)

• 1). Route 53 was used as the DNS system
• 2). An alias record was created to point to the load balancer DNS name
• 3). A simple routing policy was used
• 4). A cname record for the certificate entry was also added to verify the domain ownership to the AWS Certificate manager

Security Groups

• 1). The security groups for the load balancers, web servers, and database servers were configured to only allow traffic from the tier above it. Ex: load balancer —> web server —> database
• 2). The security groups of the load balancer only allow HTTP on port 80 and HTTPS on port 443
• 3). The security groups of the EC2 webservers only allow HTTP on port 80
• 4). The security groups of the database servers only allow inbound on the database port, which was changed to a different port instead of using the default port for Mysql 3306

CI/CD (Continuous Integration/Continuous Deployment)

Prerequisites

• 1). A private Github repo was configured as the project repo
• 2). A private S3 bucket for build artifacts was created to store the code artifacts
• 3). A GitHub deploy bot user was created in IAM with S3 write, S3 read on the build artifacts bucket
• 4). A base AMI for the project
• 5). An EC2 instance launch template with the required instance configuration like size, memory, libraries to install, install system manage agent, define the base AMI to use, etc.

Steps:

• 1). User pushes code to Github repo
• 2). Github action gets triggered for code vulnerability scanning using Sonar Cube and other security tools
• 3). Automated tests are run on the code
• 4). If the above two steps are passed then Github actions will create a build artifact and publish it to the S3 build artifacts bucket
• 5). A lambda function can be invoked, this invokes a step function sequence or we can also use the SSM (AWS Systems Manager) automation to alter the capacity of the autoscaling group by doing a scale-up by two followed by a scale down by two. This will make ASG remove the older instances and only keep the new instances. We could also perform Blue-Green deployments by creating a similar infrastructure and using weighted routing in Route53 to gradually route traffic to the new load balancer.
• 6). For performing mutable deployments, the SSM automation can be used to manage the instance fleet and pull the latest build artifact, stop the existing server, and run the server with the new code, as instances are in private subnets for them to access the S3 artifacts the free S3 Gateway endpoint can be used instead of the NAT gateways which have a charge. For private instances the SSM VPC endpoints should be configured for instances to access register with SSM or the NAT gateway should be created in one of the private subnets with a route to the internet
• 7). Logging was enabled for private EC2 instances by enabling VPC endpoints for Cloudwatch

Screenshots