Best Practices for Creating Showcase Projects in the Cloud Environment

24 Tem 21:08

A clear separation of infrastructure and application logic is the foundation for a maintainable showcase project. To achieve this, I often use a "layered architecture" model: 1) A **Foundation Layer** (networking, IAM base roles, central logging and monitoring services) is defined and versioned in a standalone IaC module. 2) A **Service Layer** contains individual cloud features (e.g., serverless functions, managed databases, event buses) as reusable modules. 3) An **Application Layer** orchestrates these services into concrete use cases. This approach closely resembles the classic "micro-frontend" approach in web apps, where each frontend component is built, tested, and later assembled into a complete system—except here, the "components" are infrastructure resources. For documentation, I use a two-tier system: First, an **automated README** framework generated from IaC modules (e.g., via terraform-docs or cfn-guard-doc). Second, a central **wiki repository** published through a Markdown renderer in the CI pipeline (e.g., MkDocs or Hugo). This keeps descriptions in sync with code changes, and the team can easily look things up without manually maintaining documents. When selecting an orchestration tool, I usually check whether the project leans more toward **serverless workflows** (Step Functions, Azure Logic Apps) or **container orchestration** (Kubernetes, ECS/Fargate). In a comparable internal proof-of-concept I tested with **Terraform** against **AWS CDK**, Terraform proved faster for multi-cloud-compatible modules, while CDK generated less boilerplate for pure AWS stacks thanks to native constructs—this can influence the learning curve and documentation overhead. I define roles and permissions according to the **least-privilege principle**, establishing a central **IAM policy library**. Each module imports only the policies it truly needs, and the CI pipeline automatically checks that no excessive permissions appear in Terraform plans (e.g., with tflint or checkov). This approach aligns well with the "feature toggle" model from application development: you activate exactly the rights needed for the current feature and deactivate them once the feature is no longer required.

24 Tem 22:40

Exactly, in my last showcase project, I started with a uniform directory structure (e.g., `modules/`, `env/`, and `pipelines/`) to encapsulate each cloud component as a standalone Terraform module. This clearly separates the base architecture, allowing individual services (like a VPC, database, or serverless function) to be reused across different environments using `terraform workspace`. For CI/CD, I rely on GitHub Actions because the jobs can be defined directly in the repo; each module gets its own workflow file that runs `plan` and `apply` only for the relevant directory. Monitoring is automated using the Terraform provider for Prometheus + Grafana, so alerts and dashboards are set up during the deployment step. For orchestration, I mostly use Terraform alongside `Terragrunt`, as it simplifies module nesting while centrally managing roles and permissions. I store IAM roles in separate modules and reference them via `data` blocks, so policy changes take effect immediately across all dependent services. Documentation is kept in Markdown files next to each module, and I generate automated README sections with `terraform-docs`—this keeps the info in sync with the code and makes maintenance updates easier. This combination of modular structure, clear CI pipelines, and automated documentation has helped me keep the showcase project neat and scalable.