Prototyping Cloud Architecture for Estate Security System
Prototyping Cloud Architecture for Estate Security System
Prototyping Cloud Architecture for Estate Security System
tl;dr:
A decoupled cloud architecture using containerized Flask microservices, cloud storage and serverless functions with pub/sub..
Introduction
I was curious about how microservices affect system architecture, so I decided to build one out to learn more. I chose to build a automated license plate detection and logging system (ALPS) for a speculative security start-up called “Sentry”.
The goal was to design and implement an architectural design that maps to a business's growth trajectory. It had to strike a balance between cost efficiency and scalability, providing a solution that remains flexible through various stages of growth.
Implementation
The system is implemented using a hybrid cloud architecture that combines serverless computing with containerised microservices.
CCTV still-frames are uploaded to a scalable cloud storage solution, which then initiates a serverless function. This function communicates with a separate containerised microservice, running a OOTB computer vision model, and processes the image, outputting a JSON that includes vehicle count, color, and license plate data.
In this system architecture, event-driven processing and business logic are separated. The event triggers are handled by serverless functions, while the complex business logic is encapsulated within a containerised microservice exposing RESTful API endpoints, developed using Flask and Python.
The decoupling of event triggers and business logic is enable greater flexibility and scalability for the business. This architecture can efficiently handle spiky workloads and scale on demand. Utilising containers for the business logic further increases this flexibility and also portability, allowing for a more straightforward migration to another platform if required.
For example, consider an early stage business just stepping into the competitive market:
At this early stage of growth, the top priority is value creation for the customer. This usually means agility and rapid deployment as the company iterates and learns. Here, containerisation enables fast and seamless deployments.
In the business’s later stages of growth, the focus gradually shifts from agility to resource optimisation. At this juncture, the architectural choice allows for an efficient migration to more cost-effective infrastructure or self-managed solutions, with minimal disruption.
Lastly, businesses can fine-tune their approach to the cost-efficiency versus scalability equation without a major overhaul because of the decoupling.
The current implementation was done on GCP.
Final Thoughts
Wrapping up this project, I have to say: this was a fun one. The project gave me an opportunity to dive into several cloud technologies, pushing me to fine-tune my critical thinking and get my beak wet in the process.
Looking forward, there are quite a few updates that can be considered.
The license plate detection model, at present, is a straightforward API call to Google Vision. This could turn into an exciting project on its own. It's entirely possible to fine-tune a local vision model, perhaps utilising architectures like ResNet or VGG, and applying YOLO (You Only Look Once) principles for object detection. This could result in a more tailored, optimised solution for license plate detection that could seamlessly integrate with our existing infrastructure.
Finally, there's always room to enhance the CI/CD pipeline, specifically with a more robust tests related to business-value. For instance, imagine a situation where a driver alters their license plate to mimic a resident's plate. By designing a test scenario to account for this specific use-case, we can build safeguards that would recognise and flag such anomalies, enhancing the business value of the system.
But for now, that’s it. Thanks for reading this far. As always, feel free to reach out. I’m usually up for a chat.
________________________
Links
Introduction
I was curious about how microservices affect system architecture, so I decided to build one out to learn more. I chose to build a automated license plate detection and logging system (ALPS) for a speculative security start-up called “Sentry”.
The goal was to design and implement an architectural design that maps to a business's growth trajectory. It had to strike a balance between cost efficiency and scalability, providing a solution that remains flexible through various stages of growth.
Implementation
The system is implemented using a hybrid cloud architecture that combines serverless computing with containerised microservices.
CCTV still-frames are uploaded to a scalable cloud storage solution, which then initiates a serverless function. This function communicates with a separate containerised microservice, running a OOTB computer vision model, and processes the image, outputting a JSON that includes vehicle count, color, and license plate data.
In this system architecture, event-driven processing and business logic are separated. The event triggers are handled by serverless functions, while the complex business logic is encapsulated within a containerised microservice exposing RESTful API endpoints, developed using Flask and Python.
The decoupling of event triggers and business logic is enable greater flexibility and scalability for the business. This architecture can efficiently handle spiky workloads and scale on demand. Utilising containers for the business logic further increases this flexibility and also portability, allowing for a more straightforward migration to another platform if required.
For example, consider an early stage business just stepping into the competitive market:
At this early stage of growth, the top priority is value creation for the customer. This usually means agility and rapid deployment as the company iterates and learns. Here, containerisation enables fast and seamless deployments.
In the business’s later stages of growth, the focus gradually shifts from agility to resource optimisation. At this juncture, the architectural choice allows for an efficient migration to more cost-effective infrastructure or self-managed solutions, with minimal disruption.
Lastly, businesses can fine-tune their approach to the cost-efficiency versus scalability equation without a major overhaul because of the decoupling.
The current implementation was done on GCP.
Final Thoughts
Wrapping up this project, I have to say: this was a fun one. The project gave me an opportunity to dive into several cloud technologies, pushing me to fine-tune my critical thinking and get my beak wet in the process.
Looking forward, there are quite a few updates that can be considered.
The license plate detection model, at present, is a straightforward API call to Google Vision. This could turn into an exciting project on its own. It's entirely possible to fine-tune a local vision model, perhaps utilising architectures like ResNet or VGG, and applying YOLO (You Only Look Once) principles for object detection. This could result in a more tailored, optimised solution for license plate detection that could seamlessly integrate with our existing infrastructure.
Finally, there's always room to enhance the CI/CD pipeline, specifically with a more robust tests related to business-value. For instance, imagine a situation where a driver alters their license plate to mimic a resident's plate. By designing a test scenario to account for this specific use-case, we can build safeguards that would recognise and flag such anomalies, enhancing the business value of the system.
But for now, that’s it. Thanks for reading this far. As always, feel free to reach out. I’m usually up for a chat.
________________________
Links