> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/basic/microservices/tips.md).

# Microservices Tips

จากบทความตอนที่แล้วเราก็จะเห็นคุณลักษณะของการทำ Microservices Architecture ไปแล้ว แต่ก็ยังมีอีกหลายอย่างที่ยังเป็นคำถามอยู่ ดังนั้นในรอบนี้เราจะมาตอบคำถามต่างๆ จากประสบการณ์ของมหาเทพ **Martin Fowler** และดูข้อแนะนำในการทำ architecture นี้เอาไว้ยังไงกันบ้าง

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของบทความ [👶 Microservices พื้นฐาน](https://saladpuk.gitbook.io/learn/basic/microservices) หากเพื่อนๆสนใจอยากรู้ประวัติความเป็นมาและข้อมูลเบื้องต้นของ Microservices architecture ก็สามารถกดเข้าไปอ่านจากลิงค์สีฟ้าๆได้เลยนะครับ
{% endhint %}

{% hint style="info" %}
**อ้างอิง**\
บทความนี้ถอดความรู้มาจากมหาเทพ [James Lewis](https://twitter.com/boicy) และ [Martin Fowler](https://martinfowler.com/) โดยสามารถเข้าไปดูบทความหลักได้จากลิงค์นี้เลยครับ [Microservices ](https://martinfowler.com/microservices/)
{% endhint %}

## 💡 ห้ามทำ Microservices ก่อน !!

หัวข้อแรกของการทำ Microservices Architecture คือ **ห้ามใช้ architecture นี้ในการเริ่มต้นโปรเจคเด็ดขาด** เพราะโปรเจคจะมีความซับซ้อนสูงมาก (สูงยังไงเพราะอะไรเดี๋ยวมีอธิบายต่ออยู่หัวข้อถัดไป) และถ้าเรายังทำแบบ monolith ไม่ดีพอแล้วกระโดดไปทำแบบ microservices มันจะยิ่งทำให้แย่ไปกว่าเดิมอีก เพราะความเข้าใจในขอบเขตของงานเรายังไม่ดีพอที่จะแบ่ง component ออกมาได้ถูก **Bounded Context** ยังไงล่ะ เลยทำให้ของที่เราคิดกับสิ่งที่เราจะได้ในตอนสุดท้ายออกมาเป็นคนละโลกกันเลย

![](/files/-LpwAReqaBa8bni_wA-v)

## 🔥 เมื่อไหร่ควรทำ Microservices ?

คำตอบคือขึ้นอยู่กับสถานะการณ์ แต่เขาแนะนำว่า **ถ้าตัวโปรเจคยังไม่ได้มีปัญหาเรื่องความซับซ้อนจงอย่าทำ microservice** เพราะถ้าการทำแบบ monolith ยังรับมือกับปัญหาได้ เพิ่มความสามารถใหม่ได้เรื่อยๆ ก็ใช้มันต่อไป เพราะ Microservices Architecture นั้นถูกออกแบบมาให้รับมือกับงานที่มีความซับซ้อนสูง โดยการแลกมากับความวุ่นวายในอีกมิตินั่นเอง จากด้านล่างจะแสดงให้เห็นว่าถ้าเอา Monolith (สีเขียว) กับ Microservice (สีน้ำเงิน) มาเทียบกัน

![](/files/-Lo6UmZV2RDYpphSPhIr)

จาดรูปด้านบนจะเห็นว่าใน**ระยะแรก**ความซับซ้อนไม่ได้เยอะเท่าไหร่ ความสามารถในการทำงานของ Microservice จะน้อยกว่า Monolith แต่ใน**ระยะยาว**ยิ่งความซับซ้อนสูงขึ้นเท่าไหร่ ความสามารถในการทำงานของ Microservice จะค่อนข้างคงที่ แต่ในขณะที่ Monolith แทบจะเรียกว่าขึ้นอืดงานไม่เดินเลยที

{% hint style="danger" %}
**ข้อแนะนำ**\
อย่าใช้ Microservices ถ้าเราไม่ได้เข้าใจขอบเขตทั้งหมดของงานจริงๆ เพราะเมื่อเราไม่รู้ว่า **Domain** ของเราคืออะไร แล้วเราไปทำการแตกตัวออกเป็น service ย่อยๆแล้วล่ะก็ การแก้ไขโยกย้ายของต่างๆจาก service ไปยังอีก service จะกลายเป็นปัญหาที่แก้ได้ยากมาก เพราะทุกอย่างของ service มันอยู่กับ **API contracts**
{% endhint %}

## 💡 จงทำ Monolith ก่อน

จากประสบการณ์มหาเทพเขาบอกว่า โปรเจคต่างๆที่เริ่มต้นจากการทำ 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 อันนี้จะอยู่รอด ตามรูปด้านล่างเลย

![](/files/-LoQd9ueVtOj3BG4ddFa)

เพราะการทำโปรเจคแบบ Monolith ไปก่อน มันจะทำให้เรามีความเข้าใจในตัวระบบที่มากขึ้น เริ่มแยกขอบเขตงานได้ชัดเจนขึ้นเรื่อยๆนั่นเอง จนกระทั่งวันที่เรารู้สึกว่าการเพิ่มความสามารถใหม่ๆมันเริ่มยากขึ้นเรื่อยหรือระบบเริ่มซับซ้อนขึ้นเรื่อยๆ เราก็ค่อยถอดชิ้นส่วนที่ต้องทำออกมาเป็น Microservice แค่บางชิ้นก่อน แล้วค่อยๆทยอยถอดชิ้นส่วนที่เหลือเป็น microservice อื่นๆตามมาทีหลังนั่นเอง

## 🔥 คนในทีมควรมีกี่คนดี ?

ในการทำ Microservice 1 เรื่องควรมีขนาดเท่าไหร่นั้นเป็นที่เถียงกันอยู่มาก แต่ก็มีแนวคิดจาก Amazon แนะนำว่า **ไม่ควรเกินพิซซ่า 2 ถาดใหญ่** หมายความว่า จำนวนคนในทีมควรจะใช้พิซซ่าแค่ 2 ถาดก็อิ่มทั้งทีมได้ ก็เหมือนจะติดตลกเพราะฝรั่งกินพิซซ่าได้เยอะกว่าคนไทยฮ่าๆ แต่หัวใจหลักของเขาจริงๆคือ จำนวนคนไม่ต้องเยอะมากแค่**คนต้องพอดีกับงาน**เหมือนกับการทำ **Agile** นั่นเอง

![](/files/-LnIIQQNn388v9YxSP4f)

## 🔥 มันคือ SOA ใช่ไหม ?

จะบอกว่าใช่ก็ได้ เพราะนิยามของ SOA มันกว้างม๊ววกกก ดังนั้นหลายคนจะมองว่า Microserives ก็คือส่วนหนึ่งของ SOA ก็ว่าได้

![](/files/-LvfUOMNqZUFvm-bQhyG)

## 🔥 ข้อดี vs ข้อเสีย คืออะไร ?

ของทุกอย่างย่อมมีข้อดีและข้อเสียตามกันมา ดังนั้นก่อนใช้งานให้ชั่งน้ำหนักให้ดีเสียก่อนว่าทีมเราควรจะเลือกเดินทางไหนนั่นเอง

| 👍 สิ่งที่ได้           | 👎 ต้องแลกมากับ         |
| ----------------------- | ----------------------- |
| แยกงานขาดจาดกันชัดเจน   | ของแต่ละอย่างกระจายกัน  |
| มีความคล่องตัวสูง       | Eventual Consistency    |
| ใช้เทคโนโลยีได้หลากหลาย | เพิ่มความซับซ้อนของระบบ |

## 🎯 บทสรุป

ในการใช้ของอะไรก็แล้วแต่มันย่อมมีช่วงเวลาที่เหมาะสมกับมัน ซึ่งต่อให้มันเป็นของที่ดีแค่ไหนก็ตามแต่ถ้ายังไม่ใช่ช่วงที่เหมาะสมมันก็อาจจะเป็นการ**ขี่รถถังจับตั๊กกระแตน**ก็ได้ ซึ่งหัวใจในการทำ Microservices Architecture ก็คือการแบ่งงานออกจากกัน ซึ่งจะต้องอาศัยความเข้าใจในขอบเขตงานให้ชัดเจนก่อนถึงจะใช้ architecture นี้ได้ดี ดังนั้นเราควรเริ่มต้นทำแบบ Monolith ก่อนแล้วค่อยๆทยอยถอดชิ้นส่วนมันให้กลายเป็น Microservices ถึงจะมีประสิทธิภาพที่สุด