- บัญชีที่แชร์เรื่องชวนงงที่พบเจอทุกวันบน Microsoft Azure ตอนนี้เกิน 400 วันแล้ว
- Day 403: เมื่อเร็ว ๆ นี้มีงาน #Microsoft Cloud for Sustainability Technical Summit แต่ในความเป็นจริงกลับให้ความรู้สึกเหมือนงาน #Copilot summit ที่โฟกัสเรื่องความยั่งยืนนิดหน่อยมากกว่า (ภาพหน้าจอนี้นำมาจากแค่สามเซสชันแรกเท่านั้น)
- Day 402: ฟีเจอร์ #AI ใหม่ของ Azure CLI จนถึงตอนนี้ทำงานได้ยอดเยี่ยมมาก (ภาพหน้าจอข้อผิดพลาด)
- Day 401: รูปภาพข้อผิดพลาดของลิงก์ เป็นเพียงหนึ่งในตัวอย่างนับไม่ถ้วนของลิงก์เอกสาร #Azure ที่พาไปยังส่วนที่ไม่มีอยู่จริง
...
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สมัยก่อนตอนทำงานที่ Mojang หลังจากถูก Microsoft ซื้อกิจการ เราพยายามย้ายจาก AWS ไป Azure
มองผิวเผินก็สมเหตุสมผล เพราะค่า AWS อยู่ที่หลักแสนดอลลาร์ต่อเดือน ส่วน Azure ใช้ได้ฟรี
แต่หลังจากผ่านไปราว 1 ปี ทีมของเราและผู้เชี่ยวชาญด้านโซลูชันที่องค์กร Azure จัดมาให้ใช้เวลาไปนับไม่ถ้วน สุดท้ายทุกคนก็เห็นตรงกันว่าควรจ่ายเงินหลักแสนให้หนึ่งในคู่แข่งรายใหญ่ของ Microsoft ต่อไป
ตั้งแต่นั้นมาผมก็ไม่มองว่า Azure เป็นผู้ให้บริการคลาวด์ที่ใช้งานจริงได้ และวันหนึ่งอาจต้องประเมินใหม่ แต่ก็คงไม่ใช่ครั้งแรกที่ผมคิดผิด
โดยรวมก็พอใช้ได้ แต่ปัญหาเริ่มเกิดเมื่อเริ่มใช้ CosmosDB ซึ่งตอนนั้นชื่อ DocumentDB
DocumentDB ช่วงแรกแย่มากจริง ๆ การคาดการณ์ราคายากเกินไปจนมีบิลสุดเพี้ยนออกมาทุกสุดสัปดาห์ และ .NET SDK ที่ให้มาก็มีบั๊กเยอะและแย่มาก
สิ่งที่แย่ที่สุดคือเว็บ UI ดูเหมือนจะผูกตรงกับอินสแตนซ์ CosmosDB บางตัว
ถ้าจัดสรรทรัพยากรฐานข้อมูลไว้น้อย มันก็ช้าลง และเว็บอินเทอร์เฟซที่ต้องใช้เพื่อเพิ่มทรัพยากรก็หน่วงไปด้วย
จึงเคยถึงขั้นต้องปิดแอปพลิเคชันทั้งตัวเพื่อเพิ่มทรัพยากร Cosmos และ Microsoft ให้ความรู้สึกเหมือนมือสมัครเล่นสุด ๆ
เข้าใจว่าตอนนี้ Cosmos ดีขึ้นมากแล้ว แต่ความค้างคาจากตอนนั้นแย่มาก
ถ้ามีเครดิตฟรีอะไรสักอย่าง อาจลอง Azure อีกครั้งได้ แต่ตอนนี้จะไม่แนะนำเด็ดขาด
การรันบริการอีเมลที่ใหญ่ที่สุดในโลกบนสแตก Windows คงเป็นการรับรองที่ยิ่งใหญ่มาก แต่กว่าจะสำเร็จก็ใช้เวลาหลายปี
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
เดาว่าอาจเป็นฟีเจอร์เฉพาะของ AWS เช่น วิธีจัดการ serverless ของ AWS ที่ย้ายตรงไป Azure ไม่ได้ แต่ผมอยากเรียนรู้อยู่เสมอว่าทำไมการย้ายจาก X ไป Y ถึงล้มเหลว
ระหว่างนั้นเทคโนโลยีฝั่งเกมน่าจะพร้อมขึ้นด้วย ซึ่งช่วยได้
แก้ไข: AWS -> Azure :)
ตอนนั้นมีช่องว่างทางเทคนิค เพราะ AWS นำหน้าโดยรวม และดูเหมือนว่าช่องว่างนั้นถูกอุดในภายหลัง
ไม่เป็นไรหรอก เดี๋ยวสัปดาห์หน้า Microsoft ก็เปลี่ยนชื่อ แล้วรื้อ UI ผู้ดูแลระบบกับ API ใหม่หมด
ชื่อใหม่จะเป็น Dynamics CoPilot OneAI 365 for Business OneCloud
live.comบางอันเป็นoutlook.comและบางอันเป็นsharepoint.com,msbinbows.comอะไรทำนองนั้นอยู่ดีแต่เอกสารกับการอ้างอิงอื่น ๆ ทั้งหมดก็คงยังใช้ชื่อเดิมต่อไป
จากประสบการณ์ของผม เคยเห็นองค์กรที่ใช้ตั้งแต่แร็กเซิร์ฟเวอร์ on-premises ไปจนถึง Linode, AWS, Azure และพบว่าความไม่พอใจต่อโครงสร้างพื้นฐานคลาวด์แปรผันตาม ปริมาณการใช้บริการแบบจัดการให้
ทีมที่พึ่งพาแค่เครื่องเสมือนเป็นหลัก อย่างมากก็ฐานข้อมูลเชิงสัมพันธ์แบบจัดการให้ แทบไม่บ่นเลย
แม้ต้องดูแลสคริปต์เพิ่มเล็กน้อย แต่เมื่อเทียบกับการต่อสู้กับปัญหาและพฤติกรรมแปลก ๆ ของบริการแบบจัดการให้ ก็เป็นความไม่สะดวกเล็กน้อย
แน่นอนว่าเครื่องเสมือนธรรมดาดูแลง่ายกว่าบริการแบบจัดการให้ และนั่นแหละคือเหตุผลที่ยอมจ่ายเงินให้ผู้ให้บริการคลาวด์แพงกว่ามากสำหรับ บริการแบบจัดการให้ เพื่อจะได้ไม่ต้องทำเอง
สรุปคือความพยายามนี้โดยเนื้อแท้แล้วไร้ความหมายหรือเปล่า?
เหตุผลหลักที่หลายบริษัทย้ายขึ้นคลาวด์คือบริการแบบจัดการให้ ดังนั้นผมไม่คิดว่าคำพูดนี้จะไม่เป็นที่ถกเถียงเลย
ลูกค้ารายหนึ่งต้องการ IPsec tunnel ไปยัง VPC ที่มีเซิร์ฟเวอร์โปรดักชันอยู่ และเราไม่อยากดูแลคอนฟิกแบบนั้นเองเพื่อแค่ลูกค้ารายเดียว พอไปดูบริการของ AWS ก็มีโซลูชัน IPsec แบบจัดการให้
แต่ลูกค้าติดต่อมาว่า tunnel ล่ม และทางแก้คือฝั่งลูกค้าต้องรีสตาร์ตเพื่อให้การเชื่อมต่อกลับมา
แม้จะเปิด S3 logging เพื่อดูสาเหตุได้ แต่คำอธิบายจากฝั่ง AWS คือทุกอย่างควรจะปกติ
แค่ใช้ EC2 ก็ยังมีเรื่องแปลก ๆ เกิดขึ้น
ล่าสุดมี EC2 instance หยุดตอบสนอง แต่ Auto Scaling Group ไม่เปลี่ยนตัวใหม่ให้ และไม่ว่าจะทำอะไรก็ขึ้นข้อผิดพลาดว่าอินสแตนซ์ไม่ได้กำลังทำงาน ทั้งที่สถานะยังเป็น running
โชคดีที่หัวหน้าเห็นด้วย แต่ก็ไม่ได้มีอำนาจเต็ม
เพราะ การผูกติดกับผู้ขาย และความเข้ากันได้ของ API ที่เกือบเหมือนโอเพนซอร์สแต่ไม่เหมือนทั้งหมด ผมยิ่งกังวลเมื่อมีทีมรับไปใช้มากขึ้น
พวกเขาบอกว่า “แต่มันง่ายกว่านี่!” ซึ่งก็คงต้องรอดูกัน
ก่อนราวปี 2014 AWS ลดราคาบริการหลักเป็นระยะ ๆ เพื่อส่งต่อส่วนต่างจากต้นทุนเทคโนโลยีที่ลดลง
Azure ไม่ชอบสิ่งนั้น จึงเริ่มตั้งราคาให้เท่ากับ AWS และตามส่วนลดเดียวกันของบริการเดียวกันทันที
นี่เป็นรูปแบบหนึ่งของการตั้งราคาแบบล่าเหยื่อ เพราะมีเป้าหมายเพื่อฆ่าแรงจูงใจในการลดราคา โดยทำให้คู่แข่งไม่ได้ส่วนแบ่งตลาดแม้จะลดราคาลง
ผมอยากชอบ Azure จริง ๆ เพราะมันผสานกับเครื่องมือต่าง ๆ ได้ดี แต่ก็เจอ ข้อจำกัดด้านความพร้อมใช้งานของเครื่องเสมือน กับความแปลกของ UX อยู่เรื่อย ๆ
ใน AWS ผมไม่เคยเจอสถานการณ์ที่หาเครื่องไม่ได้ หรือสงสัยว่าสิ่งที่ผมทำไปถูกนำไปใช้จริงหรือไม่
เคยคิดจะใช้ FaaS ของ Azure อยู่หลายครั้ง แต่ตอนนี้ยืนกรานว่า “อย่าใช้ รีบหนีไปให้ไว”
ประสบการณ์รอบ ๆ Azure Functions แปลกเกินไปจนรู้สึกสบายใจไม่ได้ และการเข้าถึงล็อกหรืออาร์ติแฟกต์ไบนารีอื่น ๆ ก็เจ็บปวดอย่างมหาศาล
การรันบิลด์ .NET แบบ self-contained บนเครื่องเสมือน Windows/Linux เปล่า ๆ มันง่ายมาก จนไม่มีเหตุผลต้องไปพัวพันกับความซับซ้อนเพิ่มเติมทั้งหมดนี้
แล้วยังมี พฤติกรรมที่ทำลาย automation เช่น SQL Server ส่ง callback มาบอกว่ากำลังรันอยู่ ทั้งที่จริง ๆ ต้องรออีก 20 นาทีถึงจะพร้อม
ผมค่อนข้างมั่นใจอยู่ครึ่งหนึ่งว่า
terraform time_sleepถูกสร้างขึ้นมาเป็นพิเศษเพื่อกันปัญหาของ Azureถ้า function app ต้องการมากกว่าฟังก์ชันธรรมดา เช่นเวลารันที่ยาวขึ้น หรือไม่มีความหน่วงจาก cold start สุดท้ายก็จะไปใช้บริการตัวเดียวกันนี้
App Services ต้องใช้เวลาทำความคุ้นเคย แต่ก็คือคอนเทนเนอร์ Win Server/IIS ที่ถูกล็อกไว้ มี FTPS ในตัว, endpoint ตรวจสุขภาพสำหรับ self-healing, การ deploy แบบระบุ storage, ตัวเลือก autoscaling และ SLA 99.95%
เมื่อไม่กี่ปีก่อนประสิทธิภาพไม่ค่อยดี แต่ Premium SKU ที่มี vCPU 2 ตัวขึ้นไปบน CPU รุ่นใหม่ ๆ ไม่มีปัญหา
มันแพงกว่าเครื่องเสมือน แต่การจัดการความปลอดภัยและอัปเดตของเครื่องเสมือนเว็บเซิร์ฟเวอร์เป็นงานที่หนักมาก
เราซื้อกิจการบริษัทหนึ่งที่โฮสต์อยู่บน Azure
พวกเขาใช้ hosted Postgres กับบริการ .NET บน Windows และอินฟราขนาดเล็ก แค่ประมาณ 200~300 คอร์กับหน่วยความจำ 1TB
ทุก ๆ ไม่กี่วัน Microsoft จะอ้างว่าเป็นการบำรุงรักษา แล้วสุ่มปิด instance ใด ๆ ลง และตัดเครือข่ายนานกว่า 10 นาที
hosted Postgres ประสิทธิภาพแย่มากจนต้องย้ายออก แต่ผู้เชี่ยวชาญจากอินเดียแนะนำให้ใช้ชนิด volume แบบอื่น และหลังรีสตาร์ต instance ฐานข้อมูลก็ขึ้นมาไม่ได้เพราะ I/O latency
ผู้เชี่ยวชาญคนนั้นบอกว่ายุ่งและเลี่ยงประชุม 3 วันติด ส่วน RCA ก็เป็นเอกสารครึ่ง ๆ กลาง ๆ ที่เหมือน LLM เขียน บอกว่าไม่ใช่ความผิดของพวกเขา แต่กราฟบอกอีกอย่าง
สิ่งเดียวที่ชนะ GCP กับ AWS ได้คือ dashboard โหลดเร็ว
แต่ก็เศร้า เพราะถ้ารันงานเครือข่ายคล้าย ๆ กัน 2 งานแบบ parallel มันจะล้มเหลวหรือใช้เวลานานกว่ารันทีละงาน 10 เท่า
หนีไป และอย่าใช้
ในบรรดาผู้ให้บริการ PaaS ทั้งหมด Azure มี abstraction และ service แย่ที่สุด
น่าเศร้าที่โดยรวมทุกคนก็ยอมรับการบริโภคบริการประหลาด ๆ แบบนี้ และมันสร้างงานให้ cloud architect กับผู้เชี่ยวชาญ
เพราะต้องทำให้พาร์ตเนอร์ยังเกี่ยวข้องอยู่ต่อไป จึงหล่อเลี้ยงการออกแบบที่แย่และการเชื่อมต่อแบบหลวม ๆ
จริง ๆ แล้วนี่ก็เป็นความเห็นของผมต่อ enterprise IT ทั้งหมดด้วย
ผมรับมรดกความยุ่งเหยิงของ Azure ในบริษัทเล็ก ๆ ที่มีนักพัฒนาราว 30 คน แล้วสร้าง abstraction ที่ใกล้เคียงมาตรฐานอุตสาหกรรมมากขึ้นสำหรับบริการที่จำเป็นไว้ในเครื่องมือพัฒนา จากนั้นไม่กี่ปีให้หลังก็ย้ายไป Hetzner
นักพัฒนาที่นี่แทบไม่รู้สึกถึงความแตกต่างเลย
เครื่องมือของเราจัดการ workflow และ abstraction ของบริการ และสิ่งเหล่านี้ไม่ควรเปลี่ยนไปเพียงเพราะเปลี่ยนผู้ให้บริการ
บิลรายเดือนเหลือ หนึ่งในสิบ และเราเอาเงินบางส่วนไปใช้สร้างประสบการณ์นักพัฒนาที่ดีที่สุดเท่าที่จินตนาการได้
ผมมองว่าเป็นการแลกเปลี่ยนที่คุ้มมาก
มีแค่สองกรณีเท่านั้นที่สมควรใช้คลาวด์รายใหญ่
คือขนาด MVP ที่เล็กมากจริง ๆ หรือสภาพแวดล้อมกระจายทั่วโลกขนาดมหึมาที่ต้องการ elasticity
เมื่อเทียบกับบริษัทส่วนใหญ่ ทั้งสองอย่างนี้แทบจะเป็นข้อยกเว้น
ผมคิดว่าผู้ใช้ Azure ทุกคนคงทำรายการ 100 เหตุผลที่ไม่ควรใช้ Azure ได้ และซอฟต์แวร์ใหญ่ ๆ ส่วนใหญ่ก็คงเช่นกัน
แม้ในฐานะคนที่สัมผัสคลาวด์อื่นไม่มาก ก็ยังเห็นได้ง่ายว่าประสบการณ์ผู้ใช้ของ Azure ไม่ได้รับการดูแลอย่างเหมาะสมและตามหลังอยู่
จำนวนหน้าที่ต้องกด “ดูเพิ่มเติม” ก่อนแถบตัวกรองจะทำงานถูกต้อง ตอนนี้ควรเป็น 0 อย่างชัดเจนแล้ว
นี่เป็นแพตเทิร์นที่แย่โดยวัตถุวิสัย อยู่มาหลายปี และ “ควรจะ” แก้ได้ง่าย แต่ก็คงไม่มีวันกลายเป็นเรื่องสำคัญ
สุดท้ายแล้ว ปัญหาแบบนี้จะไม่ถูกแก้ เว้นแต่การแก้ปัญหาเหล่านี้จะเป็นคุณค่าหลักขององค์กร หรือส่งผลกระทบต่อรายได้อย่างชัดเจน
สำหรับชุมชนผู้ใช้ ความเปิดเผยและการมองเห็นปัญหาแบบนี้สำคัญเสมอ
ผมใช้ทั้ง AWS และ Azure สิ่งหนึ่งที่ชอบมากจริง ๆ ใน Azure คือ พอร์ทัล
เหมือน AWS 2.0 ที่ความรกของคลาวด์ถูก abstract ออกไป เหลือแค่การตั้งค่าที่ต้องจัดการจริง ๆ และความสัมพันธ์ระหว่างกัน
ผมก็ชอบ AWS แต่ทุกครั้งที่เข้าไปในสภาพแวดล้อมที่ไม่คุ้นเคยแล้วต้อง reverse engineer การเชื่อมต่อทั้งหมด พอเสร็จแล้วต้องหาเหล้าดื่ม
ตอนลองใช้ Azure อยู่ไม่กี่วัน พอร์ทัลมันทรมานจริง ๆ
ทุกครั้งที่คลิกต้องรอ 5~10 วินาทีกว่าจะตอบสนอง และบางทีแค่เปลี่ยนการตั้งค่าพื้นฐานก็ต้องนั่งดู Ajax spinner นานกว่า 2 นาที
ทำงานแบบนี้แล้วสนุกได้อย่างไร?
เหมือนมีใครบางคนตั้งใจทำให้สับสนที่สุดเท่าที่จะทำได้ แต่เดาไม่ออกเลยว่าทำไปเพื่ออะไร
ไม่ได้หมายความว่าความเห็นใช้ไม่ได้หรือโกหก แต่ผมไม่เคยเห็นใครชอบ Azure Portal เลย แม้แต่คนที่ใช้ชีวิตอยู่ใน ecosystem ของ Azure ทุกชั่วโมงก็ตาม
ถ้าไม่ใช่ก็ขำดี
ผมอยู่คนละฝั่งอย่างสิ้นเชิง คงต้องถือว่าแล้วแต่รสนิยม
เคยใช้ทั้งสองค่อนข้างเยอะ และ dashboard ของ Azure ก็ยังน่ารำคาญอยู่ แต่ถ้าดูแค่ usability มันดีกว่า AWS มาก
แถม Microsoft เห็นได้ชัดว่าใช้เวลาและเงินกับเอกสาร ในขณะที่เอกสารของ AWS แย่มาตลอด
หากเป็นบริษัทเล็กและไม่ได้รันคอนเทนเนอร์ Cloudflare เป็นคลาวด์ที่ถูกประเมินต่ำไปมาก
ผมรู้ว่ามันถูกวิจารณ์ด้วยเหตุผลอื่น ๆ แต่ถ้าเบื่อ Big 3 หรือ 4 แล้ว ประสบการณ์นักพัฒนานั้นยอดเยี่ยมจริง ๆ
[1]: https://blog.cloudflare.com/container-platform-preview/
สำหรับไซต์ Svelte ผมชอบนะ แต่การถูกผูกไว้กับภาษาและข้อจำกัดแบบ request-response เป็นข้อจำกัดที่ใหญ่มาก
อย่างน้อยต้องมีคอนเทนเนอร์กับ persistent volume ก่อนถึงจะสนใจ
ผมเกลียด Azure อย่างแรงจริง ๆ
อยู่ในทีมที่สร้างเครื่องมืออัตโนมัติสำหรับการสร้างโปรเจกต์/บัญชี/การสมัครใช้งานของแต่ละผู้ให้บริการคลาวด์
ผู้ให้บริการหลักคือ GCP และการทำ implementation ก็ค่อนข้างง่าย
มีหลุมพรางเล็กน้อย แต่ก็ข้ามไปได้ไม่ยาก
ตอนนี้ต้องรองรับ Azure ในฐานะมัลติคลาวด์
เมื่อก่อนเคยอยู่บน AWS แต่ย้ายออกมาแล้ว 95% แม้จะยังมีบางทีมเหลืออยู่ แต่แทบไม่ได้สร้างเครื่องมืออะไรนอกจาก Terraform modules
แต่ Azure API, MS Graph API และ Go SDK ของทั้งสองอย่าง เป็นกองขยะที่ใหญ่ที่สุดเท่าที่เคยเจอมา
ทุกอย่างเป็น pointer แม้แต่ string literal ก็ต้องทำให้เป็น pointer แต่บางทีก็ไม่ต้องอีก
เอกสารไม่ถูกต้อง บาง API รับแค่ ID แต่ API อื่นรับ full path
บางส่วนมีเอกสารกำกับไว้ แต่ API จำนวนมากระบุรูปแบบผิด
ไม่มี API ไหนคืน ID ของ resource ที่เกี่ยวข้องมาให้เลย ต้องค้นหาทั้งหมด และมีการค้นหาตามชื่อเยอะเกินไป
ถึงขั้นต้องเพิ่มชั้นแคช ID เพื่อไม่ต้อง query resource เดิมซ้ำ ๆ ระหว่างการสร้าง
เราใช้ state machine ในการสร้างและสามารถ resume จากกลางทางได้ จึงต้องมีโค้ดที่อิงกับการตรวจสอบและการ resume จำนวนมาก
โดยรวมแล้วเป็นผู้ให้บริการคลาวด์ที่ออกแบบและ implement ได้แย่ที่สุด และถ้ามีทางเลือก ผมจะไม่แนะนำหรือเลือกใช้เด็ดขาด
สิ่งที่เขียนด้วย Go ภายในองค์กรมักจะยอดเยี่ยม
เราสร้างขึ้นมาใช้เองในบริษัท แต่ก็สนใจตัวเลือกจาก third-party เช่นกัน
อย่างไรก็ตาม เพราะกฎทางธุรกิจภายใน การสร้างเองอาจเหมาะกว่าการซื้อ