แรงขับเคลื่อนของ Microservices
ประมาณสิบปีก่อน ผมกำลังนั่งคุยกับเจ้าของ startup แห่งหนึ่ง เค้าเล่าว่ามันยากมากเลยที่จะหา senior developer เก่ง ๆ ทุกวันนี้เค้าใช้เวลาทั้งวันไล่ดูใบสมัครและสัมภาษณ์คน
เค้าบอกว่า ขนาดกรองเลือกเอาเฉพาะใบสมัครที่บอกว่ามีประสบการณ์การเขียนโปรแกรม 5–7 ปีเท่านั้นมาสัมภาษณ์ แต่พอสัมภาษณ์จริง ปรากฏว่าพอให้คนเหล่านั้นลองออกแบบระบบหรือแก้โจทย์ ประสบการณ์หลายปีของคนเหล่านั้นกลับไม่สะท้อนออกมาเลย ราวกับว่า…
“เค้ามีประสบการณ์ปีเดียว วนซ้ำ 5 รอบ?” ผมเห็นเค้าเลือกคำอยู่นาน เลยลองเดาคำตอบเค้าดู
“เป๊ะเลย!” เจ้าของ startup ตอบกลับมา แล้วเราสองคนก็หัวเราะพร้อมกัน
ทำไม?
สิ่งที่น่าสนใจคือ ทำไม developer ในไทยที่มีประสบการณ์ 5 ปีถึงไม่เก่งเหมือน developer จากต่างชาติ ภาพที่ผมเห็นสิ่งที่เกิดขึ้นในวงการไอทีไทยในยุคนั้นคือ ระบบส่วนใหญ่ที่ถูกสร้างขึ้นมาจะมีอายุแค่ 2–3 ปี แล้วก็ถูก rewrite ใหม่ซ้ำแล้วซ้ำเล่า เพราะมันเละเทะจน maintain ไม่ไหว จะแก้อะไรซักอย่างก็ใช้เวลานานมาก จนปรับตัวตามธุรกิจไม่ทัน สุดท้ายทนไม่ไหวเราเลยต้องจำใจ rewrite มันใหม่ แต่แล้วภาพความทรมานแบบเดิมก็เกิดขึ้นซ้ำอีกเพราะเราไม่สามารถรักษาข้อมูลที่จำเป็นเพื่อ maintain ระบบไว้ได้
ถึงเราจะเก็บ source code ไว้ และ developer คนไหนก็อ่านโค้ดออก แต่ไม่มีใครกล้าแก้ เพราะไม่รู้ว่าที่โค้ดมันเป็นแบบนี้เพราะอะไร ตรงไหนที่ตั้งใจให้เป็นแบบนี้เพื่อตอบสนองความต้องการบางอย่างจาก user แล้วตรงไหนที่ไม่ได้ตั้งใจ สามารถแก้ไขได้
โชคดีที่ technology ใหม่ ๆ เปิดโอกาสให้เราสามารถ capture เจตนาเหล่านี้ไว้ได้ในรูปแบบของ automate test ทั้ง unit test และ acceptance test ทำให้เราสามารถสร้าง executable document ได้ ขยายความคือเอกสารที่สามารถ execute เพื่อดูผลได้ว่าตรงไหนเป็นจริงอยู่ (เขียว) และตรงไหนที่ไม่จริงแล้ว (แดง) ซึ่งเทคโนโลยีเหล่านี้ก็ขับเคลื่อน engineering practice ดี ๆ ให้ถูกใช้แพร่หลายขึ้น ทั้ง Test-Driven Development และ Acceptance Test-Driven Develpoment
practice เหล่านี้ช่วยยืดอายุของระบบต่าง ๆ ในอุตสหกรรมให้ยืนยาวขึ้น เดี๋ยวนี้เราเริ่มเห็นระบบอายุ 5–6 ปีที่ยังสุขภาพดี มาคน maintain ได้อยู่ เพราะมี test เหล่านี้คุมไว้ ทำให้แม้ว่าจะถูกผัดเปลี่ยนมือมากี่รุ่น น้องใหม่ ๆ ก็ยัง maintain มันต่อได้ เพราะความรู้ต่าง ๆ ที่เกิดขึ้นตอนมันถูกสร้างขึ้นมาถูกถนอมไว้ อย่างไรก็ดีระบบเหล่านี้ก็ยังไม่วายโดน rewrite อยู่ดีเมื่อถึงจุด ๆ นึง
จุดที่ technology ตาย
ถ้า technology ที่ระบบนั้นใช้มันตายไป ไม่ว่าจะเป็นเพราะหา Operating System เก่า ๆ ที่จะมา run มันไม่เจอแล้ว (ซึ่งสมัยนี้เราไม่ค่อยเจอปัญหานี้ เพราะ เรามี docker แล้ว บางคนก็ OS ตั้งแต่ยุคสร้างพีระมิดมาสต๊าฟใส่ docker ไว้เพื่อแก้ปัญหานี้ก็มี) หรืออีกปัญหาที่เจอบ่อยกว่าคือหาคนที่มีความรู้เรื่องเทคโนโลยีนี้ไม่เจอแล้ว หรือเจอก็แพงมากจนจ่ายไม่ไหว
ซึ่งจุดนี้เป็นจุดที่เจ็บปวดมาสำหรับธุรกิจ เพราะต้องมาเสียเงินสร้างระบบคู่ขนาน เพื่อมา replace ระบบเดิม เรียกว่าไม่ได้ประโยชน์ใด ๆ ในทางธุรกิจเลย การต้อง rewrite ทั้งระบบเป็น cost ที่แพงมาก ทั้ง cost ในการสร้าง การใช้ การ maintain แต่เราก็ต้องจำใจจ่ายเพื่อให้ได้ระบบหน้าตาเหมือนเดิม ธุรกิจจะได้เดินต่อไปได้
Microservices
ผมเชื่อว่านี่เป็นสาเหตุที่ทำให้ Microservices ได้รับความนิยมมากในวงการไอทีไทยวันนี้ เพราะการแบ่งเป็น service ย่อย ๆ เปิดโอกาสให้เรา rewrite ใหม่เป็นส่วน ๆ ได้ หรือที่เรียกว่า ทีละ microservice ตามภาษาวัยรุ่น
ตอนผมเรียน Microservice Architacture กับพี่รูฟ พี่รูฟเล่าคุณลักษณะ 5 ประการ ของ Microservices ไว้ดังนี้
- Small — เล็กพอจะ rewrite ได้ใน 1–2 sprints
- Isolated — สามารถพัฒนามันได้ตามลำพังโดยไม่ต้องไป start service อื่น ๆ ตอนพัฒนา
- Resilience — เวลา service อื่น ๆ ตาย มันต้องอยู่ต่อได้ตามลำพัง
- Own their data — มี persistence เป็นของตัวเอง
- Scale — สามารถเลือกที่จะ Scale ได้ตามลำพัง ไม่ต้องลามไปกระทบคนอื่น
จากตรงนี้จะเห็นว่า Small ที่หมายถึงสามารถ rewrite ทั้งระบบได้ภายใน 1–2 sprints นั่นแปลว่าถ้า Microservices ถูกสร้างตามคำนิยามนี้ ผมก็มีความหวังขึ้นมา
หวังจะได้เห็น entriprise application ที่มีอายุ เป็นสิบ ๆ ปี มีความรู้ตอนที่มันถูกสร้างถูกถนอมไว้อย่างดีในรูป executable document นอกจากนี้ยังใช้เทคโนโลยีใหม่ ๆ เปิดโอกาสให้น้อง ๆ จบใหม่ได้มีพื้นที่ฝึกฝน เรียนรู้เพื่อจะพัฒนาตัวเองไปเป็น senior developer ที่มีประสบการณ์ 5 ปีจริง ๆ แล้ว
