| description |
|---|
🤔 ถ้าอยากจะทำ Microservices Architecture มีข้อแนะนำอะไรบ้างนะ ? |
จากบทความตอนที่แล้วเราก็จะเห็นคุณลักษณะของการทำ Microservices Architecture ไปแล้ว แต่ก็ยังมีอีกหลายอย่างที่ยังเป็นคำถามอยู่ ดังนั้นในรอบนี้เราจะมาตอบคำถามต่างๆ จากประสบการณ์ของมหาเทพ Martin Fowler และดูข้อแนะนำในการทำ architecture นี้เอาไว้ยังไงกันบ้าง
{% hint style="success" %}
แนะนำให้อ่าน
บทความนี้เป็นส่วนหนึ่งของบทความ 👶 Microservices พื้นฐาน หากเพื่อนๆสนใจอยากรู้ประวัติความเป็นมาและข้อมูลเบื้องต้นของ Microservices architecture ก็สามารถกดเข้าไปอ่านจากลิงค์สีฟ้าๆได้เลยนะครับ
{% endhint %}
{% hint style="info" %}
อ้างอิง
บทความนี้ถอดความรู้มาจากมหาเทพ James Lewis และ Martin Fowler โดยสามารถเข้าไปดูบทความหลักได้จากลิงค์นี้เลยครับ Microservices
{% endhint %}
หัวข้อแรกของการทำ Microservices Architecture คือ ห้ามใช้ architecture นี้ในการเริ่มต้นโปรเจคเด็ดขาด เพราะโปรเจคจะมีความซับซ้อนสูงมาก (สูงยังไงเพราะอะไรเดี๋ยวมีอธิบายต่ออยู่หัวข้อถัดไป) และถ้าเรายังทำแบบ monolith ไม่ดีพอแล้วกระโดดไปทำแบบ microservices มันจะยิ่งทำให้แย่ไปกว่าเดิมอีก เพราะความเข้าใจในขอบเขตของงานเรายังไม่ดีพอที่จะแบ่ง component ออกมาได้ถูก Bounded Context ยังไงล่ะ เลยทำให้ของที่เราคิดกับสิ่งที่เราจะได้ในตอนสุดท้ายออกมาเป็นคนละโลกกันเลย
คำตอบคือขึ้นอยู่กับสถานะการณ์ แต่เขาแนะนำว่า ถ้าตัวโปรเจคยังไม่ได้มีปัญหาเรื่องความซับซ้อนจงอย่าทำ microservice เพราะถ้าการทำแบบ monolith ยังรับมือกับปัญหาได้ เพิ่มความสามารถใหม่ได้เรื่อยๆ ก็ใช้มันต่อไป เพราะ Microservices Architecture นั้นถูกออกแบบมาให้รับมือกับงานที่มีความซับซ้อนสูง โดยการแลกมากับความวุ่นวายในอีกมิตินั่นเอง จากด้านล่างจะแสดงให้เห็นว่าถ้าเอา Monolith (สีเขียว) กับ Microservice (สีน้ำเงิน) มาเทียบกัน
จาดรูปด้านบนจะเห็นว่าในระยะแรกความซับซ้อนไม่ได้เยอะเท่าไหร่ ความสามารถในการทำงานของ Microservice จะน้อยกว่า Monolith แต่ในระยะยาวยิ่งความซับซ้อนสูงขึ้นเท่าไหร่ ความสามารถในการทำงานของ Microservice จะค่อนข้างคงที่ แต่ในขณะที่ Monolith แทบจะเรียกว่าขึ้นอืดงานไม่เดินเลยที
{% hint style="danger" %}
ข้อแนะนำ
อย่าใช้ Microservices ถ้าเราไม่ได้เข้าใจขอบเขตทั้งหมดของงานจริงๆ เพราะเมื่อเราไม่รู้ว่า Domain ของเราคืออะไร แล้วเราไปทำการแตกตัวออกเป็น service ย่อยๆแล้วล่ะก็ การแก้ไขโยกย้ายของต่างๆจาก service ไปยังอีก service จะกลายเป็นปัญหาที่แก้ได้ยากมาก เพราะทุกอย่างของ service มันอยู่กับ API contracts
{% endhint %}
จากประสบการณ์มหาเทพเขาบอกว่า โปรเจคต่างๆที่เริ่มต้นจากการทำ Microservice ส่วนใหญ่จะเจอกับอุปสรรคจนพังไม่เป็นท่า เพราะความรู้ความเข้าใจของตัวงานเรายังไม่ดีพอตั้งแต่ช่วงแรกหรอก จากกราฟของหัวข้อก่อนหน้าจะเห็นว่าในช่วงแรกของโปรเจคเราไม่ควรที่จะเริ่มต้นด้วย Microservices architecture นั่นเอง และต่อให้เข้าใจมัน 100% เราก็ไม่ควรทำให้ระบบซับซ้อนโดยไม่จำเป็น
You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.
ดังนั้นเขาเลยแนะนำว่า ให้เริ่มต้นจาก Monolith ก่อนจนกว่ามันจะรับไม่ไหวแล้วค่อยถอดชิ้นส่วนมาทำ Microservice อันนี้จะอยู่รอด ตามรูปด้านล่างเลย
เพราะการทำโปรเจคแบบ Monolith ไปก่อน มันจะทำให้เรามีความเข้าใจในตัวระบบที่มากขึ้น เริ่มแยกขอบเขตงานได้ชัดเจนขึ้นเรื่อยๆนั่นเอง จนกระทั่งวันที่เรารู้สึกว่าการเพิ่มความสามารถใหม่ๆมันเริ่มยากขึ้นเรื่อยหรือระบบเริ่มซับซ้อนขึ้นเรื่อยๆ เราก็ค่อยถอดชิ้นส่วนที่ต้องทำออกมาเป็น Microservice แค่บางชิ้นก่อน แล้วค่อยๆทยอยถอดชิ้นส่วนที่เหลือเป็น microservice อื่นๆตามมาทีหลังนั่นเอง
ในการทำ Microservice 1 เรื่องควรมีขนาดเท่าไหร่นั้นเป็นที่เถียงกันอยู่มาก แต่ก็มีแนวคิดจาก Amazon แนะนำว่า ไม่ควรเกินพิซซ่า 2 ถาดใหญ่ หมายความว่า จำนวนคนในทีมควรจะใช้พิซซ่าแค่ 2 ถาดก็อิ่มทั้งทีมได้ ก็เหมือนจะติดตลกเพราะฝรั่งกินพิซซ่าได้เยอะกว่าคนไทยฮ่าๆ แต่หัวใจหลักของเขาจริงๆคือ จำนวนคนไม่ต้องเยอะมากแค่คนต้องพอดีกับงานเหมือนกับการทำ Agile นั่นเอง
จะบอกว่าใช่ก็ได้ เพราะนิยามของ SOA มันกว้างม๊ววกกก ดังนั้นหลายคนจะมองว่า Microserives ก็คือส่วนหนึ่งของ SOA ก็ว่าได้
ของทุกอย่างย่อมมีข้อดีและข้อเสียตามกันมา ดังนั้นก่อนใช้งานให้ชั่งน้ำหนักให้ดีเสียก่อนว่าทีมเราควรจะเลือกเดินทางไหนนั่นเอง
| 👍 สิ่งที่ได้ | 👎 ต้องแลกมากับ |
|---|---|
| แยกงานขาดจาดกันชัดเจน | ของแต่ละอย่างกระจายกัน |
| มีความคล่องตัวสูง | Eventual Consistency |
| ใช้เทคโนโลยีได้หลากหลาย | เพิ่มความซับซ้อนของระบบ |
ในการใช้ของอะไรก็แล้วแต่มันย่อมมีช่วงเวลาที่เหมาะสมกับมัน ซึ่งต่อให้มันเป็นของที่ดีแค่ไหนก็ตามแต่ถ้ายังไม่ใช่ช่วงที่เหมาะสมมันก็อาจจะเป็นการขี่รถถังจับตั๊กกระแตนก็ได้ ซึ่งหัวใจในการทำ Microservices Architecture ก็คือการแบ่งงานออกจากกัน ซึ่งจะต้องอาศัยความเข้าใจในขอบเขตงานให้ชัดเจนก่อนถึงจะใช้ architecture นี้ได้ดี ดังนั้นเราควรเริ่มต้นทำแบบ Monolith ก่อนแล้วค่อยๆทยอยถอดชิ้นส่วนมันให้กลายเป็น Microservices ถึงจะมีประสิทธิภาพที่สุด