IT Foundation EP.04 — Architectures

Series: IT Foundation — พื้นฐาน IT สำหรับยุค AI (ภาษาคน)

EP.01 — รากฐานคอมพิวเตอร์

EP.02 — พื้นฐาน Computer Science

EP.03 — ซอฟต์แวร์ทำงานยังไง

EP.04 — Architectures ← คุณอยู่ตรงนี้

EP.05 — Web Technologies

EP.06 — Security พื้นฐาน

EP.07 — Performance & Testing

EP.08 — Dev/Deploy/Ops

EP.09 — Security ขั้นสูง

EP.10 — Project Management

เกริ่นก่อนเริ่ม#

ใน EP.03 เราคุยกันเรื่อง “ซอฟต์แวร์ทำงานยังไง” ตั้งแต่ Frontend/Backend/Database ไปจนถึง API และการเขียนโค้ดให้คอมพิวเตอร์เข้าใจ ทุกอย่างที่พูดในตอนนั้นเหมือน “การสร้างบ้านหนึ่งหลัง” ให้เสร็จและอยู่ได้ครับ

แต่พอธุรกิจโต ลูกค้าเพิ่มจาก 100 คนเป็น 100,000 คน ปัญหาจะเปลี่ยนจาก “เขียนโค้ดยังไง” ไปเป็น “จะวางโครงสร้างทั้งหมดยังไงไม่ให้มันพัง” ตรงนี้แหละครับคือเรื่องของ Architecture

ผมอยากชวนมองเรื่องนี้เหมือน “การวางผังเมือง” เราไม่ได้สร้างบ้านหลังเดียวแล้ว เราต้องคิดเรื่องถนน ร้านค้า ระบบไฟฟ้า น้ำประปา รถเมล์ ตำรวจ ทั้งหมดพร้อมกัน และ EP.04 จะพาไปดูว่านักวางผังเมืองของโลกซอฟต์แวร์เขาคิดกันยังไง

Server Architecture Evolution — วิวัฒนาการของหลังบ้าน#

หลังบ้าน (Backend) คือสมองของระบบครับ มีข้อมูลลูกค้า มีตรรกะการทำงาน มีการเชื่อมต่อกับธนาคาร กับคลังสินค้า ทุกอย่างรันอยู่ที่นี่ และในช่วง 20 ปีที่ผ่านมา วิธี “วาง” หลังบ้านมีวิวัฒนาการมา 4 รูปแบบหลัก

flowchart TB
    A[Monolith<br/>ตึกเดี่ยวรวมทุกอย่าง] --> B[Microservices<br/>หลายตึกแยกงาน]
    B --> C[Serverless<br/>จ้างคนครั้งละงาน]
    C --> D[Jamstack + Edge<br/>ของพร้อมเสิร์ฟที่ขอบโลก]

    style A fill:#4a5568,stroke:#2d3748,color:#fff
    style B fill:#2b6cb0,stroke:#2c5282,color:#fff
    style C fill:#2f855a,stroke:#276749,color:#fff
    style D fill:#6b46c1,stroke:#553c9a,color:#fff

1. Monolithic Architecture — คฤหาสน์หลังเดียว#

แนวคิด: เอาทุกอย่างยัดรวมในโปรเจกต์เดียว โค้ดชุดเดียว (Single Codebase) ทั้ง Frontend, Backend, Database connection, งานเบื้องหลัง อยู่ใต้หลังคาเดียวกันหมด

เปรียบเทียบ: เหมือน “คฤหาสน์หลังยักษ์” ห้องนอน ห้องครัว ห้องน้ำ ห้องรับแขก อยู่ในตึกเดียวกัน เดินไปมาหากันได้สบาย เรียกใช้กันง่าย ไม่ต้องเดินทางไกล

ข้อดี: สร้างเร็ว ทดสอบง่าย Deploy ครั้งเดียวจบ ใช้คนดูแลน้อย เหมาะสำหรับช่วงเริ่มต้นที่ต้อง “ออกตลาดให้ไว” (Time-to-market สั้นที่สุด)

