สร้าง workload บน GCP อย่างมืออาชีพ

รอบแรกวัดว่าเรารู้คอนเซปต์ไหม รอบสองกับ Team Lead วัดว่าเรา "ลงมือทำเป็นจริงไหม ตัดสินใจยังไง และจะส่งไปนั่งหน้าลูกค้าได้ไหม" คำถามจะลึกและเจาะประสบการณ์จริงมากขึ้น สามคำที่เขาบอกมาคือ building, migrating, managing ซึ่งเป็น lifecycle เต็มของ workload ตอนนี้ว่าด้วย building จุดสำคัญคืออย่าตอบแค่ "เลือก service อะไร" แต่ต้องเล่าได้ว่าสร้างจริงยังไง ตั้งแต่รากฐานจนถึง deploy รวมถึงเหตุผลและ trade-off จากประสบการณ์

Team Lead จะดูว่าเราเลือก compute ด้วยเหตุผลจริงไหม กรอบการตัดสินใจ:

• Compute Engine (VM): เมื่อต้องคุม OS เต็มที่ ต้อง lift-and-shift ระบบเดิม หรือมี dependency ระดับ OS ที่ container ไม่รองรับ
• GKE: เมื่อระบบเป็น microservices จริง มีทีม platform ที่ดูแล Kubernetes ได้ ต้องการ orchestration ยืดหยุ่นและ portability พิจารณา Autopilot ถ้าอยากลดภาระจัดการ node
• Cloud Run: เมื่ออยาก serverless container จ่ายตามใช้ scale ลงถึงศูนย์ traffic ไม่สม่ำเสมอ ทีมเล็กไม่อยากดูแล infra เหมาะที่สุดสำหรับ API และ web service ยุคใหม่
• Cloud Functions: เมื่อเป็น event-driven สั้น ๆ เช่น trigger จากไฟล์เข้า bucket

หลักที่ทำให้ดูมีวุฒิภาวะ: อย่าเชียร์ Kubernetes กับทุกคน ถ้าทีมลูกค้าไม่พร้อมดูแล GKE การเลือก Cloud Run มักเป็นคำตอบที่รับผิดชอบกว่า และให้เชื่อมโยงเสมอว่าเลือกเพราะบริบทลูกค้า ไม่ใช่เพราะเทรนด์

การสร้าง workload ระดับมืออาชีพต้องทำผ่านโค้ด ไม่ใช่คลิกใน console Terraform เป็นมาตรฐานบน GCP ประเด็นที่ควรเล่าได้:

• ทำไมต้อง IaC: ทำซ้ำได้ ตรวจสอบได้ผ่าน version control ลดความผิดพลาดจากคน สร้าง environment ใหม่ได้เร็ว
• การจัดการ state: เก็บ Terraform state ใน backend ที่ปลอดภัยเช่น Cloud Storage พร้อม state locking กัน conflict เมื่อทำงานเป็นทีม
• Module และ reusability: แยกส่วนที่ใช้ซ้ำเป็น module เช่น network, project, service เพื่อความสม่ำเสมอ
• แยก environment: dev, staging, prod แยกกันชัด ด้วย workspace หรือ directory แยก และ variable ต่างกัน
• Cloud Foundation Toolkit และ blueprint: ชุด Terraform module สำเร็จของ Google สำหรับวางรากฐานตามแนวปฏิบัติที่ดี
• Config Controller และ Config Connector: ทางเลือกจัดการ resource แบบ Kubernetes-native สำหรับองค์กรที่ทำ GitOps

ถ้าเคยเขียน Terraform จริง (รวมถึงบน AWS) ให้เล่าประสบการณ์นั้นแล้วโยงว่าหลักการเดียวกันใช้กับ GCP provider ได้

Team Lead มักถามว่า deploy ยังไงให้ปลอดภัยและทำซ้ำได้ องค์ประกอบบน GCP:

• Cloud Build: รัน pipeline build, test, deploy กำหนดขั้นตอนใน config
• Artifact Registry: เก็บ container image และ package แทน Container Registry เดิม
• Cloud Deploy: continuous delivery ไปยัง GKE และ Cloud Run พร้อม promotion ข้าม environment และ approval
• การผสานกับเครื่องมือภายนอก: หลายลูกค้าใช้ GitHub Actions หรือ GitLab CI ก็เชื่อมกับ GCP ได้ ควรเล่าได้ว่าทำ workload identity federation เพื่อ auth เข้าจาก CI ภายนอกอย่างปลอดภัยโดยไม่ฝัง key
• แนวปฏิบัติ container: build image ให้เล็ก ใช้ multi-stage build สแกนช่องโหว่ ติด tag ที่ตรวจสอบย้อนได้ ไม่ใช้ latest ใน production
• Progressive delivery: canary หรือ blue-green เพื่อลดความเสี่ยงตอน deploy

ถ้าเคยตั้ง pipeline จริง เช่น multi-arch Docker build หรือ deploy ขึ้น registry ให้เล่าเป็นประสบการณ์ตรง จะได้เปรียบมาก

