Looking for the Ideal Technology (ตามหาเทคโนโลยีในอุดมคติ)

มี ตัวเลือกมากมายเหลือเชื่อว่าไมโครเซอร์วิสหนึ่งจะคุยกับอีกตัวได้อย่างไร แต่ตัวไหนล่ะที่ใช่—SOAP? XML-RPC? REST? gRPC? และตัวเลือกใหม่ๆ ก็ยังออกมาเรื่อยๆ ดังนั้นก่อนที่เราจะพูดถึงเทคโนโลยีเฉพาะเจาะจง มาคิดกันก่อนว่าเราต้องการอะไรจากเทคโนโลยีที่เราเลือก

Make Backward Compatibility Easy (ทำให้ backward compatibility เป็นเรื่องง่าย)

เมื่อ เราทำการเปลี่ยนแปลงไมโครเซอร์วิสของเรา เราต้องมั่นใจว่าเราไม่ทำลาย compatibility กับไมโครเซอร์วิสที่เรียกใช้เราอยู่ ดังนั้นเราจึงต้องการให้เทคโนโลยีที่เราเลือกทำให้การเปลี่ยนแปลงแบบ backward-compatible เป็นเรื่องง่าย การทำอะไรง่ายๆ อย่างการเพิ่มฟิลด์ใหม่ไม่ควรทำให้ client พัง เรายังอยากได้ความสามารถในการตรวจสอบว่าการเปลี่ยนแปลงที่เราทำนั้น backward-compatible จริงหรือไม่—และมีวิธีที่จะได้ feedback นั้นก่อนที่เราจะ deploy ไมโครเซอร์วิสของเราขึ้น production

Make Your Interface Explicit (ทำให้ interface ของคุณชัดเจน)

มัน สำคัญมากที่ interface ที่ไมโครเซอร์วิสเปิดเผยออกไปสู่โลกภายนอกจะต้องชัดเจน นั่นหมายความว่าผู้ที่เรียกใช้ไมโครเซอร์วิสจะเห็นชัดเจนว่า ไมโครเซอร์วิสนั้นเปิดฟังก์ชันอะไรบ้าง แต่มันก็ยังหมายความว่านักพัฒนาที่ทำงานกับไมโครเซอร์วิสนั้นจะเห็นชัดเจนเช่นกันว่าฟังก์ชันใดบ้าง ที่ต้องคงไว้สำหรับฝ่ายภายนอก—เราต้องการหลีกเลี่ยงสถานการณ์ที่การเปลี่ยนแปลงไมโครเซอร์วิสทำให้เกิดการพัง compatibility โดยไม่ตั้งใจ

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

Keep Your APIs Technology Agnostic (ทำให้ API ของคุณไม่ผูกติดกับเทคโนโลยีใดเทคโนโลยีหนึ่ง)

ถ้า คุณอยู่ในวงการ IT มานานเกิน 15 นาที คุณคงไม่ต้องให้ผมบอกว่าเราทำงานอยู่ในพื้นที่ที่เปลี่ยนแปลงอย่างรวดเร็ว สิ่งที่แน่นอนหนึ่งเดียว คือ การเปลี่ยนแปลง เครื่องมือ, framework และภาษาใหม่ๆ ออกมาตลอดเวลา นำแนวคิดใหม่ๆ ที่ช่วยให้เราทำงานได้เร็วขึ้นและมีประสิทธิภาพมากขึ้น ตอนนี้คุณอาจจะเป็นทีมที่ใช้ .NET แต่จะเป็นอย่างไรในอีกหนึ่งปีข้างหน้า หรืออีกห้าปีข้างหน้า? ถ้าคุณอยากทดลองใช้ technology stack ทางเลือกที่อาจทำให้คุณมีประสิทธิภาพมากขึ้นล่ะ?

ผมเป็นคนที่ชอบเปิดตัวเลือกไว้เสมอ ซึ่งเป็นเหตุผลว่าทำไมผมถึงชอบไมโครเซอร์วิสมาก มันยังเป็นเหตุผลที่ผมคิดว่าสำคัญมาก ที่จะทำให้ API ที่ใช้สื่อสารระหว่างไมโครเซอร์วิสไม่ผูกติดกับเทคโนโลยีใดเทคโนโลยีหนึ่ง นั่นหมายถึงการหลีกเลี่ยงเทคโนโลยี integration ที่กำหนด technology stack ที่เราสามารถใช้ implement ไมโครเซอร์วิสของเราได้

Make Your Service Simple for Consumers (ทำให้ service ของคุณใช้งานง่ายสำหรับผู้เรียกใช้)

เรา ต้องการทำให้ผู้เรียกใช้สามารถใช้ไมโครเซอร์วิสของเราได้ง่าย การมีไมโครเซอร์วิสที่ออกแบบมาอย่างสวยงามก็ไม่มีความหมายอะไรมาก ถ้าต้นทุนในการใช้งานมันในฐานะผู้เรียกใช้สูงลิ่ว! ดังนั้นมาคิดกันว่าอะไรที่ทำให้ผู้เรียกใช้สามารถใช้ service สุดเจ๋งตัวใหม่ของเราได้ง่าย โดยหลักการแล้ว เรา อยากให้ client ของเรามีอิสระเต็มที่ในการเลือกเทคโนโลยี แต่ในอีกด้านหนึ่ง การมี client library ก็ช่วยให้การนำไปใช้ง่ายขึ้น อย่างไรก็ตาม library แบบนี้มักจะขัดแย้งกับสิ่งอื่นที่เราต้องการบรรลุ ตัวอย่างเช่น เราอาจใช้ client library เพื่อให้ผู้เรียกใช้ใช้งานง่ายขึ้น แต่มันอาจแลกมาด้วยการมี coupling ที่เพิ่มขึ้น

Hide Internal Implementation Detail (ซ่อนรายละเอียดการ implement ภายใน)

เราไม่ต้องการให้ผู้เรียกใช้ของเราถูกผูกติดกับ implementation ภายในของเรา เพราะมันจะนำไปสู่ coupling ที่เพิ่มขึ้น ซึ่งในทางกลับกันหมายความว่าถ้าเราต้องการเปลี่ยนแปลงอะไรบางอย่างภายในไมโครเซอร์วิสของเรา เราอาจทำให้ผู้เรียกใช้ของเราพัง เพราะต้องบังคับให้พวกเขาต้องเปลี่ยนแปลงตามด้วย นั่นเพิ่มต้นทุนของการเปลี่ยนแปลง—ซึ่งเป็นสิ่งที่เราพยายามหลีกเลี่ยงพอดี มันยังหมายความว่าเรามีแนวโน้มที่จะไม่อยากทำการเปลี่ยนแปลงเพราะกลัวต้องอัปเกรดผู้เรียกใช้ของเรา ซึ่งอาจนำไปสู่ technical debt ที่เพิ่มขึ้นภายใน service ดังนั้นเทคโนโลยีใดๆ ที่ผลักดันให้เราเปิดเผยรายละเอียด internal representation ควรถูกหลีกเลี่ยง