ข้อเสีย:

Tightly Coupled: ทุกอย่างผูกกันแน่น ถ้า “ท่อประปาแตกในห้องน้ำ” อาจต้อง “ปิดซ่อมทั้งบ้าน” — โมดูลเดียวล่ม ระบบล่มหมด
Scaling Limits: ถ้าคนแน่นแค่ห้องครัว จะขยายแค่ครัวไม่ได้ ต้องขยายบ้านทั้งหลัง เปลืองทรัพยากร

มุมผู้บริหาร: อย่าเพิ่งรีบทำระบบซับซ้อนถ้ายังไม่มี User เยอะครับ Monolith คือเพื่อนแท้ของ Startup เพราะราคาถูก เร็ว และพอ MVP ยังหาคำตอบไม่เจอ การทำระบบซับซ้อนแต่แรกคือการเผาเงินเปล่า

Keywords: Single Codebase, Tightly Coupled, Simple Deployment

2. Microservices Architecture — หมู่บ้านจัดสรร#

แนวคิด: ทุบคฤหาสน์ทิ้ง แล้วแยกสร้างเป็น “บ้านหลังเล็กๆ หลายหลัง” ตามหน้าที่

Service A: ระบบสมาชิก (Auth)
Service B: ระบบตะกร้าสินค้า (Cart)
Service C: ระบบชำระเงิน (Payment)
Service D: ระบบส่งอีเมล (Notification)

แต่ละ Service มีฐานข้อมูลของตัวเอง มีทีมดูแลของตัวเอง และ Deploy แยกอิสระได้

เปรียบเทียบ: เหมือน “Food Court” ในห้างครับ มีร้านข้าวมันไก่ ร้านก๋วยเตี๋ยว ร้านน้ำหวาน แต่ละร้านบริหารแยกกัน ถ้าร้านข้าวมันไก่ไฟไหม้ ร้านก๋วยเตี๋ยวยังขายต่อได้ (Fault Isolation) แต่การเดินจากร้านหนึ่งไปอีกร้านหนึ่งต้องใช้ “ถนน” (Network Call/API) ซึ่งช้ากว่าเดินในบ้านเดียวกัน

ข้อดี:

ร้านหนึ่งเจ๊งไม่ฉุดร้านอื่น (Fault Isolation)
ขยายเฉพาะร้านที่ลูกค้าเยอะได้ (Independent Scaling)
ทีมแต่ละทีมเลือกเทคโนโลยีของตัวเองได้
Deploy แยกกัน ไม่ต้องรอทุกคนพร้อม

ข้อเสีย: ความซับซ้อนมหาศาล! ต้องมีระบบจัดการจราจร (API Gateway), ระบบ Log รวม, ระบบจัดการ Error ข้าม Service และต้อง “จ้างยามเฝ้าบ้าน” ทุกหลัง ค่าดูแลสูงกว่า Monolith หลายเท่า

มุมผู้บริหาร: Microservices ไม่ใช่ยาวิเศษครับ มันคือ “Trade-off” คุณได้ความยืดหยุ่นมาแลกกับความยุ่งยากในการดูแล เหมาะกับ Enterprise ที่มี Developer หลายสิบหลายร้อยคน และระบบซับซ้อนจนคนเดียวไม่เข้าใจทั้งหมดแล้ว ถ้าทีมคุณมี 5 คน อย่าเพิ่งคิดถึงมันครับ

Keywords: Decoupling, API Gateway, Fault Tolerance, Independent Deployment

3. Serverless Architecture — เช่าโรงแรมอยู่#

แนวคิด: เลิกสร้างบ้าน เลิกสร้างตึก เอาโค้ดไปฝากไว้กับผู้ให้บริการ Cloud (AWS, Google Cloud, Azure) แล้วจ่ายเงินเฉพาะตอนที่มีคนเรียกใช้เท่านั้น

