Canopy aims to make it cheaper, faster, and easier to rent a home. Canopy’s Rent Passport can be shared with letting managers or landlords before a move, eliminating the need for a deposit. Canopy wants to change the typically painful process that renters have to go through to rent a home, specifically with the deposit-free policies that they offer.

The Brief

Canopy had an existing ECS platform on AWS for the first version of their application. They were at a point of scaling up the business, and knew they needed the implementation of CI/CD, as well as scaling the platform for anticipated growth and demand—along with version 2 of the application itself. 

There was no redundancy in the platform—it was a single EC2 host, meaning that any issues could result in major outages. This isn’t viable for a platform that needs to be able to scale. 

A security audit discovered further issues that needed to be addressed. Sensitive data needs to be handled in a very specific, secure way, and this needed to be the case before Canopy secured investment. 

The Solution

We began by moving from ECS on a single EC2 instance to ECS Fargate. This makes the platform entirely scalable as it doesn’t rely on a single host—Fargate removes the need to provision and manage servers, lets you specify and pay for resources per application, and improves security through application isolation by design.

We implemented a new deployment pipeline with AWS Code* which helps automate release pipelines for fast and reliable application and infrastructure updates. 

Finally, we moved Canopy from RDS on to Aurora with autoscaling, further allowing them to scale based on demand. Aurora delivers up to 5X the throughput of standard MySQL running on the same hardware, and enables existing MySQL applications and tools to run without requiring modification. Its high availability and scalability made it an obvious choice for Canopy. 

We created a centralised API for Canopy using AWS API Gateway, which was necessary in order for Canopy to have integration with third-party companies. We created the API Gateway resources by using Terraform (with the AWS provider), along with an OpenAPI template file to provision the specification of the API—this provided an example health check to their backend system. Canopy wanted to use API Gateway as a means of replacing their current setup with Service Gateway, hosted outside of AWS from their legacy platform.

We orchestrated a CodePipeline pipeline which allows Canopy developers to update the API template without having to run Terraform themselves. Developers from Canopy simply need to make the required changes to the template file and push this to the git repository. The pipeline is then triggered and updates the API specification accordingly. The process exists for both their staging API and their production API.

We also allowed the use of API keys to be distributed and controlled by Terraform. We gave Canopy developers the required documentation and training in order to create an API Key resource and distribute this to their teams. The running of Terraform is again handled by Terraform. 

The platform was built from the ground up with infrastructure as code. Changes are recorded in version control which eases rollback and allows for easier collaborative working. Once the initial environment is deployed it is much easier to duplicate additional similar (or identical) environments. IaC results in much better consistency—we can prevent drift between environments we expect to be the same, and ensure environments are maintained in the state we expect.

The Results

The previous solution was a disparate set of manually provisioned and configured infrastructure, resulting in cost control issues and technical debt. The new solution is entirely orchestrated, resulting in stricter controls. This has reduced Canopy’s infrastructure costs by a factor of 5x. The new solution has moved Canopy away from managing compute infrastructure and onto AWS Fargate—this has removed the toll associated with managing compute infrastructure. 

Deployments on the old solution were manual, which was time-consuming and error-prone. Deployments and rollback are now automated using a blue/green continuous delivery pipeline. This has reduced Canopy’s deployment time from 4 hours to around 5 minutes. 

Canopy are now on a platform that can fully scale—as the traffic increases the platform will expand, helping to achieve  100% uptime. It is also more efficient, as moving to a serverless architecture allows for reduction in costs; they only pay for what they use. We now have a record of all infrastructure changes stored in infrastructure code, stored in version control. All changes follow a review process reducing the risk of change or rollback operation. 

Code* integration means that they can deploy much faster, with automated continuous delivery pipelines. VPC and API Gateway are used for security, resulting in a fully CIS compliant and safe environment. 

Moving to an infrastructure as code solution resulted in various benefits. Not only does the platform have much faster speed and consistency, but changes are recorded in version control which eases rollback and allows for easier collaborative working. It is also much easier to duplicate additional similar (or identical) environments once a single environment is deployed. We can also prevent drift between environments we expect to be the same, and ensure environments are maintained in the state we expect.