นี่คือจุดที่แยกคนที่ "สร้าง app เป็น" ออกจากคนที่ "วางระบบให้องค์กรเป็น" Team Lead ชอบถามว่าก่อนสร้าง workload จะวางรากฐานให้ลูกค้ายังไง

• Resource hierarchy: Organization แล้ว Folder แล้ว Project แล้ว resource สิทธิ์และ policy สืบทอดตามลำดับชั้น ออกแบบ folder ตามหน่วยงานหรือ environment
• Project strategy: แยก project ตาม environment และ workload เพื่อจำกัดขอบเขตความเสี่ยงและ billing
• Organization policies: กำหนดกฎระดับองค์กร เช่นห้ามสร้าง external IP ห้าม region นอกที่อนุญาต บังคับ CMEK
• IAM baseline: least privilege ตั้งแต่ต้น ใช้ group แทนการให้สิทธิ์รายคน หลีกเลี่ยง basic role
• Networking baseline: ออกแบบ VPC, Shared VPC สำหรับให้หลาย project ใช้เครือข่ายกลาง, subnet, firewall, การเชื่อม on-prem
• Security baseline: เปิด Security Command Center, audit logging, องค์กร policy ด้านความปลอดภัย
• Billing และ budget: ตั้ง budget alert ตั้งแต่แรก
• Cloud Foundation blueprint: ใช้ชุดสำเร็จของ Google เร่งการวาง landing zone ตามแนวปฏิบัติที่ดี

การพูดเรื่องนี้แสดงว่าเราคิดแบบ enterprise ไม่ใช่แค่ deploy แอปเดียว

• VPC design: global VPC, แยก subnet public/private, วางแผน IP range ไม่ให้ชนกับ on-prem
• Shared VPC: ให้ network กลางที่ project อื่นมาใช้ ควบคุมจากศูนย์กลาง เหมาะองค์กรใหญ่
• Load balancing: เลือกให้ตรงชนิด traffic global external, internal, TCP/UDP
• Firewall และ Cloud Armor: กฎเข้าออกและป้องกัน layer 7
• Private connectivity: Private Google Access, Private Service Connect, การเชื่อม on-prem ด้วย VPN/Interconnect

ถ้าเคยดีบั๊กปัญหา network จริง เช่น routing หรือ VPN selector ผิด ให้เล่าเป็นเคส เพราะสะท้อนประสบการณ์ลึก

ถาม: "ลูกค้าจะเริ่มขึ้นคลาวด์ คุณจะวางรากฐานอะไรก่อนสร้าง workload" ตอบ: เริ่มจาก resource hierarchy, project strategy, IAM baseline, org policy, networking และ security baseline ผ่าน landing zone แล้วค่อยสร้าง workload บนรากฐานนั้น

ถาม: "จะเลือกระหว่าง Cloud Run กับ GKE ยังไง" ตอบ: ดูความซับซ้อนของระบบ ความพร้อมทีม และความต้องการ portability Cloud Run สำหรับความง่ายและ serverless, GKE เมื่อเป็น microservices จริงและมีทีมดูแล พร้อม trade-off

ถาม: "ทำไมต้อง IaC ไม่คลิกใน console เอา" ตอบ: ทำซ้ำได้ ตรวจสอบผ่าน version control ลดความผิดพลาด สร้าง environment ใหม่ได้เร็วและสม่ำเสมอ

ถาม: "จะ deploy ให้ปลอดภัยและ rollback ได้ยังไง" ตอบ: Cloud Build + Artifact Registry + Cloud Deploy พร้อม canary/blue-green และ approval ข้าม environment

ถาม: "CI ภายนอกอย่าง GitHub Actions จะ auth เข้า GCP ยังไงให้ปลอดภัย" ตอบ: workload identity federation แทนการฝัง service account key

ตอบแค่ชื่อ service โดยไม่เล่าวิธีสร้างจริง; เชียร์ GKE กับทุกเคสโดยไม่ดูความพร้อมทีม; ลืมเรื่อง landing zone และ resource hierarchy ทำให้ดูเหมือนสร้างแค่แอปเดียว; ไม่พูด IaC หรือพูดแต่ไม่ลงเรื่อง state/module/environment; สร้างโดยไม่คิด networking และ security baseline; ไม่โยงกับประสบการณ์จริงที่ตัวเองเคยทำ

building ในสายตา Team Lead คือการวางรากฐานแล้วสร้างอย่างเป็นระบบ เลือก compute ด้วยวิจารณญาณตามบริบทลูกค้า ทำผ่าน IaC ด้วย Terraform ที่จัดการ state, module, environment เป็น ตั้ง CI/CD ที่ปลอดภัยและ rollback ได้ และที่สำคัญคือวาง landing zone ด้วย resource hierarchy, IAM, org policy, networking และ security baseline ก่อนสร้าง workload เล่าทุกอย่างโยงกับประสบการณ์จริงเพื่อให้ Team Lead เชื่อว่าเราสร้างของจริงเป็น