คุณไม่ใช่ Google (You Are Not Google)
(blog.bradfieldcs.com)วิศวกรซอฟต์แวร์จำนวนมากไม่ได้มีเหตุผลนักในการเลือกเทคโนโลยี เมื่อจะเลือกเทคโนโลยีใหม่ หลายครั้งก็ตามกระแสเพียงเพราะเป็นเทคโนโลยีที่บริษัทบิ๊กเทคอย่าง Google หรือ Amazon ใช้ โดยไม่มีทั้งความจำเป็นจริงหรือการนิยามปัญหาให้ชัดเจน ตัวอย่างเช่น MapReduce และ Hadoop ถือกำเนิดขึ้นมาเพื่อการประมวลผลข้อมูลขนาดมหาศาล แต่บริษัทที่ไม่ได้มีข้อมูลในระดับนั้นกลับนำมาใช้ และสุดท้ายต้องแบกรับต้นทุน I/O ที่ไม่จำเป็นรวมถึงสูญเสียความสามารถบางอย่างไป นี่เป็นเพียงปรากฏการณ์แบบ "cargo cult" ทางเทคโนโลยีเท่านั้น
บทความเสนอเช็กลิสต์ชื่อ UNPHAT เพื่อหลีกเลี่ยงการเลียนแบบแบบไม่วิพากษ์วิจารณ์เช่นนี้:
Understand – ทำความเข้าใจปัญหาให้ถ่องแท้
eNumerate – ลิสต์ตัวเลือกที่เป็นไปได้ให้หลากหลาย
Paper – อ่านงานวิจัยหรือ white paper ที่เป็นรากฐานของเทคโนโลยีนั้น
Historical context – ดูบริบททางประวัติศาสตร์ที่เทคโนโลยีนี้ถูกพัฒนาขึ้น
Advantages – เปรียบเทียบข้อดีข้อเสียอย่างสมดุล
Think – คิดด้วยตัวเองว่าเทคโนโลยีนี้เหมาะกับปัญหาจริงหรือไม่
ในบทความยังยกตัวอย่างเทคโนโลยีอย่าง Cassandra, Kafka และ SOA(Service-Oriented Architecture) ที่ถูกนำไปใช้อย่างไม่วิพากษ์วิจารณ์ ทั้งที่ไม่สอดคล้องกับกรณีใช้งานจริง ยกตัวอย่างเช่น Kafka ถูกสร้างขึ้นมาเพื่อ LinkedIn ที่ต้องรองรับข้อความหลายล้านรายการต่อวินาที แต่กลับมีบริษัทขนาดเล็กที่มีธุรกรรมเพียงไม่กี่สิบรายการต่อวันเลือกใช้มัน
ผู้เขียนยังเน้นย้ำว่า แม้แต่ Google เองก็เลิกใช้ MapReduce เมื่อเห็นว่ามันไม่เหมาะสมอีกต่อไป สุดท้ายแล้ว สิ่งสำคัญไม่ใช่ตัวเทคโนโลยี แต่คือการเข้าใจอย่างแม่นยำว่าปัญหาที่คุณกำลังพยายามแก้นั้นคืออะไร แล้วจึงเลือกเทคโนโลยีที่เหมาะสมกับมัน
ท้ายที่สุด ผู้เขียนกล่าวถึงว่า Pólya, Hamming และ Rich Hickey ต่างก็เคยย้ำสารเดียวกันนี้มาแล้ว โดยแก่นสำคัญนั้นเรียบง่ายมาก:
“จงคิด และจงเข้าใจปัญหาที่แท้จริง”
15 ความคิดเห็น
ผมเข้ามาอ่านเพราะมันโผล่ขึ้นมาในคำแนะนำของ Google โดยบังเอิญ แต่บทความนี้เขียนจากมุมมองแบบ Geek มากเกินไป ซึ่งในมุมธุรกิจแล้วไม่ใช่เรื่องที่ถูกต้องเลย ทำไมถึงเป็นอย่างนั้น?
เครื่องมือขนาดใหญ่ที่ Big Tech ใช้ หาคนที่เชี่ยวชาญได้ง่าย
มีคนจำนวนมากที่ไปเรียนรู้เพื่อจะเข้าทำงานใน Big Tech และก็มีหลายคนที่เลือกศึกษาเพราะ Big Tech เป็นฝ่ายเลือกใช้มัน ดังนั้นจึงเป็นธรรมดาที่จะหาคนที่รู้เรื่องนี้ได้ง่าย และก็หาคนมีประสบการณ์หรือผู้เชี่ยวชาญได้ไม่ยาก แต่ถ้าเป็นเครื่องมือที่ไม่คุ้นตาเลยจะเป็นอย่างไร? ไม่ใช่ว่าจะไม่มีคนที่ศึกษามันอย่างจริงจัง แต่การหาคนแบบนี้น่าจะยากกว่าการหาผู้เชี่ยวชาญของเครื่องมือจาก Big Tech มาก
เครื่องมือขนาดใหญ่ที่ Big Tech ใช้ มีเอกสารอ้างอิงและข้อมูลมากมาย
เครื่องมือขนาดใหญ่ที่มีคนใช้จำนวนมาก จะมีข้อมูลสำหรับแก้ปัญหาและผลการค้นหาบน Google อยู่มากมาย ปัญหาส่วนใหญ่ก็มักเป็นสิ่งที่คนอื่นเคยเจอมาก่อน และสามารถค้นหาเพื่อทำความเข้าใจปัญหาได้ง่าย แต่ปัญหาของเครื่องมือที่ไม่คุ้นเคยนั้นหาเอกสารอ้างอิงได้ยาก และหากเกิดปัญหาขึ้นก็มีโอกาสสูงที่จะต้องใช้เวลามากในการระบุสาเหตุ ทั้งหมดนี้ล้วนเป็นต้นทุนทั้งนั้น ปัญหานี้เป็นปัญหาของเครื่องมือเล็กตัวใหม่ที่เพิ่งนำมาใช้จริงหรือ? หรือกำลังเข้าใจผิดว่าเป็นปัญหาจากอีกฝั่งหนึ่งกันแน่?
ในทางกลับกัน Big Tech ต่างหากที่เปลี่ยนไปใช้สิ่งเหล่านี้ได้ง่ายกว่า เพราะด้วยขนาดการประมวลผลข้อมูลมหาศาล เพียงแค่ได้ประโยชน์ด้าน I/O เพิ่มขึ้นเล็กน้อยก็อาจกลายเป็นผลประโยชน์มหาศาลสำหรับบริษัทได้ และก็ยังมีคนจำนวนมากที่ตั้งใจจะเรียนรู้เพียงเพราะ Big Tech เลือกใช้มันด้วย แต่สำหรับบริษัทขนาดกลางและเล็ก ด้วยขนาดข้อมูลที่เล็กกว่าเมื่อเทียบกันแล้ว ประโยชน์ด้าน I/O เล็กน้อยนั้นไม่ได้ให้ผลมากขนาดนั้น ทว่าปัญหาข้างต้นกลับร้ายแรงมาก คนที่อยากเรียนรู้โซลูชันที่บริษัทขนาดกลางและเล็กเลือกใช้ก็มีน้อยด้วย ดังนั้นถ้าเป็นผู้ประกอบการ SME หลายครั้งข้อสรุปที่ออกมากลับเป็นว่า แทนที่จะมาถกเถียงเรื่องพวกนี้แบบ Geek การทำตามเครื่องมือของ Big Tech กลับคุ้มค่ากว่าในเชิงเศรษฐกิจ
พอได้อ่านต้นฉบับแล้วก็พบว่าเป็นบทความที่เขียนไว้ตั้งแต่ปี 2017
หลังจากนั้นก็ผ่านไป 8 ปีแล้ว แต่ก็น่าทึ่งที่เนื้อหานี้ยังคงใช้ได้อยู่จนถึงตอนนี้
ผมเห็นด้วยกับเนื้อหาข้างต้นมากครับ!
แต่ในกรณีที่เกิด overengineering ในบริษัทขนาดเล็ก ผมก็มองว่าส่วนหนึ่งเป็นเพราะคนที่ตั้งเป้าไปบริษัทใหญ่ต้องการสะสมประสบการณ์กับเครื่องมือเหล่านั้นในบริษัทเล็กด้วย
แน่นอนว่าซีอีโอคงไม่ค่อยชอบเท่าไรหรอกครับ 555
เหตุผลสัก 80% ที่ทำให้แม้แต่บริษัทขนาดเล็กก็ยังใช้เครื่องมือที่ถูกออกแบบมาให้เหมาะกับความต้องการขององค์กรใหญ่แบบเดิม ๆ ก็น่าจะเป็นเรื่องนี้ไม่ใช่หรือครับ คนที่ควรควบคุมเรื่องนั้นคงเป็น CTO แต่บางครั้งแม้แต่ CTO เองก็อาจกำลังคิดจะย้ายงานไปบริษัทใหญ่อยู่ด้วย
ถ้างานที่ต้องทำมีไม่มาก ก็จะเผลอไปทำเรื่องไร้สาระกันได้อยู่แล้ว 555
แม้แต่ปัญหาง่าย ๆ ก็ยังต้องแก้ให้ยาก จะได้ทำท่าว่าตัวเองได้ทำอะไรสักอย่างด้วยก็ได้ ถ้าทำให้ง่าย คนจำนวนมากก็จะคิดว่ามันง่ายเองด้วย.. 5555
เพราะกลัวว่าถ้าทำของให้เล็กแล้วค่อยมาแก้ให้ใหญ่ทีหลังจะลำบาก จึงมีหลายกรณีที่เลือกทำให้ใหญ่ตั้งแต่แรก...
คิดว่าเป็นบทความที่ใช้ได้กับ K8s เหมือนกันครับ ทำให้นึกถึงหนังสือ "วิธีเขียนโค้ดให้บำรุงรักษายาก" เลยครับ 555
ท้ายที่สุดแล้ว เราต้องเข้าใจทั้งปัญหาที่เทคโนโลยีต่าง ๆ พยายามจะแก้ และบริบทที่ทำให้เทคโนโลยีนั้นถือกำเนิดขึ้นมา ตัวอย่างในบทความก็มีสิ่งต่อไปนี้
ผมคิดว่าเราควรพิจารณาให้ดีว่า ปัญหาที่สิ่งเหล่านั้นพยายามแก้อยู่ สอดคล้องกับปัญหาที่เราพยายามจะแก้อยู่หรือไม่
โอ้ เห็นด้วยมากครับ ทำให้นึกถึงตอนที่ผมมักจะแนะนำเหล่านักศึกษา/รุ่นจูเนียร์เวลาทำเมนทอริงให้ลองทำความเข้าใจประวัติศาสตร์ของเทคโนโลยีดู
ดูเหมือนว่ายังมีคนจำนวนไม่น้อยที่บางครั้งลืมไปว่าเทคโนโลยีเป็นเครื่องมือ ไม่ใช่เป้าหมาย
พอถึงจังหวะที่เหตุผลอย่าง "ผ่านการพิสูจน์มาแล้วใน Big Tech" หรือ "ช่วงนี้คนใช้กันเยอะ" กลายเป็นเงื่อนไขหลักในการเลือกเทคโนโลยี ต้นทุนที่เพิ่มขึ้นโดยไม่จำเป็นก็มักตามมาอย่างเป็นธรรมชาติ
ในเกาหลีมีวัฒนธรรมเลียนแบบ spring แบบไม่ลืมหูลืมตาค่อนข้างแรง
Spring หาคนได้ง่ายอยู่แล้ว...
สำหรับ spring ในเกาหลี มันไม่ถึงขั้นเป็นการเทิดทูนเสียมากกว่า..
แต่เป็นลูกผสมที่มีทั้งความไร้ความสามารถของรัฐบาลและความขี้เกียจของนักพัฒนาอย่างหนักหน่วง..
เห็นด้วยมากครับ/ค่ะ สุดท้ายแล้ว Spring ก็เป็นแค่เครื่องมือสำหรับแก้ปัญหาเท่านั้น
เบรนสตอร์มมิง ไมนด์แมป งานวิจัยดีปเลิร์นนิง เวลาเวิร์กช็อปลดลง จูไล มายดอลลิม มีผลในระยะยาว