Launchpad

Launchpad simplify recruitment through automation and AI. Their recruitment automation and video interviewing platform helps businesses transform their candidate journey and future-proof their recruitment strategy.

The Brief

Launchpad Recruits provide a video recruitment platform which has seen a huge increase in demand due to business growth, and COVID-19 restrictions making face to face interviews impossible.

One of Launchpad’s clients (the UK Government’s HMRC department) had a quota of 10,000 new hires to meet in order to process the furloughed staff applications. At the time, scaling and reliability issues in the existing infrastructure were having a detrimental impact on existing clients and potentially affecting the reputation of the business with new, high profile clients.

Launchpad approached Steamhaus to design and build a new cloud-native platform on AWS, and migrate them away from their existing Engine Yard infrastructure, which was no longer fit for purpose. The new platform needed to be highly secure, resilient, performant, and able to scale seamlessly in line with the expected growth of the business. It also needed to include DevOps best practices (including automated CICD pipelines) to enable Launchpad to accelerate their product and feature development lifecycles.

The Solution

The solution Steamhaus architected for Launchpad is an ECS Fargate based solution, whilst also leveraging a number of other key services on AWS. 

Each application function is split into an ECS service running in high availability, with a minimum of two tasks running for each set, with step-based auto-scaling enabled on each service.

There are separate CodePipeline pipelines for each ECS service:

Build Pipelines
Each service has its own build pipeline. In this pipeline Docker images use a source stage as the Launchpad source Git repository, and the code is baked into an image using CodeBuild. Then, the output is stored in Amazon ECR. Images are scanned for vulnerabilities with Claire.

Deploy Pipelines
Each service has at least one deployment pipeline, based on the requirements of the application. Deployment to the applications can be by two methods:

Non-downtime deployment pipeline
This method leverages CodePipeline blue/green deployments to ensure zero downtime deployments. The pipeline uses the latest source image which was created in the build pipeline as a source. A Health checks page is used to validate the success of the deployment, and if it fails deployment is rolled back.

Downtime Deployment pipeline
This method leverages an AWS Step Functions state machine for a custom sequential deployment unsupported natively in CodePipeline. 

  1. Step Functions invokes a Lambda, This blocks traffic by applying an WAF rule onto the CloudFront distribution fronting the application.
  2. The second Lamba function is invoked which checks the status code and passes this stage on a 503 response
  3. An ECS Fargate one-off task is invoked which accesses the DB and performs a rails DB migrate
  4. A CodePipeline blue/green deployment is run 
  5. A final post deploy stage invokes a lambda, which removes the WAF rule blocking traffic

One-off Tasks
One of the requirements was that one-off tasks must be run on the application. As it’s not possible to access the ECS Fargate tasks (as they would on the previous platform via SSH on EC2) we have developed a solution via a step functions state machine. This method uses the latest ECS task definition to create an ECS Fargate task with a custom entrypoint into the container, which is inputted by the user at the initial phase of the state machine.

Crons are also performed using step functions state machine, with a static one off task being created which runs a single command using the latest task definition of the application, then exits. 

RDS aurora
For Application Database storage. AWS Aurora with Postgres compatibility has been used. This uses Multi-AZ for HA and read replicas for scaling of reads.

Cloudfront
We leverage AWS Cloudfront for assets to be able to be delivered to clients quickly and for its Anti-DDOS protection via AWS Shield.

The Results

Launchpad’s primary requirement for the migration to AWS infrastructure was focused on the scalability of the platform, with demand expected to grow exponentially to 10 million users in the next calendar year, and the previous platform being unable to quickly or automatically scale on demand. The new platform has tackled this challenge in several ways, with the use of Asset caching in CloudFront reducing demand on the backend platform. The platform also makes use of ECS Fargate to autoscale based on demand.

Another key requirement from the customer was fast and controlled deployments (via a little and often pattern). We have integrated application unit tests and orchestrate deployments in a controlled process using AWS StepFunctions and AWS CodePipeline. Deployments are safer with the use of CodeDeploy blue/green pattern on ECS Fargate due to its ability to automatically roll back failed deployments.