Introduction
For the past few weeks, I've been developing "SecureVote" - a cloud infrastructure project for a secure online voting platform that organizations can use for internal elections, board votes, and member surveys. This project has been particularly relevant for my career goals in Qatar, where many organizations require secure, auditable voting systems that comply with data regulations.
What started as a traditional infrastructure implementation has evolved into a serverless architecture journey - one that has taught me valuable lessons about modern cloud design principles and cost optimization techniques.
The Initial Vision
SecureVote was conceptualized with four primary requirements:
High Availability: Voting periods have fixed timeframes and cannot tolerate downtime
Security: Votes must remain confidential and protected from tampering
Scalability: The system must handle voting traffic spikes efficiently
Compliance: A complete audit trail must be maintained for verification
My initial implementation focused on traditional infrastructure patterns:
VPC networks with custom subnets for isolation
VM-based compute resources
Network firewall rules for security
IAM roles for access control
The Pivot to Serverless
After deploying the initial infrastructure using Terraform, I had a realization. Managing VM instances and the associated infrastructure would require ongoing maintenance and potentially higher costs - especially during periods of inactivity between voting events.
That's when I decided to pivot to a serverless architecture. With guidance from Claude, I developed a plan to transform SecureVote into a modern cloud-native application that would:
Reduce operational overhead
Lower costs through pay-per-use billing
Improve security by reducing the attack surface
Scale automatically based on demand
Technical Evolution
Infrastructure as Code Foundation
The project uses Terraform to define all infrastructure components, allowing for consistent deployment and version control. The repository structure evolved from focusing on networks and firewalls to encompassing serverless components:
securevote-gcp-iac/
├── terraform/
│ ├── backend.tf # GCS backend configuration
│ ├── variables.tf # Input variables
│ ├── main.tf # Provider and API configuration
│ ├── service_accounts.tf # Service account definitions
│ ├── networks.tf # VPC and subnet definitions
│ ├── firewalls.tf # Firewall rules
│ ├── storage.tf # Frontend static hosting
│ ├── cloud_run.tf # Backend API services
│ ├── database.tf # Cloud SQL configurations
│ ├── iam.tf # IAM roles and bindings
│ └── outputs.tf # Output values
└── README.md
From Network Security to Service-Based Security
My initial approach to security focused heavily on network controls:
hcl# SSH access firewall rule
resource "google_compute_firewall" "vpc_dev_allow_ssh" {
project = var.project_id
name = "vpc-dev-allow-ssh"
network = google_compute_network.vpc_dev.name
allow {
protocol = "tcp"
ports = ["22"] # SSH port
}
source_ranges = ["0.0.0.0/0"]
description = "Allow SSH access to resources"
}
This was a traditional approach where I was securing VM instances through IP filtering. However, with the serverless architecture, the security model shifted to service-based identity and authorization:
hcl# IAM binding for cloud run production service with restricted access
resource "google_cloud_run_service_iam_binding" "api_prod_auth" {
location = google_cloud_run_service.api_prod.location
service = google_cloud_run_service.api_prod.name
role = "roles/run.invoker"
members = [
"serviceAccount:${google_service_account.cloud_run_service_account.email}"
]
}
Each component underwent a transformation:
Frontend: From potential VM-hosted web servers to Cloud Storage static website hosting
Backend: From Compute Engine VMs to fully managed Cloud Run services
Database: Remained as Cloud SQL but with serverless connectivity
Networking: Added VPC Service Connectors to bridge serverless services with VPC resources
Benefits of the Serverless Approach
Cost Optimization
The serverless model dramatically changed the cost profile of the project. Instead of paying for 24/7 VM instances, the new architecture only incurs costs when the system is actually processing votes. For an election system that might only be used periodically, this difference is substantial.
Initial estimates suggest that with careful resource management, the entire development and testing phase could cost less than $20, and potentially even run within GCP's free tier limits.
Reduced Operational Burden
With serverless components, there's no need to:
Google Cloud manages these aspects automatically, allowing me to focus on application logic rather than infrastructure maintenance.
Improved Security Posture
Removing SSH access and publicly accessible VMs significantly reduced the attack surface. The serverless architecture leverages Google Cloud's identity-aware security controls and private networking features to ensure that only authorized services can communicate with each other.
Why This Matters for Qatar's Tech Landscape
Projects like SecureVote are particularly valuable in Qatar's context for several reasons:
Digital Transformation: Qatar's National Vision 2030 emphasizes technological advancement, and organizations are seeking modern cloud solutions.
Security Requirements: Financial institutions, government agencies, and corporations in Qatar have stringent security requirements that cloud-native architectures can address effectively.
Cost Efficiency: As businesses optimize operations, the pay-per-use model of serverless is increasingly attractive.
Technical Skill Development: Building expertise in serverless architecture positions IT professionals for the evolving job market in Qatar.
Learning Outcomes
This project has been invaluable for my professional development:
Practical IaC Experience: Gained hands-on experience with Terraform for managing cloud infrastructure.
Architectural Decision-Making: Learned to evaluate traditional vs. serverless approaches based on requirements.
Security-First Design: Implemented defense-in-depth through multiple security layers.
Cost Management: Developed strategies for controlling cloud costs without sacrificing functionality.
Modern DevOps Practices: Applied CI/CD concepts through version-controlled infrastructure.
Next Steps
As I continue to refine SecureVote, my focus will be on:
Implementing a CI/CD pipeline for infrastructure deployment
Adding application-level components like Firebase Authentication
Creating developer documentation and operational runbooks
Setting up monitoring and alerting for the serverless components
Conclusion
The journey from traditional to serverless architecture for SecureVote has been enlightening. It's demonstrated that modern cloud platforms enable powerful, secure systems without the operational overhead traditionally associated with such projects.
For anyone building a portfolio for cloud engineering roles, I highly recommend including serverless projects that showcase these principles. They not only demonstrate technical competency but also an understanding of business considerations like cost optimization and operational efficiency - qualities highly valued by employers in Qatar's growing tech sector.
The SecureVote project remains open-source, and I welcome collaboration from the community as I continue to expand its capabilities.
This project is available on GitHub under the MIT license. The infrastructure design and code are provided for educational purposes.
