Platformteam
ทำไมบริษัทถึงสร้าง Platform team กัน (และมันสำคัญกับโปรแกรมเมอร์ยังไง)
. พอบริษัทมีจำนวนโปรแกรมเมอร์เพิ่มถึงจุดนึง มักเริ่มมีการสร้าง Platform team ขึ้นมา . เป้าหมายของ Platform team ส่วนใหญ่จะมีอยู่สองด้าน ด้านแรกคือ Efficiency ส่วนอีกด้านคือ Governance . เริ่มที่ Efficiency ก่อน ลองนึกภาพบริษัทที่มี Engineer ประมาณ 40 คน ถูกแบ่งย่อยออกเป็น 5 ทีม ทีมละ 8 คน . ทีมพวกนี้มักจะทำอะไรที่ซ้ำกันเยอะ ยกตัวอย่างเช่น
- Continuous Deployment (CD) pipeline
- Observability tooling (log aggregation, metrics, tracing)
- authentication & authorization
- UI components
- Library sharing server (e.g. npm, artifactory) ฯลฯ . การทำอะไรซ้ำๆกันนี่นอกจากจะเสียเวลาแล้ว ยังทำให้งานที่ต้องทำกันหลายทีมลำบากด้วย ถ้าสองทีมใช้ Tooling ที่ไม่เหมือนกัน เวลาคุยกันก็จะงงๆ แชร์โค้ดกันก็ยาก . หนักกว่านั้นคือใช้ Practice ที่ต่างกัน ทีมนึงอาจจะใช้ Continuous delivery ส่วนอีกทีมอาจจะ Release ขึ้น Production ทุก 2 สัปดาห์ . เวลาจะ Release feature ที่ทำงานร่วมกัน ทีมแรกอาจจะต้องเอาฟีเจอร์ไปซ่อนไว้ก่อน (Feature flag) เพราะพออีกทีมเอาขึ้น Production เสร็จ ค่อยไป Toggle feature flag เพื่อเปิดใช้งาน เพิ่มงานโดยไม่จำเป็น ลด Efficiency . หรืออีกอันนึงที่เจอบ่อย คือเก็บ Log คนละ Format คนละที่ และไม่มี Universal Trace ID . เวลาดีบั๊กข้ามเซอร์วิซนี่ปวดหัวมาก ต้องมานั่งเทียบด้วยเวลากันว่า Request จากเซอร์วิซนึง กลายเป็น Request ID ไหนของอีกเซอร์วิซนึง .
.
ถึงจุดนี้ บางคนอาจจะเสนอว่า ก็ให้อีกทีมปรับให้เป็นแบบเดียวกับอีกทีมสิ กำหนดวิธีกลาง สั่งให้ใช้ Best Practices เดียวกันหมด
.
ในทางทฤษฏีก็ได้ แต่ในทางปฏิบัติ Product Owner (PO) ของทีมนึงจะต้องไม่พอใจมาก เพราะจะต้องเสียเวลาผลิตฟีเจอร์ใหม่ๆไปอีกพักใหญ่ ซึ่งฝั่ง Business เองก็อาจจะไม่ยอม
.
Platform team อาจจะเกิดขึ้นมาเพื่อแก้ปัญหานี้ โดยรับเอาส่วนที่ซ้ำๆกันของทุกทีมไปทำเป็น internal product ให้คนอื่นใช้
.
เวลาทีมอื่นต้องการจะขึ้น service ใหม่ ก็จะมาให้ Platform team ทำพวก CD pipeline ให้ หรือยืมใช้ ElasticSearch ของส่วนกลาง เพื่อเอาไปเก็บ Log ของทีมตัวเองด้วย
.
วิธีนี้ช่วยจะช่วยเพิ่ม Efficiency ให้กับทั้งบริษัท โดยไม่มีแรงต่อต้านมาก
.
.
เรื่องที่สองที่บริษัทใหญ่ๆมักจะแคร์กัน คือเรื่องของ Governance
.
คำนี้กว้างมาก ผมขอยกตัวอย่างให้เห็นภาพ สมมติว่าคุณเป็น CTO ของบริษัทพาวเวอร์เรนเจอร์จำกัด มีทีมอยู่ 5 ทีม ทุกทีมใช้เทคโนโลยีต่างกันหมดเลย
.
ทีมแรกเร็วเฟี้ยวด้วย C++
ทีมที่สองเขียนโค้ดสวยงามด้วย Ruby on Rail
ทีมที่สามเน้นความเสถียรด้วยเทคโนโลยีที่ได้รับการพิสูจน์มาหลายทศวรรษอย่าง Java + Spring
ทีมที่สี่ใช้ .NET ด้วยศรัทธาในสตีฟ (บาล์มเมอร์) อย่างแรงกล้า และ Development Environment ที่ครบครัน
ส่วนทีมที่ห้าใช้ PHP เพราะเป็นเทคโนโลยีที่ปลอดภัยมาก เห็นได้จากจำนวน Security patch ที่ถี่สุดๆ
.
(ขอแซวนิดนึง อดไม่ได้ 😃 ทีม Python, NodeJS, GoLang Scala อย่างน้อยใจไปนะครับ)
.
นี่แค่ภาษานะครับ ถ้าแถมให้เต็มที่จะมีเรื่องอื่นๆให้เลือกอีกเยอะมาก
- Container vs Server
- Web server
- Database
- Cloud provider
- Monitoring tools
.
ปัญหานี้เรียกว่า Fragmentation ซึ่งมักจะเกิดในบริษัทสตาร์ทอัพที่มีวัฒนธรรม Decentralized หนักๆ คือใครใคร่ใช้อะไร ใช้ได้เลย เราเน้นเร็วและคล่องตัว
.
ผลที่ตามมาคือคนใช้ Service ใหม่เป็นหนูทดลองวิชา ปัญหาที่ตามมาคือไม่มีใครในบริษัทที่สามารถอ่านโค้ดเข้าใจกันได้หมด
.
ลองนึกภาพว่าถ้าระบบพวกนี้เชื่อมกันหมด แล้วมี Operation issue ที่ร้ายแรงขึ้นมาตอนตีหนึ่ง จะงมหาต้นตอที อันนี้คือยากมาก ต้องเอาคนมารวมกันให้ครบทั้งห้าทีม ถึงจะหาต้นตอนและแก้ได้
.
การจะให้คนจากทีมนึงมาทำงานในอีกเซอร์วิซนึงก็ยาก เพราะต้องเรียนรู้ทั้งภาษาและ Framework เพิ่มเยอะ
.
การแก้ปัญหาเรื่อง Fragmentation ที่เกิดขึ้นไปแล้วค่อนข้างยาก เพราะเป็นเรื่องคนมากกว่าเรื่องเทคโนโลยี
.
ลองไปบอกให้คนเขียน .NET เปลี่ยนไปใช้ Java สิ โดนค้อนตาแตกแน่ๆ
.
แต่ถ้าปล่อยไว้นานๆ คุณก็จะได้บริษัทพาวเวอร์เรนเจอร์ห้าสีแบบข้างบน จะทำอะไรใหญ่ๆทีนี่ต้องรวมร่างเป็นหุ่นยนต์ยักษ์ก่อน ไม่งั้นสู้สัตว์ประหลาดไม่ได้
.
นี่เลยเป็นเรื่องที่น่าหนักใจสำหรับพวก Leadership team บนๆ
.
แทนที่จะไปบีบคอ Developer หนึ่งในสิ่งที่หลายบริษัทเลือกทำ คือให้เทคโนโลยีบางอย่างใช้งานได้ง่ายขึ้นในบริษัท
.
โดยสร้างสิ่งที่เรียกว่า “Golden Path” ขึ้น (เครดิต: คำนี้มาจาก Spotify)
.
Golden path จะถูกกำหนดโดย Platform team โดย Golden path คือเทคโนโลยีและ Best Practices ของบริษัทที่แนะนำให้ทุกทีมใช้ หากยอมใช้ จะได้รับการสนับสนุนโดย Platform team ให้ทำงานได้สบายและน้อยลง
.
ตัวอย่างเช่น Platform team กำหนดให้ทีมส่วนใหญ่ใช้ Python + Flask ในการสร้าง API ด้วย Container บน Cloud
. ส่วน Database ให้ใช้ MySQL เป็นหลัก และทำ Frontend ด้วย React + Next.js . ถ้าทีมยอมใช้ Golden path นี้ ทาง Platform team จะมี Template ให้คุณลง CD pipeline ให้ได้ง่ายๆ (หรือลงให้แล้วดูแลเซอร์เวอร์ให้เองด้วย)
. พอ Push code ปุ๊บ รันเทสต์ให้เสร็จสรรพ . พอ Merge สำเร็จ มี Infrastructure as a code ไว้ลง development + acceptance environment ให้อัตโนมัติ ถ้า End-to-end tests รันผ่านหมด เตรียมตัวขึ้น Production ได้เลย . แต่แค่นี้ยังไม่พอ เราแถม Library ไว้ทำ Logging ส่งไปให้ ElasticSearch + Kibana ที่เรา Provision และดูแลให้ เช่นเดียวกันกับ Metrics และ Tracing
. แต่ยังครับ ยังไม่หมดเท่านี้ ถ้าคุณยอมย้ายมาภายใน 6 เดือน เราจะแถมทีม SRE (Site Reliability Engineer) มานั่งช่วยคุณ Oncall . ถ้าติดปัญหาแล้วพบว่าเป็นที่โค้ดจริงๆ ถึงจะโทรหาคุณ .
สรุปคือแทนที่จะบังคับทีม ผู้บริหารจะใช้บริการของ Platform จูงใจให้ทีมใช้เทคโนโลยีเดียวกันหมด เพราะชีวิตจะง่ายกว่าเยอะ . ถ้า Leadership team สร้างทีมได้ในเวลาที่เหมาะสม ไม่เร็วหรือช้าเกินไป ก็จะช่วยหลบหรือลดปัญหาของ Fragmentation ได้ . ตัวอย่างนี้เป็นแค่รูปแบบหนึ่งที่เป็นไปได้ เพราะเรื่องของ Governance นี่เป็นอะไรที่ตึงไปก็ไม่ดี หย่อนไปก็ไม่ได้ . เช่น ถ้ามีทีม Data engineering อาจจะต้องยอมใช้ Scala ในบางทีมแทน หรือบางทีมก็จำเป็นที่จะต้องใช้ C++ เพื่อ Optimize performance สำหรับเซอร์วิซที่จำเป็น
.
.
จบแล้วครับ ถ้าชอบอยากให้คุยเรื่องนี้ลึกลงไปอีก ลองทิ้งคำถามหรือหัวข้อไว้ในคอมเม้นต์นะครับ
.
ถ้าบริษัทยังมีโปรแกรมเมอร์ไม่ถึง 30 คน อาจจะยังไม่ได้ประโยชน์จาก Platform ทีมมาก เพราะการใช้ซ้ำยังเกิดขึ้นน้อย (Low efficiency)
.
แต่ Leadership team ต้องมองเกมให้ขาดและตัดสินใจให้ดีว่าเวลาไหนถึงควรสร้างทีมนี้ เพราะถ้าช้าเกินไป แต่ละทีมเลือกเทคโนโลยีและฝังรากลึกจนเปลี่ยนแปลงยาก (Fragmentation)
.
ในฐานะโปรแกรมเมอร์หรือ Software Engineer ผมอยากให้ลองสังเกตเรื่องนี้ดู ว่าการสร้าง Platform team เหมาะกับองค์กรของเราหรือเปล่า คุ้มแค่ไหน ถึงเวลาแล้วหรือยัง
.
ถ้าถึงแล้วยังไม่มีใครขยับ อาจจะเป็นเพราะว่า Leadership team ไม่ได้เห็นภาพหน้างานเหมือนเรา ลองสะกิดๆดูหน่อย ถ้าทุกอย่างไปได้ด้วยดี ทีมเราเองก็ทำงานง่าย มีความสุขขึ้นครับ
บทความนี้ได้รับการสนับสนุนจาก TechTalkThai.com โดยเนื้อหาไม่ได้มีการปรับแต่งจากต้นฉบับเพื่อให้เป็นประโยชน์ต่อสปอนเซอร์ . ดังนั้น ต้องโฆษณาให้เค้าหน่อย... . ใครที่สนใจติดตามข่าวสารด้ายผลิตภัณฑ์ระดับองค์กร (Enterprise-grade Products) ระบบเครือข่าย, ระบบรักษาความปลอดภัย และระบบคลาวด์ ติดตามได้ที่เฟสบุ้ค https://www.facebook.com/techtalkthai/ . . ส่วนใครที่ชอบบทความสำหรับโปรแกรมเมอร์แนวนี้ ติดตามเพจนี้ได้ที่ https://www.facebook.com/notaboutcode ครับ .