Representative Projects

Technical Implementation

• Built a Red Hat ACM hub cluster to register OpenShift spoke clusters with managed cluster sets, placement rules, and PolicySets so governance decisions could be targeted by environment and cluster role.
• Structured the GitOps model into bootstrap, platform-services, and environment overlay repositories, using Kustomize overlays and Argo CD application definitions so cluster configuration could be promoted through pull requests rather than applied manually.
• Used Terraform for shared prerequisites such as DNS records, load balancer inputs, and environment metadata, then used Ansible playbooks with oc and ACM APIs to register clusters, label them, and apply baseline namespace, RBAC, and operator configuration.
• Validated rendered manifests with kustomize build and kubeconform before promotion, then verified policy compliance, operator health, ingress routing, Vault integration, and Prometheus targets on a non-production cluster before rolling the same pattern across the fleet.

Client Delivery & Handover

The work was done directly with the client platform and operations teams in weekly architecture and implementation sessions. Changes were built in code, reviewed with the client team before promotion, and validated against their support model rather than a lab-only design. Handover included cluster build runbooks, ACM governance procedures, repository structure documentation, upgrade-preparation notes, and operator enablement sessions so the internal team could provision, govern, and extend the fleet without depending on the engagement.

Outcome

The result was a more repeatable cluster delivery model, less configuration drift between environments, and a platform team that could manage fleet-level changes with more control and less manual coordination.

Technical Implementation

• Deployed Backstage on Kubernetes with PostgreSQL for catalog storage and OIDC-based sign-in, then enabled the catalog, TechDocs, Kubernetes, and Scaffolder plugins so the portal could serve as the actual entry point for platform workflows.
• Built Scaffolder templates in TypeScript and JSON schema to create repositories, catalog-info.yaml metadata, GitHub Actions pipelines, Helm chart stubs, and Terraform module references in a single flow rather than relying on manual service bootstrapping.
• Integrated catalog entities with Kubernetes resources, GitHub repositories, and TechDocs publishing so service ownership, runtime visibility, and documentation stayed linked through the same catalog record.
• Validated the golden paths by onboarding pilot teams through the templates, checking generated repositories with actionlint, helm lint, and terraform validate, and only then promoting the templates for broader engineering use.

Client Delivery & Handover

The work was delivered incrementally with platform and application teams through workshops, paired implementation, and early-adopter feedback loops. Internal maintainers were trained on template lifecycle management, catalog governance, and plugin administration, and engineering teams were shown how to create new services through the approved paths. Handover included portal governance guidance, template maintenance documentation, entity modeling notes, and end-user instructions so the client team could keep evolving the Backstage deployment after rollout.

Outcome

The client gained a stronger internal platform entry point, more consistency in new-service setup, and a delivery model that reduced dependency on ad hoc platform support.

Technical Implementation

• Built the landing zone around separate AWS accounts for workloads, shared services, and security, using Terraform modules for account bootstrap, guardrail IAM roles, CloudTrail, and baseline networking so additional environments could be added without redesigning the foundation.
• Defined the network model with segmented VPCs, private subnets, NAT routing, VPC endpoints, and cross-account access patterns, then validated Terraform changes with tflint, tfsec, and plan reviews before promotion.
• Deployed EKS with managed node groups, IRSA, the AWS Load Balancer Controller, ExternalDNS, cert-manager, and External Secrets Operator so ingress, TLS, DNS, and secret injection were handled as part of the platform rather than per application.
• Connected GitHub Actions pipelines to AWS through OIDC and used Argo CD to deploy workloads from Git, which made the deployment path reproducible and allowed platform validation through kubeconform, helm lint, and smoke tests on the first onboarded services.

Client Delivery & Handover

The project was implemented with the client architects and platform engineers through architecture reviews, paired Terraform work, cluster bootstrap sessions, and rollout checkpoints as environments were promoted. Handover included landing-zone diagrams, module guidance, EKS runbooks, deployment workflow documentation, and enablement sessions on platform operations, account administration, and workload onboarding. The goal was to leave the client team with both the working platform and the operating knowledge required to extend it safely.