เปรียบเทียบ: เหมือน “Cloud Kitchen” หรือ “การนอนโรงแรม” คุณแค่เตรียมวัตถุดิบ (Code) ไป เรื่องแก๊ส น้ำ ไฟ ความปลอดภัย การขยายร้าน (Infrastructure) ทางโรงแรมจัดการให้หมด ไม่มีลูกค้า = ไม่เสียเงินสักบาท (Pay-as-you-go)

ข้อดี:

ไม่ต้องดูแล Server เอง (No-Ops)
ขยายตัวอัตโนมัติ (Auto-scaling) มีคน 10 คนก็ได้ 10 ล้านคนก็ได้
จ่ายตามที่ใช้จริง ไม่มีคนเข้า = ไม่ต้องจ่าย
เริ่มต้นเร็วมาก เหมาะกับงาน Event-based เช่น ย่อรูปเมื่อมีการอัปโหลด

ข้อเสีย: ควบคุมสภาพแวดล้อมไม่ได้ 100% และอาจมีอาการ “Cold Start” — ถ้าไม่มีคนเข้านานๆ ตอนคนแรกกลับมา ระบบต้อง “เปิดเตา” ก่อน ซึ่งใช้เวลาครึ่งวินาทีถึงสองวินาที ลูกค้าคนนั้นจะรู้สึกว่าเว็บช้า

มุมผู้บริหาร: ประหยัดค่า DevOps ได้มหาศาลครับ เหมาะกับธุรกิจที่ traffic ไม่สม่ำเสมอ (เช่น แอปจัดอีเวนต์ ที่มีคนแห่มาวันงานวันเดียว) แต่ถ้า traffic สูงตลอด 24 ชั่วโมง ค่าใช้จ่ายอาจจะแพงกว่าการซื้อ Server เองก็ได้ ต้องคำนวณให้ดี

Keywords: AWS Lambda, FaaS (Function as a Service), Auto-scaling

4. Jamstack — บ้านสำเร็จรูป#

แนวคิด: แยกส่วนหน้าบ้าน (Frontend) ออกจากหลังบ้านให้เด็ดขาด และสร้างหน้าเว็บ “รอไว้ล่วงหน้า” (Static Generation) ไม่ต้องรอปรุงสดตอนลูกค้ามาถึง

เปรียบเทียบ: เหมือน “อาหารกล่องแช่แข็ง” หรือ “บ้านน็อคดาวน์” ประกอบเสร็จจากโรงงาน (Build Time) พอลูกค้ามาถึง หยิบไมโครเวฟ แล้วกินได้เลย ไม่ต้องรอพ่อครัวทำสด

ข้อดี:

โหลดเร็วที่สุด เพราะเป็นไฟล์ static ที่ผ่าน CDN ทั่วโลก
ปลอดภัยสูง ไม่มี Database ให้แฮกโดยตรง
ค่า Hosting ถูกมาก บางทีใช้ Netlify/Vercel ฟรีได้เลย
SEO ดีเยี่ยม Google ชอบเว็บที่โหลดเร็ว

ข้อเสีย: ไม่เหมาะกับงานที่ต้องแสดงข้อมูล real-time ตลอดเวลา (เช่น Dashboard หุ้น) เพราะข้อมูลถูก “อบ” ตอน build ถ้าข้อมูลเปลี่ยนต้อง rebuild ใหม่

มุมผู้บริหาร: เหมาะกับเว็บ Content, Blog, E-commerce, Corporate Website, Landing Page ทั้งหลาย ที่ต้องการความเร็วและ SEO เป็นหลัก บล็อกที่คุณกำลังอ่านอยู่นี้ก็เป็น Jamstack ครับ

Keywords: Static Site Generator, CDN, Headless CMS

Mobile Strategy — กลยุทธ์ผังเมืองฝั่งมือถือ#

ถ้าฝั่งหลังบ้านคือการวางผัง “ตัวเมือง” ฝั่งมือถือก็คือการวาง “สาขา” ของเราในย่านที่ลูกค้าอยู่จริง คำถามคือเราจะเปิดร้านแบบไหน?

1. Native App — ร้านหรู Custom-made#

