สรุป Dev Club Meetup #1: Microservices @ Finema

สำหรับวันนี้ลองมางาน On-Site ในวันธรรมดาดูครับ แม้ว่าจะมีอุปสรรคบ้างทั้งจากเคสด่วน / เท Merge Code ก่อน เดวมาทำวันเสาร์ และ การเดินทาง

การเดินทาง

• ออกจาก บ ตอน 17.15 รอรถกะป้อ แบบว่ารอจนท้อ จนมีเจอรถเมล์ 57 ตอน 17.45 และได้นั่งจากลาดหญ้า มาลงที่ MRT อิสรภาพตอน 17.55
• MRT อิสรภาพ > MRT ศูนย์การประชุมแห่งชาติสิริกิติ์ ประมาณ 25 นาที และเดินมาตอนแรกคิดว่าใกล้ๆ แอบไกลเหมือนกันเดินประมาณ 15-20 นาทีตาม Google Map มา ซอยมีแต่ร้านอาหาร (ในใจคิดว่า Google Map มันจะเล่นกูป่าวหว่า 555)
• แต่พอลองเดินไปซอยหน้า มันก็ไม่น่าใช่นะ เลยเชื่อตาม Map ดู และมาเจอที่จัดงาน

Common Mistake in Microservices (Apaichon Punopas)

- Why we use Microservice

• Microservice ถูก Drive มาจาก business เพราะต้องการความรวดเร็ว แต่พอใช้ไปแล้ว ปรากฏว่า cost เพิ่ม deliver ช้าลง
• เดิม Monolith for Enterprise App - รวมที่อย่างเป็น 1 เดียว
  • Single point of failure - ถ้ามันพังสักจุด มันเสียคุณสมบัติเองไป หรือทำงานไม่ได้เลย
  • More Dependency - แต่ละ Component พันกันไปหมด
  • Awkward -ใหญ่ เทอะทะ และ
  • Difficult to reuse - เอาไปใช้งานต่อยาก มี Project ใหม่ก็ต้องเขียนใหม่
• อนาคตระบบของเราโตขึ้น ตัว Application Scalable ได้ โดยมี 3 จุดที่ scale ได้
  • Hardware - เพิ่มได้ แต่มีจำกัด spec limit ว่าแต่ละเครื่องรับ Load ได้เท่าไหร่
  • Software - แม้ว่าจะ Scale HW ได้ ตัวระบบต้องพร้อมด้วยกับจำนวน HW ที่เพิ่มมา
  • People - เพิ่มคน หรือปรับ skill front / back / infra / data

• ใหม่ Microservice แต่ละตัว ควรทำงานได้ด้วยตัวมันเอง พยายามให้มี dependency น้อยที่สุด และพัฒนาได้ดีขึ้น เพราะซับซ้อนน้อยลง เพื่อให้มีคุณสมบัติ
  • Faster & Flexibility - มีความคล่อง ทำ Feature ได้ไวขึ้น เพราะ dependency น้อย
  • Reuse
  • Diversification - การกระจายความเสี่ยง ถ้ามีบาง Microservice พังไปตัวอื่นยังทำงานได้

- Common mistake

• เรื่องเดียวกัน ทุกคนเข้าใจเหมือนกันไหม ? คุยกันแล้ว อาจจะต้องมาถามทวนกัน เน้นให้ เกิด two-way communication จะได้ไม่ไปคนละทาง ถ้าพบจูนเทรนปรับจูนระบบให้เข้ากัน โดยมี 3 Check List มาช่วยตรวจว่า เรายังไม่ไปผิดทางนะ

1. Not Prepare for microservice - ปกติ no plan เอาคนมาก่อน ไม่ได้วาง Tech Roadmap Convention เช่น log เรายังไม่รู้ว่าต้องทำอะไร ทำไปแล้วทุกระบบมี REST API คุยกันเท่านั้น
   สิ่งที่ควรคุยกันก่อน เพื่อไม่ให้มีปัญหา
   • โครงสร้างองค์กร
   • Logging & Monitoring
   • Authentication & Authorization - ทุกระบบมีหมด จะรวมกันยังไง ?
   • Technical Skill
   • Working Standard - เช่น Repo เก็บ Code / เอกสาร
   • Technical Standard - Coding Standard เช่น ชื่อตัวแปร / API
   • Testing Standard
   • Deployment Standard - ทำด้วยมือ / Container หรือ Automate จาก Jenkins
   • Version Control
   • Backup and recovery