Outcome

The client gained a cleaner AWS operating model, a more production-ready deployment foundation, and a platform architecture that could support additional teams without repeating early design mistakes.

Technical Implementation

• Built the landing zone with management groups, separate subscriptions, hub-and-spoke virtual networks, NSGs, route tables, and Azure Policy assignments so network and governance controls were consistent before workloads landed.
• Implemented environment provisioning through Terraform and Azure DevOps pipelines, using reusable modules for networking, identity, and cluster dependencies and validating changes with terraform validate, tflint, and staged plan review.
• Deployed AKS with managed identities, Azure CNI, ingress, cert-manager, and the Key Vault CSI driver so cluster access, secret delivery, and certificate handling were part of the base platform design.
• Integrated Azure Monitor, Container Insights, and log routing into the cluster baseline, then validated onboarding with pilot services to confirm image pull paths, secret mounts, ingress behavior, and workload telemetry before wider use.

Client Delivery & Handover

The implementation was done with the client infrastructure and engineering teams through design sessions, paired rollout work, and validation checkpoints against real workload requirements. Handover included landing-zone documentation, subscription and network diagrams, AKS support runbooks, environment build guidance, and training sessions for both platform operators and engineering leads. The enablement work focused on ensuring the client team could both operate the platform and onboard additional services without losing consistency.

Outcome

The client moved to a more coherent Azure architecture with cleaner deployment patterns, better environment consistency, and a platform foundation that application teams could consume more predictably.

Technical Implementation

• Built the ingestion layer with Pub/Sub topics and subscriptions so source systems could publish events asynchronously without being coupled to downstream transformation timing.
• Implemented Dataflow pipelines in Apache Beam to validate schemas, apply enrichment and normalization steps, and write failed records to dead-letter storage instead of dropping them silently.
• Used Cloud Storage for raw and replayable landing zones, then loaded curated datasets into partitioned BigQuery tables with scheduled quality checks on row counts, null thresholds, and late-arriving data.
• Orchestrated scheduled loads and backfills with Composer, codified the platform in Terraform, and validated pipeline changes with Beam unit tests, sample replay runs, and BigQuery reconciliation queries before production release.

Client Delivery & Handover

The implementation was done with the client data, platform, and reporting stakeholders so source-system assumptions, transformation boundaries, and downstream reporting needs were validated as the pipeline was built. Operational visibility and failure handling were designed with the client team from the start rather than added after deployment. Handover included pipeline flow diagrams, runbooks, data ownership notes, training sessions on monitoring and failure recovery, and documentation for safely adding new sources and transformations later.

Outcome

The client ended up with a cleaner data pipeline architecture, more dependable movement of operational data into analytics, and a platform that was easier to reason about and extend over time.

Technical Implementation

• Analyzed Jira request patterns by request type, lead time, and repeat frequency to identify which platform tasks were consuming the most support capacity and therefore worth turning into productized workflows first.
• Built Backstage templates to scaffold repositories, catalog metadata, CI configuration, namespace manifests, and deployment descriptors so common requests such as new-service onboarding or environment setup could be executed as a standard flow.
• Backed those templates with GitHub Actions, Terraform modules, Kubernetes manifests, and Argo CD application definitions so a self-service request produced working infrastructure and deployable runtime configuration rather than a partially completed handoff.
• Validated the new paths by running them with pilot teams, checking generated Terraform with terraform validate, Kubernetes manifests with kubeconform, and deployment behavior in lower environments before replacing the equivalent manual ticket workflow.

Client Delivery & Handover

The work was done directly with the client platform team by reviewing backlog themes, identifying the highest-cost interruptions, and building self-service replacements with input from the application teams affected by them. The client team was involved in defining intake rules, ownership boundaries, and the sustainment model for the new templates and workflows. Handover included platform product definitions, self-service documentation, backlog-management guidance, platform-lead training, and user-facing instructions so the organization could keep evolving the model after the engagement.

Outcome

The platform function moved closer to a product model, with less repeated support work, faster enablement for application teams, and better use of engineering capacity.