Going Serverless for Automotive Dealerships and Customers
Automotive Going Serverless for Automotive Dealerships and Customers

Mission:

The goal was to develop a new platform for automotive dealerships to find new business opportunities. In addition to the dealer side, customers needed a seamless and easy way to move vehicles from their location to a service center.

Outcome:

A new and improved system was created that automatically linked dealer inventory and found service opportunities. The system connects to several different API and data sources to aggregate more in-depth information on every vehicle processed through the system.

Impact:

Over 12 dealerships were onboarded within the first two weeks of deployment. Six months later there are over 100 dealerships operating within the BizzyCar system.

Services:

  • Custom Software Development
  • API Development
  • AWS Serverless (Lambda / Beanstalk / CloudWatch)
  • Database Architecture
  • Server Infrastructure

Why Serverless?

This application was the perfect use case for going serverless without having to invest a lot of time or money into the architecture.

 

We justified going down the route of using AWS Lambda with the following criteria: 

  • Disconnected: Most of the services were connecting to an API that the main application didn't need to connect to.
  • Lightweight: The logic inside was lightweight and didn't average more than a few seconds or processing time, even on heavy load.
  • Scalable: This was the largest area of concern, with Lambdas our resources scale as we need them to.
  • Flexible: We only needed to process data at certain intervals or times of the day, we didn't need a powerful application server running 24/7.
  • Cost: We only pay for what we use, in this case our average run time per day was less than 1 minute.

 

AWS Architecture

 

BC Serverless Architecture (2).png

 

Cloud Watch / SNS:

CloudWatch was utilized for two of the four lambdas to help fire them on a specific interval. Instead of building out a queueing mechanism like we may do with Hangfire in .NET Core, we decided to use CloudWatch events. 

 

Advantages of using CloudWatch over an application-side queue: 

  • Less technical debt and maintenance
  • If our application server went down, our queue would still be running
  • The event mechanism integrates directly as a Lambda trigger
  • Intervals can be changed without deploying new code

 

SNS (Simple Notification Service) was utilized after the  CloudWatch triggered Lambas had fired. Part of the logic inside of the CloudWatch fired Lambdas checked to make sure results were returned. If no results were found, we continued to check on an interval until they were. Once the results were identified, we sent an SNS message to a queue. On the other end of the queue were two Lambdas listening for messages, once received they knew they could begin running. 

 

Benefits of using SNS:

  • Reliably deliver messages without ties to the application itself
  • Easily scales with higher demand
  • Keeps messages private through topic-specific channels

 

Managing Configurations:

One of the more important aspects of deploying applications is how their credentials are stored. You don't want values stored in a version control repository or anywhere that unauthorized users can access them. We used Parameter Store inside of the System Manager to configure different environment variables. Every time a Lambda was fired, we passed through an environment type that told AWS what parameters to use.

 

AWS automatically injects the CLI profile for other services like SNS and S3.

 

 

Great team and very easy to work with! Highly recommend if you need flexibility of staffing up!

Ryan Maher

CEO of Bizzy Car

More Projects
Going Serverless for Automotive Dealerships and Customers Read More
Seamlessly Connecting Homeowners and Solar Installers Read More

Modsi helps companies turn ideas into realities

Book a call

Our Location

Remote, USA
We hire the best talent in the U.S.
2020 © Modsi. All rights reserved.