2. ทำไปแล้ว Increase Dependency - พันกันไปหมด
3. Slow than the past - หลักๆ ไม่อยากแก้ของคนอื่น 55 เขียนใหม่ อันนี้จริงนะ ที่ บ ตัวเอง คนชอบ Copy Code มาเยอะมาก และบอกว่าไม่อยากทำของคนอื่นพัง แต่พอต้นทางมันแก้ Code ตรงนี้มันไม่ได้แก้ด้วยสิ

- Sample microservice architecture

• ที่แบ่ง เพราะ Design ให้รับ User มาเยอะๆได้ รวมถึงทีมงานที่เข้ามาเยอะๆ ต้องมีภาพรวมให้เห็นภาพด้วย

1. Layer Business - เอามากรอบบน เพื่อบอกว่าแต่ละอันอยู่ในส่วนงานไหน
2. Layer Tech แบ่งโดย ใช้แนวคิด DDD ร่วมกันทางทีม Business เพื่อมาแบ่ง Microservice
   • Front End
   • API Gateway - ไม่ให้ Service คุยกันเอง จะได้คุม Dependency ได้ระดับนึง
   • Back End
     • อะไรที่ common ให้แยกออกมา auth / log / master data
     • API เน้น core biz
   • Database + Report

- The way to manage

• API Broken - field change / remove ที่พังๆ มาจากอะไร
  • หา API Stakeholder ไม่ครบ A คุยกะ B แล้วชั้นหละ C D ที่มาด้วยกัน
  • ไม่สนอ่า - แก้เลย push ก่อนได้เปรียบ
  • NOTE: ถ้า org ส่อง code ข้ามทีมกันได้ปัญหาจะเกิดน้อยลง หรือจัดโครงสร้างองค์กรให้มัน flat เท่ากัน

• Control API Version - ทำไมต้อง Control เพราะทุก request มี constraint ต่างกัน ทั้ง Web Mobile มี 3 ท่า
  • Incremental Data Structure and Provide view layer ถ้ามีแก้ Field แบบเปลี่ยนชื่อ / ขยายขนาด ให้เพิ่ม Field ใหม่ลงไป และ migrate
  • Contract by grpc - กำหนด data structure ระหว่าง client server //มาฟังแล้วแสดงว่าเราน่าจะกำลังมาถูกทาง
  • Graph QL - client เป็นคนบอกอยากได้อะไร แล้วให้ GrapQL ทำหน้าที่เป็น facade จัดการก่อนแต่เราต้องทีมงานคุม data structure ตรงกลาง

- Q&A

• Q: Field ที่เพิ่มไป เอาออกไปตอนไหน ?
  A: ปกติ Field เดิมกว่าจะเอาออกไปก็ตอน Tech Stack เปลี่ยน ถ้าไม่ได้กำหนดเวลาไว้ชัดเจน
• Q: Microservice วันแรกเลยไหม เช่นมีระบบ User + Blog ?
  A: ขึ้นกับ Goal และ Cost จะเริ่มจาก mono ก่อน หรือ ต้องทำให้เป็น microservice ready เขียน Code รวมกันแหละ ถ้าคิดว่าอาจจะต้องแยก DB ในอนาคต อาจจะต้องวาง Structure Code ให้รองรับไว้ แทนที่จะ JOIN ตรงๆ อาจจะให้ Service มาจัดการข้อมูลแต่ละอันมาร่วมกัน หรือใช้ GraphQL มาช่วย เป็นต้น
• Q: ถ้ามี Microservice 10 อัน ต้องรันหมดเลย หรือแยก Server Dev เฉพาะ
  A: ได้หมดนะ ถ้าเครื่องไหว //ส่วนตัวใช้ Mock Rest และไปลองที่ Server Dev
• Q: จากเคสที่ระบบ Streaming ล่ม ตัว streaming ไม่มีปัญหา แต่ไปติดที่ Authen มีท่าไหนมาช่วยบ้าง
  A: ใช้ Feature DB + Infra ช่วยกระจาย load จาก request ให้เข้าไป Zone ที่กำหนด / In-memory db หรือ ใช้ระบบ Queue - ทำเป็น publish sub ไม่ต้องมาทิ้ง Connection ค้าง
