Han Cho

A legacy Java application running on Apache Tomcat required frequent builds and deployments. The build process was resource-intensive and time-consuming, requiring manual operations team intervention for each request. Due to limited operational resources and increasing developer demands, the deployment pipeline became a significant bottleneck.

As a solution, I implemented an automated, self-service build system using a Slack bot. This system allowed developers to initiate builds and deploy to development environments without involvement from the operations team. The key technologies leveraged included Node.js for the Slack bot logic back end, AWS Lambda for serverless execution of build and deploy tasks, API Gateway for exposed endpoints for Slack interactions, Slack API for an interactive UI for developers to trigger and monitor builds, and Serverless Framework as infrastructure as code for Lambda/API deployment.

The project reduced manual intervention and freed up the operations team's bandwidth. The system successfully enabled developers to trigger builds, get build state updates, update branches, receive notifications, and deploy to the QA/stage system on-demand via Slack.

The policy restricts access to internal systems from unknown public IPs and
GitHub-hosted runners use dynamic IPs. Self-hosted runners were considered, but resource mismatches and static provisioning caused inefficiencies. To solve these issues, I implemented a containerized self-hosted runner platform on a Kubernetes cluster using GitHub Actions Runner Controller.

Key features included Kubernetes-based containerized runners, custom runner images built and maintained to match job requirements, on-demand runner provisioning by users for their own workflows, automated runner image creation to streamline custom image management, and self-service workflow allowing users to deploy and manage their runners securely within the operations team cluster/the user's custom cluster.

Our solution achieved fully isolated and secure CI/CD pipeline execution, eliminated the dependency on GitHub's runner, and significantly improved runner utilization and performance by matching runner specs to job size. In addition, the system enables user autonomy with self-service runner deployment, reducing DevOps overhead and streamlining the creation and maintenance of custom runners for different job profiles.

While AWS offers cost explorer tools, access requires specific IAM roles that corporate administrators must grant. This often limits visibility for developers and project managers, who would benefit from understanding the cost implications of infrastructure changes. AWS Cost Explorer access is restricted by role-based policies, and developers and PMs lack visibility into the cost impacts of their changes. Manual report generation is inefficient and inconsistent.

I developed an automated cost reporting system that collects and processes billing metadata from multiple AWS accounts via the AWS Cost Explorer API. Raw data is restructured, filtered, and parsed into various timeframes (daily, weekly, monthly) and report formats. These reports are then delivered to registered users, improving transparency and accountability. The solution offers cross-account cost data collection,
cost data parsing and transformation using Pandas (Python), flexible time window filtering (daily/weekly/monthly), automated email or system notifications to registered users, and full automation via GitHub Workflows.

As cloud infrastructure scales, managing resources across accounts becomes increasingly complex. To ensure consistent governance and compliance across environments, a centralized, automated cloud governance solution was implemented using Cloud Custodian, an open-source policy-as-code framework.

I developed a GitHub Workflow–based governance automation system using Cloud Custodian. Each AWS account (with potential extension to GCP and Azure) defines its YAML-based policies to monitor specific resource types and conditions. When non-compliant resources are detected, custom actions are executed to automatically remediate or remove them.

The solution leverages a YAML-defined policy-as-code framework for cloud resource governance, support for multi-account and multi-cloud (AWS, GCP, Azure) environments, GitHub Workflows for automated policy execution and reporting, and automated actions for remediation, deletion, tagging, and notification. Added features include self-service workflows that users can define policies, schedules, and targets.