แนวคิด: เขียนโค้ดด้วย “ภาษาแม่” ของแต่ละระบบปฏิบัติการโดยเฉพาะ — Swift สำหรับ iOS, Kotlin สำหรับ Android

เปรียบเทียบ: เหมือนสร้างร้านหรูแบบ Custom-made ในแต่ละห้าง ใช้วัสดุที่ดีที่สุด เข้าถึงกล้อง, GPS, Face ID, AR ได้ลึกที่สุด ประสบการณ์ลื่นไหลที่สุด (60fps ไม่สะดุด)

ข้อดี: ประสิทธิภาพสูงสุด เข้าถึงฟังก์ชันเครื่องได้ 100% UX เนียนสุด

ข้อเสีย: แพงและช้า ต้องจ้างช่าง 2 ทีมที่คุยกันคนละภาษา — ทีม iOS และทีม Android ดูแลแยก Bug แยก อัปเดตแยก ค่าใช้จ่ายแทบจะเท่าตัว

มุมผู้บริหาร: ถ้าแอปของคุณต้องใช้ประสิทธิภาพสูงมาก เช่น เกม, แอปแต่งรูป, AR, แอปถ่ายทอดสด หรือมีงบเหลือเฟือและคู่แข่งใช้ Native หมด Native คือคำตอบที่ดีที่สุดครับ แต่ถ้าไม่ใช่เคสเหล่านี้ อย่าเพิ่งรีบ

Keywords: Swift (iOS), Kotlin (Android), High Performance

2. Cross-Platform — ร้านแฟรนไชส์มาตรฐาน#

แนวคิด: เขียนโค้ดชุดเดียว (Single Codebase) แล้วแปลงร่างไปรันได้ทั้ง iOS และ Android เทคโนโลยีเด่นๆ คือ React Native (Facebook) และ Flutter (Google)

เปรียบเทียบ: เหมือนร้านแฟรนไชส์มาตรฐาน ออกแบบแปลนครั้งเดียว สร้างได้ทุกห้าง อาจจะไม่เนี้ยบเท่า Native 100% แต่ User ทั่วไปแยกไม่ออกจริงๆ ครับ ทุกวันนี้แอปใหญ่ๆ หลายตัวก็ใช้แนวทางนี้

ข้อดี: ประหยัดงบและเวลาไปประมาณ 50% เพราะใช้ทีมพัฒนาทีมเดียว ดูแลโค้ดชุดเดียว เวลาแก้ bug แก้ที่เดียวได้ทั้งสองฝั่ง

ข้อเสีย: ประสิทธิภาพไม่สุดเท่า Native โดยเฉพาะงานที่ใช้กราฟิกหนัก และบางฟีเจอร์ใหม่ของ iOS/Android อาจตามไม่ทันทันที

มุมผู้บริหาร: นี่คือ Standard Choice ของธุรกิจปัจจุบันครับ คุ้มค่าที่สุด เริ่มเร็วที่สุด ถ้ายังไม่รู้ว่าจะเลือกอะไร เริ่มที่นี่ก่อนเลย

Keywords: React Native (Facebook), Flutter (Google), Code Reusability

3. PWA / Web App — ร้านป๊อปอัป#

แนวคิด: เว็บไซต์ที่ทำตัวเนียนเป็นแอป เปิดผ่าน Browser ปกติ แต่กด “Add to Home Screen” แล้วจะมี icon บนมือถือเหมือนแอปจริงๆ

เปรียบเทียบ: เหมือนบูธป๊อปอัปในห้าง เข้าถึงง่ายที่สุด แค่คลิกลิงก์ก็ถึงร้าน ไม่ต้องเข้า App Store ไม่ต้องรอโหลด ไม่กินเนื้อที่เครื่องมาก

ข้อดี:

ไม่ต้องผ่าน App Store Review (ไม่ต้องเสียค่าธรรมเนียม Apple/Google 30%)
อัปเดตได้ทันที ลูกค้าไม่ต้องกดอัปเดตเอง
แชร์ลิงก์ได้ ไม่ต้องสอนให้ลูกค้าไปโหลดแอป