• Q: Use Case แบ่ง Microservice ตามไหน ?
  A: business domain หรือ จะดูจากพวกระบบ ERP จะพบอะไรที่มัน common
• Q: การจัดการ Transaction ทำอย่างไร ?
  A: ท่ายาก อาจจะต้องเขียน Code มาจัดการเอง แต่จะเอา Message Queue เข้ามาช่วยได้
  และขอเสริม อันนี้ Transactions Across Microservices ที่ตัวผมเองลองเอามาปรับใช้ครับ

Expanding API Contract (Natthapong Intharak)

• Microservice จาก Session ที่แล้วจะมี Key อันนึง Drive มาจาก Business อันนี้มาเสริม
  • Digital transformation การแปลง Flow ที่คนมีหลายฝ่าย > ระบบ ฺฺBusiness + IT ทำงานร่วมกัน
  • Business Evolution แต่ละฝ่ายต้องทำงานกันอย่างไร
  • แล้ว Software Architecture Evolution ตอนไหน ? เอาอะไรมาช่วย >> เอา Business มาช่วย จะได้เลือกไรทีจำเป็นต้องทำ ณ เวลานั้น

- Keyword ที่ควรรู้

• Conway's Law
  • Org Chart + การทำงาน มันส่งผลกับ Source Code ที่ได้มันออกแบบไหน Software เป็นอย่างไร
  • ถ้าเราทำให้ Team มัน Lean + Cross-functional ช่วยใ่ห้ดีขึ้นได้
• 3 Simple Truth (Response to change over the follow plan)
  • It is impossible to gather all requirements at the beginning of a project
  • Whatever requirements you do gather are guaranteed to change
  • There will always be more to do than time and money will allow
• MVP (Mininum Viable Product)
  • ปัญหาที่เราเจอๆ กัน เมื่อๆมี Requirement มา กว่าจะทำออกมาได้ใช้เวลานานโขเลย
  • ตัว MVP มาช่วยให้มี Feature ขึ้นมาน้อยๆ ลองตลาด และมันไปสอดรับกับตัว Business Evolution พอดีเลยนะ
  • แต่ปกติว่า Feature มันคลอดออกมาได้จะไปเจอประชุมมากมาย ไปติด Process Flow ดังนั้น คุยกัน เปลี่ยนแปลง กระทบลูกค้าน้อยสุด

- ลองดูเคสตัวอย่างของระบบ E-Commerce

• ฝั่ง Business เข้ามา Drive ระบบยังไงบ้าง
  • Support พอว่าลูกค้าติดปัญหา แต่จำเลข Order ไม่ได้ ต้องมาหาจากชื่อ เบอร์มือถือ แทน
  • เริ่มมีคู่แข่ง แล้วต้องมาเพิ่ม Feature บ้าง
  • ต้องมาทำ Data Governance / PDPA
  • และพองานคนล้น เช่น การแจ้งปัญหา / Claim จากเดิมคน > ระบบเพิ่ม Feature ใหม่
• แต่ Software มันโต และ Complex ไปเรียบร้อยแล้ว เราจะรู้ได้อย่างไรว่ามัน Smell ว่าการควรจะ Evolution ขึ้นมา
  • Compatibility bugs
  • Fear of changes
  • การจัดการปัญหาระหว่างทีม และมี Meeting เยอะมากๆ

- Software Evolution & Cost of Change

• Software Evolution
  • ดูก่อนว่าทำไป Business + Stakeholder (Team) ได้อะไร ทำเงิน/ลดเวลา จะได้รู้ว่าเราได้แก้ปัญหาได้ถูกเวลา (Right Time)
  • เอา Automation มาช่วย เช่น เริ่มทำ Unit Test กว่าจะทำได้ ต้องทำให้ Code มันถูก Refactor ตัว Software Evolution ด้วย โดยมี Keyword
    • Continuous Delivery
    • Continuous improvement
  • ถ้าระบบเดิมมันเก่า ต้องมาทำ Legacy Modernization - เขียนใหม่ และค่อยๆมาแทนในระบบแต่ต้อง Design ไปด้วย Code มันรองรับการเปลี่ยนแปลงในอนาคต
