How Cloud SQL freed Arcules to keep building

Editor’s note: Arcules, a Canon Company, delivers the next generation of cloud-based video monitoring, access control, and video analytics–all in one unified, intuitive platform. Here, we look at how they turned to Google Cloud SQL’s fully managed services so they could focus more of their engineers’ time on improving their architecture.

As the leading provider of unified, intelligent security-as-a-service solutions, Arcules understands the power of cloud architecture. We help security leaders in retail, hospitality, financial and professional services use their IP cameras and access control devices from a single, unified platform in the cloud. Here, they can gather actionable insights from video analytics to help enable better decision-making. Since Arcules is built on an open platform model, organizations can use any of their existing cameras with our system; they aren’t locked into particular brands, ensuring a more scalable and flexible solution for growing businesses.

As a relatively young organization, we were born on Google Cloud, where the support of open-source tools like MySQL allowed us to bootstrap very quickly. We used MySQL heavily at the time of our launch, though we’ve eventually migrated most of our data over to PostgreSQL, which works better for us from the perspective of both security and data segregation.

Our data backbone

Google Cloud SQL, the fully managed relational database service, plays a significant role in our architecture. For Arcules, convenience was the biggest factor in choosing Cloud SQL. With Google Cloud’s managed services taking care of tasks like patch management, they’re out of sight, out of mind. If we were handling it all ourselves by deploying it on Google Kubernetes Engine (GKE), for example, we’d have to manage the updates, migrations, and more. Instead of patching databases, our engineers can spend time to improve performance of our codes or features of our products or automated our infrastructure in other areas to maintain and adopt an immutable infrastructure. Because we have an immutable infrastructure involving a lot of automation, it’s important that we stay on top of keeping everything clean and reproducible.

Our setup includes containerized microservices on Google Kubernetes Engine (GKE), connecting to the data through Cloud SQL Proxy sidecars. Our services are all highly available, and we use multi-region databases. Nearly everything else is fully automated from a backup and deployment perspective, so all of the microservices handle the databases directly. All five of our teams work directly with Cloud SQL, with four of them building services, and one providing ancillary support.

Our data analytics platform (covering many centuries of video data) was born on PostgreSQL, and we have two main types of analytics–one for measuring overall people traffic in a location and one for heat maps in a location. Because our technology is so geographically relevant, we use the PostGIS plugin for PostgreSQL in intersections, so we can re-regress over the data. In heat mapping, we generate a colorized map over a configurable time period–such as one hour or 30 days–using data that displays where security cameras have detected people. This allows a customer to see, for example, a summary of a building’s main traffic and congestion points during that time window. This is an aggregation query that we run on demand or periodically, whichever happens first. That can be in response to a query to the database, or it can also be calculated as a summary of aggregated data over a set period of time.