ข้อเสีย: ทำอะไรซับซ้อนไม่ได้ เช่น เข้าถึง Bluetooth, Background task หนักๆ หรือ push notification บน iOS ที่ยังจำกัดมาก

มุมผู้บริหาร: เหมาะสำหรับธุรกิจที่ไม่อยากให้ลูกค้าต้อง “ลำบาก” โหลดแอปครับ เช่น เว็บข่าว, เว็บจองคิวโรงพยาบาล, เว็บ e-learning, เว็บเมนูร้านอาหาร หรือใช้ทดสอบตลาด (MVP) ก่อนลงทุนทำแอปจริงก็เวิร์ก

Keywords: Progressive Web App, Service Workers, No App Store

Recap — การวางผังเมือง#

เส้นทางวิวัฒนาการ (The Evolution Path)#

Backend:

Monolith (ง่าย/รวมศูนย์) → Microservices (ยืดหยุ่น/กระจายตัว) หรือ Serverless (เช่าเอา/สะดวก) → Jamstack (สำเร็จรูป/เร็วสุด สำหรับ Content)

Mobile:

PWA (เร็ว/ง่าย) → Cross-Platform (คุ้มค่า/มาตรฐาน) → Native (พรีเมียม/แพงสุด ถ้าจำเป็นจริงๆ)

สิ่งที่ผู้นำต้องจำ (Management Takeaway)#

อย่า Over-Engineer: อย่าบ้าจี้ทำ Microservices ตั้งแต่มี User 100 คน คุณจะเจ๊งเพราะค่าดูแลรักษา Monolith ดีพอแล้วสำหรับ Startup
เลือก Battle ให้ถูก: กลยุทธ์ Mobile ต้องดู “พฤติกรรมลูกค้า” เป็นหลัก ถ้าลูกค้าใช้แค่เดือนละครั้ง ทำ PWA/Web ก็พอ ไม่ต้องบังคับให้โหลดแอป
Architecture เปลี่ยนได้: ไม่มีใครห้ามคุณเริ่มที่ Monolith แล้วค่อยๆ แยกส่วนออกเป็น Microservices ทีหลัง จริงๆ แล้วนี่คือวิธีที่บริษัทใหญ่ๆ ในโลกทำกันทั้งนั้น

เช็กลิสต์สำหรับผู้บริหาร#

ก่อนตัดสินใจเลือก Architecture ลองถามตัวเองครับ

User มีกี่คน? น้อยกว่าหมื่น → Monolith พอ เกินแสน → เริ่มคิด Microservices
ทีม Dev มีกี่คน? ต่ำกว่า 10 → Monolith หลักสิบ/ร้อย → Microservices เริ่มมีประโยชน์
Traffic สม่ำเสมอไหม? ขึ้นๆ ลงๆ → Serverless คุ้ม สม่ำเสมอ → Server ประจำคุ้มกว่า
เว็บเน้น Content? → Jamstack เลยครับ
แอปต้องใช้กล้อง/AR/เกม? → Native ค่อยคิด ไม่งั้น Cross-Platform

ก้าวต่อไปสู่ EP.05#

ตอนนี้เรามี “พิมพ์เขียว” (Blueprint) แล้วครับ ว่าอยากได้บ้านหลังบ้านแบบไหน (Monolith / Microservices / Serverless / Jamstack) และร้านสาขามือถือแบบไหน (Native / Cross-Platform / PWA)

แต่ยังเหลือคำถามสำคัญ — แล้วเราต้อง ซื้อ “วัสดุก่อสร้าง” ยี่ห้ออะไร? React? Vue? Node.js? Python? Go? ถึงจะสร้างบ้านตามพิมพ์เขียวนี้ได้จริง

EP.05 เราจะเข้าโกดังวัสดุด้วยกัน ดูว่าเครื่องมือแต่ละตัวเหมาะกับงานแบบไหน และทำไม Developer ถึงทะเลาะกันไม่เลิกเรื่องจะเลือกอะไรดี

→ EP.05 — Web Technologies