• Evolutionary Architecture
  • Evolutionary vs Design up Front (Design ล่วงหน้า) - เน้นทำให้ Code มันปรับตาม Business ง่ายดีกว่า เพราะการ Design ล่วงหน้า แต่เราไม่รู้ว่าอนาคต Business ไปทางไหน อาจจะทำให้ทำงานเกินความจำเป็นได้
  • Design Support
    • Business Case First - ลูกค้าติดปัญหา แต่จำเลข Order ไม่ได้ แสดงว่า API ต้องรองรับหาด้วยอย่างอื่น เช่น ชื่อ เบอร์มือถือ เป็นต้น
    • Quality Attribute เช่น Security - API Protection
  • API Evolution strategy?
    • Expanding contract > API expand-contract | Technology Radar | Thoughtworks
    • New version

• Cost (Code) Of Change
  • feedback of breaking changes - รู้ยิ่งเร็ว ยิ่งดี เพราะยิ่งช้าใช้เวลามากขึ้น และอาจจะมี Dependency พันมากขึ้นด้วย
  • Provider’s Code ready
    • SOLID Principle
    • TDD / Refactoring
    • Healthy test pyramid - น่าจะมาจาก Software Engineering @ Googe ที่พยายามเน้น Unit Test เยอะมากๆ ถัดมา Integration / UI
  • Consumer Code ready
    • Anti-corruption layer - Anti-corruption Layer pattern - Azure Architecture Center | Microsoft Learn
    • SOLID Principle
    • TDD & Refactoring
  • Consumer Driven Contract Testing

Kafka & Schema Registry (Chatchai Kritsetsakul)

• สำหรับผม Session นี้จะตัวอย่างการ Implement Microservice โดยเอาตัว Kafka มาแก้ปัญหา Dependency ระหว่าง Microservice + Software Evolutionary ตามปัญหาที่พบ

- เอา Microservice มาใช้ยังไงบ้าง

• เดิม Monoliths (Gen1) แยกระบบตาม Business ประกันรถยนต์ / มือถือ / Health เป็นต้น ทุกคนต่างมีข้อมูลเป็นของตัวเองหมด Login / Customer แยกจากกัน
• ใหม่ Microservice (Gen2)
  • ทำ foundation พวก common login/ notification หรือ อนาคตใช้ร่วมกัน analytic
  • แยก Domain Specific ตาม domain ของประกัน
  • แต่ตอนแยก Microservice ยังมี Dependency ระหว่าง Microservice อยู่ เส้นโยงเต็มไปหมด

- ทำไมถึงเอา kafka มาใช้

• ทำไมถึงเอา kafka มาใช้
  • Scalability - "Partitions" / "Consumer groups"
  • Reliability - "Replication"
  • Message ไม่หายไปหลังจากถูกดึงไปประมวลผล แต่ถูกลบหลังจากเวลาที่กำหนดไว้ (Retention)
  • แบ่ง Topics / Offsets
  • มี Schema คุม
• ใช้แบบไหนบ้าง แยกกลุ่มของ Message ตาม Zone
  • Foundation Event Topic - ถนนสายหลัก รวม Message ที่ใช้งานร่วมกัน Microservice เช่น การ Authentication / Notification
  • Product Event Topic- ถนนสายรอง Message ที่ใช้งานกลุ่มตาม Business นั้นๆ
• Note สำหรับใครอยากรู้เรื่อง kafka คือ อะไร แนะนำ Blog นี้ Intro to Apache Kafka Universe: Kafka คืออะไร ? | by Burasakorn Sabyeying | Mils’ Blog (mesodiar.com) ครับ

- Wrong Decision ที่พบ

