Developer Experience (ประสบการณ์ของนักพัฒนา)

หนึ่ง ในความท้าทายสำคัญที่อาจเกิดขึ้นเมื่อนักพัฒนาพบว่าต้องทำงานกับ microservices มากขึ้นเรื่อยๆ คือประสบการณ์ของนักพัฒนาอาจเริ่มแย่ลง ด้วยเหตุผลง่ายๆ คือพวกเขากำลังพยายามรัน microservices มากขึ้นเรื่อยๆ ในเครื่อง สิ่งนี้มักเกิดขึ้นในสถานการณ์ที่นักพัฒนาต้องรันเทสต์ขอบเขตใหญ่ที่เชื่อมโยง microservices ที่ไม่ได้ stub หลายตัวเข้าด้วยกัน

สิ่งนี้จะกลายเป็นปัญหาเร็วแค่ไหนขึ้นอยู่กับปัจจัยหลายอย่าง จำนวน microservices ที่นักพัฒนาต้องรันในเครื่อง technology stack ที่ microservices เหล่านั้นเขียนขึ้น และพลังของเครื่องในเครื่องล้วนมีส่วนเกี่ยวข้อง technology stack บางตัวใช้ทรัพยากรมากกว่าในแง่ของ footprint เริ่มต้น microservices ที่ใช้ JVM เป็นตัวอย่างที่นึกถึงได้ ในทางกลับกัน tech stack บางตัวอาจส่งผลให้ microservices มี resource footprint ที่เร็วและเบากว่า ซึ่งอาจทำให้คุณสามารถรัน microservices ในเครื่องได้มากขึ้น

แนวทางหนึ่งในการจัดการกับความท้าทายนี้คือการให้นักพัฒนาทำงานพัฒนาและทดสอบใน cloud environment แทน แนวคิดคือคุณจะมีทรัพยากรที่พร้อมใช้งานมากขึ้นสำหรับการรัน microservices ที่คุณต้องการ นอกเหนือจากความจริงที่ว่าโมเดลนี้ต้องการให้คุณเชื่อมต่อกับทรัพยากร cloud ของคุณตลอดเวลา ปัญหาหลักอีกอย่างคือ feedback cycle ของคุณอาจแย่ลง ถ้าคุณต้องเปลี่ยนแปลงโค้ดในเครื่องและอัปโหลดโค้ดเวอร์ชันใหม่ (หรือ artifact ที่ build ในเครื่อง) ไปยัง cloud มันอาจเพิ่มความล่าช้าอย่างมากให้กับ cycle การพัฒนาและทดสอบของคุณ โดยเฉพาะอย่างยิ่งถ้าคุณทำงานอยู่ในส่วนของโลกที่การเชื่อมต่ออินเทอร์เน็ตถูกจำกัดมากกว่า

การพัฒนาแบบเต็มรูปแบบบน cloud เป็นความเป็นไปได้หนึ่งในการแก้ปัญหา feedback cycle cloud-based IDE อย่าง Cloud9 ซึ่งตอนนี้เป็นของ AWS แสดงให้เห็นว่าสิ่งนี้เป็นไปได้ อย่างไรก็ตาม ในขณะที่สิ่งแบบนี้อาจเป็นอนาคตของการพัฒนา แต่มันก็ไม่ใช่ปัจจุบันของพวกเราส่วนใหญ่อย่างแน่นอน

โดยพื้นฐานแล้ว ผมคิดว่าการใช้ cloud environment เพื่อให้นักพัฒนารัน microservices ได้มากขึ้นสำหรับ cycle การพัฒนาและทดสอบของพวกเขานั้นพลาดประเด็นไป ทำให้เกิดความซับซ้อนมากกว่าที่จำเป็น นอกเหนือจากต้นทุนที่สูงขึ้น โดยหลักการแล้ว คุณควรตั้งเป้าให้นักพัฒนาต้องรันแค่ microservices ที่พวกเขาทำงานอยู่จริงๆ เท่านั้น ถ้านักพัฒนาคนหนึ่งเป็นส่วนหนึ่งของทีมที่เป็นเจ้าของ microservices ห้าตัว นักพัฒนาคนนั้นก็ต้องสามารถรัน microservices เหล่านั้นได้อย่างมีประสิทธิภาพที่สุดเท่าที่จะทำได้ และสำหรับ feedback ที่รวดเร็ว ผมชอบให้พวกเขารันในเครื่องเสมอ

แต่จะเป็นอย่างไรถ้า microservices ห้าตัวที่ทีมของคุณเป็นเจ้าของต้องเรียกไปยังระบบและ microservices อื่นที่เป็นของทีมอื่น ถ้าไม่มีมัน local development และ test environment ก็คงทำงานไม่ได้ใช่ไหม ตรงนี้อีกครั้งที่ stubbing เข้ามาช่วยชีวิต ผมควรจะสามารถตั้ง local stub ที่เลียนแบบ microservices ที่อยู่นอกขอบเขตของทีมผมได้ microservices จริงเพียงตัวเดียวที่คุณควรรันในเครื่องคือตัวที่คุณกำลังทำงานอยู่เท่านั้น ถ้าคุณทำงานในองค์กรที่คาดหวังให้คุณทำงานกับ microservices ที่แตกต่างกันหลายร้อยตัว งั้นคุณก็มีปัญหาใหญ่กว่านั้นมากที่ต้องจัดการ นี่เป็นหัวข้อที่เราจะสำรวจอย่างละเอียดมากขึ้นใน “Strong Versus Collective Ownership”