# Samson Gama — full content
> Root index: https://samsongama.com/llms.txt
Samson Gama — SRE, DevOps engineer, and cloud architect. Writing on infrastructure, automation, observability, and cloud-native systems.
Generated from public pages only. Internal RAG context is not included.
## About
URL: https://samsongama.com/about/
{{< figure src="/samson.webp" alt="Professional headshot photo" caption="Samson Gama - Senior SRE/Platform Engineer" class="rounded-full mx-auto" width="300" fetchpriority="high">}}
## Hi, I'm Samson 👋
I’m a Senior SRE/Platform Engineer with 8+ years of experience in distributed systems, Kubernetes, cloud infrastructure, and service reliability, including GPU infrastructure for AI/HPC workloads. I care deeply about systems that hold up under real-world pressure, and I am equally driven by the process of learning: new tools, better patterns, and clearer ways to ship dependable software.
Right now, I am actively using AI to upgrade this website itself, from content quality and structure to workflow automation and faster iteration. I treat the site as a living engineering artifact where I can test ideas, refine implementation details, and show how I work in public.
---
## 💼 What I Bring
I specialize in the operational side of software that has to work under real load. I bring a reliability-first mindset, but I also keep evolving my approach as tools and systems change.
- 📈 **Supported large-scale player-facing systems** during peak gaming events, with a focus on uptime, fault tolerance, and load readiness
- 🤖 **Built and maintained automation for deployments and monitoring** using IaC and config management to reduce manual work
- 🔐 **Led security-aware engineering work** including offensive security training, penetration testing, and incident-driven hardening
- 🧠 **Continuously upskill in modern AI workflows** and apply them directly to real projects, including this site
{{< button href="/resume" target="_self" >}}
📄 View Full Resume
{{< /button >}}
## 🎯 How I Work
**🔁 Automate Repetition**
If a workflow gets repeated, it should be encoded, observable, and recoverable.
**📊 Measure the Impact**
I care about latency, throughput, reliability, and the operational cost of a change, not just whether it looks elegant.
**🛠️ Design for Production**
Good systems survive imperfect inputs, traffic spikes, and human mistakes.
**🧪 Learn in Public**
I use this website as an active sandbox for new ideas, especially AI-assisted content, UX, and engineering workflows.
**🛡️ Security by Design**
OSCP certified. I treat security as part of the system, not a separate review step.
---
## 🛠️ Technical Expertise
| | |
| --- | --- |
| **💻 Backend & Infrastructure** | Go • Rust • Python • Kubernetes • Docker • AWS |
| **🧱 Platform & Automation** | Terraform • Ansible • GitHub Actions • Infrastructure as Code |
| **📊 Monitoring & Reliability** | Prometheus • Datadog • ELK Stack • Load Testing |
| **🤖 AI in Practice** | Prompt-driven workflows • Content/system iteration • Practical automation with LLMs |
| **🔐 Security & Testing** | OSCP • Penetration Testing • CTF Competitions |
{{< button href="/portfolio" target="_self" >}}
🎨 See My Work
{{< /button >}}
---
## 🎮 Beyond the Terminal
Outside work, I’m usually:
- ⚡ **Building electric bicycles** — hardware meets sustainability
- 📸 **Photography** — light, composition, and storytelling
- 🌲 **Exploring Vancouver** — trails, coastlines, and city energy
---
## 🤝 Let's Connect
{{< alert "star" >}}
**I’m always open to discussing production reliability, AI-assisted engineering workflows, and systems work that benefits from continuous learning.**
{{< /alert >}}
{{< button href="/contact" target="_self" >}}
✉️ Get in Touch
{{< /button >}}
{{< button href="/posts" target="_self" >}}
📝 Read My Posts
{{< /button >}}
## Resume
URL: https://samsongama.com/resume/
# Samson Gama
Senior SRE / DevOps Engineer | Kubernetes | Go | Cloud Infrastructure | OSCP
Vancouver, BC
## Summary
Senior SRE/Platform Engineer with 8+ years of experience designing, building, and operating distributed systems, Kubernetes platforms, cloud infrastructure, and high-scale production services. Experienced in reliability engineering, incident response, performance engineering, infrastructure automation, and observability, with recent experience operating GPU infrastructure for AI/HPC workloads. Strong background in Go, Kubernetes, Terraform, GitOps, and production systems at scale.
## Professional Experience
### Bitcomplete
Senior Service Reliability Engineer, GPU Infrastructure | Mar 2026 - Jun 2026
- Improved operational readiness for GPU infrastructure, establishing standardized runbooks, alerting, and incident-response workflows to improve reliability and accelerate incident resolution across AI/HPC workloads
- Designed and executed the consolidation of fragmented ArgoCD-managed GPU environments, eliminating deployment drift and standardizing NVIDIA tooling across clusters, reducing customer workload downtime
### Demonware
Senior Service Reliability Engineer | Aug 2020 - Jan 2026
- Applied SRE practices to improve reliability, scalability, and operational efficiency across production systems, establishing company-wide conf.d configuration standards and improving resource utilization
- Designed, built, and owned a distributed load-testing platform used by engineering teams company-wide to validate services against large-scale traffic spikes, using Kubernetes, Go, Redis, and distributed rate limiting
- Diagnosed and resolved complex production incidents across distributed systems during peak live traffic, developing runbooks and operational improvements that reduced repeat incidents and alert fatigue
- Partnered with product and platform engineering teams to improve service architectures through pull requests, code reviews, technical design, technology selection, RFCs, and load-testing infrastructure
- Evaluated and helped drive adoption of Vitess for MySQL workloads on Kubernetes, developing PoCs, design documents, RFCs, and migrations to reduce the overhead of maintaining MySQL clusters on VMs
- Mentored engineers and promoted service ownership and operational excellence, helping teams adopt more reliable engineering and production practices by taking pride in our work for the video game series Call of Duty
### Mastercard (Nudata Security)
Senior Software Engineer (DevOps) | Oct 2018 - Jul 2020
- Designed and developed highly available microservice infrastructure across AWS regions using CloudFormation and SaltStack, including backup strategies, disaster recovery procedures, and operational runbooks
- Implemented transparent production traffic mirroring to reproduce and debug live production issues safely, improving root-cause analysis and reducing time to resolution
- Developed and enhanced operational tooling and observability to improve logging, error handling, and notification workflows for background jobs, reducing manual developer intervention and improving visibility into failures
- Led bi-weekly technical sessions on offensive security, covering practical attack techniques and security concepts to improve engineering security awareness and defensive practices
### Absolute Software
Software Developer | Jun 2017 - Sep 2018
- Developed and executed MongoDB data migrations that improved production performance by 20% while maintaining application compatibility
- Re-engineered a microservice from Python to Go, achieving a 20x increase in throughput and 90% reduction in CPU and memory utilization while maintaining integration test coverage
- Built internal testing and simulation tooling to replicate and simulate hundreds of thousands of devices in development environments, enabling realistic scalability and performance testing
- Collaborated with engineers on Docker, Python, Go, Kubernetes, and infrastructure best practices, improving consistency across development and production environments
- Automated repetitive deployment workflows through Jenkins, reducing manual operational work and improving engineering productivity
### Prizm Media Inc
Software Developer Intern | Dec 2015 - Aug 2016
- Developed Android and iOS applications for an AWS-hosted fitness-oriented social networking platform, contributing across mobile application development, and backend services
- Developed and evaluated machine-learning solutions using support vector machines (SVMs) and neural networks to address application-specific problems, applying model development and performance evaluation techniques
- Reduced response times for frequently used APIs by up to 90% through database query optimization and application-level caching, improving application responsiveness and reducing backend processing overhead
### Ericsson
Software Developer Intern | Sep 2015 - Dec 2015
- Developed an OpenStack Neutron plugin in Python to automate lifecycle management of virtual Ericsson routers, integrating network infrastructure with OpenStack and improving infrastructure provisioning consistency
- Troubleshot containerized virtual-router environments and automated test pipelines on Mirantis OpenStack, diagnosing infrastructure, networking, and deployment issues to improve reliability and test consistency
### Grin Technologies
Software Developer Intern | May 2014 - Aug 2014
- Developed two web applications that processed and visualized raw electric-vehicle telemetry data, enabling users to plot trip data and generate customized wheel configurations using dynamic frontend and backend data
- Administered an electric-vehicle forum serving 5,000+ daily users on AWS through 2020 - [endless-sphere.com](https://endless-sphere.com)
## Technical Skills
| Category | Skills |
| --- | --- |
| SRE & Reliability | Reliability Engineering, Distributed Systems, Scalability, Incident Response, Root Cause Analysis, Monitoring, Alerting, Runbooks, Disaster Recovery, Performance Engineering, Load Testing |
| Observability | Prometheus, Grafana, StatsD, Graphite, VictoriaMetrics, OpenTelemetry |
| Programming | Go, Python, Bash, C/C++, Java, JavaScript, Rust |
| Cloud & Infrastructure | AWS, GCP, Azure, Kubernetes, Terraform, Ansible, Packer, Helm, Linux |
| CI/CD & GitOps | ArgoCD, Jenkins, GitOps, CloudFormation, SaltStack |
| Databases & Distributed Data | MySQL, PostgreSQL, MongoDB, Redis, Cassandra, Kafka, Vitess |
| Networking | Cilium, Nginx, HAProxy, OpenResty, MikroTik |
| Security | Linux Hardening, Offensive Security, OSCP, CEH |
## Projects
### Self-Hosted Homelab & Cloud Infrastructure | 2010 - Present
- Built and managed multi-cloud infrastructure across GCP, DigitalOcean, and Cloudflare using Terraform, Ansible, Packer, and GitOps, with Prometheus and Grafana observability across Linux workloads and infrastructure
- Designed and operated a self-hosted Kubernetes platform on Proxmox, using Talos Linux, Cilium CNI, ArgoCD, Helm, Terraform, and GitOps to provide reproducible infrastructure and automated application deployments
- Engineered a production-grade homelab environment spanning MikroTik VLAN/firewall networking, custom OpenResty/Lua load balancing, authentication, and hardened Ubuntu infrastructure
- Implemented disaster-recovery and S3 backup/restore testing and deployed honeypots to validate recovery procedures and detect malicious activity
## Leadership and Community
### Strata Council President
- Lead a council representing a community of ~1,200 residents, coordinating stakeholders, facilitating meetings and decision-making, and communicating community priorities and operational issues
### Veazey Foundation Trustee
- Serve on the board of a charitable foundation providing full scholarships to incoming UBC students, contributing to governance, financial decisions, and long-term planning
## Achievements
- Trend Micro CTF 2019 Global Finalist | Maple Bacon, UBC CTF | 12th of 1,000 teams | 2019
## Education
- University of British Columbia, B.A.Sc., Computer Engineering | 2017
## Contact
URL: https://samsongama.com/contact/
## Did we meet somewhere
I’d love to chat! Just fill out the form, and feel free to share how we met or what brought you to my site.
Send a Message
Message Sent Successfully!
Thank you for reaching out. I'll get back to you within 24 hours.
## Portfolio Projects
## Bitcomplete
URL: https://samsongama.com/portfolio/bitcomplete/
## Scope
Operated and improved a cloud AI infrastructure platform serving AI-native teams and neo-cloud providers reselling excess GPU capacity. Focus areas included Kubernetes operations, production reliability for training and inference workloads, incident handling, observability, and automation across multi-provider environments.
## What I Owned
- **Platform operations across providers**: Provisioned, configured, and operated Kubernetes clusters and containerized workloads across heterogeneous infrastructure.
- **Automation of infrastructure workflows**: Built internal tooling for cluster provisioning, integration, and lifecycle management to reduce manual operational load.
- **Observability and alerting**: Implemented and refined monitoring, health checks, and alerting signals to detect regressions and customer-impact risk earlier.
- **Incident response and follow-through**: Investigated and resolved customer-facing incidents across networking, storage, scheduling, and system layers, then fed findings into postmortems, runbooks, and prevention work.
## Reliability Outcomes
- Increased operational maturity by standardizing runbooks, escalation flow, and post-incident follow-up for production AI infrastructure.
- Improved detection and triage readiness through stronger monitoring and alert coverage on critical service paths.
- Reduced repeat operational toil by automating core cluster lifecycle and integration tasks.
- Strengthened resilience for customer workloads by addressing failure modes across the full stack instead of applying temporary mitigations.
- Improved production support for neo-cloud GPU resale customers by stabilizing the infrastructure layers their training and inference workloads depended on.
## Call of Duty: Black Ops 7
URL: https://samsongama.com/portfolio/call-of-duty-bo7/
## Scope
Worked in **Demonware's** service reliability and platform engineering organization supporting core Call of Duty online systems. The role aligned with service reliability and cloud/platform engineering responsibilities across production operations, launch readiness, and incident management.
## What I Owned
- **Service reliability for live player systems**: Supported production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Call of Duty: Black Ops 6
URL: https://samsongama.com/portfolio/call-of-duty-bo6/
## Scope
Supported the core online services behind **Call of Duty: Black Ops 6** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic multiplayer systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## EV Charger Installation
URL: https://samsongama.com/portfolio/mp-ev-project/
## Summary 🧭
During my time as Strata Council President at Marina Pointe, I worked on a number of projects, but the EV upgrade is one I'm especially proud of.
EV ownership has been steadily increasing, and we could see that more residents were either driving electric vehicles or planning to. Our existing electrical setup was not designed for that level of demand.
Key drivers were:
- **Provincial targets:** BC Zero Emission Vehicles Act goals of 26 percent of new vehicle sales by 2026 and 90 percent by 2030.
- **Resident demand:** clear interest from owners and residents.
- **Rebate deadline:** incentives scheduled to end on **February 28, 2024**.
We replaced two older unmetered chargers with **18** smart, networked, metered units. The new system allows us to manage electrical load, scale as demand increases, and ensure users pay for what they consume, while maintaining overall electrical stability in the building.
---
## Technical Visualization: Project Timeline & Dependencies 📆
The following diagram illustrates the critical phases and the timeline.
{{< mermaid >}}
flowchart TD
A["Owner Interest Survey Mar 2022"] --> B["Electrical Load Assessment 2022"]
B --> C["BC Hydro Rebate Pre-Approval 2023"]
C --> D["Vendor/Proposal Acceptance Jan 2024"]
D --> E["Materials + Permitting Jan-Feb 2024"]
E --> F["Legacy Decommission Feb 13, 2024"]
F --> G["Install Panel + Transformer Feb 2024"]
G --> H["Final Cutover + Commission Feb 28, 2024"]
H --> I["Rebate Submission Deadline Feb 28, 2024"]
H --> J["User Registration Post-Cutover"]
{{< /mermaid >}}
---
## Technical Deep Dive: Electrical Infrastructure ⚡
The main task was to integrate a **280 Amp** total reserved load without forcing a costly strata main-service upgrade, which is a common issue for buildings over 25 years old. Fortunately, this was not a problem for this project.
### Conceptual Electrical Flow Diagram 🧩
The new system operates through a dedicated sub-panel and is supplied by **two dedicated transformers**. This subsystem is isolated from the rest of the building's common area services, and its total load is actively managed by the Plugzio system.
**Note that the EV Panel and Load Management System have been simplified for this post.**
{{< mermaid >}}
flowchart TD
A["Building Main Service"] --> B1("Transformer 1")
A --> B2("Transformer 2")
B1 --> C["New Dedicated EV Panel"]
B2 --> C
C --> D{"Plugzio Load Management System (LMS)"}
D --> E1["EV Charger 1"]
D --> E2["EV Charger 2"]
D --> E3["..."]
D --> EN["EV Charger N"]
subgraph EC["Electrical Components"]
B1
B2
C
D
end
{{< /mermaid >}}
### Key Technical Specifics ✅
- **Total Reserved Capacity:** **280 Amps**. This capacity is the maximum total load allocated for the entire EV charging subsystem and is managed across the new electrical infrastructure, including the two transformers.
- **Capacity Proof & Verification:** The capacity was verified by **McKinley Electric** using a **Power Analyzer** to log historical load data, a critical step required for the **City of Vancouver (COV)** electrical permit to prove available head-room on the existing building service.
- **New Equipment:** The installation involved a **new dedicated electrical panel** and **two new dedicated transformers** to service the EV system. **Note:** The exact KVA or Amp ratings are not being disclosed in this post.
- **Load Management System (LMS):** The Plugzio LMS is central to the design. It acts as a circuit breaker, dynamically allocating the **280A capacity** among all active chargers. This prevents the main breaker from tripping and allows the Strata to install more chargers than the panel could support if they were all charging at max capacity simultaneously.
## Carbon Credit Revenue Stream 💰
The installation of new, metered EV charging stations created a passive revenue stream for the Strata through the accumulation of carbon credits.
- **Revenue generation:** The metered stations enable the Strata to generate tradable carbon credits based on EV energy consumption.
- **Projected income:** The Strata's carbon credit income for the installation's initial period was **$2,500 in 2023**.
- **Future projections:** Based on usage, the Strata is projected to generate **$12,000 for 2024** from this carbon credit revenue.
- **Intended use of funds:** This revenue is being collected to supplement the Strata's general income. A draft report noted that the **$12,000/year** from EV-generated carbon credits would contribute to overall revenue streams.
## The Legacy System: Eaton Chargers 🧯
In total, the project covered **11 chargers**: **two older Eaton units** in the Landmark (LM) section, **seven new chargers** in the Waterworks (WW) visitor parking area, and the replacement of two old chargers in the WW section.
### Operational and Technical Flaws of the Eaton System 🔧
The original chargers, operational for **over 10 years**, presented significant operational challenges that the new system was designed to resolve:
- **Non-Networked Status:** The Eaton chargers were **non-networked**, lacking smart communication, remote control, and consumption data.
- **Manual Activation:** Their non-networked nature required concierge staff to **manually turn the breakers in P1 on and off every few hours** to activate and deactivate the chargers, which created a steady and tedious staff task.
- **Billing and Theft Issues:** They were associated with **electricity theft** and operated on a simple **flat-rate charging fee** ($75/month was an estimate of average consumption), which did not incentivize turnover and was more likely to be overused by high-use vehicles (like Uber/Lyft).
- **Decommissioning:** The former Eaton chargers were officially decommissioned on **February 13, 2024**.
## Phase 1: Planning, Feasibility, and Initial Design (2022 - Early 2023) 🧠
This initial phase focused on assessing resident interest, securing funding, and determining the electrical feasibility of the new system.
### 1. Owner Interest Survey 🗳️
The project began with a formal **EV Charging Survey** sent to all owners in **March 2022** to gauge the demand for EV charging within the building.
### 2. Electrical Load Assessment and Permitting (The 280A Challenge) 🧮
Given the building is over 25 years old, an early step was confirming the existing infrastructure could support the new load.
- **Capacity Proof:** The contractor, McKinley Electric, was required to use a **Power Analyzer** to monitor the main distribution panel's load profile over a period of time.
- **Design & Engineering:** Initial budget concerns led to the removal of the **design assessment** cost from the contractor's scope, indicating budget constraints were a factor from the start.
### 3. Rebate Pre-Approval and Vendor Selection 🧾
The project's financial viability was tied to a BC Hydro EV charger rebate, which required specific eligible hardware and a defined approval process.
- **Initial Challenge:** The rebate application was initially rejected because the quote identified the chargers as "Plugzio," a brand not yet listed as eligible at the time (July 2023).
- **Resolution:** The quote was modified to reference eligible **Wallbox Pulsar Plus** devices or other Plugzio-branded, Wallbox-compatible hardware that was later confirmed as eligible (August 2023). The available rebate amount was noted to be up to **$5,000 per charger** with a maximum of **$25,000**.
## Phase 2: Financial, Vendor Lock-in, and Logistics (Late 2023 - Early 2024) 💼
This phase finalized the vendor and scheduling ahead of the rebate deadline.
### 1. Proposal Acceptance and Deposit 🧾
Following council approval, the financial agreement was executed.
- **Acceptance:** The Strata Council accepted the quote, authorizing work to begin.
- **Payment:** A 50% deposit was paid to **Parkizio Technologies LTD** (Plugzio's parent company) in **January 2024** to initiate the order and installation process.
### 2. Permit Acquisition and Scheduling 🗓️
To meet the rebate deadline of February 28, 2024, the process required immediate action and coordination.
- **Schedule:** The electrical contractor, Recharge Electric, emphasized starting early to **secure permits** and **organize materials** due to long lead times for specialized electrical components.
- **Installer Coordination:** The Strata Manager and the building's electrician, McKinley Electric, coordinated with Recharge Electric for the final power cutover, ensuring minimal disruption to the building's common areas.
## Phase 3: Decommissioning, Installation, and Commissioning (February 2024) 🛠️
The final stages involved removing the old equipment and integrating the new system into the building's electrical infrastructure.
### 1. Decommissioning of Legacy System 🧹
The old **Eaton chargers** were officially decommissioned on **February 13, 2024**. Current users were directed to use temporary chargers (EV chargers 8 and 9) in the WW P1 visitor area to minimize service interruption.
### 2. Technical Commissioning Sequence 🔌
The commissioning involved a sequence of electrical work to bring the new system online.
{{< mermaid >}}
sequenceDiagram
participant S as Strata Council/Manager
participant RE as Recharge Electric (Electrical Contractor)
participant ME as McKinley Electric (Building Electrician)
participant COV as City of Vancouver (Permits)
participant BH as BC Hydro
S->>RE: Issue PO & 50% Deposit (Jan 2024)
RE->>COV: Submit Electrical Permit Application
RE->>RE: Procure New Panel & Transformers
ME->>RE: Decommission Legacy Eaton System (Feb 13)
RE->>RE: Install New Dedicated Electrical Panel
RE->>RE: Install New Transformers
S->>ME: Schedule Common Area Power Shutdown
ME->>RE: Verify Main Breaker Lock-Out for Safety
RE->>ME: Final Electrical Tie-in (New Panel to Service)
ME->>S: Power Restored
RE->>COV: Schedule Final Electrical Inspection
COV->>RE: Pass Final Inspection
RE->>S: System Handover & Commissioning
S->>BH: Submit Rebate Final Application (Feb 28 Deadline)
{{< /mermaid >}}
### 3. Electrical Tie-in and Commissioning 🔒
The new system's power infrastructure was finalized with a scheduled power shutdown.
- **Final Cutover:** A **power shut down of the common areas of Landmark** was scheduled for **February 28th at 10 am** to connect the new subsystem to the building service. This was the final technical step of the electrical installation and needed to meet the rebate deadline.
---
## Phase 4: User Onboarding and Program Management (Ongoing) 🚗
With the chargers operational, the focus shifted to user onboarding and policy rules under Canadian regulations.
### 1. User Account and Agreement 🧾
To access the new system, users must complete two steps:
- **Agreement:** Sign the **Plugzio EV Charging User Agreement**.
- **Account:** Register for a **Plugzio account** for billing and access control.
### 2. Charging Policy and Compliance (Measurement Canada) ⚖️
The pricing model was discussed with residents, but the main driver is regulatory compliance.
**Measurement Canada compliance (why time-based):**
Charging by **kilowatt-hour (kWh)** is regulated in Canada. For non-utility operators, kWh billing requires Measurement Canada-approved metering and ongoing compliance. To avoid the administrative work of applying for temporary dispensation per device and monitoring accuracy, the Strata adopted time-based billing.
**Pricing model (time-based tiers):**
- **Tier 1 (First 4 hours):** **$2.00 per hour** (considered the "affordable rate" for an average user).
- **Tier 2 (4-6 hours):** **$3.00 per hour**.
- **Tier 3 (6+ hours):** **$4.00 per hour**.
- **Payment fees:** Plugzio uses PayPal, which charges the user **$0.30 + 2.9%** for adding money to their wallet.
**Why the tiers exist:**
1. **Stall turnover:** Discourages long idle sessions.
2. **Efficient charging:** Encourages stopping around **80%**, where charge speed is still high.
**Liability:** The User Agreement explicitly states that the **User is solely responsible** for the operation and safety of their vehicle, and the Operator (Strata) assumes **no liability** for any damage or injury from the station's use.
**External references:**
- [Measurement Canada](https://ised-isde.canada.ca/site/measurement-canada/en)
- [Electricity and Gas Inspection Act (Canada)](https://laws-lois.justice.gc.ca/eng/acts/E-4/)
## Call of Duty: Modern Warfare III
URL: https://samsongama.com/portfolio/call-of-duty-mw3/
## Scope
Supported the core online services behind **Call of Duty: Modern Warfare III** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic multiplayer systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Call of Duty: Warzone 2.0
URL: https://samsongama.com/portfolio/call-of-duty-wz2/
## Scope
Supported the core online services behind **Call of Duty: Warzone 2.0** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic battle royale systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Call of Duty: Modern Warfare II
URL: https://samsongama.com/portfolio/call-of-duty-mw2/
## Scope
Supported the core online services behind **Call of Duty: Modern Warfare II** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic multiplayer systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Call of Duty: Vanguard
URL: https://samsongama.com/portfolio/call-of-duty-vanguard/
## Scope
Supported the core online services behind **Call of Duty: Vanguard** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic multiplayer systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Call of Duty: Black Ops Cold War
URL: https://samsongama.com/portfolio/call-of-duty-bo5/
## Scope
Supported the core online services behind **Call of Duty: Black Ops Cold War** at **Demonware (Activision)**. The work focused on production reliability, launch-scale readiness, observability, and operational response for high-traffic multiplayer systems.
## What I Owned
- **Service reliability for live player systems**: Operated production services with emphasis on uptime, fault tolerance, and safe release behavior during live events.
- **Capacity and launch readiness**: Helped prepare infrastructure and service behavior for peak traffic windows and large launch demand.
- **Automation and operational tooling**: Built and improved deployment and infrastructure workflows to reduce manual operations and recurring failure modes.
- **Observability and incident response**: Monitored production signals, triaged incidents under load, and translated incident learnings into preventative platform improvements.
- **Cross-team execution**: Partnered with service owners and game teams to keep online experiences stable, performant, and shippable.
- **Operational ownership**: Participated in on-call and reinforced a service-ownership culture for live operations.
## Reliability Outcomes
- Improved operational readiness for launch and live-service demand through stronger reliability and capacity planning practices.
- Reduced repeat operational toil by increasing automation coverage in deployment and infrastructure workflows.
- Strengthened incident response posture with clearer production signals and tighter feedback loops from incident review to remediation.
- Increased resilience of customer-facing game services by prioritizing durable fixes over temporary recovery.
**Tech Stack:**
- **Languages**: Python, C++, Golang, Bash
- **Infrastructure**: Kubernetes, On-Prem
## Mastercard CTF Team
URL: https://samsongama.com/portfolio/insiderthreats/
To foster a culture of security awareness and technical curiosity, I founded **"Insider Threats"**, a Capture The Flag (CTF) team at the Mastercard Vancouver office.
## Initiative Goals
The goal was to upscale the engineering team's understanding of offensive security concepts to better defend our own systems.
## Key Activities
- **Workshops & Tutorials**: I designed and led hands-on sessions covering fundamental security topics:
- **Binary Reversal**: Analyzing compiled executables to understand logic flow and vulnerabilities.
- **Digital Forensics**: Investigating artifacts to reconstruct security incidents.
- **Web Exploitation**: Understanding common vulnerabilities like SQLi and XSS.
- **Team Coordination**: Organized participation in competitive CTF events, fostering team bonding and collaborative problem-solving under pressure.
## CTF Writeups
URL: https://samsongama.com/portfolio/ctfsamsongamacom/
{{< figure src="/portfolio/2019-12-23-ctfsamsongamacom/ctf.webp" title="CTF Writeup Repository" >}}
I maintain a dedicated repository of writeups for the CTF challenges I've solved. This serves as both a personal knowledge base and a community resource for up-and-coming security researchers.
## Categories Covered
- **Binary Exploitation (Pwn)**: Buffer overflows, ROP chains, Heap exploitation.
- **Reverse Engineering**: Disassembling ELF/PE binaries to understand proprietary logic.
- **Web Security**: SQL Injection, XSS, SSRF, and deserialization attacks.
- **Cryptography**: Breaking weak encryption schemes and implementation flaws.
[Visit ctf.samsongama.com](https://ctf.samsongama.com/)
## TrendMicroCTF2019 Finalist
URL: https://samsongama.com/portfolio/trendmicroctf2019/
{{< figure src="/portfolio/2019-11-23-trendmicroctf2019/tmctf_team.webp" title="Team Maple Bacon in Tokyo" >}}
As a key member of the CTF team **Maple Bacon**, I helped secure a spot in the prestigious Trend Micro CTF Finals held in Tokyo, Japan.
## The Achievement
- **Selection**: We qualified by placing in the top 10 online out of over 800 competing teams globally.
- **Performance**: In the finals, we placed **12th overall**, marking a significant milestone for Canadian representation in international cybersecurity competitions.
- **Challenges**: The competition involved high-pressure scenarios in binary exploitation, IoT security, and industrial control systems (ICS).
{{< figure src="/portfolio/2019-11-23-trendmicroctf2019/tmctf_ranking.webp" title="Official Rankings" >}}
## Dynamic Biometrics (Verifeye)
URL: https://samsongama.com/portfolio/mastercard-verifeye/
**Verifeye** was a Proof of Concept (PoC) developed during Mastercard's Innovation Week. The project aimed to rethink payment authentication by moving beyond static passwords to dynamic biological markers.
## The Concept
We designed a passive authentication layer that works in the background during a transaction.
### 1. Identity Verification
- **Facial Age/Gender Estimation**: Used computer vision to compare the user's estimated demographics against the cardholder's file.
- **Liveness Detection**: Ensured the user is a real person and not a photograph.
### 2. User Sentiment
- **Friction Analysis**: Analyzed facial expressions to determine "customer delight" or frustration during the checkout flow. This data could help merchants optimize their UX.
{{< figure src="/portfolio/2019-06-14-mastercard-verifeye/verifeye-2.webp" title="Initial Screen" >}}
{{< figure src="/portfolio/2019-06-14-mastercard-verifeye/verifeye-0.webp" title="Debug View (Facial Landmarks)" >}}
## FinTech: Algorithmic Trading Bot
URL: https://samsongama.com/portfolio/hft-bot/
{{< figure src="/portfolio/2017-11-01-hft-bot/hft_btc_grafana.webp" title="Real-time Monitoring Dashboard" >}}
This project is a high-frequency trading (HFT) system designed to capitalize on volatility in the cryptocurrency markets. It evolved from a simple Python scraper into a robust distributed system capable of processing market data in nanoseconds.
## System Evolution
### 1. Data Engineering Limitations
I initially started with Python and PostgreSQL, but the sheer volume of tick data (Level 2 order books) created a bottleneck.
- **The Pivot**: Migrated to **Golang** for its raw performance and concurrency primitives.
- **Storage**: Switched to **InfluxDB** (Time Series Database) to handle millions of data points effectively without the write-lock overhead of relational databases.
### 2. Strategy & Analysis
Accumulating a 40GB+ dataset allowed for rigorous backtesting.
- **Pattern Matching**: Implemented algorithms to detect arbitrage opportunities and specific "market maker" patterns.
- **Machine Learning**: Utilized sentiment analysis and risk assessment models to filter trade signals.
- **Performance**: The bot achieved **0.5% weekly returns** (net of fees) during the testing period.
## Architecture
The system is composed of nine specialized microservices communicating via a message bus.
- **Ingestion**: Co-located VPS instances near exchange servers to minimize network latency.
- **Monitoring**: Full observability stack using **Grafana** to track "Tick-to-Trade" latency and system health.
- **ChatOps**: Integrated with **Slack** to broadcast trade decisions and predictive signals in real-time.
**Tech Stack:**
- **Language**: Golang, Node.js
- **Database**: InfluxDB, MongoDB
- **DevOps**: Docker, Grafana, Promethus
- **APIs**: REST, WebSockets (Exchange Feeds)
{{< figure src="/portfolio/2017-11-01-hft-bot/hft_btc_cc_charts.webp" title="Backtesting Simulation" >}}
{{< figure src="/portfolio/2017-11-01-hft-bot/hft_btc_slack.webp" title="Slack Notifications" >}}
## High-Scale Backend: Absolute Data Pipeline
URL: https://samsongama.com/portfolio/absolute/
At **Absolute Software**, I served as a Backend Developer focused on modernizing the company's core data ingestion infrastructure.
## The Problem
The legacy pipeline struggled to process the massive volume of security telemetry data coming from millions of endpoint devices. It was resource-heavy, slow to scale, and difficult to maintain.
## The Solution
I led the redesign of critical components of the pipeline, shifting from a monolithic approach to a microservices architecture.
### 1. Golang & Concurrency
- **Language Switch**: We rebuilt the ingestion workers in **Go (Golang)** to take advantage of its lightweight goroutines and superior handling of concurrent network I/O.
- **Async Processing**: Implemented a non-blocking, asynchronous processing model that could handle thousands of concurrent connections effortlessly.
### 2. Kubernetes Autoscaling
- **Orchestration**: Deployed the new services on **Kubernetes**.
- **Elasticity**: Configured Horizontal Pod Autoscalers (HPA) to automatically spin up new worker pods during traffic spikes and scale down during lulls.
## Results
- **Performance**: Achieved **20x throughput** after re-engineering a microservice from Python to Go.
- **Efficiency**: CPU and memory utilization were reduced by **90%**, while maintaining integration test coverage.
- **Reliability**: The system became resilient to bursts of data that previously caused outages.
## DevOps Contributions
Beyond the code, I improved the developer experience:
- **Internal Tools**: Built CLI tools for load testing and generating mock telemetry data.
- **Automation**: Optimized Jenkins pipelines to remove manual deployment steps.
**Tech Stack:**
- **Core**: Golang
- **Infrastructure**: Kubernetes, Docker
- **CI/CD**: Jenkins
- **Domain**: High-Volume Data Processing
## Capstone: Contextual Ad Targeting Engine
URL: https://samsongama.com/portfolio/ubc-capstone/
For my UBC Engineering final year project, our team built a **Contextual Inference Engine**. This SaaS platform analyzed unstructured user content (text and images) to extract metadata—Time, Location, and Sentiment—to serve highly relevant advertising parameters.
## Technical Architecture
The system was designed as a modern microservices application.
### 1. Model Ensemble
We didn't rely on a single model. Instead, we orchestrated a pipeline of various AI services and custom models:
- **Third-Party APIs**: Integrated **Microsoft Azure Cognitive Services**, **Amazon Rekognition**, and **IBM Watson** for robust baseline analysis.
- **Custom Models**: Built specialized models using **Google TensorFlow** and **SyntaxNet** (for dependency parsing) to refine sentiment analysis and entity extraction.
### 2. Cloud Native Deployment
- **Containerization**: All services were Dockerized for consistency across development and production.
- **Orchestration**: Deployed on a **Kubernetes** cluster to manage scaling and service discovery.
- **CI/CD**: Configuring **TravisCI** for automated testing and deployment pipelines.
## Outcome
We successfully built a working prototype that could take a raw image or text snippet and output structured JSON targeting data (e.g., "User is happy, at a beach, during sunset -> Suggest Sunscreen or Travel Ads").
**Tech Stack:**
- **ML Frameworks**: TensorFlow, SyntaxNet
- **Cloud Services**: Azure, AWS, IBM Cloud
- **Infrastructure**: Docker, Kubernetes, TravisCI
- **Languages**: Python
> Note: The demo is offline as the Azure student credits have expired.
## Mobile Development: Kudolife Health App
URL: https://samsongama.com/portfolio/kudolife/
**Kudolife** is a comprehensive health and wellness tracking application. As a full-stack developer at **Prizm Media**, I was responsible for maintaining and enhancing both the mobile apps and the backend infrastructure.
## Key Improvements
### 1. Backend Optimization
- **Performance Tuning**: Analyzed and optimized slow database queries and API endpoints.
- **Result**: Achieved an average **50% reduction in API response time** across the platform, significantly improving the app's responsiveness and "snappiness" for users.
### 2. Feature Development
- **Cross-Platform**: Published multiple updates to both the **iOS** (App Store) and **Android** (Google Play) applications.
- **New APIs**: Designed and implemented new RESTful API endpoints availability to support novel tracking features requested by the product team.
- **Bug Fixes**: Systematically eliminated backlog bugs revealed during QA testing.
**Tech Stack:**
- **Mobile**: Android (Java), iOS (Objective-C/Swift)
- **Backend**: PHP, MySQL, REST API
- **Tools**: JIRA, Git
[Visit Kudolife](http://www.kudolife.com/)
## Internship: OpenStack Virtual Router Plugin
URL: https://samsongama.com/portfolio/ericsson-openstack/
During my internship at **Ericsson**, I worked on integrating their telecommunications hardware into the cloud via OpenStack.
## Key Contributions
### 1. Neutron Plugin Development
- **Software Defined Networking (SDN)**: Co-developed a plugin for **OpenStack Neutron**, the networking component of OpenStack. This plugin allowed OpenStack to act as a control plane for managing virtualized Ericsson routers.
- **API Integration**: The plugin translated standard OpenStack API calls into specific configuration commands for the Ericsson routing hardware.
### 2. Testing & Automation
- **Integration Testing**: Enhanced the team's CI/CD pipeline by writing Python scripts to automate scenario-based testing across different environments.
- **Dockerization**: Leveraged Docker containers within the OpenStack environment to isolate test components and simulate complex network topologies.
### 3. Network Security
- **Inter-VM Communication**: Investigated and implemented secure communication channels between multiple Virtual Machines (VMs) without requiring runtime reconfiguration of Linux network interfaces.
**Tech Stack:**
- **Platform**: OpenStack (Neutron)
- **Languages**: Python, Bash
- **Tools**: Docker, Git, Jenkins
- **Domain**: SDN, Virtualization, L2/L3 Networking
[Learn more about Ericsson Virtual Routers](https://www.ericsson.com/ourportfolio/products/virtual-router)
## Computer Vision: Kinect SVM Hand Tracking
URL: https://samsongama.com/portfolio/kinect-svm/
{{< youtube id="ZT-NPwJW3Mw" autoplay="false" >}}
**Kinect SVM** is a computer vision application that allows users to trigger operating system tasks (like launching apps or controlling volume) by drawing specific shapes on a piece of paper in front of a Kinect camera.
## Technical Implementation
### 1. Recognition Pipeline
- **Depth Segmentation**: Utilized the Kinect's depth sensor to isolate the user's hand and the paper from the background scene.
- **Feature Extraction**: Processed the image frames to extract the contours of the hand-drawn shapes.
- **Classification**: Fed these features into a trained **Support Vector Machine (SVM)** to identify the shape (e.g., Triangle, Circle, Star).
### 2. Performance Optimization
- **Multithreading**: Implemented a heavy multi-threaded architecture in C++. One thread handled the high-bandwidth 1080p video ingestion, while separate worker threads processed the SVM prediction logic.
- **Frame Rate**: Successfully maintained a stable **30 Frames Per Second (FPS)** detection rate, ensuring the interaction felt "real-time" to the user.
### 3. Training Utility
- **Custom Tooling**: Built a companion desktop application that allowed us to rapidly record new gestures and train the SVM model, making the system extensible.
**Tech Stack:**
- **Language**: C++
- **Hardware**: Microsoft Kinect v2
- **Libraries**: OpenCV (Computer Vision), LIBSVM
- **OS**: Windows
## Infrastructure: Endless-Sphere Migration
URL: https://samsongama.com/portfolio/endless-sphere/
**Endless-Sphere** is the premier online community for DIY electric vehicle enthusiasts, boasting over 25,000 active members and millions of posts. The forum serves as a critical knowledge base for the EV industry.
## The Challenge
The site was hosted on a legacy Virtual Private Server (VPS) that suffered from:
- **Frequent Downtime**: Hardware limitations led to database locking during peak traffic.
- **High Costs**: Inflexible pricing models meant paying for peak capacity 24/7.
- **Security Logic**: Lack of automated backups and no SSL/TLS encryption.
## Technical Solution
I led the migration and modernization effort, serving as the lead Systems Administrator.
### 1. Cloud Migration (AWS)
- **Lift & Shift + Optimize**: Migrated the LAMP stack (Linux, Apache, MySQL, PHP) to Amazon Web Services (EC2).
- **Database Optimization**: Tuned the MySQL configuration to handle high-read/low-write workloads typical of forum software (phpBB).
### 2. DevOps & Automation
- **Backups**: Implemented automated incremental snapshots (EBS) and S3 off-site backups to ensure data durability.
- **Security**: Deployed **Let's Encrypt** certificates for complying with modern HTTPS standards, improving SEO and user trust.
- **Cost Reduction**: Utilized Reserved Instances and rightsizing to reduce monthly hosting costs while improving uptime availability to 99.9%.
## Outcome
The migration stabilized the platform, allowing the community to grow without technical interruptions.
*(Note: You can find me on the forum under the username **gammaray**)*
[Visit Endless-Sphere](https://endless-sphere.com)
## Mobile App: Boardcast for Android
URL: https://samsongama.com/portfolio/boardcast/
{{< youtube id="CUDMqm04WdI" autoplay="false" >}}
**Boardcast** is a real-time collaborative whiteboarding tool designed for Android tablets and phones. It allows teams to sketch, diagram, and brainstorm together without needing an internet connection, relying instead on local peer-to-peer mesh networking.
## Core Features
### 1. Peer-to-Peer Mesh Networking
The standout feature of Boardcast is its connectivity versatility.
- **Wi-Fi Direct & NFC**: Users can "bump" devices to establish an ad-hoc high-bandwidth connection without a router.
- **Local Network Discovery**: Uses DNS-SD (Service Discovery) to find peers on the same Wi-Fi LAN.
- **Custom Protocol**: Designed a low-latency socket messaging layer to sync drawing paths and state changes across arbitrary numbers of connected devices.
### 2. High-Performance Drawing
- **Hardware Acceleration**: Implemented a custom OpenGL-backed drawing view that discretizes touch inputs into smooth Bezier curves.
- **Input Handling**: Multi-touch support for zooming, panning, and drawing simultaneously.
### 3. Computer Vision Integration
- **Whiteboard Capture**: Implemented a multi-threaded edge-detection and perspective correction algorithm (similar to Office Lens).
- **Digitization**: Users can snap a photo of a physical whiteboard, and Boardcast enhances contrast and flattens the image to be used as a digital canvas background.
## Design & Polish
The application was built following Google’s then-new **Material Design** guidelines, featuring custom view transitions, floating action buttons, and intuitive gesture controls. It was released on the Google Play Store and Amazon App Store, maintaining a high crash-free session rate.
**Tech Stack:**
- **Platform**: Android SDK (Java)
- **Networking**: Wi-Fi P2P (Direct), NSD (Network Service Discovery), Java Sockets
- **Graphics**: Android Canvas API, OpenGL ES
- **CV**: OpenCV (Android port)
*Website: [boardcastapp.com](http://boardcastapp.com/)*
## FPGA Embedded System: UberNios
URL: https://samsongama.com/portfolio/ubernios/
{{< figure src="/portfolio/2014-10-31-ubernios/ubernios-post-0.webp" title="UberNIOS Game Play" >}}
**UberNios** is a custom hardware/software co-design project demonstrating full-stack embedded development—from the logic gate level up to the application layer. We built a functional arcade game console on an Altera DE2 FPGA board.
## Technical Architecture
The system uses a **system-on-chip (SoC)** approach, instantiating a Nios II soft-core processor alongside custom hardware peripherals in the FPGA fabric.
### 1. Hardware Design (VHDL/Verilog)
- **VGA Controller**: Custom logic to drive the VGA DAC, handling timing signals (HSYNC/VSYNC) for 640x480 output.
- **Audio Codec Interface**: Direct hardware interface to the Wolfson WM8731 codec for lag-free sound effects.
- **Input Controllers**: Drivers for PS/2 keyboard/mouse and on-board push buttons.
### 2. Software Layer (C / Assembly)
- **Graphics Engine**: Implemented a "2.5D" perspective engine. It used efficient sprite scaling and shifting to simulate depth, optimizing for the Nios II's limited clock speed.
- **Render Loop**: Optimized drawing routines to only redraw "dirty pixels" (changed regions) rather than full frame buffering, ensuring high frame rates (60 FPS).
- **Audio Engine**: Utilized hardware timers and interrupts to feed audio samples to the FIFO buffer, preventing CPU stalling.
### 3. Multiplayer Networking
- **Ethernet Driver**: Wrote a raw packet driver for the DM9000A controller.
- **Protocol**: Simple custom protocol to synchronize game states between two FPGA boards connected via Ethernet, allowing for head-to-head racing.
## Outcomes
The project successfully demonstrated the power of hardware acceleration for specific tasks (graphics/audio) while keeping game logic flexible in software.
**Tech Stack:**
- **Hardware**: Altera DE2 Development Board (Cyclone II FPGA)
- **HDL**: VHDL, SystemVerilog
- **Soft Core**: Nios II
- **Language**: C, MIPS Assembly
- **Tools**: Quartus II, SOPC Builder
## Hackathon: FleetAware
URL: https://samsongama.com/portfolio/fleetaware/
{{< figure src="/portfolio/2014-10-01-fleetaware/fleetaware-post-0.webp" title="FleetAware Dashboard" >}}
**FleetAware** was developed during a 24-hour Hackathon with the goal of extending the capabilities of the **Mojio** connected car platform. While Mojio was designed for single-vehicle owners, we recognized an opportunity to scale the technology for enterprise fleet management (Rental agencies, Logistics, Taxi services).
## Technical Implementation
We reverse-engineered the Mojio consumer API to aggregate data from multiple devices into a single administrative dashboard.
**Features Implemented:**
1. **aggregated Tracking**: Real-time GPS location of all fleet vehicles on a master Google Map.
2. **Distance Geofencing**: Automated alerts if rental vehicles exceeded daily mileage limits.
3. **Route Optimization**: Algorithms to suggest fuel-efficient headers based on traffic data, beneficial for bus or delivery routing.
## Market Potential
We pitched a business model targeting the 360,000+ rental and taxi vehicles in North America. By providing the dashboard as a value-add service for bulk hardware purchases, we demonstrated a scalable B2B revenue stream—a pitch that resonated well with the judges.
## Outcomes
Our team successfully built a "market-ready" MVP (Minimum Viable Product) in under 20 hours. We delivered a working web application that could ingest live data from the Mojio vehicle simulator, alert managers of "problem vehicles," and visualize the entire fleet status instantly.
**Tech Stack:**
- **Frontend**: HTML5, CSS3, JavaScript (jQuery)
- **Maps**: Google Maps JS API
- **Backend**: PHP5
- **Hardware Integration**: Mojio REST API
*Challenge Post: [http://challengepost.com/software/fleetaware](http://challengepost.com/software/fleetaware)*
## Custom Electric Bicycle
URL: https://samsongama.com/portfolio/electric-bicycle/
Leveraging my experience at **Grin Technologies**, I engineered a custom electric bicycle optimized for urban commuting and efficiency testing. The build integrated commercial off-the-shelf components with custom telemetry solutions.
## Component Specifications
- **Frame**: Montague Paratrooper (Folding Mountain Bike)
- **Propulsion**: **Nine Continent 2807** Direct Drive Hub Motor (optimized for regenerative braking).
- **Power Storage**: **AllCell Technologies** 36V 11Ah Li-ion battery (utilizing Phase Change Material for thermal management).
- **Control System**: **ASI BAC-350** Field-Oriented Controller (FOC) for silent, efficient operation.
- **Lighting**:
- **Front**: Cycle Lumenator (1000 lumen output, tapping into main pack voltage).
- **Rear**: Electrolight (Integrated brake light).
- **Telemetry & Human Machine Interface**:
- **Display**: **Cycle Analyst V3** (Primary dashboard for tracking Ah consumed, Watts, Speed).
- **Data Logging**: Custom-solder **HC-05 Bluetooth Module** bridge to transmit serial data to the [EV Trip Analyzer](/portfolio/ev-trip-analyzer/) web app.
*Note: This vehicle served as the primary testbed for the EV Trip Analyzer software.*
## Web Appe: EV Trip Analyzer
URL: https://samsongama.com/portfolio/ev-trip-analyzer/
During my engineering co-op at **Grin Technologies** (ebikes.ca), I served as the lead developer for the **EV Trip Analyzer**, a web platform for scrutinizing electric bicycle performance data.
## Functionality
The application parses raw telemetry logs (analog and digital) outputted by the **Cycle Analyst** hardware. It transforms this data into interactive insights:
- **Performance Metrics**: Plots Speed, Power (Watts), Efficiency (Wh/km), and Regenerative Braking data against Time or Distance.
- **Geospatial Analysis**: Overlays trip data onto a **Google Maps** route, allowing users to correlated energy consumption with elevation changes.
- **Sharing**: Implemented a trip upload feature that generates permalinks for community sharing.
## Technology Stack
- **Core**: HTML5, CSS3, PHP, JavaScript (jQuery).
- **Compression**: **LZ-String** for efficient client-side compression/decompression of large telemetry datasets.
- **Visualization**: **DyGraphs** for high-performance time-series plotting.
- **Mapping**: Google Maps JavaScript API.
Try it out here: [http://www.ebikes.ca/tools/trip-analyzer.html](http://www.ebikes.ca/tools/trip-analyzer.html)
## Web App: Bicycle Spoke Calculator
URL: https://samsongama.com/portfolio/spoke-calculator/
The **Spoke Calculator** is a precision tool I developed to help mechanics and hobbyists build bicycle wheels. Because wheel building tolerances are extremely tight (±1mm), accurate calculation is critical.
## Features
- **Visual Lacing**: Unlike spreadsheet calculators, this tool renders a real-time vector graphic of the wheel using the **JSGL** library.
- **Dynamic Calculation**: Users inputs rim diameter, hub flange dimensions, and spoke count to get instant length requirements.
- **Pattern Verification**: It allows users to visualize different cross-patterns (1-cross, 3-cross) to ensure physical compatibility with the hub.
## Tech Stack
- **Frontend**: HTML5, CSS3, JavaScript
- **Vector Graphics**: JSGL Library
- **Backend logic**: PHP (legacy support)
Try it out here: [http://www.ebikes.ca/tools/spoke-calc.html](http://www.ebikes.ca/tools/spoke-calc.html)
## Robotics: Electromagnetic Tetherbot
URL: https://samsongama.com/portfolio/electromagnetic-tetherbot/
{{< vimeo 91260438 >}}
For the EECE 281 capstone, my team engineered an **Electromagnetic Tetherbot**, an autonomous vehicle designed to track and follow a specific electromagnetic frequency generated by a mobile transmitter.
## System Design
- **Firmware (C)**: Both the transmitter beacon and the receiver unit on the robot were programmed in C for low-latency signal processing.
- **Control Interface (Android/Java)**: We replaced the standard push-button controller with a custom Android tablet application. This allowed for:
- Remote steering commands.
- Visualization of signal strength.
- Mode switching (Autonomous Follow vs. Manual Override).
user experience over the regular push-button method.
## Outcomes
The project exceeded requirements by successfully demonstrating reliable tracking in noisy environments and offering a modern touch-interface for control.
## Biomedical Engineering: Photoelectric Heart Rate Monitor
URL: https://samsongama.com/portfolio/heart-rate-monitor/
For this module, I executed the full lifecycle design—build, program, and test—of a **photoelectric heart rate monitor**.
## Operational Principle
The device functioned as a **photoplethysmogram (PPG)** sensor. It utilized a non-invasive photo transmitter/receiver pair clipped to a finger.
1. **Sensing**: The sensor detected minute variations in light absorption caused by the volumetric change of blood flow with each heartbeat.
2. **Signal Processing**: The raw analog data was filtered and amplified to isolate the heartbeat signal from noise.
3. **Calculation**: A microcontroller algorithm measured the period between peaks to calculate the beats-per-minute (BPM) in real-time.
## Embedded Systems: Reflow Oven Controller
URL: https://samsongama.com/portfolio/over-controller/
I collaborated with a team of six to engineer a precise **reflow soldering oven controller** using the **DE2-8052 microcontroller (FPGA)**. The system aimed to adhere to industry-standard reflow thermal profiles.
## Technical Architecture
The project integrated low-level hardware control with high-level software interfaces:
- **Firmware (Assembly)**: Wrote optimized assembly code to handle sensor data acquisition and heating element control loops.
- **Middleware (Java)**: Developed a desktop application that communicated over serial (UART) to receive real-time temperature telemetry and visualize it on a live strip chart.
- **Database (SQLite)**: Integrated a local database to store historical reflow profiles and run parameters.
- **Interface (Android)**: Built a mobile app allowing users to remotely configure reflow parameters (preheat, soak, reflow, cooling) via the Java bridge.
## Outcomes
The solution successfully automated the soldering process, allowing users to monitor temperature curves in real-time on their mobile devices, significantly improving the user experience compared to traditional on-device 7-segment displays.
## Veazey Scholarship Foundation
URL: https://samsongama.com/portfolio/veazey-scholars/
I collaborated with Albert Hynek to design and develop the digital presence for the **Veazey Scholarship Foundation**, an initiative supported by the Canadian law firm **Borden Ladner Gervais LLP (BLG)**.
The project involved creating a professional, accessible informational site for prospective applicants.
*Note: I was also a proud recipient of the Tom and Phyllis Veazey Scholarship, making this a project of personal significance.*
Visit this site: [http://veazeyscholars.com/](http://veazeyscholars.com/)
## Elsie Roy iPad Project
URL: https://samsongama.com/portfolio/er-ipad-project/
I provided technical consultation and deployment support for the Elsie Roy Elementary iPad project (2010–2013), a pioneering initiative to integrate mobile technology into elementary education.
## Project Scope
The goal was not just to hand out tablets, but to build a personalized learning environment where technology facilitated self-directed education.
### Infrastructure & Technology Stack
To support this "Personalized Learning" framework, I assisted in deploying and configuring:
- **Mobile Device Management (MDM)**: Establishing protocols for synchronizing 30+ notebooks and mobile carts.
- **Network Architecture**: Upgrading and securing portable WiFi connectivity to handle high-density device usage in classrooms.
- **Smart Classroom Integration**: Interfacing iPads with SmartBoard technology for interactive lessons.
- **Accessibility Tools**: Configuring iPod Touch devices for Speech and Language support staff.
## Outcomes
The project shifted the school's approach from "teaching for the iPad" to "teaching *because* of the iPad." It created a seamless feedback loop where:
1. **Cloud-based workspaces** allowed universal access to assignments.
2. **Knowledge libraries** were digitized for instant troubleshooting.
3. **Student Engagement** increased significantly, with students using devices for content creation rather than just consumption (games).
> "Ms. Rosa says our teachers like them too because everyone is so engaged while working independently and responsibly." – *Student Reflection*
## King George Secondary Website
URL: https://samsongama.com/portfolio/kg-website/
I served as one of the lead webmasters for King George Secondary, managing the school's digital presence from ideation in 2010 to a full launch in August 2011. The platform served as the central hub for the school community, replacing fragmented paper bulletins.
## Key Contributions
- **Portal Management**: Maintained a centralized CMS for school events, assignment calendars, and administrative announcements.
- **Live Broadcast Infrastructure**: Engineered a live-streaming solution for the senior Varsity basketball team (2011-2012 season). This involved setting up capture hardware, encoding streams, and distributing them to the public web, significantly boosting community engagement.
- **IT Leadership**: Demonstrated the value of student-led IT initiatives to the administration, creating a model for digital engagement.
*Note: The system was eventually deprecated following a Vancouver School Board (VSB) IT centralization initiative to unify school web architectures.*
## Green Screen Projects
URL: https://samsongama.com/portfolio/green-screen/
During high school, I specialized in post-production and visual effects computation for student film projects. While my collaborator Albert Hynek focused on cinematography and directing, I handled the digital workflow, specifically **chroma key compositing** (green screen).
## Technical Implementation
The primary tool for these projects was **Adobe After Effects CS5/CS6**. My responsibilities included:
- **Keying**: Removing green/blue backgrounds cleanliness using the Keylight effect.
- **Rotoscoping**: Manually isolating subjects when keying failed due to lighting inconsistencies.
- **Compositing**: Integrating subjects into generated backgrounds, often simulating sci-fi environments (Star Trek themes were a frequent motif).
- **Color Correction**: Matching the lighting and color temperature of the foreground subject to the digital background for realism.
This experience built a strong foundation in layer-based compositing logic and timeline management, skills that later translated well into UI/UX animation and non-linear editing.
## Technical Blog Posts
## AI-Accelerated Full-Stack Development in a Rust Project
URL: https://samsongama.com/posts/ai-full-stack/
A Rust-based AI SaaS can blend a WebAssembly-capable backend, a static UI, and contract-first OpenAPI workflows. This post explains how such a project can be structured to **accelerate development with AI across backend, frontend, and CI/CD**, while preserving reliability, coverage, and deployment efficiency.
---
## 1) Architecture designed for AI speedups
The project is structured to let AI assistants and automated tooling make **targeted, safe changes**.
At a high level, the repo is organized into **clear functional zones** rather than a monolithic codebase. Each zone has a single responsibility (public interfaces, domain logic, data access, runtime wiring, and build automation), which makes the system easy to extend without exposing internal details. This separation is deliberate: it lets AI tools make localized edits while humans retain architectural control.
- **Contract-first API**: The OpenAPI spec is the source of truth, enabling AI to modify APIs and regenerate clients safely.
- **Layered backend**: Clear MVC boundaries help AI tools reason about changes (controllers → services → repositories).
- **Static UI build**: Predictable output encourages AI-assisted refactors without runtime surprises.
### MVC format and testability
An explicit MVC-style structure improves testability and AI-assisted change safety:
- **Controllers** are thin and easy to mock, ensuring request/response behavior is testable.
- **Services** hold business logic and can be unit-tested in isolation.
- **Repositories** abstract persistence and enable deterministic test doubles.
This separation makes it easier to write focused tests, reduce regression risk, and let AI tools propose changes without coupling across layers.
### Key structural components
- Backend (Rust + serverless runtime)
- OpenAPI contract
- Generated server/client bindings
- CI/CD orchestration
{{< mermaid >}}
flowchart LR
A[OpenAPI Spec] --> B[Generated Rust Server]
A --> C[Generated UI Client]
B --> D[Rust Services & Repos]
C --> E[UI Features]
D --> F[Serverless Runtime]
E --> G[Static Hosting]
{{< /mermaid >}}
---
## 2) Backend acceleration: Rust + OpenAPI + tests
The backend is designed to **amplify AI productivity** while enforcing correctness:
- **OpenAPI-generated traits and adapters** reduce boilerplate and make AI-driven API additions consistent.
- **Service/repository traits** allow AI to propose isolated changes and test against in-memory or mocked implementations.
- **TDD strategy** standardizes behavior and gives AI tools a clear contract for expected outcomes.
### Why this matters for AI
- AI can update the contract, regenerate bindings, and implement the service without guessing types or endpoints.
- With strict layering, AI can localize changes and avoid leaking business logic into controllers or repositories.
{{< mermaid >}}
sequenceDiagram
autonumber
participant API as OpenAPI Spec
participant GEN as Generated Rust Axum
participant SVC as Service Layer
participant REPO as Repository Layer
API->>GEN: Generate route traits & models
GEN->>SVC: Call implemented handlers
SVC->>REPO: Persist/query data
REPO-->>SVC: Results
SVC-->>GEN: Response models
{{< /mermaid >}}
---
## 3) Frontend acceleration: generated clients + static UI
The UI consumes **generated OpenAPI clients**, which is ideal for AI-assisted feature work:
- The client stays in sync with backend changes.
- The UI can focus on state, layouts, and UX rather than hand-written network glue.
AI assistants can:
- Add endpoints to the spec
- Regenerate the UI client
- Implement UI state changes with compile-time guidance
This reduces “API drift” and improves confidence in AI-generated frontend changes.
---
## 4) CI/CD acceleration without sacrificing reliability
The project enforces reliability through **standardized automation targets** that are easy for AI tools to call and reason about:
- Linting and formatting
- Unit and integration tests
- Coverage and security checks
- Serverless + static deployment
Relevant orchestration is centralized in reproducible automation scripts. Policy rules require tests and coverage for any change, which keeps AI-generated modifications **safe to merge**.
{{< mermaid >}}
flowchart TD
A[AI Change Proposal] --> B[Automation Targets]
B --> C[Format/Lint/Test/Coverage]
C --> D{Pass?}
D -- Yes --> E[Deploy Serverless + Static]
D -- No --> F[Fix & Re-run]
{{< /mermaid >}}
---
## 5) Serverless-first deployments enable fast iteration
Deployments are aligned with serverless compute and static hosting, a great match for AI-assisted workflows:
- **Serverless edge/runtime** keeps backend latency low and enables global execution.
- **Static hosting** publishes UI outputs quickly.
- **CLI-driven deploys** keep build artifacts consistent with CI.
This encourages a tight loop: AI changes → tests → deploy preview → verify.
### Cost curve comparison (illustrative)
{{< mermaid >}}
xychart-beta
title "Cost vs. Usage (Illustrative)"
x-axis "Monthly Requests" [10k, 50k, 100k, 500k, 1M, 5M]
y-axis "Monthly Cost ($)" 0 --> 2000
line "Serverless" [0, 5, 20, 120, 300, 1500]
line "VM/Kubernetes" [120, 140, 160, 400, 700, 1200]
{{< /mermaid >}}
### Cost-aware validation, then scale-up
This architecture is especially valuable for **early customer validation**:
- Serverless deployments often offer generous free tiers or low-cost pay-as-you-go pricing.
- You can validate product-market fit without committing to always-on infrastructure.
- Usage-based billing aligns cost to adoption, which is ideal for the first customers.
As the product reaches a defined threshold (e.g., **number of customers**, **monthly requests**, or **GPU minutes**), the same architecture can shift to **VMs or Kubernetes** to optimize cost and performance:
- Move latency-sensitive services to VMs for predictable performance.
- Use Kubernetes for horizontal scaling and workload isolation.
- Keep the API contract and client generation unchanged, minimizing migration risk.
This creates a pragmatic path: **serverless for validation**, **VM/Kubernetes for scale**.
### Migration decision map
{{< mermaid >}}
flowchart TD
A[Start: Low Usage] --> B[Serverless + Static Hosting]
B --> C{Threshold Reached?}
C -- No --> B
C -- Yes --> D[Hybrid: Move hot paths to VMs]
D --> E[Full Kubernetes if growth continues]
{{< /mermaid >}}
---
## 6) Modern AI topics addressed by this workflow
This layout naturally supports many *current AI development best practices*:
### ✅ AI-assisted coding with guardrails
- Structured layers and strict contracts reduce hallucinations.
- Generated code ensures type-safe changes.
- TDD and coverage requirements limit regressions.
### ✅ CI/CD with AI-driven automation
- Standardized `make` targets let AI run repeatable steps.
- Predictable deployment pipelines reduce human review overhead.
### ✅ LLM-friendly docs and policy
- A public LLM policy file defines crawling rules for public pages.
- Automated policy rules codify tests and security requirements.
### ✅ AI-augmented API evolution
- OpenAPI contract enables safe AI-assisted API design.
- Client regeneration prevents breaking front/back drift.
### ✅ Responsible productivity gains
AI accelerates development **without removing human oversight** by:
- Requiring tests for every change
- Enforcing deterministic pipelines
- Keeping deployments reproducible
This improves delivery velocity and reduces toil, while preserving reliability and accountability.
### ✅ Agentic AI for request → tested PR
As the workflow matures, **agentic AI** can turn product requests into ready-to-review changes:
1. A feature request arrives in Slack via a structured template (user story, acceptance criteria, priority).
2. An agent analyzes the request, maps it to API/UI changes, and drafts a plan.
3. The agent applies the changes, writes tests, and runs the automated checks.
4. A pull request is opened with passing tests, a summary, and any risk notes.
This creates a fast, auditable path from stakeholder request to a **tested PR**, while keeping human review as the final gate.
---
## 7) Example: an AI-assisted full-stack change (contract-first)
1. Update the OpenAPI contract with a new endpoint.
2. Regenerate server and client bindings.
3. Implement backend logic using services + repositories.
4. Extend the UI using the generated client.
5. Run automated targets for test, coverage, and deployment readiness.
{{< mermaid >}}
flowchart LR
A[Edit OpenAPI] --> B[Generate Bindings]
B --> C[Implement Rust Service]
B --> D[Update UI]
C --> E[Tests + Coverage]
D --> E
E --> F[Deploy]
{{< /mermaid >}}
---
## 8) Where AI helps most in this project
- **Backend**: propose new endpoints, add service tests, and improve repository queries.
- **Frontend**: generate UI states and wiring using strongly-typed API clients.
- **Ops**: assist with deploy scripts, config validation, and log analysis.
- **Docs**: keep API and workflow documentation synchronized with code.
---
## 9) Tools that could make the project better
The following categories of tools can raise quality and speed without exposing internal details:
- **AI coding assistants**: Accelerate refactors, test writing, and boilerplate reduction while keeping human review in control.
- **Agent runners**: Orchestrate multi-step changes (design → implement → test → PR) with audit logs and policy gates.
- **Static analysis and linters**: Enforce style, security, and correctness in both backend and frontend code.
- **Security scanners**: Surface dependency and supply-chain risks before release.
- **Performance profiling**: Identify hot paths and regressions early, especially for serverless workloads.
- **Contract testing**: Validate API compatibility across server and clients.
- **End-to-end testing**: Catch integration breakage across UI, API, and data layers.
- **Observability tooling**: Centralized logs, metrics, and traces for fast root-cause analysis.
- **Cost monitoring**: Track serverless spend and identify the right moment to migrate to VM/Kubernetes.
- **Feature flagging**: Ship safely with staged rollouts and A/B testing.
---
## 10) Summary
A Rust-based product can be built for speed **without sacrificing correctness**. A contract-first API, generated clients, strict testing discipline, and a serverless-first deployment model make it ideal for AI-accelerated development across the entire stack.
If you want to scale development velocity while keeping CI green, this project structure offers a modern, practical blueprint.
## My Over-Engineered Serverless & Self-Hosted Stack
URL: https://samsongama.com/posts/website-stack/
About 10 years ago, hosting a website meant paying \$5/month for a VPS, configuring Nginx, and manually FTPing files. Today, we have the "Modern Web"—a beautiful, chaotic mix of static site generators, edge computing, vector databases, and zero-trust tunnels.
This website is a static site (Hugo), but it's wrapped in layers of automation and serverless features that make it feel alive. Here is an architectural overview of how `samsongama.com` is built, deployed, and monitored, updated for the current implementation.
## 🏗️ The High-Level Architecture
At its core, the site lives on the **Cloudflare Edge**. Content is distributed globally, while dynamic features (like the AI Chat) run on serverless workers. Analytics are self-hosted on my home lab but exposed securely to the internet.
{{< mermaid >}}
graph TD
User((Visitor))
subgraph Cloudflare["☁️ Cloudflare Edge"]
DNS[DNS & DDoS Protection]
CDN[CDN Cache]
WAF[Web App Firewall]
Pages[Cloudflare Pages]
Functions[Pages Functions /api/chat]
Workers[Cloudflare Workers AI]
Vectorize[Vectorize]
KV[KV Chat Logs]
Tunnel[Cloudflare Tunnel]
end
subgraph Github["🐙 GitHub"]
Repo[Source Code]
Actions[GitHub Actions CI/CD]
end
subgraph HomeLab["🏠 Home Lab"]
Cloudflared[cloudflared daemon]
Analytics[Analytics Container]
end
User -->|HTTPS| DNS
DNS --> WAF
WAF --> CDN
CDN -->|Static Content| Pages
CDN -->|Dynamic API| Functions
Functions --> Workers
Functions --> Vectorize
Functions --> KV
CDN -->|ping.samsongama.com| Tunnel
Tunnel <-->|Secure Connection| Cloudflared
Cloudflared <--> Analytics
Repo -->|Push| Actions
Actions -->|Deploy| Pages
{{< /mermaid >}}
---
## 1. Development & Quality Assurance
Quality starts before any deployment. Quality checks run through **Make targets** on demand and in CI:
1. **Linting**: `make lint` checks all JavaScript (ESLint); `make format-check` checks YAML and CSS formatting; workflow linting uses `actionlint`.
2. **Content Checks**: `make audit-content` validates front matter coverage. Production rendering is checked separately in CI.
3. **Tests**: `make test` runs the complete offline Node.js unit suite.
```bash
# The offline validation entry point
make ci-check
```
---
## 2. CI/CD: GitHub Actions
Production deployment is handled by a **GitHub Actions** workflow on pushes to `develop`. Pull requests targeting `develop` run validation without deploying or making paid embedding calls. Make targets also support deliberate local builds and deployments.
### The Pipeline Steps
1. **Checkout**: Pulls the latest code.
2. **Setup Node & Hugo**: Installs dependencies.
3. **Validate & Build**: Runs `make ci-check`: workflow and JavaScript linting, offline tests with coverage, corpus checks, Functions compilation, PostCSS/PurgeCSS, the production Hugo build, and generated-layout tests.
4. **Refresh Corpus**: Runs `make ai-refresh` to skip an unchanged corpus or embed a changed one into a versioned Vectorize namespace. It waits for indexing before preparing the matching deployment configuration; failure blocks deployment.
5. **Deploy**: Runs `make deploy-built` to upload the validated `public/` output and Functions to Cloudflare Pages.
6. **Cleanup**: Removes previews, prunes old production deployments while retaining rollback history, and deletes versioned corpora no retained deployment references.
For example, a CSS-only change can reuse the existing corpus. A published content edit changes the corpus hash and requires new embeddings before the deployment proceeds.
{{< mermaid >}}
sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant Build as Build Container
participant CF as Cloudflare Pages
participant Vec as Vectorize DB
participant AI as Workers AI
Dev->>GH: git push develop
GH->>Build: Spin up Runner
Build->>Build: Install Hugo & Node
Build->>Build: make ci-check
rect rgb(20, 20, 20)
Note over Build, Vec: Refresh changed corpus; skip unchanged corpus
Build->>Build: Parse content and compute corpus hash
opt Corpus changed
Build->>AI: Generate embeddings
AI-->>Build: Return vectors
Build->>Vec: Upsert versioned records
Build->>Vec: Wait for indexing completion
end
end
Build->>CF: Deploy assets, Functions and matching namespace
CF-->>Dev: Deployment Success 🚀
Build->>CF: Prune previews and old deployments
Build->>Vec: Delete unreferenced corpora
{{< /mermaid >}}
---
## 3. The Edge: Cloudflare Ecosystem
Once deployed, the site lives on Cloudflare's network. Static hosting, edge caching and managed TLS reduce the infrastructure I operate; dynamic AI and storage still have usage limits and potential charges.
### DNS & CDN
Cloudflare proxies all traffic. This means:
- **SSL is automatic:** I don't manage certificates; Cloudflare handles edge encryption.
- **Caching:** Static assets (images, CSS, JS) are cached in data centers close to the user, reducing latency.
- **Build-Time Optimization:** Hugo minifies output, while PostCSS/PurgeCSS builds the production stylesheet. This does not depend on Cloudflare auto-minification.
### Workers & Vectorize (The "Smart" Layer)
This is where the [AI Assistant](/posts/2026-01-25-ai-chat/) lives. A **Cloudflare Pages Function** handles `/api/chat`, **Workers AI** provides embedding and answer models, and **Vectorize** holds the searchable corpus. I do not operate a dedicated Python inference server or train model weights.
- **Conversation:** The browser sends bounded recent history. A follow-up such as "What did he do before that?" is rewritten into a standalone search question before embedding.
- **Retrieval:** Vectorize returns three semantic matches. Matching child excerpts expand into bounded source sections, with generic canonical-source links keeping curated summaries tied to authoritative public content.
- **Generation:** The answer model receives retrieved text, history and the original question, then streams its response. Insufficient context produces an abstention; service failures produce explicit errors.
- **Transparency:** The widget shows actual progress stages, public retrieved excerpts and expandable timing/token/cost diagnostics. Source retrieval does not independently verify an answer.
- **State:** Conversation history stays in browser storage across deployments until manually cleared. When configured, KV separately records questions, responses and answer-model usage.
For example, an internship excerpt can lead retrieval to the full newest-first employment section, rather than presenting that historical fragment as recent experience. This reduces missing context; it does not guarantee that a model interprets every date correctly.
Edge execution reduces the need to manage application servers, but model inference and retrieval still dominate some responses. I measure latency rather than assuming every answer is instant.
---
## 4. Observability: Self-Hosted Analytics via Tunnels
I self-host **Umami**, served at `ping.samsongama.com`, rather than relying on a third-party analytics dashboard. Cloudflare still proxies the traffic, so self-hosting is not a claim that no external infrastructure handles the data. How do I expose the service without forwarding an inbound port on my home router?
**Cloudflare Tunnels (cloudflared)**.
### How it works
Instead of forwarding port `443` on my home router, I run a lightweight daemon called `cloudflared`.
1. `cloudflared` creates an outbound-only connection to Cloudflare's edge.
2. A public hostname, `ping.samsongama.com`, routes analytics traffic through the tunnel.
3. Cloudflare Access can protect private dashboard routes, while the tracking script and collection endpoints must remain accessible to visitors.
{{< mermaid >}}
flowchart LR
Visitor["Visitor Browser"]
CF["Cloudflare Edge"]
Router["Home Router (No Open Ports)"]
Server["Home Server"]
Container["Analytics Docker"]
Visitor -->|"HTTPS"| CF
CF <-->|"Encrypted Tunnel"| Server
subgraph HomeNetwork["Home Network"]
Router
Server -->|"Running cloudflared"| Container
end
style Router stroke:#f00,stroke-width:2px,stroke-dasharray:5
{{< /mermaid >}}
### Benefits
- **No Port Forwarding:** The analytics service does not require an inbound router port or a public DNS record pointing directly to my home IP.
- **Edge Protection:** Public requests pass through Cloudflare; this does not make the origin or application immune to abuse.
- **Access Control:** I can put the dashboard usage behind **Cloudflare Access** (OAuth / Email OTP), so only I can view the data, while the tracking script remains public.
## Conclusion
This stack represents the sweet spot of modern web development: **Static reliability** mixed with **serverless power**, all glue-coded together with **CI/CD** and secured by **Zero Trust** networking.
Static delivery is inexpensive, but this is not an infinitely scalable or universally free stack. Workers AI, Vectorize and KV have quotas and usage-based costs, while self-hosting adds hardware, power and maintenance. The chat's displayed cost estimates cover answer and rewrite tokens, not the entire infrastructure bill.
## What's Next
- **Retrieval quality:** Expand regression questions and human review, especially for ambiguous follow-ups and unsupported claims.
- **Runtime controls:** Add request deadlines and rate limits, and measure behavior under concurrent traffic.
- **Ingestion efficiency:** Reuse unchanged document embeddings across corpus versions instead of regenerating the whole changed corpus.
## Building a Serverless AI Chatbot for My Static Portfolio
URL: https://samsongama.com/posts/ai-chat/
Static sites are fast and straightforward to host, but visitors still need a way to find relevant information. I built a custom assistant for questions such as "What has Samson built at scale?" rather than embedding a generic chatbot iframe. This article describes the current implementation, updated in October 2026.
## The architecture
The assistant uses **Retrieval-Augmented Generation (RAG)**: find relevant portfolio evidence, supply it to an answer model, and stream the response. It does not train a model or browse the web.
- **Frontend:** Hugo with Blowfish, a native dialog and modular JavaScript.
- **API:** Cloudflare Pages Functions with Hono at `/api/chat`.
- **Inference:** Workers AI; GLM-4.7-Flash is the default answer and rewrite model.
- **Search:** Cloudflare Vectorize with BGE-base-en-v1.5 embeddings, 768 dimensions.
- **State:** Browser conversation history, plus optional server-side KV response logging.
## From question to answer
The browser sends a question and bounded recent history. First-turn questions go straight to embedding. Follow-ups are rewritten for search: after "Tell me about Bitcomplete," "What did he do before that?" can become "What role did Samson hold before Bitcomplete?" Generation still receives the original question and history.
{{< mermaid >}}
sequenceDiagram
participant User
participant Frontend
participant Function as Pages Function
participant VectorDB as Vectorize
participant AI as Workers AI
User->>Frontend: Ask a question
Frontend->>Function: POST query and bounded history
Function->>Function: Validate request and service bindings
opt Follow-up with history
Function->>AI: Rewrite standalone search question
AI-->>Function: Search question
end
Function-->>Frontend: Progress events
Function->>AI: Embed search question
AI-->>Function: Query vector
Function->>VectorDB: Search deployed namespace, top 3
VectorDB-->>Function: Matches
opt Referenced source sections
Function->>VectorDB: Fetch section records
VectorDB-->>Function: Canonical and parent evidence
end
Function->>Function: Expand, deduplicate and bound context
Function-->>Frontend: Public source excerpts
Function->>AI: Generate with context, history and query
AI-->>Function: Model stream
Function-->>Frontend: Normalized SSE answer and metrics
Frontend-->>User: Render answer and expandable sources
{{< /mermaid >}}
History is bounded to four messages, 2,000 characters each and 4,000 characters total. Retrieval selects three matches; expanded sections are capped at 6,000 characters and the assembled context at 12,000. The answer has a 512-token completion budget. These bounds control work, not factual correctness.
Insufficient context produces an explicit abstention without calling the answer model. Missing bindings return HTTP errors before streaming. Failures after SSE begins become error events instead of an empty successful answer.
## Building the knowledge base
`make ai-refresh` coordinates the maintained ingestion entry point, `scripts/generate_embeddings.mjs`, and corpus modules. Structured Markdown/HTML parsing removes presentation controls while preserving lists, links and code. Hugo's published-page export supplies canonical URLs, including slugs and permalink rules.
Level-one/two headings define sections. Long sections produce bounded parent records and 2,000-character children with 200-character overlap. Curated excerpts can supplement themselves with a canonical public section:
```yaml
retrievalSource: "content/resume/_index.md"
retrievalSection: "Professional Experience"
```
For example, a historical internship hit can add the full newest-first employment section while retaining unique curated facts. Internal excerpts help generation but are not exposed in the public source panel.
{{< mermaid >}}
flowchart LR
Content[Markdown and front matter] --> AST[Structured normalization]
Hugo[Hugo published URLs] --> Corpus[Validated versioned corpus]
AST --> Corpus
Corpus --> Embeddings[Workers AI embeddings]
Embeddings --> Index[Vectorize candidate namespace]
Index --> Ready[Wait for indexing]
Ready --> Deploy[Deploy matching namespace]
{{< /mermaid >}}
Corpus namespaces and record IDs include content/configuration identity and full source paths. Different page bundles cannot overwrite each other merely because both use `index.md`. Unchanged corpora skip ingestion; changed corpora are re-embedded. Indexing must complete before deployment proceeds.
## A native, inspectable chat window
Starter questions introduce experience, projects, scale and the assistant itself. The widget respects the theme, supports keyboard controls and uses a full-height mobile layout.
Progress labels reflect actual operations: understanding a follow-up, preparing search, finding sources and writing an answer. An elapsed counter runs until answer text arrives. Failed requests offer a manual Retry using the original question and pre-request history; there are no automatic paid retries.
**Retrieved sources** displays public excerpts actually supplied to generation, not a claim that each answer sentence was independently verified. Markdown renders with restricted markup. Mermaid diagrams load when the panel opens; invalid or truncated diagrams retain their source with an explanation.
The diagnostics footer shows server-side total latency, time to first answer token and estimated answer/rewrite token cost. Details expands stage timings and token counts. Missing provider usage is unavailable, not zero; the estimate excludes embeddings, Vectorize, KV and hosting.
Conversation history persists on the device across deployments until manually cleared. Clear History does not delete separately stored server-side logs.
## Verification and limits
```bash
make ai-check # Corpus identities, Hugo URL provenance and evaluation labels
make test # Offline regressions
make ai-build # Compile Functions with Node.js 22+
make dev-ai # Local site with the chat API
```
Tests cover parsing preservation, section expansion, explicit errors, streaming, token accounting and deployment gates. Live evaluations separately test retrieval and generation against labeled questions. For example, a recent-experience regression checks for Bitcomplete, Demonware and dated evidence instead of accepting a plausible internship summary.
Prompt instructions and pattern checks are not a complete security boundary. Semantic search can miss relevant evidence, models can misinterpret dates, and term-based evaluations cannot prove factual entailment. Runtime deadlines, rate limits, human review and concurrency testing remain useful next steps.
Static hosting can be inexpensive, but AI inference and storage have quotas and usage-based costs. The point of this architecture is not "free AI": it is a small, inspectable system whose retrieval, transport, quality and economics can be measured separately.
## Privacy-First Analytics: Self-Hosting Umami with Cloudflare Tunnels
URL: https://samsongama.com/posts/self-hosted-analytics/
I wanted to know how people were using my portfolio, but I didn't want to feed the data surveillance machine of Google Analytics. I also didn't want a heavy script slowing down my blazing fast [Blowfish](https://blowfish.page/) site.
Enter [Umami](https://umami.is/). It's open-source, lighter than a feather, and privacy-focused (no cookies!).
Here is how I deployed it securely on my home server using Docker and Cloudflare Tunnels, ensuring my home IP remains hidden.
## The Architecture
The setup is surprisingly simple but robust. Instead of opening ports on my router (port forwarding 80/443), which exposes my home IP to the world, I use **Cloudflare Tunnels**. A lightweight daemon (`cloudflared`) creates an outbound connection to Cloudflare's edge, creating a secure tunnel for traffic to flow in.
{{< mermaid >}}
flowchart TD
subgraph Client
Browser[User Browser]
end
subgraph "Cloudflare Edge Network"
CDN[CDN / Cache]
TunnelEntry[Tunnel End Point]
end
subgraph "Cloudflare Pages"
Static[Static Assets]
HTML[index.html]
end
subgraph "Home Lab (Private Network)"
Cloudflared[cloudflared]
Umami[Umami App]
DB[(PostgreSQL)]
end
%% Flow 1: Static Content
Browser -- "GET /" --> CDN
CDN -- "Fetch" --> Static
Static --> Browser
%% Flow 2: Analytics Data
Browser -- "POST /api/send" --> TunnelEntry
TunnelEntry -. "Encrypted Tunnel" .-> Cloudflared
Cloudflared -- "Internal Docker Network" --> Umami
Umami --> DB
linkStyle 0,1,2 stroke:blue,stroke-width:2px;
linkStyle 3,4,5,6 stroke:orange,stroke-width:2px;
{{< /mermaid >}}
This dual-path architecture enables the best of both worlds:
1. **Blue Path:** Static content is served instantly from Cloudflare's global cache (Pages).
2. **Orange Path:** Analytics data travels securely through the tunnel to my home server without ever exposing my IP.
## 1. The Infrastructure: Docker Compose
I orchestrate everything in a single `docker-compose.yml` file. This ensures reproducibility and ease of updates.
### Logging Strategy
First, I set up a robust logging configuration. I pipe logs to Loki for analysis, but limit buffer sizes to prevent memory leaks on my server.
```yaml
x-logging: &default-logging
driver: loki
options:
loki-url: "http://127.0.0.1:3100/loki/api/v1/push"
mode: non-blocking
max-buffer-size: 4m
max-size: 20m
```
### The Services
There are two main stars of the show here:
1. **cloudflared**: This container authenticates with Cloudflare using a token and establishes the tunnel. It's the gatekeeper.
2. **umami**: The analytics engine itself.
```yaml
services:
# 1. Cloudflare Tunnel
# Securely exposes the internal Umami service to ping.samsongama.com
cloudflared-sg:
image: cloudflare/cloudflared:latest
container_name: cloudflared-sg
logging: *default-logging
networks: [dev-tier]
restart: always
command: tunnel --no-autoupdate run
environment:
- TUNNEL_TOKEN=${CLOUDFLARED_SG_TUNNEL_TOKEN}
# 2. Umami Analytics
umami:
image: ghcr.io/umami-software/umami:latest
container_name: umami
restart: unless-stopped
depends_on:
- postgres
environment:
DATABASE_URL: postgresql://umami:${UMAMI_PASSWORD}@postgres:5432/umami_data
# Add IP Geolocation support
GEO_DATABASE_URL: "https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-City.mmdb"
logging: *default-logging
networks: [dev-tier]
volumes:
- umami_data:/app/data
```
*Note: I also use a `postgres` service (not shown above for brevity) which Umami depends on.*
## 2. Secure Networking
Notice that the `umami` service **does not map any ports** (e.g., `ports: - 3000:3000`). This is intentional.
The container lives entirely inside the `dev-tier` Docker network. The `cloudflared` container is also on this network. It proxies traffic directly to `http://umami:3000` internally. The outside world literally cannot touch the Umami instance except through the verified Cloudflare Tunnel.
## 3. Hardening with Nginx
To take security a step further, I don't expose the Umami container directly to the tunnel. Instead, I place an **Nginx** reverse proxy in between. This allows me to selectively expose endpoints.
My public domain (`ping.samsongama.com`) allows legitimate visitors to download the tracking script and send data, but strictly blocks the admin dashboard.
```nginx
# Public Facing Block (ping.samsongama.com)
server {
server_name ping.samsongama.com;
# 1. Allow public access to tracking scripts
location ~ ^/(script\.js|umami\.js)$ {
proxy_pass http://umami:3000;
# ... proxy headers ...
}
# 2. Allow public access to tracking API (metrics collection)
location /api/send {
proxy_pass http://umami:3000;
# ... proxy headers ...
}
# 3. Block everything else (Login Page, Admin Panel)
location / {
return 403;
}
}
```
If I need to check my stats, I access the dashboard via a separate, private domain (`https://analytics.local`) that is only available on my home LAN.
```nginx
# Internal Admin Block (analytics.local)
server {
listen 443 ssl;
server_name analytics.local;
# Full access to the entire application
location / {
proxy_pass http://umami:3000;
proxy_set_header Host $host;
# ...
}
}
```
## 4. Integration with Hugo
Once the backend is running at `https://ping.samsongama.com`, integrating it into Hugo is trivial.
I keep the script external so I can update the backend without touching the site code. In the Blowfish theme, we can inject this into the `` using `layouts/partials/extend-head.html`.
```html
{{/* Umami Analytics */}}
```
Using `defer` ensures the script doesn't block the initial page render, keeping those Lighthouse scores at 100.
## Future Improvements
While this setup is robust, there are a few enhancements on my roadmap:
1. **Database Backups to R2**: Automating PostgreSQL dumps and shipping them to Cloudflare R2 for off-site disaster recovery.
2. **High Availability**: Adding a second `cloudflared` replica on a Raspberry Pi to ensure the tunnel stays up even if the main server takes a brief nap.
## Conclusion
By self-hosting Umami, I own my data. By using Cloudflare Tunnels, I protect my home infrastructure. It's a win-win that costs nothing but a bit of configuration time.
Now I can see exactly which blog posts are trending without compromising my visitors' privacy.
## Building a Reproducible Infra Lab with Packer, Terraform, Ansible, and Docker Compose
URL: https://samsongama.com/posts/homelab/
> This post is intentionally generic and redacts all environment-specific details. Replace placeholders (like ``, ``, and ``) with your own values.
## Overview
A reliable infrastructure lab is built on **repeatable, auditable, and layered automation**. The most effective way to achieve this is to separate concerns into four distinct layers:
1. **Image Baking** (Packer) — produce a minimal, consistent base image.
2. **Infrastructure Provisioning** (Terraform) — create compute, storage, and network resources.
3. **Configuration Management** (Ansible) — apply OS hardening and tool installation.
4. **Service Orchestration** (Docker Compose) — run application stacks with minimal drift.
This guide walks through an end-to-end architecture you can build and expand over time. The flow is straightforward and safe to extend.
---
## High-Level Architecture
{{< mermaid >}}
flowchart TD
A[Source Control] --> B[Packer Build]
B --> C[Golden Image Artifact]
C --> D[Terraform Plan]
D --> H1[Proxmox Hypervisor]
D --> E[Provisioned Hosts]
E --> F[Ansible Playbooks]
F --> G[Hardened Hosts]
G --> H[Docker Compose Stacks]
H --> I[Services Online]
{{< /mermaid >}}
**Key properties of this layout:**
- Every stage has a clean input/output boundary.
- Any stage can be re-run without re-implementing the others.
- The system is resilient to partial rebuilds (e.g., re-provision only, or re-harden only).
---
## Repository Structure (Conceptual)
A clear folder structure makes the pipeline maintainable. The following is a logical layout that you can implement in your own repository:
```text
/packer/
templates/
scripts/
/terraform/
modules/
envs/
/ansible/
playbooks/
roles/
/assets/
containers/
configs/
```
This structure lets each layer evolve without pulling in unrelated changes.
---
## Hypervisor Layer: Proxmox (VMs and LXC)
While Packer, Terraform, Ansible, and Docker Compose are the visible layers, they usually sit **on top of a hypervisor**. In this architecture, **Proxmox** is the virtualization substrate. It sets your execution primitives, scaling model, and upgrade path.
### Why Proxmox fits this model
Proxmox provides:
- **VMs** for strong isolation, kernel independence, and OS customization.
- **LXC containers** for lightweight system services and fast boot times.
- **Snapshots and backups** that fit well with immutable image workflows.
- **A stable API surface** for automation and integration with Terraform.
### VM vs LXC decision points
- **Use VMs** when you need kernel-level isolation, custom kernels, or full OS control.
- **Use LXC** for lightweight, single-purpose services or build agents.
In practice, a common pattern is:
- **Core services in VMs** (e.g., edge, monitoring, data stores).
- **Utility services in LXC** (e.g., DNS, internal tools, CI runners).
### Where Docker Compose fits
Docker Compose runs **inside VMs**, not on the hypervisor directly. That keeps the separation of concerns clear:
- Proxmox manages compute and isolation.
- VMs provide a stable OS boundary.
- Docker Compose orchestrates app-level services within those VM boundaries.
{{< mermaid >}}
flowchart LR
P[Proxmox] --> V[VMs]
P --> L[LXC]
V --> D[Docker Compose]
{{< /mermaid >}}
---
## Layer 1: Image Baking with Packer
### Why bake images
Baked images give you predictable system bootstrapping. A base image means:
- All instances start from the same OS snapshot.
- Core system packages and agents are already installed.
- Initial boot time is faster (fewer first-boot tasks).
### Recommended Packer Responsibilities
Keep your Packer responsibilities narrow and predictable:
- Base OS updates
- Security patches
- Essential system packages (e.g., `sudo`, SSH server)
- Optional: VM guest agents, disk utilities, cloud-init tools
Anything beyond that is better handled by Ansible to avoid rebuilding images unnecessarily.
### Example: Packer Workflow
{{< mermaid >}}
sequenceDiagram
participant Git as Git Repo
participant Packer as Packer
participant Image as Image Registry
Git->>Packer: Build request (template + vars)
Packer->>Packer: Provision base OS
Packer->>Packer: Install core utilities
Packer->>Image: Publish golden image
{{< /mermaid >}}
### Common Pitfalls
- **Image bloat:** Avoid installing application stacks in Packer. It slows rebuilds.
- **Drift:** If you mutate images after provisioning, you lose reproducibility.
- **Version creep:** Always tag image outputs with explicit versions.
---
## Layer 2: Infrastructure Provisioning with Terraform
### Why Terraform
Terraform gives you:
- Declarative infrastructure
- Transparent plans and diffs
- Dependency tracking
- State management
That makes it a good foundation for a lab that should be reproducible and shareable.
### Recommended Terraform Responsibilities
Terraform should focus on _infra ownership_:
- VMs / instances
- Networks
- Firewalls
- Storage and volumes
- DNS records (if required)
Everything else (packages, services, app configs) should be deferred to Ansible or Docker Compose.
### Terraform Module Strategy
A disciplined module structure helps keep your infrastructure understandable:
{{< mermaid >}}
graph LR
A[Root Module] --> B[Compute Module]
A --> C[Network Module]
A --> D[DNS Module]
A --> E[Inventory Module]
{{< /mermaid >}}
### Declarative Outputs and Inventory
Terraform can generate:
- Dynamic inventory files for Ansible
- Local artifacts for tools (like SSH or editor configs)
- Outputs that power downstream provisioning steps
This cuts down on manual coordination across layers.
> **Hypervisor note:** Terraform can target Proxmox APIs to create both **VMs** and **LXC containers**, allowing you to treat the hypervisor as a first-class infrastructure provider.
---
## Layer 3: Configuration Management with Ansible
### Why Ansible after Terraform
Terraform provisions hosts, but it does **not** manage the OS lifecycle well. Ansible excels at:
- Enforcing configuration state
- Running idempotent provisioning
- Applying role-driven logic
- Simplifying system updates
### Recommended Playbook Structure
Split playbooks by concern, not by host:
- **Bootstrap:** OS updates, base tools, SSH hardening
- **Harden:** firewall, kernel tuning, security baselines
- **Deploy:** service dependencies, config files, user provisioning
{{< mermaid >}}
flowchart LR
A[Provisioned Host] --> B[Bootstrap Playbook]
B --> C[Harden Playbook]
C --> D[Deploy Playbook]
{{< /mermaid >}}
### Idempotency Patterns
Use these patterns to keep Ansible safe to re-run:
- `changed_when` for commands that are safe but not idempotent
- `creates:` in `command` and `shell` tasks to avoid rework
- Explicit `state: present` / `state: absent` definitions
### Security Model
Always separate variables and secrets:
- Store secrets in encrypted files or vault systems
- Use environment variables or CI-injected values
- Never commit plaintext credentials
#### Encrypted secrets with age + sops (CI-friendly)
For full automation, keep **encrypted** secrets in version control and decrypt them only in CI. A common approach is:
1. Generate an age keypair with `age-keygen` on a trusted machine.
2. Configure sops to use the age public key.
3. Encrypt secret files (including terraform variables) before committing.
4. In CI, load the age private key from GitHub Actions secrets and decrypt at runtime.
{{< mermaid >}}
flowchart TD
Dev[Developer workstation] -->|age-keygen| AgeKeys[Age keypair]
AgeKeys -->|public key| SopsConfig[sops.yaml config]
SecretsPlain[Plaintext secrets] -->|sops encrypt| SecretsEnc[Encrypted secrets]
SopsConfig -->|rules| SecretsEnc
SecretsEnc -->|git commit| Repo[Git repository]
Repo -->|checkout| CI[CI runner]
CI -->|age private key from secrets| Decrypt[sops decrypt]
Decrypt --> Ephemeral[Ephemeral files for jobs]
Ephemeral -->|apply| Terraform[Terraform/Ansible]
{{< /mermaid >}}
This lets you safely commit encrypted files such as [terraform.tfvars.json](terraform.tfvars.json) while keeping plaintext out of the repo.
{{< mermaid >}}
sequenceDiagram
participant Dev as Developer
participant Repo as Git Repo
participant CI as CI Runner
participant Vault as CI Secrets Store
participant Sops as SOPS
participant Age as age
Dev->>Age: Generate keypair
Dev->>Sops: Configure age public key
Dev->>Sops: Encrypt secrets
Dev->>Repo: Commit encrypted files
Repo->>CI: Pipeline starts
CI->>Vault: Fetch age private key
CI->>Sops: Decrypt secrets
Sops->>CI: Plaintext in temp workspace
CI->>CI: Use secrets, then delete
{{< /mermaid >}}
**Why this works:**
- Encrypted files remain auditable and versioned.
- CI pipelines are fully automated without manual secret handling.
- Rotating keys is straightforward (re-encrypt with a new age key).
**Good practice:**
- Treat encrypted files as the source of truth.
- Decrypt into ephemeral paths in CI.
- Never persist decrypted files as build artifacts.
---
## Layer 4: Service Orchestration with Docker Compose
### Why Docker Compose
Docker Compose is lightweight and ideal for lab stacks. It provides:
- Multi-service wiring
- Dependency ordering
- Simple replication
- Portable definitions
It fits well in a lab where you want fast iteration without standing up a full Kubernetes cluster.
### Compose Pattern: Split by Domain
Rather than one monolithic file, split stacks by concerns:
- `docker-compose.core.yml`
- `docker-compose.monitoring.yml`
- `docker-compose.services.yml`
Then aggregate them with a top-level include file or manual composition scripts.
{{< mermaid >}}
graph TD
A[Base Compose] --> B[Monitoring Stack]
A --> C[Services Stack]
A --> D[Edge/Proxy Stack]
{{< /mermaid >}}
### Configuration Hygiene
- Use `.env` for non-sensitive parameters
- Use `.env.local` for local-only overrides
- For secrets: mount them from a secure vault or encrypted store
> **VM boundary reminder:** Docker Compose is intentionally scoped to **within a VM**, so that service-level failures or upgrades do not impact the hypervisor or other workloads.
---
## Development Environment Strategy
A solid dev environment keeps this workflow sustainable.
### Recommended Tooling
- **Formatter and lint hooks** for YAML, HCL, and shell scripts
- **Task runners** to standardize common commands
- **CI checks** that validate syntax and schema
### Local Iteration Loop
{{< mermaid >}}
sequenceDiagram
participant Dev as Developer
participant Repo as Repository
participant CI as CI/Lint
participant Lab as Lab Host
Dev->>Repo: Commit change
Repo->>CI: Run format + lint
CI->>Repo: Report status
Dev->>Lab: Apply Terraform + Ansible
Lab->>Dev: Validation feedback
{{< /mermaid >}}
### Tips for Fast Feedback
- Keep a small "canary" host for rapid testing
- Use targeted Ansible tags
- Isolate Compose stacks to avoid restarting everything
---
## End-to-End Flow (Detailed)
Putting it all together:
1. **Bake** a minimal OS image with Packer.
2. **Provision** infrastructure from that image using Terraform.
3. **Bootstrap** and **harden** systems with Ansible.
4. **Deploy** services using Docker Compose.
{{< mermaid >}}
flowchart LR
A[Packer] --> B[Terraform]
B --> C[Ansible]
C --> D[Docker Compose]
{{< /mermaid >}}
Each layer stays focused and can be improved independently.
---
## Operational Best Practices
### Versioning and Release Strategy
- Tag Packer images with `vYYYYMMDD` or `vX.Y.Z`
- Store Terraform state in a remote backend for multi-user workflows
- Pin Ansible role versions for stable results
- Version Compose files and avoid floating tags for critical services
### Observability
Even in a lab, observability prevents unknown drift:
- Centralized logs
- Metrics collection
- Optional alerting routes
### Documentation
Treat docs as part of the infrastructure:
- Document service ports and security policies
- Keep a dependency map in the repo
- Explain build and provisioning workflows
---
## Example: Skeleton Automation Map
{{< mermaid >}}
mindmap
root((Infra Lab))
Packer
Base OS
Guest Agent
Security Updates
Terraform
Compute
Network
DNS
Inventory
Ansible
Bootstrap
Harden
Users
Tooling
Docker Compose
Proxy
Monitoring
Services
{{< /mermaid >}}
---
## Final Thoughts
This approach is modular and practical. It lets you:
- swap Packer builders (VMs, cloud images, containers)
- evolve Terraform modules safely
- re-run Ansible for drift correction
- redeploy services with minimal disruption
Keep each layer clear and minimal, and the lab stays stable as it grows.
---
## Next Steps
If you want to extend this pattern:
- Add a CI pipeline that validates every layer.
- Introduce an inventory generator from Terraform outputs.
- Add automated compliance checks in Ansible.
- Add a service catalog for Docker Compose stacks.
### Future path: Kubernetes with TalosOS
If the lab outgrows Compose, a **TalosOS-based Kubernetes cluster** on Proxmox VMs is a solid next step. TalosOS offers:
- Immutable, minimal OS for Kubernetes nodes
- API-driven operations (no SSH required)
- Predictable upgrades and rollbacks
It still fits the same layered model:
{{< mermaid >}}
flowchart LR
A[Packer] --> B[Proxmox VMs]
B --> C[TalosOS Nodes]
C --> D[Kubernetes]
D --> E[Platform Services]
{{< /mermaid >}}
You can stage this transition by:
- Keeping Compose for legacy or low-complexity stacks
- Introducing a small TalosOS cluster for new workloads
- Migrating services gradually using GitOps tooling
This setup scales from a single test host to a serious homelab or small production setup without losing the simplicity that keeps it manageable.
## Zeit - Functions as a Service
URL: https://samsongama.com/posts/zeit/
> **Update 2020:** Zeit has rebranded to [Vercel](https://vercel.com). The `now` command and `zeit.co` URLs referenced below correspond to the platform's state in 2019.
Let me introduce you to this amazing service called [zeit.co AKA ZEIT NOW](https://zeit.co).
I currently use it with another free online service called [MicroBadger](https://microbadger.com/), a service I use to trigger custom Docker builds after a base image such as `alpine` has been updated.
This allows all my personal projects to be on the latest base image, potentially improving performance and security.
The Microservice sends a POST request to a function hosted on ZEIT NOW, and that function runs a bunch of tasks: invoking new builds of personal projects that depend on that image, grabbing changelists, and sending all that information to Slack.
I won't show you how to do that, but I'll show you how to get started with a full CI/CD pipeline.
---
ZEIT NOW is self-described as a *All-in-one: Static and JAMstack deployment, Serverless Functions, and Global CDN.*
In this post, I will be focusing on the *serverless functions* aspect as it is the most unique offering I know of.
Serverless functions are not new. AWS Lambda has been doing it for a few years now, but the utility of Zeit NOW for me is derived from the fact that I did not have to enter any credit card information to get started.
Let's go over the main [limits of the (Hobby) free-tier](https://zeit.co/docs/v2/platform/limits#general-limits):
|2020-01-01|Hobby|Pro|Enterprise|
|---|---|---|---|
|Deployments (per day)|100|2000|Custom|
|Serverless Functions per Deployment|12|24|Custom|
|Serverless Functions per Month|160|640|Custom|
|Serverless Function Duration (Seconds)|10|60|900|
|Deployments created from CLI per week|2000|2000|Custom|
|Team members per Team|-|10|Custom|
But let's also remember the [fair-use policy](https://zeit.co/docs/v2/platform/fair-use-policy):
|Examples of Fair Use|Never Fair Use|
|---|---|
|Jamstack sites and apps|Proxies and VPNs|
|Frontends|Media hosting for hot-linking|
|SPAs|Scrapers|
|Functions that query DBs or APIs|Crypto Mining|
|Blogs, e-commerce, marketing|CPU-intensive APIs (e.g.: Machine Learning)|
---
1. Let's get started, install the [zeit/now-cli](https://github.com/zeit/now-cli).
2. Clone/Fork my repository containing the example codebase [sgama/demo-zeit-now](https://github.com/sgama/demo-zeit-now).
3. Import this project through the [ZEIT web portal](https://zeit.co/import).
4. Login to the now cli:
```bash
now login
```
1. Run and deploy with the CLI:
```bash
/demo-zeit-now$ now
Now CLI 18.0.0
? Set up and deploy “/mnt/c/Vcs/demo-zeit-now”? [Y/n] y
? Which scope do you want to deploy to? MyUser
? Link to existing project? [y/N] n
? What’s your project’s name? demo-zeit-now
? In which directory is your code located? ./
�🔗 Linked to myuser/demo-zeit-now (created .no
�🔍 Inspect: https://zeit.co/myuser/demo-zeit-now/abc12cdef [1s]
✅ Production: https://demo-zeit-now.now.sh [19s]
�📝 Deployed to production. Run `now --prod` to overwrite later (https://zeit.ink/1A).
�💡 To change the domain or build command, go to https://zeit.co/myuser/demo-zeit-now/settings
```
- You should see your deployment at [https://zeit.co/dashboard](https://zeit.co/dashboard)
- Add the following to your repository's secrets for CI/CD here: `https://github.com/$YOUR_USER/$YOUR_REPO/settings/secrets`
|ORG_ID|`jq -r '.orgId' .now/project.json`|
|---|---|
|PROJECT_ID|`jq -r '.projectId' .now/project.json`|
|ZEIT_TOKEN|Get one from [https://zeit.co/account/tokens](https://zeit.co/account/tokens)|
- Uncomment the contents of `.github/workflows/main.yml`
- Push your code and view the CI/CD pipeline run: `https://github.com/$YOUR_USER/$YOUR_REPO/actions`
---
Now you can visit the following URLs:
- `https:/$YOUR_REPO.now.sh/src/nodejs`
- `https:/$YOUR_REPO.now.sh/src/python`
I'll let you figure the rest out, but with this repo, you will have a fully integrated continuous integration and continuous delivery system deploying functions for free.
## Continuous Integration & Deployment: A Practical Introduction
URL: https://samsongama.com/posts/cicd/
Every time a developer changes code, they commit it and push it upstream to a repository. From there, they typically create a Pull Request (PR) for other developers to review. After the PR is approved, the code is merged into the `develop` or `main` branches.
**Without continuous integration and deployment**, that new code involves a manual verification process for integration and a manual deployment step. This is generally a tedious, repetitive, and error-prone task.
## The Problem: Manual Deployment Hell
### My Pre-CI/CD Process
Before implementing automation, my workflow looked something like this:
1. **Local Development**: Use Docker to keep environments consistent.
2. **Manual Integration**: Test services locally on my computer.
3. **Push Code**: Upload changes to the remote repository.
4. **SSH into Production**: Connect to production servers via credentials I had to manage.
5. **Pull and Build**: Pull the latest code and build Docker images directly on the production server.
6. **Deploy**: Run `docker-compose up -d` manually.
### Why This Was Suboptimal
- **Wasted Developer Time**: It was repetitive manual work that took focus away from coding.
- **Production Risk**: Building images on production servers consumed CPU/RAM, potentially slowing down live services.
- **Deployment Delays**: The manual process created bottlenecks; I would deploy less often to avoid the hassle.
- **Human Error**: It was easy to run the wrong command, forget a configuration change, or deploy the wrong branch.
- **No Rollback Strategy**: if a deployment failed, manual recovery was stressful and slow.
*Sure, you could use a container registry and pull from it, but you still run the risk of a bad image being pulled and blocking the system until a healthy image is built (ignoring complex image versioning strategies for a moment).*
## The Solution: Automated CI/CD
Once CI/CD is configured properly, a Pull Request can go through the process of integration testing and deployment **automatically**. If anything fails, notifications are sent instantly via Slack, PagerDuty, or your tool of choice.
### A Modern CI/CD Pipeline
1. **Code Commit** → Triggers the pipeline automatically.
2. **Integration Testing** → Automated verification (Unit/Integration tests).
3. **Image Building** → Consistent, isolated builds on a build server.
4. **Registry Push** → Versioned, immutable artifacts pushed to a private registry.
5. **Deployment** → Automated rollout via Kubernetes or SSH runners.
6. **Notifications** → Real-time status updates to the team.
## Implementation Benefits
### Using Tools like GitLab CI, Travis CI, or GitHub Actions
- **Zero Manual Intervention**: CI/CD pipelines link your services automatically.
- **Safe Builds**: Images are built in isolated environments (runners), never on production hardware.
- **Registry Management**: Images are tagged and versioned automatically (e.g., `v1.0.1`, `sha-a1b2c3`).
- **Kubernetes Integration**: Deploy new images instantly through `kubectl` commands or Helm charts.
- **Real-time Notifications**: You know immediately if a build passes or fails.
### Key Advantages
- **Reliability**: Consistent, repeatable deployments every single time.
- **Speed**: Drastically reduced time from "code complete" to "in production".
- **Safety**: Easy rollback capabilities to previous Docker tags.
- **Visibility**: Full logs of every deployment status.
- **Developer Focus**: More time coding, less time babysitting terminals.
## Why Automate Early
**Human Psychology**: Impending tedious tasks (like manual deployments) make us look less forward to shipping features. We subconsciously delay releases to avoid the "chore" of deploying.
**Productivity Compound Effect**: If you set up the pipeline right away, you will:
- See results sooner.
- Be more productive immediately.
- Build better deployment habits.
- Catch integration issues faster (Continuous Integration!).
- Ship features more confidently.
**The Bottom Line**: We're only human. Automate the boring stuff so you can focus on building great features.
**So what are you waiting for?** Set up that CI/CD pipeline today!
## Notifications: Smart Alerting Strategy
URL: https://samsongama.com/posts/notifications/
**Notifications make monitoring useful.**
Without proper alerting, even the best monitoring setup is just a collection of pretty dashboards that nobody looks at until it's too late.
## Passive Monitoring Integration
When looking at it from a passive monitoring perspective using Prometheus, **AlertManager** is a great service to leverage as it can hook into:
- **Slack**: Instant team notifications in dedicated channels.
- **PagerDuty**: Escalation policies and on-call management for critical incidents.
- **SMS**: Critical alerts that need immediate attention (e.g., via Twilio).
- **Email**: Non-urgent notifications and daily/weekly reports.
## Application Performance Monitoring
Other times you may want to know about business-critical events:
- When a client registers on your SaaS product.
- When a client is attempting to cancel their subscription.
- When specific business thresholds (revenue, traffic) are met.
### Real-World Example: Trading Bot Alerts
In my trading bot implementation, I configured specific triggers:
**Trade Execution Alerts:**
- ✅ **Trade Executed**: Whenever the bot buys or sells → Slack message with price/volume.
- ⚠️ **Stop-Loss Triggered**: When a position is closed to prevent loss → Slack message (High Priority).
- 🚨 **Error State**: If an API fails or logic crashes → Slack message (Critical).
**Benefits:**
- **Remote Management**: Restart services from my phone if necessary without needing a laptop.
- **Peace of Mind**: Enjoy your day without constantly refreshing dashboards.
- **Immediate Response**: Know about issues as they happen, not hours later.
- **Context**: Get actionable information (variables, stack traces) directly in the alert, not just "something broke".
## Smart Alerting Strategy
### What TO Alert On
- **Critical System Issues**: Service down, high 5xx error rates, database locking.
- **Business Events**: Revenue-impacting events, VIP user actions.
- **Performance Degradation**: Response time (latency) spikes, disk space exhaustion.
- **Security Events**: Failed authentications, unusual IP access patterns.
### What NOT to Alert On
- **Noise**: Temporary CPU spikes that self-resolve.
- **Non-actionable**: Warnings you can't or won't fix immediately.
- **Over-alerting**: Sending so many alerts that the team develops "alert fatigue" and ignores them all.
## Implementation Results
This approach has allowed me to:
- **Avoid SSH sessions** while out and about.
- **Skip opening Grafana/Kibana** constantly to check health.
- **Respond quickly** to actual issues before users report them.
- **Maintain work-life balance** without sacrificing system reliability.
**Key insight**: The goal isn't to get *more* notifications—it's to get the *right* notifications at the *right* time so you can take meaningful action.
## Passive Infrastructure Monitoring with Prometheus
URL: https://samsongama.com/posts/monitoring/
Monitoring is a broad topic in DevOps. I generally simplify it into four main categories:
## Types of Monitoring
1. **Passive Infrastructure Monitoring**: Tracking CPU, Memory, Disk usage, Uptime, and Network I/O.
2. **Log Logging/Aggregation**: Services stream their logs to a central system (ELK, Loki) where you can set alerts on specific patterns (e.g., "Exception").
3. **Active Monitoring (Synthetics)**: Pinging your servers on a timer for aliveness/health, or performing full verification of API endpoints.
4. **Application Performance Monitoring (APM)**: Metrics gathered through code injection/instrumentation to view application-level performance (e.g., function execution time, DB query latency).
## Why Passive Monitoring Matters
The focus of this post is **passive monitoring**. Unless your career depends on things working 100% of the time, you probably don't want to constantly second-guess yourself or have to manually check if your services or applications are running.
### Real-World Example: Trading Bot reliability
While working on my [trading bot](/portfolio/2017-11-01-hft-bot/), I often found that some microservices would crash silently. This isn't a huge issue with orchestrators like Docker Compose or Kubernetes, as the service will simply be restarted automatically.
However, repeated restarts are a symptom of a deeper problem. Microservices shouldn't just "turn off and on again" constantly.
**The question becomes**: How would I know if services were restarted 50 times last night?
## The Solution: Prometheus + AlertManager
One approach is to check Docker logs or `kubectl get pods` manually, but that's not practical—especially from a phone while at dinner.
**The Better Approach**: Prometheus with AlertManager. It can inform me that my services are unstable (flapping) or not behaving as expected, prompting me to check the logs to debug further.
### Key Use Cases
**Performance Monitoring:**
- If your application becomes unstable during high load, you want to be alerted if CPU usage spans >90% or memory is exhausted (OOM Kill).
- Identifying bottlenecks to determine if you need to scale vertically (bigger server) or optimize code.
- **Tooling**: `node_exporter` is excellent for exporting Linux machine metrics to Prometheus.
**Service Health:**
- **Automatic Restart Detection**: Alert if uptime < 10 minutes.
- **Service Availability**: Alert if a scrape target is down.
- **Resource Utilization**: catch memory leaks before they crash the server.
- **Network Connectivity**: Monitor latency and packet loss between services.
## Implementation Benefits
- **Proactive**: Catch issues before they impact users.
- **Remote**: Monitor from anywhere via mobile alerts (Slack/PagerDuty).
- **Automated**: No manual checking required; the system watches itself.
- **Scalable**: Works across multiple services and environments without extra effort.
**Bottom line**: If you don't have passive monitoring yet, you're flying blind and wasting time on manual checks that could be automated.
## Millions of Inserts: The Ideal Database?
URL: https://samsongama.com/posts/insertingdata/
*Disclaimer: I didn't run synthetic benchmarks in High Availability (HA) mode for Proof of Concepts (POC). This post reflects my practical experience working with massive datasets for my HFT Trading Bot.*
## The Data Challenge
High-Frequency Trading (HFT) generates an enormous amount of data, all indexed by time. Here is the structure I needed to persist:
- **1 Minute Candle**: `{timestamp, instrument, high, low, open, close, volume, trades}` - ~1 insert per instrument/minute.
- **Individual Trade**: `{timestamp, instrument, price, side, type}` - 0 to 2,000 inserts per minute.
- **Individual Order**: `{timestamp, instrument, price, side, type, status}` - 0 to 5,000 inserts per minute.
*Note: I maintained one collection/database per exchange, as data quality and granularity varied between them.*
## Query Patterns
The database needed to support specific access patterns efficiently:
1. **Range Queries**: "Give me all trades between time X and Y for Instrument Z" (indexes on Time + Instrument).
2. **Latest Data**: "Give me the last X candles for Instrument Z" (heavy read load on recent data).
## Retention Policy
Storing this much data indefinitely is expensive and unnecessary for my algorithm.
- **Candle Data**: Pruned every 3 days.
- **Trade/Order Data**: Pruned every 3 hours. (A longer retention would be preferred, but the volume is manageable).
---
## Database Comparison
### 1. MongoDB (NoSQL)
**Pros:**
- **Write Throughput**: Handles thousands of inserts per minute exceptionally well with batching.
- **Flexibility**: Schema-less design made development fast.
- **Cleanup**: Enforcing retention via TTL indexes or CRON jobs is straightforward.
**Cons:**
- **Resource Hog**: Consumed excessive memory and disk space as the dataset grew.
- **Data Integrity**: **Data loss issues**. After ~10 million rows, I noticed gaps in the data.
- **Stability**: Batch inserts and queries began timing out as the collection size increased.
- **Scaling**: Required increasingly powerful hardware just to keep up.
**Verdict**: Not acceptable. Data loss is a critical failure for a trading algorithm.
### 2. PostgreSQL (SQL)
**Pros:**
- **Reliability**: ACID compliance meant zero data loss.
- **Simplicity**: Standard SQL for inserting, querying, and deleting was easy to implement.
- **Tools**: Excellent ecosystem and client libraries.
**Cons:**
- **Performance Decay**: Inserts slowed down significantly as tables grew into the millions of rows.
- **Maintenance**: Querying and deleting old data (vacuuming) impacted write performance.
- **Bloat**: Disk/Memory usage grew inefficiently for this specific workload.
- **Latency**: Unacceptable latency for real-time HFT decision making.
**Verdict**: Reliable, but too slow for the sheer volume of high-frequency time-series data.
### 3. InfluxDB (Time-Series DB)
**Pros:**
- **Purpose-Built**: Designed specifically for time-series data; "Time" is a first-class citizen.
- **Retention Policies**: Built-in support at the database level (no external cron jobs needed).
- **Reliability**: **Never lost a single data point** despite the high load.
- **Efficiency**: Incredible compression algorithms resulted in optimal disk usage compared to MongoDB.
- **Performance**: Consistent read/write speeds regardless of dataset size.
**Cons:**
- **Resources**: CPU usage can be high during heavy compaction.
- **Cardinality**: Required a workaround for events happening at the exact same millisecond (added a unique "match index" tag).
**Verdict**: ✅ **The Ideal Choice** for an HFT Trading Bot.
## Key Takeaways
- **MongoDB**: Great for general application data but struggled with integrity at this scale.
- **PostgreSQL**: The gold standard for reliability, but time-series is a specific niche where general SQL engines struggle without tuning (e.g., TimescaleDB).
- **InfluxDB**: The specialist tool won. It handled millions of data points flawlessly with built-in features that solved my specific problems (retention, time-indexing).
**Result**: InfluxDB became the foundation for my trading system, handling millions of inserts daily without losing a single record.
## Ansible, why didn't I use this sooner
URL: https://samsongama.com/posts/ansible/
I've been working with Linux since 2008. Back then, I mostly used a spare machine to run FreeNAS, Apache, MySQL, Python to host a static or Wordpress website.
Then as I got more invested with projects running on Linux, I started to set up VPSes to start hosting online in 2011. Everytime, it was the same process. Login as root, set up new user, disable root, set up PKA, enable firewall... etcetc. Took about 30min-1hour depending on how much of the process I remembered. I continued this process till 2015.
By this point, I was starting VPSes for every small project. Even if I wanted a scratch Linux server to work on a proof of concept to run for a couple of hours. I often needed a VPS to make it accessible by all viewers. After all, what good is a REST API if its only accessible to your internal network. Heroku existed at the time, however I wasn't fond of the CPU/Memory restrictions available on the free tier.
## The Solution: Ansible
In comes Ansible and Ansible-Playbooks, "the simplest way to automate apps and IT infrastructure".
I'll skip the details for now but with Ansible I was able to write my default setup as config files. Include my SSH Keys, and b64-ed passwords. Run the playbook and it takes care of the rest.
Now my **1 hour server setup takes 2 minutes** (times may vary based on CPU power of your VM). I no longer cringe at the idea of setting up a new VPS/VM to work on.
## Key Benefits
- **Time Savings**: Reduced setup time by 97% (60 minutes → 2 minutes)
- **Consistency**: Every server configured identically
- **Reproducibility**: Playbooks serve as infrastructure documentation
- **Error Reduction**: Eliminates manual configuration mistakes
I wish I knew about this sooner as I could have potentially saved **days of my life**.
If you're in a similar position of needing to set up VMs for POCs or new projects, I highly recommend adding Ansible into your automation pipeline.