1. Shared topic - เพราะบาง Message ที่ยกเข้ามาในส่วน Foundation Event Topic ถูกใช้เฉพาะ Product เดียวเท่านั้น แต่กลายเป็นว่าทุก Consumer ต้องรับไปตีความก่อน แล้วมองว่ามันไม่ใช่นะ ทางแก้ เพิ่มถนน (Topic) อีกเส้นระหว่าง Product Specific <-> Foundation ขึ้นมา โดยมีตัว X Service มาดัก Message นี้ให้
2. Inter-related topics - คล้ายกับหัวข้อที่แล้วเลย แต่ที่นี้ตัวตัว Message ใน Topic เดียวกัน จะมองว่ามันมี Flag/State ของการทำงาน อย่าง
   • เดิม Sell Service - หลังจากเกิดรายการส่งให้ Payment Service ต่อและ เมื่อจ่ายเงินเสร็จจะให้ Business Admin Service ตรวจสอบข้อมูลต่อ แต่กลายเป็นว่าตอนนี้ Sell Service ต้องมาตามด้วยว่าจ่ายเงินยัง ถึงจะส่งงานให้ Business Admin Service ทำต่อ
   • ใหม่ เพิ่ม X Service เข้ามา เพื่อลด Coupling ระหว่าง Sell (Product) / Payment (Foundation)
3. Event name as a message key - กำหนด Message Key ผิดทำให้แต่ละ Partition กระจาย Message ได้ไม่ Balance ทำให้ฝั่ง Consumer ว่าง
4. Lack of Error handling - แยก App ส่วนของ Main / Retry (Deploy 2 Container)
   • Case ปกติมันจาก Source Topic > Main App > Target Topic
   • กรณีที่ Error เอามาใส่ Retry Topic > Retry App > Target Topic จนครบ แต่ถ้าครบ Retry Count แล้วให้ใส่ใน Error Topic
     มี Pattern ที่น่าสนใจเยอะ Error Handling Patterns in Kafka (confluent.io)
5. Message without schema - Field เดียวกัน แต่มีหลายคำที่สื่อความหมายเดียวกัน เช่น Order amount มีคำอื่นๆ เช่น total / charges / amount ตรงนี้จะเอาตัว Schema Registry มาช่วยแก้ปัญหาได้

- Schema Registry

• Schema Registry - เอาไว้ Control การ Evolution ของ Message
  • schema - เอาไว้ validate ว่า message ควรมีโครงสร้างแบบไหน โดยถ้าไม่มีทาง Producer สามารถ register เข้าไปได้ (แต่จะคุม Version ยากขึ้น)
  • subject - เอาไว้บอกว่า scope ของ message ของ topic ไหน และจัดการ version
  • Schema Reference Union - 1 Topic มีได้หลาย Message Event รวมกัน Multiple Event Types in the Same Kafka Topic - Revisited (confluent.io)
• Schema Evolution and Compatibility
  • BACKWARD
  • FORWARD
  • FULL (แนะนำ)
• Best practices

- Q&A

• Q: Schema Registry เกิดขึ้นตอนไหน Dev / Production
  A: ตอนไหนก็ได้ แต่ตอนที่ Evolve ขึ้นมาควรระบุด้วยว่า Subject Topic ไหนใช้เวอร์ชันไหน ปกติมันจะเอาเวอร์ชันล่าสุด
• Q: ไม่ใช้ Schema Registry แยกคนละ Topic เลยไหม
  A: ได้ แต่อาจจะไม่ scale เต็มที่
• Q: kafka ถ้าตายจะเป็นไง
  A: มี replication กำหนดตาม replication factor
• Q: ตอนใช้งาน kafka มีปัญหากับ Zookeeper
  A: เวอร์ชันหลังๆเอา Zookeeper แต่ที่ใช้งานจะเป็นพวก Managed Service บน Cloud มากกว่า

- อื่นๆ

• ส่วนตัวผมไม่เคยใช้ kafka นะ แต่เคยใช้ Redis > RabbitMQ ทำแนวนี้อยู่ รู้สึกว่าเรื่อง Error Handing เหมือนพลาด แต่ไม่ได้แยก Retry Topic ไว้เอามาต่อที่ Source แทน ไปๆมาๆนอกจาก Retry ต้องมี Priority ขึ้นมาอีก ให้มันมาสนใจงานที่พลาด เหมือนไปเพิ่ม Load ยังไงไม่รู้
• อันนี้สงสัยเองเลยลองหาดู What is the equivalent of Kafka Table on Azure Service bus? - Stack Overflow

Reference

• Dev Club Meetup #1 Micro services | Eventpop | Eventpop
• Resource + Slide: Dev Club Meetup1 - Google ไดรฟ์