- ประสบการณ์ของนักพัฒนาที่โยกจาก AWS ไปใช้เซิร์ฟเวอร์ของตัวเองและ ลดค่าโครงสร้างพื้นฐานรายเดือนลงเหลือหนึ่งในสิบ โดยลดจาก 1,400 ดอลลาร์ต่อเดือนเหลือ 120 ดอลลาร์ พร้อมได้ ประสิทธิภาพเซิร์ฟเวอร์ที่แรงกว่าเดิม
- เซิร์ฟเวอร์แบบ bare metal ที่ผู้ให้บริการอย่าง Hetzner เสนอในราคา 190 ดอลลาร์ต่อเดือนสำหรับ 80 คอร์ ซึ่งถูกกว่าอินสแตนซ์สเปกใกล้เคียงบน AWS ราว 7–18 เท่า
- เหตุผลที่วิศวกรคลาวด์คัดค้านการดูแลเซิร์ฟเวอร์เองคือ ความมั่นคงในการจ้างงานและการพึ่งพาโครงสร้างพื้นฐานที่ซับซ้อน ขณะที่ภาระต้นทุนจริงเป็นของนายจ้าง
- ธุรกิจขนาดเล็กส่วนใหญ่ ไม่จำเป็นต้องมีฟีเจอร์ระดับองค์กรอย่าง high availability, multi-zone replication หรือ automatic failover และเซิร์ฟเวอร์เครื่องเดียวก็รองรับคำขอได้หลายล้านครั้งต่อวัน
- การดูแลเซิร์ฟเวอร์มักเสถียรหลังตั้งค่าเริ่มต้น และด้วยความช่วยเหลือจาก เครื่องมือ AI ทำให้กำแพงในการเริ่มดูแล Linux server ต่ำที่สุดเท่าที่เคยมีมา
กรณีศึกษาการลดค่าใช้จ่ายคลาวด์
- เมื่อไม่นานมานี้ ผู้เขียนย้ายทุกโปรเจกต์ออกจากคลาวด์และทำได้สำเร็จทั้ง ลดค่า AWS รายเดือนลง 10 เท่าและประหยัดเงินได้หลายพันดอลลาร์
- ค่าใช้จ่าย AWS รายเดือนลดจากราว 1,400 ดอลลาร์เหลือต่ำกว่า 120 ดอลลาร์
- ได้โครงสร้างพื้นฐานเซิร์ฟเวอร์ที่แรงกว่าในราคาที่ถูกกว่า
- ประสิทธิภาพ ดีขึ้น 2 เท่า และหลุดพ้นจาก vendor lock-in
- ทวีตนี้กลายเป็นไวรัลและทำให้เห็นสองอย่าง: นักพัฒนาจำนวนมากสนใจวิธีการนี้ และอีกจำนวนไม่น้อยแสดง ความไม่พอใจอย่างรุนแรงและท่าทีเป็นปฏิปักษ์ ต่อแนวคิดนี้
- แม้จะได้ ประโยชน์ที่ชัดเจน ในมุมธุรกิจ คือประหยัดต้นทุน 10 เท่า ประสิทธิภาพดีขึ้น 2 เท่า และลดการผูกติดกับผู้ขาย แต่กลับต้องเจอกระแสต่อต้านอย่างหนัก
ผลประโยชน์ของฝ่ายที่สนับสนุนคลาวด์
- คนส่วนใหญ่ที่ออกมาคัดค้านมีคำในโปรไฟล์อย่าง "devops", "cloud engineer", "serverless guy", "AWS certified"
- คนเหล่านี้ไม่ได้รันโปรเจกต์ของตัวเองบนคลาวด์ และไม่ได้จ่ายค่าคลาวด์ด้วยตัวเอง
- พวกเขาไม่สนใจบิล AWS ของนายจ้าง และ ไม่ได้รู้สึกถึงความเจ็บปวด จากการเผาเงินหลายพันดอลลาร์ทุกเดือน
- เหตุผลที่ AWS สะดวกสำหรับพวกเขา
- มันดูซับซ้อนทางเทคนิค จึงช่วยให้ดูฉลาดต่อหน้านักพัฒนาคนอื่น
- มันสร้างการพึ่งพาและผลของการผูกติด ทำให้ตัวเองกลายเป็นพนักงานที่แทนที่ได้ยาก
- การใช้คลาวด์ รับประกันเงินเดือนที่สูงกว่า จึงไม่มีแรงจูงใจให้ตัดสินใจอย่างมีประสิทธิภาพเพื่อธุรกิจ
- ยิ่งโครงสร้างพื้นฐานของธุรกิจซับซ้อนและเข้าใจยากเท่าไร งานของพวกเขาก็ยิ่งมั่นคงมากขึ้น
- พวกเขาจะไม่พูดถึง ความจริงที่ว่าเซิร์ฟเวอร์จริง ๆ แล้วราคาถูก
ตัวเลือกการเช่าเซิร์ฟเวอร์ราคาถูก
- ย้ายไปใช้ Hetzner (ไม่มีสปอนเซอร์ แค่เป็นผู้ให้บริการเซิร์ฟเวอร์ราคาถูก)
- เช่า เซิร์ฟเวอร์ bare metal 80 คอร์ได้ในราคาไม่ถึง 190 ดอลลาร์ต่อเดือน
- อินสแตนซ์สเปกใกล้เคียงในตระกูล C5-C6 ของ AWS อยู่ที่ 2,500–3,500 ดอลลาร์ต่อเดือน ซึ่ง แพงกว่า 13–18 เท่า
- แม้ใช้ reserved instance ก็ยังอยู่ที่ราว 1,300 ดอลลาร์ต่อเดือน แพงกว่า 7 เท่า และต้องจ่ายล่วงหน้า 46,000 ดอลลาร์พร้อมสัญญา 3 ปี
- ตัวเลือก VPS ก็น่าสนใจเช่นกัน
- เครื่อง 48 vCPU ราคา 300 ดอลลาร์ต่อเดือน ไม่มีค่าตั้งค่าและไม่มีสัญญาระยะยาว ให้ ความยืดหยุ่นเต็มที่
- เครื่อง 8 คอร์, RAM 32GB ราคา 50 ดอลลาร์ต่อเดือน ถ้าไม่ได้มีคำขอหลายล้านครั้งต่อวัน ก็สามารถ รันทุกโปรเจกต์พร้อมกัน ได้
การซื้อเซิร์ฟเวอร์และใช้ดาต้าเซ็นเตอร์
- ระยะยาวแล้ว การซื้อเซิร์ฟเวอร์คุ้มกว่า
- ซื้อ rack mount server ที่มี 44 CPU, RAM 256GB และ 2TB NVMe SSD ได้ในราคาไม่ถึง 1,000 ดอลลาร์
- ถูกกว่าค่าคลาวด์รายเดือนเสียอีก และใช้รันแอปได้นานหลายปี
- ทางเลือกการเช่าพื้นที่แร็กในดาต้าเซ็นเตอร์
- สามารถเช่า cage หรือ shared rack space ในดาต้าเซ็นเตอร์ ที่มีไฟฟ้า อินเทอร์เน็ต ระบบทำความเย็น และความปลอดภัยให้
- ใช้เว็บไซต์อย่าง DatacenterMap เพื่อค้นหาดาต้าเซ็นเตอร์ในพื้นที่ได้
- แต่สำหรับนักพัฒนารายเล็ก มันซับซ้อนเกินไป
- ต้องจ้างวิศวกร ต้องต่อรองราคา และมีขั้นตอนที่ยุ่งยาก
- โดยมากออกแบบมาสำหรับองค์กรขนาดกลางถึงใหญ่ จึงไม่ค่อยเหมาะกับทีมเล็ก
- และในทางปฏิบัติก็ แทบไม่ต่างจากการเช่าเซิร์ฟเวอร์ที่ติดตั้งในแร็กมาแล้วจากผู้ให้บริการอย่าง Hetzner ซึ่งช่วยลดภาระการดูแลฮาร์ดแวร์
โต้แย้งคำวิจารณ์แบบ "มันก็ยังเป็นคลาวด์อยู่ดีไม่ใช่เหรอ"
- คำวิจารณ์ที่พบบ่อยที่สุดคือ: "นั่นมันก็ยังเป็นคลาวด์ไม่ใช่เหรอ" หรือ "คุณไม่ได้ออกจากคลาวด์ แค่เปลี่ยนผู้ให้บริการคลาวด์"
- เป็นคำวิจารณ์ที่พลาดประเด็นสำคัญ
- สิ่งสำคัญคือคุณค่าระหว่าง การดูแลเซิร์ฟเวอร์เอง vs การยอมรับว่าคลาวด์คือทางเลือกปริยาย
- ถ้ารัน Linux machine เล็ก ๆ แล้วแทนที่บริการ managed service กินเงินอย่าง RDS คุณจะจ่าย น้อยลง 10–100 เท่า
- นักพัฒนาส่วนใหญ่กลัวเซิร์ฟเวอร์ และแค่ต้องการกำลังใจเล็กน้อยว่าพวกเขาตั้งค่าเซิร์ฟเวอร์ของตัวเองในราคาประหยัดได้
- ในโลกความจริง แทบไม่มีใครต้องใช้บริการ managed service ราคาแพงของคลาวด์เลย เพราะซอฟต์แวร์ทั่วไปบน Linux box ไม่กี่เครื่องก็เพียงพอ
- การเถียงเรื่องชื่อเรียกทำให้สาระหลักเลือนหาย
- จะเป็น VPS, bare metal, on-premise หรือ colo ก็ ชื่อเรียกไม่สำคัญ
- คุณต้องวางเซิร์ฟเวอร์ไว้ที่ไหนสักแห่งอยู่แล้ว และคำถามสำคัญคือ คุณเก็บเงินไว้ในกระเป๋าได้มากขึ้น หรือยกมันให้ผู้ถือหุ้น Amazon
- คนที่พูดแบบนี้โดยพื้นฐานแล้วกำลังทำตัวเป็น gatekeeper
- "นั่นไม่ใช่วิธีที่ถูกต้อง คุณต้องซื้อสวิตช์เอง สร้างแร็กเอง ต่อสาย Ethernet เอง"
- มันเป็นตรรกะที่เป็นพิษและขี้เกียจ เป็นการยึดติดกับรายละเอียดผิวเผินเพื่อ หลบเลี่ยงประเด็นหลัก
ต้นทุนคลาวด์นั้นแพงโดยธรรมชาติ
- ความพยายาม gaslighting จากฝ่ายสนับสนุนคลาวด์
- "คุณใช้คลาวด์ผิด" "ที่มันแพงเพราะคุณทำผิด" "คุณต้องรู้วิธีใช้คลาวด์"
- แต่คนเหล่านี้ไม่เคยลองทางเลือกอื่นจริง ๆ และไม่มี ประสบการณ์ตรง ในการดูแลเซิร์ฟเวอร์ให้โปรเจกต์ของตัวเอง
- ผู้เขียนเองคุ้นเคยกับ AWS และเคยเรียนเพื่อสอบใบรับรอง AWS ด้วย
- ตรวจสอบว่าโครงสร้างพื้นฐานไม่ได้ overprovisioned
- ตรวจสอบว่าไม่ได้จ่ายเงินให้บริการที่ไม่ได้ใช้งาน
- ใช้เวลานับไม่ถ้วนกับการ optimize ค่าใช้จ่าย AWS และเคยลดบิลที่เกิน 5,000 ดอลลาร์ต่อเดือนลงได้มากกว่าครึ่ง
- รู้จักทั้ง serverless computing, reserved instance และอื่น ๆ
- reserved instance กลับทำให้ปัญหาแย่ลง เพราะสร้าง vendor lock-in และผูกตัวเองไว้กับสัญญา 3 ปี
- ถ้ากำลังคิดจะหนีออกจากคลาวด์ สัญญา 3 ปีถือเป็น ตัวเลือกที่แย่ที่สุด
- บทสรุปหลังลองทุกทางแล้วคือ: คลาวด์แพงเกินไปจริง ๆ
สาเหตุของแรงต้าน
- ทำไมคนมากมายถึงใส่ใจกับเรื่องการประหยัดต้นทุนขนาดนี้?
- มีข้อสรุปหลักสองข้อ
- ปากท้องของพวกเขาเกี่ยวข้องโดยตรง: ถ้าคนแบบผู้เขียนโน้มน้าวคนได้มากพอ พวกเขาอาจตกงาน
- การโต้เถียงแบบไร้เหตุผลที่ขับเคลื่อนด้วยความกลัว: ในช่วง 10 ปีที่ผ่านมา การสร้างระบบบนคลาวด์เป็นเทรนด์และก่อให้เกิดตำแหน่งงาน "devops" และ "cloud engineers" หลายล้านตำแหน่ง หากการออกจากคลาวด์กลายเป็นเทรนด์ขึ้นมา อาชีพของผู้เชี่ยวชาญคลาวด์จำนวนมากก็อาจจบลง
- นักพัฒนาจำนวนมากรู้อยู่ลึก ๆ ว่าคลาวด์ไม่ได้ดีอย่างที่เคยสัญญาไว้
- เห็นค่าใช้จ่าย AWS ของนายจ้างสูงกว่าที่ควรเป็น 10 เท่า แต่ก็ปล่อยผ่านว่า "ไม่เป็นไร"
- ไม่อยากเสี่ยงทำให้ผู้จัดการไม่พอใจหรือกลายเป็นคนต้องรับผิดชอบ
- กลัวต้นทุนทางการเมืองจากการเห็นต่างกับคนที่เสียงดังที่สุดในทีม
- AWS มี ฐานผู้ติดตามแบบคล้ายลัทธิที่แข็งแรง
- ใช้การรับรองเพื่อฝึกให้คนท่องจำหน้า sales page และคำอธิบายผลิตภัณฑ์
- มี evangelists ที่ผลักดันแนวคิดแบบยึดมั่นในคำสอนมากกว่าความเป็นจริงเชิงปฏิบัติ
- ปลูกฝังความกลัวต่อโลกภายนอก (เซิร์ฟเวอร์อันตราย! scale ไม่ได้!)
- ทำให้คำว่า "cloud engineer" กลายเป็นตัวตน เข้าง่ายแต่ออกยาก
- เพราะปากท้องของพวกเขาเกี่ยวข้องโดยตรง ผู้ศรัทธา AWS จึงยึดติดกับหลักความเชื่อและวนเวียนอยู่กับ ข้อถกเถียงที่ไร้เหตุผล
- พูดซ้ำทีละข้อเหมือนข้อความจากหน้า landing page การขายของ AWS โดยไม่คิดว่าจำเป็นจริงหรือไม่
- เมื่อมันเป็นการโต้เถียงเรื่องระบบความเชื่อ คนจึงกลายเป็นไม่มีเหตุผล
ประวัติศาสตร์ของคลาวด์
- ในอดีต ทุกคนดูแลเซิร์ฟเวอร์กันเอง
- ทั้ง VPS, hosting service, bare metal ในดาต้าเซ็นเตอร์, ห้องมืดในบริษัท หรือที่บ้าน
- ทุกคนคุ้นเคยและสบายใจกับการ SSH เข้าเครื่อง
- ต้นทศวรรษ 2010 เป็นจุดเริ่มของแคมเปญการตลาดแบบ psyops ของคลาวด์
- เป็นความเคลื่อนไหวอย่างจงใจเพื่อขายเทคโนโลยีระดับองค์กรให้สตาร์ตอัประยะเริ่มต้น
- ยิ่งทำให้ผูกติดได้เร็วเท่าไร ก็ยิ่งหาประโยชน์ได้มากขึ้นเมื่อพวกเขาระดมทุน
- กลยุทธ์ของ AWS
- เริ่มแจกเครดิตสำหรับสตาร์ตอัป
- ตระเวนตาม accelerator เพื่อ onboarding ทุกสตาร์ตอัปเข้าสู่ระบบ
- กลลวงนั้นเรียบง่ายมาก: ทำให้การสร้างโครงสร้างพื้นฐานของสตาร์ตอัปราคาถูกมากในช่วงแรก (หรือฟรี!) แล้วเมื่อโตขึ้นก็ทำให้ทุกอย่างแพงมหาศาล ขณะเดียวกันก็อาศัยความผูกติดที่ทำให้หนีออกจาก ecosystem ได้ยาก
- IBM cloud ก็ใช้กลยุทธ์คล้ายกัน (งานอีเวนต์ในปี 2014)
- ตอนนั้นผู้เขียนรันทุกอย่างบน Heroku และมันก็ทำงานได้ดี
- จึงสงสัยว่า "คลาวด์พวกนี้คืออะไร และใช้อย่างไร"
- มันให้ความรู้สึกเหมือนกำลังพยายามขายสิ่งที่ไม่ได้ออกแบบมาเพื่อพวกเขา
- ตลอดหลายปีที่ผ่านมา บริษัทเหล่านี้ทุ่ม เงินหลายล้านดอลลาร์ไปกับแคมเปญโปรโมตคลาวด์ เพื่อผลักดันให้สตาร์ตอัประยะแรกเลือกใช้เทคโนโลยีระดับองค์กร
- อัตราดอกเบี้ยใกล้ศูนย์ในช่วง 10 ปีที่ผ่านมาก็มีส่วนทำให้เกิดสภาพนี้
- ตอนนี้มีกระแสโต้กลับในเชิงวัฒนธรรม
- ส่วนใหญ่ขับเคลื่อนโดย @dhh และชุมชน Rails
- เป็นแนวคิดที่สดใหม่ ถูกต้อง และสอดคล้องกับความเป็นจริงของธุรกิจซอฟต์แวร์ส่วนใหญ่บนโลก
ธุรกิจส่วนใหญ่ไม่จำเป็นต้องใช้คลาวด์
- บางคนมองภาพธุรกิจซอฟต์แวร์จริง ๆ แบบหลุดจากความเป็นจริงไปมาก
- คิดจากมุมมองแบบ Fortune 500 และเชื่อว่ามาตรฐานต้องเป็นระดับองค์กร
- คิดว่าธุรกิจทั่วไปต้องมี high availability, multi-zone replication, automatic failover, distributed Kubernetes cluster และความสามารถทุกอย่างของคลาวด์
- แต่ในความจริง มีธุรกิจซอฟต์แวร์เพียงส่วนน้อยมากที่ต้องการสิ่งเหล่านี้
- ธุรกิจส่วนใหญ่จะมีขนาดเล็กเสมอตามกฎ power law
- ในสหรัฐฯ ธุรกิจขนาดเล็กคิดเป็น 99.9% ของธุรกิจทั้งหมด
- ในสหภาพยุโรป SME (พนักงานน้อยกว่า 250 คน) คิดเป็น 99% ของธุรกิจทั้งหมด
- นักพัฒนาส่วนใหญ่มักประเมินความต้องการในการ scale สูงเกินจริง
- เกณฑ์ของคำว่า "ทราฟฟิกสูง" ต่ำเกินไปมาก
- จุดอ้างอิงคือปัจจุบันผู้เขียนรับคำขอหลายล้านครั้งต่อวันจากผู้เยี่ยมชมหลายล้านคนต่อเดือนด้วย การตั้งค่าเพียง 2 เซิร์ฟเวอร์
- อินดี้เมกเกอร์อย่าง @levelsio ยังรันทุกอย่างบนเซิร์ฟเวอร์เครื่องเดียว
- นักพัฒนาส่วนใหญ่ไม่เคยรันโปรเจกต์ของตัวเองที่มีผู้ใช้จริงและ production traffic จริงบนเซิร์ฟเวอร์เครื่องเดียวด้วยซ้ำ
- ความต้องการทางเทคนิคก็ถูกประเมินสูงเกินจริงเช่นกัน
- มีธุรกิจซอฟต์แวร์เพียงส่วนน้อยมากที่ต้องใช้ฟีเจอร์เหล่านี้ และโดยมากพวกเขาก็มีเหตุผลทางเทคนิคที่ชัดเจน
- เช่น Netflix ที่ต้องแปลงและสตรีมวิดีโอปริมาณมหาศาลให้ลูกค้าทั่วโลก จึงต้องใช้ distributed system, CDN และ edge computing
- แต่ถ้าเป็น แอปเล็ก ๆ ที่มีผู้ใช้พันคนและแค่ส่ง JSON object ไปมา สิ่งเหล่านั้นไม่จำเป็นเลย
- นักพัฒนาหลายคนมีภาพฝันว่าตัวเองกำลังสร้างโปรเจกต์แบบ Netflix
- มันเป็นความหวังที่เข้าใจได้ แต่ก็นำไปสู่การตัดสินใจทางเทคนิคที่ผิดพลาด
- พวกเขาเชื่อว่าจำเป็นต้องมีเซิร์ฟเวอร์กระจายทั่วโลก เพราะผู้ใช้จะสังเกตเห็นความหน่วงเพิ่มขึ้นไม่กี่มิลลิวินาทีตอนแตะปุ่ม
เซิร์ฟเวอร์จะไม่เป็นไรหรอก
- หลายคนมีความคิดแบบมายาว่าดาต้าเซ็นเตอร์ทำงานอย่างไร
- คิดว่าเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์เปราะบาง ผันผวน และอาจหายวับไปในอากาศ
- บางคนถึงขั้นคิดว่าฟ้าผ่าครั้งเดียวอาจทำให้ดาต้าเซ็นเตอร์ทั้งแห่งพังได้
- ดาต้าเซ็นเตอร์สมัยใหม่เตรียมรับมือปัญหาแทบทุกอย่างไว้อยู่แล้ว และมีระบบป้องกันจำนวนมาก
- ไม่ใช่แค่เรื่องทั่วไปอย่างฟ้าผ่า แต่แทบทุกสิ่งที่คุกคาม uptime
- มี redundant power, redundant cooling, redundant internet connection, redundant fire suppression system, redundant security system และความปลอดภัยทางกายภาพอีกมาก
- ทุกอย่างในดาต้าเซ็นเตอร์ถูกออกแบบโดยคำนึงถึงความทนทานและความซ้ำซ้อน (อย่างน้อย N+1 บางครั้งถึง 2N) เพื่อรับประกัน uptime
- ความเห็นเหล่านี้ส่วนใหญ่เกิดจากความกลัว และเป็นผลจากการตลาดและแคมเปญ psyops ของคลาวด์ที่ประสบความสำเร็จ
- AWS เก็บเครื่องไว้ที่ไหน? ใต้สายรุ้งในที่วิเศษหรืออย่างไร?
- ทำไมมีแต่เครื่องของ AWS ที่เหมือนจะถูกปกป้องจากปัญหาที่ดาต้าเซ็นเตอร์อื่นก็มีได้?
- แน่นอนว่าภัยพิบัติเกิดขึ้นได้ (เช่นไฟไหม้ OVH ในปี 2021) จึงต้องมีแบ็กอัปเพื่อการกู้คืน
- แต่จากประสบการณ์ดูแลเซิร์ฟเวอร์ราว 15 ปี เหตุการณ์แบบนี้เกิดขึ้นน้อยมาก และไม่เคยเจอ downtime เกินไม่กี่นาที
การดูแลเซิร์ฟเวอร์ไม่ใช่งานเต็มเวลา
- ใครก็ตามที่ดูแลเซิร์ฟเวอร์มานานพอจะรู้ว่า เวลาส่วนใหญ่หมดไปกับการตั้งค่าเริ่มต้น หลังจากนั้นเซิร์ฟเวอร์มักเสถียรพอสมควร
- ความเสียหายของฮาร์ดแวร์เกิดขึ้นค่อนข้างน้อย และเมื่อเซิร์ฟเวอร์เริ่มรันแล้ว โดยทั่วไปมันจะทำงานได้สมบูรณ์เป็นปี ๆ โดยแทบไม่ต้องแทรกแซงมาก
- การดูแลเซิร์ฟเวอร์เองไม่ใช่งานเต็มเวลา
- ไม่จำเป็นต้องจ้างทีม devops 5 คน
- ไม่จำเป็นต้องจ้างคนดูแลเซิร์ฟเวอร์โดยเฉพาะ: คุณทำเองได้ และมันไม่ได้ยากขนาดนั้น
- Claude และ ChatGPT เข้าใจ Linux system และวิธีการดูแลได้ดี สามารถขอความช่วยเหลือได้
- หลังโพสต์ทวีต มีคนคิดว่านี่เป็นครั้งแรกที่ผู้เขียนดูแลเซิร์ฟเวอร์ และกล่าวหาว่าผู้เขียนมองโลกสวยเกินไปเกี่ยวกับความหมายของการรันเซิร์ฟเวอร์จริง ๆ
- ผู้เขียนมีประสบการณ์ดูแลเซิร์ฟเวอร์ตั้งแต่ปี 2006
- เริ่มจากแก้ PHP script และอัปโหลดขึ้น FTP server
- เรียนรู้วิธีติดตั้ง WordPress แก้ template ของ WP แล้วทุกอย่างก็ต่อยอดจากตรงนั้น
- มันเป็นประสบการณ์ที่มีค่าและสอนพื้นฐานให้
- ได้เรียนรู้ว่า Linux คืออะไร และจะใช้งานมันอย่างไร
- ภายในปี 2007 ผู้เขียนถึงกับขอ Ubuntu CD-ROM จาก Canonical ทางไปรษณีย์ แล้วเอามาติดตั้งบนพาร์ทิชันของคอมพิวเตอร์พ่อแม่เพื่อเรียนรู้ Linux
- ประสบการณ์ช่วงแรกเหล่านี้สอนพื้นฐานของเว็บดีเวลลอปเมนต์ และ ทุกอย่างอื่นก็ถูกสร้างขึ้นบนรากฐานนั้น
ความสำคัญของการเรียนรู้ Linux
- นักพัฒนารุ่นใหม่ (Gen Z, Gen Alpha) ถูกตัดขาดจากฮาร์ดแวร์ที่ใช้รันซอฟต์แวร์อย่างสิ้นเชิง
- พวกเขาขาดประสบการณ์พื้นฐานแบบนี้
- เติบโตมาในยุคที่คนสุ่มบน YouTube สอนให้รันคำสั่งบางอย่างเพื่อโปรโมต vendor รายหนึ่ง พร้อมสัญญาว่าจะแก้ปัญหาโครงสร้างพื้นฐานทั้งหมดอย่างน่าอัศจรรย์
- จึงไม่แปลกที่พวกเขาจะมีสมมติฐานแบบมายาเกี่ยวกับเซิร์ฟเวอร์และการทำงานของมัน
- พวกเขาอาจอ้างว่าสร้างทุกอย่างได้ด้วย "serverless" โดยไม่ตระหนักว่าแท้จริงแล้วมันก็คือ การรันโค้ดบนกล่องอื่นหลายกล่อง
- แน่นอนว่าหลายคนเรียนรู้ Linux และเซิร์ฟเวอร์เพิ่มขึ้นภายหลัง แต่ผู้จบ bootcamp โดยเฉลี่ยยังไม่มีประสบการณ์ Linux แบบลงมือทำที่พวกแฮ็กเกอร์ FTP เมื่อ 20 ปีก่อนเคยมี
- ผู้เขียนไม่ได้ตัดสินเชิงศีลธรรม ไม่ได้บอกว่าดีหรือแย่ — มันก็แค่เป็น สภาพปัจจุบันของเว็บดีเวลลอปเมนต์
- ผลที่เกิดขึ้นคือบริษัทอย่าง Vercel สามารถ ทำเงินหลายล้านดอลลาร์จากนักพัฒนารุ่นใหม่ที่ไม่รู้จริงว่าตัวเองกำลังทำอะไร และไม่เคยรันเซิร์ฟเวอร์มาก่อนในชีวิต
- ความไม่รู้นั้นมีต้นทุนสองชั้น: ต้นทุนของความไม่รู้เอง และต้นทุนที่ต้องจ่ายให้คนอื่นใช้ประโยชน์จากความไม่รู้นั้น
- ถ้าคุณไม่รู้ว่าสิ่งต่าง ๆ ทำงานอย่างไร มันทำให้คุณเสียเงินจริง
ตอนนี้คือช่วงเวลาที่ดีที่สุดในการเรียนรู้เซิร์ฟเวอร์
- ต่อให้คุณไม่เคยดูแลเซิร์ฟเวอร์เองมาก่อน และกลัวทุกอย่างที่มีกลิ่นอายของแบ็กเอนด์ ก็ยังไม่เป็นไร
- ในความเป็นจริง ไม่เคยมีช่วงเวลาไหนดีกว่านี้แล้วสำหรับการเรียนรู้วิธีจัดการเซิร์ฟเวอร์ให้เก่ง
- ทั้ง Claude และ ChatGPT รู้เรื่อง Linux ดีมาก และสามารถแนะนำเป็นขั้นตอนแบบที่ไม่เคยเกิดขึ้นมาก่อนในประวัติศาสตร์เทคโนโลยี
- คุณไม่เพียงเรียนรู้วิธีตั้งค่าและเข้าใจหลักการทำงานได้ แต่เมื่อจำเป็นต้องเปลี่ยนแปลงอะไร ก็สามารถถามและทำตามขั้นตอนได้โดยไม่ต้องจ้างใคร
- มันไม่น่ากลัวขนาดนั้น และก็ไม่ต้องทำบ่อยขนาดนั้นด้วย
- ในยุค AI ที่การสร้างโค้ดกลายเป็นมาตรฐานและโค้ดอาจกลายเป็น commodity การรู้ วิธี deploy โค้ดนั้นลงบน production server ราคาถูก และทำให้มันเป็นประโยชน์กับผู้ใช้จริง อาจกลายเป็นจุดต่างสำคัญของการเป็นนักพัฒนา
- แน่นอนว่าคุณต้องกังวลเรื่องความปลอดภัยอยู่บ้าง
- แต่ให้มองข้ามคำพูดที่บอกว่าการรันเซิร์ฟเวอร์เองปลอดภัยน้อยกว่าการรันบน AWS ราวกับว่า EC2 instance มีเวทมนตร์ป้องกันแฮ็กเกอร์ได้
- ในความจริง การตั้งค่าให้ถูกต้องไม่ได้ยากขนาดนั้น แค่อ้างอิงคู่มือและสคริปต์ตั้งค่าก็พอ
- นักพัฒนาหลายคนที่มีประสบการณ์มากกว่าคุณ ยังทำ production ได้แย่กว่าคุณที่มี AI ช่วยเสียอีก
- ถ้าคุณถาม ChatGPT ว่าจะ harden Linux server อย่างไร และทำตาม security best practices (เช่นไม่ใช้ password authentication และใช้เฉพาะ SSH key ที่แข็งแรง) คุณก็ เสร็จไปแล้ว 90%
- ใช้ Cloudflare เป็นชั้นการป้องกันเพิ่มเติม
- เมื่อล็อก Linux box แน่นแล้ว ก็วาง Cloudflare ไว้ข้างหน้าอีกชั้น
- ถ้าพร็อกซี IP ของเซิร์ฟเวอร์ผ่าน DNS โดยไม่เปิดเผย IP จริง ก็แทบจะสมบูรณ์แบบ
- ได้ทั้งการป้องกัน DDoS, edge caching และ DNS ระดับท็อป โดยแทบไม่เสียเงินเลย
24 ความคิดเห็น
พอคิดถึงเวลาและความพยายามที่ต้องใช้ในการสร้างโครงสร้างพื้นฐานที่จำเป็นขึ้นมาเองแบบ on-premises แล้ว ก็ไม่รู้สึกว่าบริการคลาวด์แพงขนาดนั้น
และบริการคลาวด์ก็ถูกใช้เพราะมีความพร้อมใช้งานสูง ไม่ใช่เพราะเรื่องต้นทุน
ผมว่ามันคล้าย ๆ กับแนวคิดของ IKEA หรือ Daiso นะครับ
น่าจะมีบริการคลาวด์ที่คุ้มค่ามากและสมเหตุสมผลอยู่เหมือนกัน
แต่พอเริ่มใช้ไปแล้ว ก็จะได้ใช้พวกตัวที่ดูแพงขึ้นอีกนิดไปด้วย
(ยกตัวอย่างคร่าว ๆ) พอใช้ Lambda ก็เดี๋ยวต้องใช้ API Gateway ต่อ ซึ่งอันนี้ค่อนข้างแพงและไม่ค่อยสะดวก -_-^
ประมาณนี้แหละครับ
ว่าแต่สิ่งที่ผมเห็นด้วยมาก ๆ คือ
เหตุผลที่ AWS สะดวกสำหรับคนพวกนี้
คือมันดูซับซ้อนในเชิงเทคนิค เลยทำให้ดูฉลาดต่อหน้านักพัฒนาคนอื่น
คือประโยคข้างบนนี้แหละครับ
พูดกันตรง ๆ เลยว่า เพราะบริการของ AWS อยู่มานานและค่อย ๆ พัฒนามา เลยมีฟีเจอร์หลายอย่างที่เลิกใช้ก็ยังเลิกไม่ได้อยู่ การรู้เรื่องพวกนี้แล้วใช้งานเป็นมันดูเท่มาก ตอนนั้นผมเองก็เลยถึงขั้นไปสอบใบ SA มาเหมือนกัน 555.. เห็นด้วยแรงมาก~~
คลาวด์, on-premises และ IDC ต่างก็มีข้อดีข้อเสียของตัวเอง ดังนั้นท้ายที่สุดแล้ว หัวใจสำคัญคือการเลือกให้เหมาะกับวัตถุประสงค์การใช้งานและขนาดขององค์กร
สมมติฐานใหญ่ที่สุดคือ "ฮาร์ดแวร์แทบไม่พังเลย" แต่...
จากที่เคยเจอ ตอนบริษัทเช่าแร็กใน IDC แล้วรันเซิร์ฟเวอร์เอง จำได้ว่าดิสก์พังทุกประมาณ 3 วัน
เลยต้องคอยวิ่งไปเปลี่ยนดิสก์และกู้คืน RAID อยู่ตลอด...
ถ้าเป็นไปได้ก็แนะนำให้ใช้คลาวด์ไปเลยครับ
ตอนฮาร์ดแวร์พังแล้วกด "คลิก" เดียวก็ยกกลับขึ้นมาได้ มันมีคุณค่ามหาศาลจริง ๆ.....
ดิสก์พังทุก ๆ 3 วันนี่ดูแปลกไปหน่อยนะ... ดูเหมือนจะไม่ใช่เคสทั่วไป
เป็นเรื่องเมื่อกว่า 10 ปีที่แล้ว และน่าจะเป็น Seagate..มั้งครับ
Backblaze บอกว่าปีที่แล้วมีไดรฟ์เสีย 4,372 ลูก ดังนั้นในสเกลระดับนั้นก็เท่ากับมีไดรฟ์เสียหนึ่งลูกทุก ๆ 2 ชั่วโมงอยู่ดี...
เป็นความถี่ที่อาจเกิดขึ้นได้เมื่อมีขนาดใหญ่มาก
อืม ผมเคยทำงานอยู่ค่อนข้างนานในสภาพแวดล้อมที่มีห้องคอมพิวเตอร์ขนาด 42U Rack 100 ตู้ ซึ่งประกอบด้วย HPC, HCI, distributed file system ที่สร้างด้วย Hadoop ยุคแรก ๆ และสตอเรจสารพัดแบบ แต่ไม่เคยเห็นดิสก์เสียทีละครั้งทุก 3 วันเลยครับ
ความคิดเห็นจาก Hacker News
ฉัน ดูแลเซิร์ฟเวอร์เอง มาหลายปี รักษาความเรียบง่ายไว้ได้และประหยัดทั้งเวลาและเงินไปมาก
เลี่ยง AWS กับ Azure เพราะตั้งค่ายุ่งยากและ UI ก็ไม่ค่อยดี
สิ่งสำคัญคือต้องจัดการให้สามารถ สร้างเซิร์ฟเวอร์ขึ้นมาใหม่ได้จากไฟล์คอนฟิกเท่านั้น ได้เสมอ เพราะงั้นเครื่องมืออย่าง Ansible จึงจำเป็น
ถ้าจำเป็นต้องใช้คลาวด์จริง ๆ ก็แนะนำ DigitalOcean เพราะเรียบง่าย เข้าใจง่าย และดีต่อสุขภาพจิต
ฉันใช้ DO แค่สำหรับ ระดับ 3 ของการกู้คืนจากภัยพิบัติ เท่านั้น และตั้งค่าคลัสเตอร์อัตโนมัติด้วย Terraform และ Ansible
ชุมชนนักพัฒนาส่วนใหญ่มักไหลไปตามกระแส แต่ฉันยังคงดีพลอย Clojure monolith บน JVM ลงบนคลัสเตอร์เซิร์ฟเวอร์จริงของตัวเอง และทำกำไรได้อย่างมั่นคงท่ามกลางบรรยากาศแบบนั้น
ทั้งการตั้งค่า ulimit, ปัญหาด้านประสิทธิภาพของ syn cookies, การอัปเดตความปลอดภัย, การรับมือกับ การโจมตีแบบ zero-day, การส่งอีเมล (การวอร์ม IP, การจัดการรายการสแปม), การปฏิบัติตาม GDPR ฯลฯ
ทั้งหมดนี้กลายเป็นความรับผิดชอบของฉัน และคนที่ใช้คลาวด์ก็ไม่ได้เป็นแค่พวก ‘โดนหลอก’ เสมอไป
ฉันไม่ชอบการมองอะไรแบบขาวดำ สตาร์ตอัปส่วนใหญ่จะประหยัดค่าใช้จ่ายได้มากถ้าย้ายจาก EC2 ไปใช้ Hetzner, Linode หรือ DigitalOcean
แต่คลาวด์ก็มีข้อดีเยอะมาก — ฟังก์ชันอย่าง แบ็กอัป, managed DB, multi-AZ ใช้งานได้ด้วยการคลิกไม่กี่ครั้ง
ไม่มีต้นทุนลงทุนฮาร์ดแวร์ตั้งต้น และถ้ามีโหลดพีกสูงมาก บางทีก็อาจถูกกว่าด้วยซ้ำ
แต่เพราะเวลาของวิศวกรมีมูลค่าสูง คลาวด์จึงอาจเป็นตัวเลือกที่สมเหตุสมผลในช่วงเติบโตเร็ว
สุดท้ายแล้วคลาวด์ไม่ได้แพงเพราะมันแพงเอง แต่แพงเพราะ ใช้ฟีเจอร์ที่ไม่จำเป็น
ก็มีหลายกรณีที่กลยุทธ์ multi-cloud ช่วยป้องกันภัยพิบัติได้จริง
VPS หรือ dedicated server ก็แทบไม่มีต้นทุนเริ่มต้นเหมือนกัน และถ้าโหลดพีกไม่ได้สุดโต่งมาก คลาวด์ก็ไม่ได้ถูกกว่าเสมอไป
managed DB สะดวกก็จริง แต่มี การอัปเกรดแบบบังคับ บ่อย และถ้าไม่ได้ขนาดใหญ่มาก ผมมองว่าดูแลเองดีกว่า
เมื่อก่อนการขยายฮาร์ดแวร์ทำได้ยาก แต่ตอนนี้เซิร์ฟเวอร์เครื่องเดียวก็ให้ประสิทธิภาพได้เทียบเท่ากับทั้งแร็กในอดีต
โปรเจกต์ขนาดกลางตอนนี้สามารถแก้ปัญหาที่แต่ก่อนต้องพึ่งคลาวด์ได้ด้วยตัวเองแล้ว
เพียงแต่ถ้าต้องพึ่ง แรงสนับสนุนจากคนนอกองค์กร คลาวด์จะง่ายกว่ามาก ส่วน self-hosting หาคนซัพพอร์ตยาก
โดยส่วนตัวฉันชอบ self-hosting แต่ถ้าเป็นคนที่ไม่อยากยุ่งกับอินฟราด้วยตัวเอง ฉันคิดว่าคลาวด์เหมาะกว่า
เมื่อก่อนฉันดูแลงาน IT ให้สตาร์ตอัปเฮดจ์ฟันด์แห่งหนึ่ง
เรารันโปรแกรมวิเคราะห์ C++ บนเซิร์ฟเวอร์ Dual Xeon (RAM 512GB) แล้ววันหนึ่ง CEO ไปกินข้าวกลางวันและได้ยินคำถามว่า “ทำไมไม่ใช้ AWS” จนเริ่มกังวล
ได้เห็นความจริงที่ว่า ‘การทำตาม buzzword’ กลับสำคัญกว่าประสิทธิภาพ
CTO จำนวนมากใช้งบก้อนโตโดยไม่จำเป็นเพราะบรรยากาศแบบนี้ และโครงสร้างที่มีประสิทธิภาพกลับกลายเป็นจุดอ่อนทางการตลาดในโลกแบบนี้
คำว่า “ประหยัดได้ 10 เท่า” นั้นผิดในเชิงตรรกะ เพราะ 10 เท่าหมายถึงมากขึ้น
ต้นทุนแรงงานด้านการบำรุงรักษา สูงกว่าค่าเซิร์ฟเวอร์
ต่อให้รัน EC2 อยู่ 10 อินสแตนซ์ ก็ยังแพตช์อัตโนมัติด้วย Systems Manager ได้ จึงไม่จำเป็นต้องสร้างระบบอัตโนมัติเองทั้งหมด
การถกเรื่องคลาวด์ไม่ใช่ขาวดำ
ธุรกิจขนาดเล็กจะใช้ Hetzner หรือ AWS ก็ใกล้เคียงกัน ส่วนองค์กรใหญ่ประเด็นอยู่ที่สร้างเครื่องมือของตัวเองได้ไหม
ช่วง SME นี่แหละที่ก้ำกึ่งที่สุด ถ้าต้องการระบบแยกขาดสำหรับลูกค้าแต่ละราย AWS จะได้เปรียบ แต่ถ้าเป็นโหลดคงที่ตลอด 24/7 เซิร์ฟเวอร์ของตัวเองจะดีกว่า
ถ้าใช้คลาวด์แค่เป็น VM hosting ก็ขาดทุน เพราะมักจะเป็นการ จ่ายเงินโดยไม่ได้ใช้ความสามารถของคลาวด์
เซิร์ฟเวอร์ของตัวเองต้องจ่ายสำหรับความจุสูงสุดตลอดทั้งเดือน แต่คลาวด์จ่ายเฉพาะไม่กี่วันที่จำเป็น
คลาวด์มีประโยชน์มากสำหรับ การสร้าง MVP และทดสอบตลาด
ใช้สตาร์ตอัปเครดิตและฟรีเทียร์เพื่อทดลองได้อย่างรวดเร็ว แล้วถ้าต้นทุนเริ่มเป็นปัญหาค่อยย้ายก็ได้
แต่ต้องออกแบบให้เป็น สถาปัตยกรรมที่ไม่ผูกกับเซิร์ฟเวอร์ตั้งแต่แรก และการหาเวลาสำหรับ migration ก็ไม่ง่าย
ทีมของเราใช้ Google Cloud แต่เพราะใช้จ่ายไม่มาก ฝ่ายขายเลยไม่ค่อยพอใจ
ความเป็นไปได้ที่จะย้ายข้ามคลาวด์ได้ช่วยเพิ่มอำนาจต่อรอง
นอกจากนี้คลาวด์ยังช่วยเรื่อง SLA และการปฏิบัติตามข้อกำหนดด้านการคุ้มครองข้อมูลได้ง่าย จึงเอื้อต่อ การสร้างความเชื่อมั่นกับลูกค้าองค์กร
สงสัยว่าทำไม AWS ถึงเติบโตแบบก้าวกระโดดในช่วงแรก
ช่วงต้นทศวรรษ 2010 การเช่าแร็กและตั้งเซิร์ฟเวอร์ยังแพงและช้า และแทบเป็นไปไม่ได้เลยที่จะทำ สถาปัตยกรรมหลายรีเจียน
AWS แก้ปัญหาเหล่านี้ได้ แต่ตอนนี้สถานการณ์เปลี่ยนไปแล้ว
ยังมีเกร็ดด้วยว่า Squarespace เคยขนน้ำมันเชื้อเพลิงไปช่วยเซิร์ฟเวอร์ของตัวเองช่วงพายุเฮอริเคน Sandy
ที่ Hetzner สั่งเซิร์ฟเวอร์แล้วภายใน 10 นาทีก็ติดตั้ง Ubuntu และเซ็ต Ansible เสร็จได้
ค่าบริการคงที่ แบนด์วิดท์ไม่จำกัด ประสิทธิภาพคาดเดาได้ — เสน่ห์คือ ความเรียบง่ายที่ไร้นามธรรมเกินจำเป็น
EC2 ช่วยลบความยุ่งยากแบบนั้นไป และ Lambda ก็ไปไกลกว่านั้นอีก ตอนนี้ การเช่า bare metal ถูกลงมาก แล้ว
นโยบายให้เครดิตฟรีของ AWS ในอดีตก็คือ กลยุทธ์ lock-in ในทางปฏิบัติ
การเอาเซิร์ฟเวอร์ไปวางในดาต้าเซ็นเตอร์เองไม่ได้ยากอย่างที่คิด
ฉันต้องการ CPU ความถี่สูงสำหรับ เกมเซิร์ฟเวอร์ ซึ่งหายากบนคลาวด์ เลยสร้างเอง
รวมค่าติดตั้งแล้วจ่ายแค่ประมาณ £15 ต่อเดือน ใช้งานได้ดีมาหลายปี และสรุปแล้วช่วยประหยัดค่าใช้จ่ายได้มาก
วางอุปกรณ์ไว้ที่ดาต้าเซ็นเตอร์ในซีแอตเทิล และบริหารจากระยะไกลด้วย KVM แบบโมเด็ม
เรา ย้ายไป Hetzner เมื่อหลายปีก่อน และจากเงินที่ประหยัดได้ก็คงไม่กลับไปใช้คลาวด์อีกแล้ว
ข้อยกเว้นคือ Cloudflare Workers เพราะคุณภาพดีและโควต้าฟรีก็ให้มาเยอะ
AI ทำให้การเขียนสคริปต์สำหรับงานอัตโนมัติ ดีพลอย และแบ็กอัปง่ายขึ้นมาก จึงดูแลง่ายกว่าเมื่อก่อน
เผื่อใครสนใจ Claude Code ของ Anthropic กำลังให้ เครดิตฟรี $250 สำหรับผู้ใช้ Pro/Max ถึงวันที่ 18 พฤศจิกายน
ประกาศที่เกี่ยวข้องดูได้จากทวีตนี้
แค่เคยเจอการกู้คืนจากแบ็กอัปสักครั้งก็น่าจะรู้สึกถึงคุณค่าได้แล้วไม่ใช่เหรอ? ระบบ on-premises นี่ปวดหัวที่สุดก็เรื่องการกู้คืนจากแบ็กอัปนี่แหละ
ก็เอาเถอะ.. ผมเห็นด้วยร้อยเปอร์เซ็นต์กับประเด็นที่ว่า 'ค่าใช้จ่ายคลาวด์แพงเกินความจำเป็น' และ 'ในกรณีส่วนใหญ่ไม่ได้ต้องการความสามารถของคลาวด์รายใหญ่' แต่โทนของบทความมันทำให้อ่านแล้วรู้สึกขัด ๆ เหมือนกำลังอ้างว่าบริการคลาวด์ทั้งหมดเป็นการหลอกลวง ฟังดูเหมือนพูดว่า 'ผลิตภัณฑ์ประกันภัยทั้งหมดเป็นการหลอกลวง' เลยครับ
คลาวด์ก็มีไว้ใช้ตอนที่ไม่อยากดูแลเซิร์ฟเวอร์เอง หรือเมื่อต้องการสเกลอย่างรวดเร็วในกรณีที่คาดการณ์ความต้องการได้ยากเท่านั้น นอกเหนือจากนั้น ผมก็ไม่แน่ใจว่ามันจะมีความหมายกับการใช้งานแบบอื่นแค่ไหน
เห็นด้วยทั้งหมด แต่ก็น่าเสียดายที่ไม่มีการกล่าวถึงมุมมองด้านความปลอดภัยเมื่อดูแลเซิร์ฟเวอร์ด้วยตัวเองเป็นรายปี
ผมก็อยากโหวตเห็นด้วยกับความเห็นนี้อีกหนึ่งเสียงครับ
ถูกต้องครับ
เห็นด้วยร้อยเปอร์เซ็นต์ว่าคลาวด์แพง
แต่ถ้าคิดว่าตอนนี้ต้องมาตั้งค่า Kubernetes เองบน bare metal เพื่อใช้งานคอนเทนเนอร์มากกว่า 200 ตัว
ในสถานการณ์ที่มีแบ็กเอนด์เดเวลอปเปอร์แค่คนเดียวและไม่มี devops ถ้ามองว่าสามารถลดภาระเรื่องการดูแลและปฏิบัติการเซิร์ฟเวอร์ได้ด้วยค่าใช้จ่ายเพียงครึ่งหนึ่งของครึ่งหนึ่งของเงินเดือนคนหนึ่งคน ก็ถือว่าเป็นตัวเลือกที่ไม่ได้แย่เหมือนกัน
ถ้ามีคนที่ทำหน้าที่ดูแลโครงสร้างพื้นฐานเซิร์ฟเวอร์"อย่างเดียว" การออกจากคลาวด์ก็น่าจะเป็นตัวเลือกที่ดีได้อย่างแน่นอน
ส่วนตัวพอลองสร้างบริการโดยพยายามตัดการใช้คลาวด์ออกให้มากที่สุดแล้ว บอกเลยว่าแทบจะปวดหัวตายเลยครับ.
ผมต้องการที่เก็บ container image แต่พอจะสร้างเองก็รู้สึกว่า local storage เป็นภาระ เลยไปหาพวกที่รองรับ
s3 compatibleเพื่อให้สำรองข้อมูลง่ายขึ้น แล้วก็ต้องตั้งบริการ VPN เพื่อบล็อกการเข้าถึงจากภายนอก ต่อด้วยการจัดการใบรับรอง HTTPS บน reverse proxy และการตั้งค่าต่าง ๆ เพื่อความปลอดภัยของ CI/CD อีก... สร้างเองทั้งหมด...ถ้าเป็นกรณีใช้แค่บริการง่าย ๆ บนคลาวด์ไม่กี่ตัว แน่นอนว่า bare metal ถูกกว่าและใช้งานแบบนั้นก็คงเหมาะครับ แต่ถ้าจำเป็นต้องเชื่อมต่อกับบริการอื่น ๆ และอยากลดภาระจุกจิกพวกนี้ลง ต่อให้ค่าเซิร์ฟเวอร์ตอนนี้แพงกว่า การไม่ต้องมานั่งสร้างบริการเหล่านี้ทีละอย่างเองก็อาจทำให้คุ้มกว่าได้ เพราะประหยัดต้นทุนด้านการติดตั้งและการดูแลรักษา.
มีโอเพนซอร์สสำหรับคลังเก็บอิมเมจอยู่มากมาย
มีเยอะครับ ผมหมายถึงภาระที่ต้องดูแลและดำเนินการเองครับ ผมเองก็ใช้ Nexus หรือ Harbor เหมือนกันครับ
จากประสบการณ์ส่วนตัว ผมไม่ได้รู้สึกว่าเป็นภาระหรือมีปัญหาอะไรนะครับ
แต่เพราะเกณฑ์ในการมองว่าอะไรเป็นภาระของแต่ละคนต่างกัน ก็เลยอาจจะคิดแบบนั้นได้เหมือนกันครับ
คุณกำลังพัฒนาบริการแบบใดอยู่จึงต้องการที่เก็บอิมเมจคอนเทนเนอร์?
ไม่ว่าจะพัฒนาบริการแบบไหน ผมก็ชอบการดีพลอยแบบคอนเทนเนอร์อยู่ดี เลยเป็นแบบนั้นครับ และก็ชอบทำให้การดีพลอยไม่ต้องเชื่อมต่อ
sshโดยตรงให้ได้มากที่สุดด้วย ถ้าคิดแค่เรื่องค่าใช้จ่ายอย่างเดียว... ก็น่าจะมีวิธีที่ดีพลอยตรงได้โดยไม่ต้องมีรีจิสทรีอยู่บ้าง แต่สิ่งที่ยกมานี่เป็นแค่ตัวอย่างนะครับ และผมอยากโฟกัสไปที่ความไม่สะดวกบางอย่างที่อาจเกิดขึ้น เช่น บริการอีเมล เป็นต้น