Cloud infrastructure. Secure delivery. Reliable operations. I’m a systems engineer working across Azure, Kubernetes, infrastructure as code, and CI/CD.
Seeking Cloud, SRE, DevOps, Platform, and DevSecOps engineering roles.
At Boeing, I write parameterized infrastructure as code for pipelines, research platform tools, and provide technical direction and onboarding for junior engineers.
The goal is a platform that teams can use and operators can understand. Select a responsibility to inspect its purpose.
See my professional experienceMy professional work includes standardizing infrastructure provisioning with Terraform. A versioned configuration gives teams a shared way to review and repeat changes.
A repeatable starting point for engineering teams.
My platform lab defines dedicated service accounts and RBAC. These controls separate workload identity from the permissions each workload receives.
Access can be inspected and reviewed.
At Boeing, I work on Azure Kubernetes Service capabilities and reusable tooling. My independent lab uses Kind to exercise Kubernetes delivery patterns locally.
A clear boundary between cloud experience and local lab evidence.
My work includes observability and health-check automation. In the lab, Prometheus, Grafana, Alertmanager, Alloy, and Loki make metrics, alerts, and logs available for investigation.
Operators can inspect a change and verify the result.
I built the Enterprise Platform Lab to connect the full delivery path: build an image, publish it, change the desired version, and reconcile it into Kubernetes.
Each component has a different job. Advance the artifact through the delivery path.
Independent local lab. Image publication does not depend on the separate validation workflow. Commit-specific tags do not guarantee registry-enforced immutability.
Open the release validationFollow an artifact from source to workload.
Build frontend and API images from a source commit. CI creates artifacts; it does not deploy them to the cluster.
Store the images with commit-specific tags. The registry holds artifacts that Kubernetes can pull.
After both builds succeed, update the Helm image tags in Git. This commit records the version the cluster should run.
Compare live configuration with Git. Apply the Helm configuration and let Kubernetes roll out the workloads.
Run React, Flask, PostgreSQL, and Redis in a two-node Kind cluster. Use metrics, alerts, and logs to inspect workload behavior.
Conceptual walkthrough of my independent lab. Open the project for source code and validation records.
The lab records configuration recovery and an autoscaling exercise. A separate restore drill exposed a database backup gap. I am reviewing the current implementation before repeating key tests myself.
The record validates configuration recovery. It does not measure recovery time or production availability.
Open the self-healing validationSelect a scenario. Follow the response and see which component owns each step.
Git still declares the frontend Deployment. Follow how the controller restores that desired state.
Read the self-healing validationGit declares a resource that is missing in the cluster.
Argo CD compares the live cluster with Git. The declared Deployment is missing.
Component boundary: Argo CD detects configuration drift. Prometheus does not restore Kubernetes resources.
With automated self-healing enabled, Argo CD reapplies the declared Deployment.
Component boundary: The Deployment controller creates the ReplicaSet and Pods. The scheduler selects nodes; the kubelet starts containers.
Inspect the rollout and readiness. A restored manifest alone does not prove that the application can serve traffic.
Component boundary: Self-healing restores declared configuration. It cannot correct an error already committed to Git.
Follow the CPU-based scaling path. Each controller has a separate job.
Read the autoscaling validationIllustrative counts: 2, 4, then 2. These are not measured test results.
Metrics Server supplies resource metrics. The HPA compares CPU utilization with its configured target.
Component boundary: For this CPU-based HPA, Metrics Server supplies the metrics. Prometheus is a separate monitoring system.
The HPA changes the desired replica count within its limits. The workload controller creates more Pods.
Component boundary: The HPA changes replica count. The scheduler places new Pods only when eligible nodes have enough resources.
After traffic stops, the HPA can reduce replicas according to its scaling policy and stabilization settings.
Component boundary: More replicas use existing cluster capacity. They do not add nodes or guarantee lower latency.
Use each observability tool for a specific question. This is an illustrative investigation, not a recorded incident.
Inspect the logging configurationMove from the symptom to the notification, then inspect workload events.
Prometheus collects metrics and evaluates alert rules. Grafana displays the metrics so an operator can inspect changes in errors and latency.
Component boundary: Prometheus evaluates the rule. Grafana provides the dashboard; it does not collect workload metrics in this flow.
Prometheus sends firing alerts to Alertmanager. Alertmanager groups, routes, and silences notifications.
Component boundary: Alertmanager handles notifications. It does not scrape metrics or evaluate Prometheus alert rules.
Grafana Alloy collects workload logs and sends them to Loki. Query the logs through Grafana to inspect events around the failure.
Component boundary: A dashboard or notification does not repair a failure. Use the evidence to choose a fix, then verify recovery.
My professional work includes GitLab CI/CD security gates, SAST, and configuration validation. In the lab, a Kyverno admission test rejected a pod that did not meet the workload policy.
The interaction models a release policy: a failed required check blocks promotion. It is an example, not the current lab publication workflow.
Read the policy validation and security limitsChange a check result. See how the release decision changes.
A release policy can block promotion when a required check fails.
This model explains a decision rule. It does not scan an image or approve a real release.
Replacement of a generic website with a live course and content platform. I own the technical implementation and operations.
03A learning and assessment application with versioned scoring, service contracts, and validated Helm deployment to a local Kind cluster.
04The tradeoffs behind a content-focused portfolio built with Astro, custom CSS, and static delivery.
I want to own and operate Kubernetes platforms: secure them, improve availability, support application delivery, and build internal developer services. I am open to St. Louis hybrid and remote roles.