จากบทความเรื่อง Why I'm No Longer Talking to Architects About Microservices
โดยผู้เขียนจะไม่พูดคำว่า Microservices สำหรับ Architecture ของ Software อีกแล้ว
เนื่องจากไม่ได้ทำให้เกิดคุณค่าใด ๆ ลย
เนื่องจาก 3 ปัจจัยหลักดังนี้
- ความหมายของ Microservices ที่แตกต่างกัน เหมือนตาบอกคลำช้าง ไม่มีใครผิดหรือถูก แต่มันไม่ไปในทิศทางเดียวกันเลย ทำให้คุยกันไม่รู้เรื่อง
- ไม่ได้สนใจ business goal กันเลย ว่าสิ่งที่ทำอยู่นั้นมันแก้ไขปัญหาทาง business อย่างไร
- นำมาใช้โดยไม่ปรับเปลี่ยนโครงสร้าง หรือ การทำงานององค์กรเลย จะพบว่าบริษัทเล็ก ๆ จะประสบความสำเร็จมากกว่า เนื่องจากเปลี่ยนแปลง หรือ ปรับเปลี่ยนได้ง่ายกว่า
มาดูรายละเอียดกันหน่อย
1. ความหมายหรือความเข้าใจเกี่ยวกับ Microservices
เป็นปัญหาอย่างแรก ที่ก่อให้เกิดปัญหาอื่น ๆ ตามมา
ซึ่งมาหลากหลายความหมายมาก ๆ ตามแต่ละคน หรือ ประสบการณ์ต่างกันไป
เหมือนตาบอดคลำช้าง
ยกตัวอย่างเช่น
- มีจำนวน line of code (LoC) น้อย ๆ
- two-pizza team
- ต้องการเพียง programmer 1 คนเท่านั้น ในการออกแบบ สร้าง และ ดูแล
- แต่ละ service ต้องทำงานเป็นอิสระ
- แต่ละ service ต้อง pack อยู่ในเพียง container หรือ pod เดียวเท่านั้น
- แต่ละ service ต้องมี data store หรือ database เป็นของตัวเอง
- เป็นอิสระในการ upgrade และ replace
ดังนั้นเพื่อความง่าย อย่าพูดเลยคำนี้ ถ้ายังให้ความหมายไม่ตรงกัน
แทนที่จะบอกชื่อของ architecture
ให้เปลี่ยนเป็นว่า สิ่งที่เรากำลังคุยกันนี้
มันแก้ไขปัญหาอะไร
มี trade-off อย่างไร
ยกตัวอย่างเช่น
- จะทำการ deploy feature ใหม่ ๆ ให้เร็วขึ้นอย่างไร
- จะลดการผูกมัดของระบบต่าง ๆ อย่างไร
- จะ scale ในส่วนต่าง ๆ อย่างไร
โดยปัญหาเรื่องของคำใหม่ หรือ Buzzword มีปัญหามาอย่างต่อเนื่อง
ไม่ว่าจะเป็น DevOps, Agile, SRE และ Observability
เช่น DevOps แทนที่จะเป็นการทำงานร่วมกันระหว่าง Development กับ Operation team
กลายเป็นว่าเกิดทีมใหม่ขึ้นมาคือ DevOps team ซะอย่างงั้น !!
ที่เป็น centralized team ของเครื่องมือการ deploy และ monitoring
2. สิ่งที่กำลังทำอยู่นั้น ไม่ได้มีความสัมพันธ์กับ Business goal เลย !!
เป็นปัญหาที่เกิดมาจากปัญหาข้อแรกนั่นเอง
เพราะว่าในการแก้ไขปัญหา ควรเริ่มต้นจากปัญหาก่อนเสมอ
ซึ่งปัญหาที่มักจะส่งผลกระมากสุด ๆ คือ business problem นั่นเอง
ดังนั้นถ้ามีการใช้งาน Microservices แล้วนั้น
ทำการแก้ไขปัญหาเชิง business อย่างไรบ้าง ? หรือไม่มีเลย ?
ยกตัวอย่างเช่น
ถ้าบอกว่าต้องการใช้งาน Microservices เพราะว่าต้องการ scale
คำถามคือ scale อะไร และ ตรงไหนที่เป็นคอขวดของระบบ
ถ้าบอกว่าต้องการใช้งาน Microservices เพราะว่าจะทำให้เรา agile ขึ้น
คำถามคือ ทำอย่างไร
เช่น การที่เราทำการ deploy ได้ช้า เป็นปัญหามาจาก Architecture ใช่ไหม ?
หรือเป็นปัญหาที่คน ?
หรือเป็นปัญหาที่ technology ?
หรือเพราะว่าข้อจำกัด process ของการทำงาน ?
เอาให้มันแน่
ถ้าบอกว่าต้องการใช้งาน Microservices เพราะว่าต้องการ deploy เป็นอิสระ
คำถามคือ เป็นความต้องการจริง ๆ ของทีม
หรือถ้าทำได้ก็ดี ถ้าไม่ได้ก็ไม่เป็นไร
ถ้าบอกว่าต้องการใช้งาน Microservices จะช่วยลดงานลงไป
คำถามคือ ลดงานของใคร
หรือเพียงย้ายไปให้คนอื่นทำแทนเท่านั้นเอง
ในการพูดคุยนั้น เราต้องการที่จะเปลี่ยนไปใช้ของใหม่
ทั้ง programming ใหม่ ๆ technology ใหม่ ๆ
มากกว่าการแก้ไข หรือ ปรับปรุงปัญหาของระบบเดิมกันหรือไม่
ถ้าบอกว่า ของเดิมอย่าไปแตะมัน ถ้ามันยังทำงานได้
แสดงว่า เราไม่ได้สนใจการปรับปรุงเลย
แต่อยากไปสร้างของใหม่ขึ้นมาแทนที่มากกว่า
บ่อยครั้งจะพบว่า มันคือการสร้างปัญหาเดิมขึ้นมาใหม่เท่านั้นเอง
ดังนั้นให้ focus ที่เป้าหมายก่อนเสมอ
3. อยากจะเปลี่ยน Architecture แต่ไม่ยอมเปลี่ยนแปลงตัวเองและองค์กร
ถึงแม้จะทำการเปลี่ยนแปลง architecture มาเป็น Microservices แล้ว
แต่ไม่ปรับตัวเอง ทีม หรือ องค์กร ให้สอดคล้อง
ก็จะไม่ได้ผลตามที่คาดหวัง
หรืออาจจะเปลี่ยนเพียงชื่อเท่านั้นเอง
ยกตัวอย่างเช่น
เราต้องทำการแบบ cross-functional team มีการทำงานแบบ end-to-end นะ
แต่จะไปจัดการข้อมูลกับ database
ต้องทำการเปิด request ไปขอให้ทีม DBA จัดการให้เสมอ
กลายเป็นปัญหาคอขวดอีก
แบบนี้คือ end-to-end และ cross-functional team จริง ๆ หรือ ?
คำตอบคือ กำลังหลอกตัวเองอยู่
ทำให้การตัดสินใจเป็นแบบ decentralized คือ ไม่มีศูนย์กลาง
เพราะว่าการทำงานร่วมกัน มันมี overhead ในการทำงานร่วมกัน
แต่เมื่อทำการ deploy ต้องมี approval process ที่เยอะแยะเต็มไปหมด
แบบนี้หรือคือ decentralized
และคำที่บอกว่า แต่ละ service จะเป็นอิสระต่อกัน ก็ลืมไปได้เลย
มันไม่เคยเกิดขึ้น
ถ้ายังไม่พร้อมต่อการเปลี่ยนแปลงแล้ว
Microservices พร้อมที่จะเป็นปัญหาขึ้นมาทันที
ดังนั้นเราไม่น่าจะเหมาะกับ Microservices แน่ ๆ !! ...
โดยรวมแล้ว เรื่องของ Architecture ที่เลือกมานั้น
มันช่วยเพิ่ม productivity ใช่หรือไม่
มันช่วยเพิ่มความน่าเชื่อของระบบหรือไม่
มันช่วยแก้ไขปัญหาทาง business หรือไม่
นั่นคือ หัวใจ หรือ เป้าหมาย ที่สำคัญ
สิ่งที่น่าสนใจคือ
เรามักจะเปลี่ยน Architecture ของระบบไปเรื่อย ๆ
แต่สิ่งที่ไม่ค่อยเปลี่ยนคือ คน ที่เลือก Architecture มาใช้นั้นเอง
ถ้าผลออกมาไม่ดี ก็แค่บอกว่า มันไม่ดี ไม่เหมาะกับเรา
จากนั้นก็ ...