วันนี้ว่าง ๆ หยิบหนังสือ One + One = Three
"A Masterclass in Creative Thinking"
หรือแปลเป็นไทยคือ หนึ่งบวกหนึ่งเท่ากับสาม
ในหนังสือเล่มนี้ พยายามชี้ให้เห็นว่า
แนวคิดหรือความรู้ใหม่ ๆ นั้น ส่วนใหญ่ก็มาจากเรื่องเดิมนี่แหละ
แต่นำมาเชื่อมโยงในรูปแบบใหม่ ๆ
บางคนเรียกว่า Connect dot นั่นเอง

แต่ปัญหามันอยู่ที่เรามี dot ต่าง ๆ เยอะเพียงใด

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

ดังนั้นในหนังสือเล่มนี้

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

หนังสือเล่นนี้แบ่งออกเป็น 9 ส่วน

แต่ละส่วนประกอบด้วยเรื่องสั้น ๆ ที่น่าสนใจมาก
เพื่อชี้ให้เราเห็นประเด็นที่น่าสนใจ
แนะนำให้ลองอ่านกันดูครับ
ผมอ่านรวดเดียวจบเลยทั้ง 9 ส่วน
เป็นหนังสืออีกเล่มที่วางไม่ลงครับ

ช่วงว่าง ๆ ปีใหม่ลองหยิบมาอ่านดูครับ 
แต่ละเรื่องแต่ละตอนสั้น กระชับ
อ่านง่ายแถมให้แนวคิดที่ดีอีกด้วย
เล่มนี้แปลเป็นภาษาไทยแล้วนะครับ

หนึ่งในเรื่องที่น่าสนใจจากหนังสือ Monolith to Microservices
(Evolutionary patterns to transform your monolith)
อธิบายว่า เมื่อจำนวน service ของระบบเพิ่มมากขึ้นแล้ว
ปัญหาที่ต้องพบเจอก็มากและแตกต่างกันไป
เช่นปัญหาของ service ที่ไม่เกิน 10 service
จะแตกต่างจาก 50 หรือ 100 service

ดังนั้นสิ่งที่เราควรต้องรู้แล้วเข้าใจคือ
จะรับมือหรือแก้ไขปัญหาเหล่านั้นกันอย่างไร ?

ในหนังสือยกตัวอย่างให้เข้าใจง่าย

ด้วยการแบ่งปัญหาตามจำนวนของ service ดังนี้

• Breaking change
• Reporting
• Ownership at scale
• Developer experience
• Running to many things
• Global vs. Local optimisation
• Orphaned services

แสดงดังรูป

ปัญหาแรกที่มักเจอคือ เรื่อง Ownership at scale

หรือความเป็นเจ้าของ service ต่าง ๆ นั่นเอง
เมื่อมีจำนวน service มาก ๆ ขึ้นมา
คำถามคือ ใครละเป็นเจ้าของ เป็นเจ้าภาพ เป็นคนดูแล service แต่ละตัว ?
จากบทความเรื่อง Code ownership นั้นของคุณ Martin Fowler
ได้แบ่งไว้ 3 กลุ่ม ในมุมมองของ service นั้น
มองในแง่ของการเปลี่ยนแปลง มากกว่าที่จะมองในแง่ของการ deploy
รวมไปถึงการ support ต่าง ๆ เป็นดังนี้

กลุ่มที่ 1 Strong code ownership 

แต่ละ service มีเจ้าของชัดเจน
ดังนั้นถ้าใครก็ตามที่อยู่นอกกลุ่ม ต้องการเปลี่ยนแปลง
ต้องส่งการเปลี่ยนแปลงนั้นมาที่เจ้าของ
หรืออาจจะอยู่ในรูปแบบของ pull request
เพื่อให้เจ้าของพิจารณาว่าจะอนุญาตหรือไม่

กลุ่มที่ 2 Weak code ownership

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

กลุ่มที่ 3 Collective ownership

กลุ่มนี้ไม่มีใครเป็นเจ้าของ service เลย
และทุก ๆ คนสามารถทำการแก้ไขได้ตามที่ต้องการ

ในหนังสืออธิบายปัญหาที่เกิดจาก Collective ownership

ตอนเริ่มต้นนั้นมีจำนวนทีมและจำนวน service ไม่เยอะ
ดังนั้นจึงมีแนวคิดการทำงานแบบ collective ownership
เพื่อทำให้การทำงานคล่องตัว
และทุกคนเข้าใจในภาพรวมทั้งหมดของระบบ

แต่เมื่อจำนวน service และขนาดของทีมเพิ่มขึ้น
ยกตัวอย่างเช่นจำนวนคนในทีมมีประมาณ 30-100 คน
แนวคิดการทำงานแบบ collective ownership นั้นจึงเกิดปัญหา !!
เนื่องจากไม่มีการแบ่งหน้าที่ความรับผิดชอบที่ชัดเจน
ว่าใครทำอะไร ส่วนไหนบ้าง
และทำให้แนวคิดและแนวทางของ architecture ของระบบไม่ชัดเจน
ว่าจะโตไปทางไหน
ก่อให้เกิดปัญหาตามมา ยกตัวอย่างเช่น ระบบแบบ Distributed monolith !!

การแก้ไขปัญหาในกรณีนี้คือ

เริ่มมีการตั้งกฏกติการในการทำงานขึ้นมา
ซึ่งเป็นช่วงเวลาที่เหมาะสมอย่างมากในการจัดการ
ว่าแต่ละทีมจะดูแล service อะไรบ้าง
มันเป็นการแยกให้เป็น local collective ownership
หรือบ่อยครั้งก็แยกไปตาม business domain ได้เลย
ทำให้แต่ละทีมสามารถ focus ไปเพียง business domain นั้น ๆ ได้เลย

ลองดูสิว่า โครงสร้างของทีมและองค์กรของเราเป็นอย่างไร

แล้วมีปัญหาในรูปแบบใดบ้าง
จากนั้นทำการแก้ไขหรือไม่
หรือ มันกลายเป็นข้อจำกัดไปแล้ว 
ถ้ามีปัญหาแล้วไม่แก้ไข 
จะใช้อะไรมันก็มีปัญหาเช่นเดิม หรือ หนักกว่าเดิมก็เป็นไปได้

ช่วงปลายปีมีโอกาสไปสอนและแบ่งปันความรู้
เรื่อง ELK stack สำหรับ Big Data Analytic เป็นเวลา 3 วัน
ที่สำนักวิทยบริการ มหาวิทยาลัยราชภัฏยะลา
โดยครั้งนี้มีเวลา 3 วัน จึงทำให้ได้เนื้อหาที่เข้มข้นและลงรายละเอียดเยอะ
เลยทำการสรุปไว้นิดหน่อย
ไว้ปีหน้าหาเวลามาแบ่งปันกันนิดหน่อย
เนื่องจาก ELK stack มันเปลี่ยนบ่อยเหลือเกิน
มาเริ่มกันเลย

เป้าหมายของการสอนและแบ่งปันครั้งนี้

ปูพื้นฐานให้เข้าใจตัว ELK stack ซึ่งประกอบไปด้วย

• Elasticsearch สำหรับจัดเก็บข้อมูล
• Log stash สำหรับนำเข้าและ transform ข้อมูลให้อยู่ในรูปแบบที่ต้องการ สามารถนำมาสร้างเป็น data pipeline ได้
• Kibana สำหรับ visualize ข้อมูลในรูปแบบต่าง ๆ เพื่อทำให้เข้าใจข้อมูล รวมทั้งมีเครื่องมือต่าง ๆ อีกเพียบ ทั้ง dev tool, monitoring เป็นต้น

แต่ในปัจจุบันก็มี project ที่ชื่อ Beats ขึ้นมา
ทำหน้าที่คล้ายกับ Log stash นั่นเอง แต่มีความเฉพาะเจาะจงอย่างมาก 
รวมทั้งไม่มีส่วนของการ transform ข้อมูล
มีเพียง input และ output เท่านั้น
ทำให้ทำงานเร็ว และ ใช้ resource ที่น้อยลง
เหมาะกับการเป็น Agent ไปทำงานในแต่ละเครื่องมากกว่า Log stash นั่นเอง

โดยทั้ง 4 ตัวแสดงการทำงานดังรูปนี้

จากนั้นทำการลงรายละเอียดของ Elasticsearch ที่สุด

จึงทำการสรุปแต่ภาพรวมในส่วนนี้
Elasticsearch มีความสามารถดังนี้

• จัดเก็บข้อมูลเป็น Document ซึ่งอยู่ในรูปแบบ JSON
• สามารถทำการค้นหาได้ดี เนื่องจากทำการสร้าง index ให้อัตโนมัติ
• สามารถใช้งานโดยไม่ต้องสร้าง schema ไว้ก่อนได้ เนื่องจากจะสร้างให้อัตโนมัติตามข้อมูล หรือเรียกว่า Dynamic schema
• สามารถทำการ analyze ข้อมูลได้ ผ่าน Aggregation API ซึ่งเป็นส่วนการทำงานที่ใช้สำหรับสร้าง visualization นั่นเอง

โดยส่วนนี้จะใช้ควบคู่ไปกับ Kibana
เนื่องจากใน Kibana ได้เตรียมเครื่องมือของการใช้งานและเรียนรู้ไว้ให้ครบ
ทั้ง Dev tools สำหรับใช้งาน Elasticsearch ผ่าน RESTFul API 
เป็นสิ่งที่คนใช้งาน Elasticsearch ทั้งนักพัฒนา คนออกแบบ และ infrastructure
ต้องใช้งานได้และเป็น

ทำการเรียนรู้ทั้ง

• CRUD operation กับ Elasticsearch ผ่าน RESTFul API ที่ได้เตรียมไว้
• Query DSL ของ Elasticsearch มีเยอะมาก ๆ โดยแบ่งเป็นการ query และ filter ข้อมูล
• Analyse API สำหรับการดูขั้นตอนการจัดทำ index ของ Elasticsearch ทั้ง Tokenizer, Filter, Normalize เป็นต้น
• Aggregation API สำหรับการวิเคราะห์ข้อมูล
• Alias index และการ routing ข้อมูลตามที่ต้องการ
• Bulk API สำหรับการปรับปรุงความเร็วในการนำข้อมูลเข้า

อีกเรื่องใหม่ที่ขาดไม่ได้คือ Index Lifecycle Management (ILM)
เป็นความสามารถใหม่ เพื่อรองรับข้อมูลขนาดใหญ่
ที่สำคัญช่วยให้ Elasticsearch ทำงานได้รวดเร็วขึ้นอีกด้วย

จากนั้นช่วงท้าย ๆ ทำการอธิบายเรื่องของ Cluster

สำหรับออกแบบให้รองรับการ scale ที่ง่ายขึ้น
ยกตัวอย่างเช่น การแบ่งหน้าที่ของแต่ละ node ให้ชัดเจน
ซึ่งใน Elasticsearch นั้นโดยค่าปกติจะทำให้ที่ทุกอย่างดังนี้

• Master ทำหน้าที่ควบคุมและดูแล cluster
• Data ทำหน้าที่จัดเก็บข้อมูล
• Ingest สำหรับทำการ pre-processing และ transform ข้อมูลก่อนนำไปจัดเก็บ
• Machine learning สำหรับความสามารถใหม่คือ Machine learning นั่นเอง
• Query หรือ Coordination สำหรับทำการดึงข้อมูลและนำข้อมูลเข้าผ่าน Bulk API

ถ้าเราเข้าใจในส่วนนี้จะทำให้เรา
สามารถวางแผนในการขยายแต่ละส่วนได้ง่ายขึ้น

แต่ก็ยังมีอีกหลายเรื่องที่ยังไม่ได้แนะนำไป

• การ modeling data
• การ tuning performance
• การ monitoring
• การพัฒนาระบบงานกับ ELK stack

สุดท้ายแล้วต้องขอขอบคุณทางอาจารย์ที่ให้โอกาสไปแบ่งปันครับ

สิ่งหนึ่งที่มักได้ยินบ่อย ๆ ในการพัฒนา software คือ
เรื่องของ Event-based Architecture
ยิ่งมีการพูดถึงมาก ๆ ในแนวคิดของ microservices
ตามจริงก็พูดกันเยอะมาก ๆ จาก Domain-Driven Design
ในเรื่อง Strategic design (Integration pattern)

อ่านเจอบทความเรื่อง Best Practices for Event-Driven Microservice
ซึ่งอธิบายได้อย่างน่าสนใจ ประกอบไปด้วย

• Event-based Architecture คืออะไร ?
• ทำไมถึงต้องใช้ด้วย ?
• Event-based Architecture มีข้อดีและแน่นอนว่ามีข้อเสียอะไรที่ต้องรับมือ ?

จึงทำการสรุปไว้นิดหน่อย

Event-based Architecture คืออะไร ?

ผมคิดว่าเรื่องของ event หรือเหตุการณ์ต่าง ๆ มันเป็นเรื่องธรรมชาติอยู่แล้ว
แน่นอนว่า แต่ละ event ที่เกิดขึ้นมา
ย่อมเกิดผลกระทบหรือ side effect
โดยอาจจะเกิดผลกระทบในหลาย ๆ ส่วนงานก็เป็นไปได้ที่ให้ความสนใจต่อ event นั้น ๆ
ที่สำคัญแต่ละ event ที่เกิดขึ้นมา ต้องมีคนกระทำหรือคนที่สั่ง (Command)

โดยผู้สร้าง event จะเรียกว่า Producer
ส่วนผู้สนใจใน event ต่าง ๆ จะเรียกว่า Consumer
และ event ต่าง ๆ เหล่านี้จำเป็นต้องมีที่จัดเก็บ เราจะเรียกว่า Event store

เมื่อนำแนวคิดนี้มาใช้ใน Microservices แล้ว

สามารถออกแบบได้ดังตัวอย่าง
ของการสมัครสมาชิก (Register service)
จะมีขั้นตอนการทำงานและ services ต่าง ๆ ดังนี้

• ขั้นตอนที่ 1 ผู้ใช้งานทำการสมัครสมาชิกผ่านหน้า website
• ขั้นตอนที่ 2 Register service ทำการสร้างข้อมูล user ลง database
• ขั้นตอนที่ 3 Register service ทำการสร้าง event ชื่อว่า Registered event ขึ้นมาใน Event store
• ขั้นตอนที่ 4 Notification service ทำการ consume Registered event เพื่อทำการส่ง notification ไปหา user
• ขั้นตอนที่ 5 Report service ทำการ consume Registered event เพื่อทำการบันทึกข้อมูลของ user เพื่อใช้ในการสร้าง report ต่อไป

โดยที่ event ที่สร้างขึ้นมานั้นคือ Registered event
จะถูกสร้างและจัดเก็บได้หลากหลายรูปแบบ
ยกตัวอย่างเช่น
จัดเก็บลง queue ซึ่งจะการันตีว่า event ต่าง ๆ
จะถูกส่งไปยัง consumer ที่กำหนดอย่างแน่นอน
หรืออาจจะสร้างในรูปแบบ pub/sub ก็ได้

ข้อดีของ Event-based Architecture ประกอบไปด้วย

1. ทำงานแบบ Asynchronous

ทำให้แต่ละ request ไม่จำเป็นต้องรอให้การทำงานทุกอย่างเสร็จ
จึงจะได้ response กลับมา
ทำให้ไม่ block การทำงาน
นั่นคือ resource ต่าง ๆ ไม่โดย block หรือ lock ไว้
ส่งผลให้รองรับ request ได้มากขึ้น

2. Loosely coupling หรือแต่ละส่วนงานผูกมัดกันแบบหลวม ๆ

เป็นแนวทางของการออกแบบระบบที่ดี
นั่นคือแต่ละ service เป็นอิสระต่อกันมากขึ้น
เนื่องจากติดต่อสื่อสารกันผ่าน event เท่านั้น
ดังนั้นจึงเพียงทำข้อตกลงในรูปแบบของ event ก็พอ
โดยไม่จำเป็นต้องรู้รายละเอียดการทำงานของแต่ละ service เลย
รวมไปถึงความเป็นอิสระด้านการพัฒนา ทดสอบและ deploy อีกด้วย

3. ง่ายต่อการ scale ระบบ

แต่ละ service แยกกันชัดเจนจากข้อที่ 2
มีการทำงานที่เฉพาะเจาะจง
ทำให้ง่ายต่อการ tracking ปัญหา รวมทั้งง่ายต่อการ scale อีกด้วย

4. ง่ายต่อการ recovery ระบบ

ในกรณีที่ consumer มีปัญหาขึ้นมา
ระบบในรูปแบบนี้ สามารถนำ event ที่จัดเก็บใน event store มา replay ใหม่ได้
ซึ่งช่วยตอบโจทย์เรื่องของข้อมูลสูญหายได้อีกด้วย

มีข้อดีก็ย่อมมีข้อเสีย โลกสวยไม่ได้นะ !!

ข้อแรกคือ แยกการทำงานดีเกินไป (Over engineer)

ให้เกิด service ต่าง ๆ แยกกันเยอะมาก
แน่นอนบางครั้งเล็กจนเกินไป
ทำให้การทำงานหนึ่ง ๆ เกิดความซับซ้อนจนเกินไปตั้งแต่เริ่มต้น
ซึ่งบ่อยครั้งเราไม่ได้ต้องการอย่างนั้นเลย

ข้อสองคือ การจัดการข้อมูลและ transaction

เนื่องจากทำงานแบบ asynchronous 
ทำให้แต่ละส่วนงานไม่ได้สนใจเรื่องความถูกต้องของข้อมูลระหว่างกัน
จะสนใจเฉพาะการทำงานของตัวเองเท่านั้น
ซึ่งอาจก่อให้ข้อมูลเกิดซ้ำซ้อนขึ้นมา
ซึ่งอาจก่อนให้เกิดปัญหาเรื่อง transaction ข้ามระบบงาน
นั่นคือปัญหาเรื่องความถูกต้องของข้อมูล (Data consistency)
จะทำการจัดการอย่างไร ?

แน่นอนว่าไม่สนับสนุน ACID แน่ ๆ
ดังนั้นข้อมูลจะอยู่ในรูปแบบ Eventualy consistency
ซึ่งยากต่อการ tracking และ debug !!

ดังนั้นใครก็ตามที่เริ่มนำเอา Event-based Architecture มาใช้งาน

จำเป็นต้องเข้าใจด้วยว่าข้อดีข้อเสียเป็นอย่างไร
รวมทั้งเป้าหมายของสิ่งที่นำมาใช้ด้วย
เพื่อให้สามารถออกแบบ พัฒนาและ deploy ได้อย่างเหมาะสม

Reference Websites

• https://vaadin.com/learn/tutorials/ddd/strategic_domain_driven_design
• https://hackernoon.com/best-practices-for-event-driven-microservice-architecture-e034p21lk

เนื่องจากมีงานพัฒนาที่ต้องใช้และเตรียม environment เยอะ
และไม่อยากติดตั้งในแต่ละเครื่องที่พัฒนาเพราะว่า ใช้ resource เยอะ
ก็เลยคิดว่าแนวทางการใช้ server กลางน่าจะแก้ไขปัญหาได้
ซึ่งการพัฒนาก็ใช้ VS Code อยู่แล้ว
ดังนั้น Remote server ผ่าน SSH จึงเป็นคำตอบที่เหมาะสม
ก็เลยบันทึกการใช้งานไว้นิดหน่อย

เริ่มจากการอ่านเอกสารที่ VS Code

แสดงการทำงานดังรูป

โดยที่ extension ตัวนี้สามารถทำงานได้ทั้ง

• SSH
• Container
• Windows Subsystem for Linux (WSL)

จากนั้นก็ไป setup server ปลายทางที่ต้องการ และ config ssh server ไว้ด้วย

เมื่อทุกอย่างเรียบร้อย ก็ทำการติดตั้ง extension ชื่อว่า Remote-SSH

ทำการ config SSH server ใน extension ดังนี้

จากนั้นก็เปิดไฟล์และ directory ที่ต้องการบน remote server ได้เลย
กลับไปสู่โลกยุค mainframe ที่ต้องใช้งานผ่าน terminal กันเลยทีเดียว
ซึ่งตอบโจทย์ปัญหาที่เจอได้ดี

อีกตัวที่ใช้ง่ายบ่อย ๆ คือ Cloud Code สำหรับใช้งานผ่าน Google Cloud

ช่วงเช้า ๆ มานั่ง review code ของ project ต่าง ๆ มาศึกษา
ก็เจอ code แปลก ๆ เยอะพอควร
เป็น code ที่อาจจะก่อให้เกิดปัญหาได้
ที่สำคัญ เจอบ่อยมาก ๆ ในแต่ละ project
เลยสรุปไว้นิดหน่อย เพื่อจะได้ไม่ทำตาม

เรื่องแรก แต่ละ function ทำงานเยอะเกินไป

เมื่อไปดูชื่อ function กับ code ที่อยู่ใน function แล้ว
คำถามคือ ทำไม code มันทำงานเยอะมาก ๆ
หนักกว่านั้น แต่ละ function มี code มากกว่า 100 บรรทัด
คนเขียนคิดอะไรอยู่นะ ?
ไม่ได้บอกว่าผิด แต่คิดอะไรอยู่ ?
หรือ ทำให้เสร็จ ทำให้เสร็จ นะ

ผลที่ตามาคือ กว่าจะทำความเข้าใจว่า function นี้ทำอะไรบ้าง
ต้องใช้เวลานานมาก ๆ
หนักกว่านั้น จะทำการแก้ไขนี่จัดว่านรกมาก ๆ 

ทำการแยก code ออกไปเป็น function ย่อย ๆ ดีกว่าไหมนะ
แล้วตั้งชื่อ function ให้ชัดเจน

เรื่องที่สอง เจอตัวเลขแปลก ๆ ใน code ซึ่งจะเรียกว่า magic number

บางครั้งเจอ 0, 1, 2 ,3
บางครั้งเจอ 552
บางครั้งเจอ 60
บางครั้งเจอ XYZ429
มันคืออะไรนะ ?
ใครเคยเจอบ้าง ?
ถามใครก็ไม่มีใครรู้
ที่สำคัญเปลี่ยนค่าแล้วพัง !!

เรื่องที่สาม การตั้งชื่อตัวแปรที่สื่อสารไม่ได้หรือไม่ชัดเจน

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

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

เรื่องที่สี่ ชอบทำการ hard code ไว้ใน code

จะเจอบ่อยมาก ๆ ใน code
ใส่ค่าตรง ๆ ไว้ใน code เลย
ยกตัวอย่างเช่นค่า URL ต่าง ๆ ค่า Username
รวมไปถึงค่า config ต่าง ๆ ใส่ไว้ใน code กันเลยทีเดียว
แก้ไขยากไหมละเนี่ย ?
คนจริงต้องเปิดเผยทุกอย่าง ?

เรื่องที่ห้า เรื่องของ format ของ code ที่ต่างกัน

บางคนอาจจะบอกว่า ไม่เคยเจอ
เพราะว่าใช้ editor เหมือนกัน
เพราะว่าใช้เครื่องมือการจัดรูปแบบ code เดียวกัน ทำงานแบบอัตโนมัตด้วย

แต่มีหลาย ๆ project ไม่ได้ทำเช่นนี้
ทำให้เกิดการจัดรูปแบบของ code ตามใจตัวเองเยอะมาก ๆ
ซึ่งทำให้การทำงานร่วมกันลำบากน่าดู
ยกตัวอย่างสิ่งที่เจอบ่อยคือ space bar vs tab เป็นต้น

ก่อนจบมีอีกเรื่องเพิ่งเจอเลยคือ
ขยัน comment code เหลือเกิน
Version control ก็ใช้ อะไรไม่ใช้ก็ลบไปสิ
จะ comment ไว้ทำไม ?

VDO งาน Kong Summit 2019 ที่ทางนเรศแชร์มาใน facebook
มีหลายอย่างที่น่าสนใจ
เรื่องที่ผมสนใจคือ การเขียน Kong plugin ด้วยภาษา Go
ซึ่งจะมีใน Kong gateway 2.0 นั่นเอง
โดยจะอยู่ใน session Keynote:: Announcing Kong Gateway 2.0
ดังนั้นว่าง ๆ มาลองเล่นดูหน่อย

เริ่มด้วย software ที่ใช้งานเพื่อลองของ

ประกอบไปด้วย

• Docker
• Kong Image จาก Docker Hub version 2.0.0rc1-ubuntu
• Kong :: Go plugin server
• Kong :: Go PDK (Plugin Development Kit)

จากบทความข้างต้นนั้น

แนะนำให้ใช้ Kong Preview Version (Alpha)
แต่จากที่ลอง run แล้วมันเดี้ยง ๆ เลยไปใช้ version 2.0.0rc1 แทน
ซึ่งทั้งสอง version นี้แตกต่างกันเรื่อง config ของ DBless

โดยใน  Kong Preview Version นั้นต้องกำหนด environment variable
ชื่อว่า KONG_STORAGE: memory
แต่ใน version 2.0.0rc1 นั้นต้องใช้ KONG_DATABASE: off เช่นเดิม

มาเริ่มต้นกัน

จากที่เริ่มแกะ ๆ เล่นดู เจอ error เพียบเพราะว่าไม่รู้อะไรเลย !!
แต่ก็มั่ว ๆ ไปจากการดูใน VDO นั่นเอง
run ตามรูป

ใน VDO ดูง่ายนะ แต่พอมาลองทำเองไม่ง่ายเลย
เพราะว่าเอกสารยังไม่มี ต้องมั่วเองไปก่อน !! มามั่วกัน

นั่งมั่วไปมั่วมา ได้โครงสร้างการทำงานดังนี้

• Kong gateway โดยจะมีทำการ connect ไปยัง Go plugin server จากไฟล์ kong/db/dao/plugins/go.lua อยู่ใน branch release/2.0.0 
• Go plugin server จะ run socket ทิ้งไว้
• เขียน plugin ด้วยภาษา Go ซึ่งทาง Kong เตรียม Go-pdk ไว้ให้ แน่นอนทำการเชื่อมต่อผ่าน Go plugin server ด้วย Go channel นั่นเอง
• โดย plugin นั้นก็ต้องประกาศใน Kong gateway ด้วยทั้ง เช่น directory ของ plugin เพื่อทำการติดตั้งและ load plugin มาใช้งาน

ดังนั้นรูปการทำงานน่าจะประมาณนี้

ขั้นตอนการใช้งานเป็นดังนี้

ขั้นตอนที่ 1 ทำการ config Kong gateway เพื่อใช้งาน plugin ที่เขียนด้วยภาษา Go

ทำการ config ค่าของ environment variable ดังนี้

• KONG_GO_PLUGINS_DIR กำหนด directory สำหรับเก็บ plugin ที่เขียนด้วยภาษา Go เป็นไฟล์นามสกุล .so
• KONG_PLUGINS กำหนด plugin ที่จะใช้งาน ซึ่งจะทำการ load และ ติดตั้งตอน start Kong gateway ขึ้นมา

ขั้นตอนที่ 2 ทำการ start Go plugin server ขึ้นมาใน Kong gateway 

จากที่ลองใช้งาน Docker image ของ Kong  2.0.0rc1-ubuntu นั้น
จะเจอ error เรื่องของการเชื่อมต่อไปยัง Go plugin server ไม่ได้
แสดงดังนี้

ดังนั้นจำเป็นต้องทำการ start Go plugin server เอง
โดยทำการ build binary เองและ start เอง สามารถนำ code มาจาก Kong Go Plugin Server นั่นเอง

เพียงเท่านี้ก็สามารถ start Kong gateway ได้แล้ว
ซึ่งผมทำการ restart นิดหน่อย และใส่ mode debug เข้าไป

ขั้นตอนที่ 3 มาสร้าง plugin ด้วยภาษา Go กันหน่อย

ทาง Kong ได้เตรียมตัวอย่างของ plugin ไว้ที่ Go-plugin
จะประกอบไปด้วย go-hello และ go-log
โดยผมทำการ copy go-hello มาลองเล่นนิดหน่อยดังนี้

ถ้าใครสังเกตจะพบว่า code ไม่ตรงกับ code ใน VDO นะ !!

เป็นตัวอย่างของการเพิ่ม Header ใน response ชื่อว่า X-Kong-Go เข้ามาเท่านั้นเอง

ทำการ build เป็น plugin ดังนี้ (Go สนับสนุนอยู่แล้ว)
จะได้ output เป็นไฟล์นามสกุล .so มา ดังนี้

จากนั้นนำไฟล์ go-hello.so ไปไว้ใน directory ที่กำหนดไว้ใน KONG_GO_PLUGINS_DIR

ขั้นตอนที่ 4 เมื่อทุกอย่างพร้อม ก็ run ละครับ รออะไร !!

ได้ผลการทำงานดังนี้

เพียงเท่านี้ก็พอถู ๆ ไถ ๆ ไปได้นะ !!

หลังจากที่ run แล้วก็มีคำถามเพียบ

ยกตัวอย่างเช่น

ข้อที่ 1 ทำไมต้องเขียน code แบบนี้ด้วยละ ทำไมต้องมี function Access หรือ Log มีอย่างอื่นอีกไหม ?

พอไปนั่งอ่าน code ดู ก็ถึงบางอ้อ
โดย code ที่น่าสนใจอยู่ที่ Go plugin server (instance.go)
จะทำการกำหนดไว้ว่าจะประกาศ function อะไร อย่างไร ?

• Certificate
• Rewrite
• Access
• Preread
• Log

มาดู code กัน

ข้อที่ 2 ภาษา Go จะเข้ามาแทนภาษา Lua หรือไม่ ?

คำถามนี้ก็มีใน repository ที่ Github เช่นกัน
ซึ่งทาง Kong ตอบไว้ว่า ไม่ได้เอามาแทน 
แต่เอามาเพื่อเพิ่มความหลากหลาย
ซึ่งจะมีข้อจำกัดอย่างแน่นอน

ว่าง ๆ มาลองเล่นดูกันครับ
แต่รอเอกสารจาก official ดีกว่านะ
ขอให้สนุกกับการ coding ครับ

จากบทความเรื่อง เปรียบเทียบ JVM OpenJ9 และ HotSpot
โดยที่ OpenJ9 เป็นสิ่งที่น่าสนใจมาก ๆ 

เป้าหมายหลักของ OpenJ9 คือ
ปรับปรุงการจัดการ resource ต่าง ๆ นั่นเอง
ทั้งเรื่องของ startup time และการใช้ memory/cpu น้อยลง
ซึ่งช่วยทำให้เหมาะสมต่อการนำไป run บน Cloud และ Container
นั่นคือการพยายามทำให้ขนาดของ service ที่พัฒนาด้วยภาษาบน JVM เล็กลง
ถึงแม้ว่ามันจะไม่ค่อยเล็กมากก็ตาม !!

ดังนั้นเลยลองเอามา run ใน Docker หน่อยสิ ว่าจะเป็นอย่างไร ?
ข่าวดีคือ Docker image ของ AdoptOpenJDK มีให้ด้วย

ก็เลือกได้ตามสะดวกเลย

เริ่มด้วยการใช้งาน AdoptOpenJDK กับ HotSpot

โดยระบบงานตัวอย่างพัฒนาด้วย Spring Boot
ซึ่ง code ต่าง ๆ อยู่ที่ Github:: Up1

จากการ run ด้วย docker-compose ได้ผลดังนี้

ต่อมาลองเปลี่ยนไปใช้กับ OpenJ9 บ้าง

จากการ run ด้วย docker-compose ได้ผลดังนี้

จากผลการใช้งานถือว่า OpenJ9 นั้น 

ทำให้ startup time ของระบบที่พัฒนาด้วย Spring Boot เร็วขึ้น
และใช้ memory น้อยลงมากจริง ๆ ด้วย
เป็นตัวเลือกที่น่าสนใจมาก ๆ

เพิ่งเห็น e-mail สำหรับหนังสือฟรีจากทาง RedisLabs
หนังสือชื่อว่า Redis Microservices for Dummies
เป็นหนังสือที่อธิบายเกี่ยวกับ

• ความรู้เกี่ยวกับ Microservices architecture
• ความรู้เกี่ยวกับ Redis ซึ่งมีความสามารถทั้ง caching, messaging และ storage/database
• การออกแบบการติดต่อสื่อสารระหว่าง service โดยนำ Redis ไปใช้งาน
• การจัดการข้อมูลระหว่าง cluster ของ Redis

สำหรับใครที่ยังไม่รู้ว่า Redis คืออะไร

ลองไปดูที่ Redis.io นะครับ
มันคือ Key-value database หนึ่งในกลุ่มของ NoSQL นั่นเอง
มักจะเรียกว่า Data structure database
เนื่องจากข้อมูลสามารถเก็บได้ทั้ง string, hash, list และ set เป็นต้น
และสามารถทำตัวเป็น messaging ได้อีก (Pub/Sub, Stream และ List)
และมีความสามารถเพิ่มเติมเรื่องของ HA คือ สามารถทำ cluster ได้

โดยในหนังสืออธิบายความสามารถต่าง ๆ ที่ Redis มี

ยกตัวอย่างเช่น

Redis สำหรับการสร้างระบบ messaging ทั้ง

• Pub/sub
• Redis streams
• Redis Lists

Redis สำหรับเป็นที่จัดเก็บข้อมูลในรูปแบบต่าง ๆ ทั้ง

• Hash
• Sorted Set
• สำหรับการ search
• Graph
• ข้อมูลในรูปแบบ JSON

แน่นอนว่าต้องมีการใช้เป็น caching หรือที่เก็บข้อมูลชั่วคราว

และชี้ให้เห็นว่า Redis นั้นเหมาะสมกับแนวทางของ Microservices อย่างไรบ้าง ?

ทั้งเรื่องของ communication หรือการติดต่อสื่อสารระหว่าง services
รวมไปถึงเรื่องการจัดการ state หรือ data ที่กระจายอยู่ในแต่ละ services
ว่าต้องทำอย่างไร

ปิดท้ายด้วยการสรุปเกี่ยวกับ Redis + Microservices

ไว้ดังนี้

1. Database ที่ช้า ๆ ไม่น่าจะเหมาะกับ Microservices
2. Redis สามารถใช้เป็น database ของแต่ละ service ได้ เนื่องจากสามารถ config ให้ persist ข้อมูลบน disk ได้ ข้อมูลไม่หาย ดังนั้นควรใช้ disk ที่มีความเร็วสูงนะ
3. Redis สามารถใช้เป็นตัวกลางในการติดต่อสื่อสารระหว่าง services ได้
4. Redis สามารถทำเป็น caching ของ database ใน service ได้
5. Redis สามารถเก็บข้อมูลในรูปแบบที่ปกติและซับซ้อนได้
6. Redis มี module เพิ่มเติมได้ เช่น Redis search และ Redis graph เป็นต้น

สุดท้ายเรื่องเครื่องมือให้เหมาะสมกับงาน
หรือเรามีเครื่องมือเดียว เลยต้องใช้มันไปทุกงานนะ !!

หลาย ๆ ครั้งมีการพูดคุยเรื่องของ DevOps
ว่าองค์กรเราต้อง DevOps นะ
ออกแบบ DevOps process นะ
ใช้ DevOps tool อะไรดี
ใช้ framework อะไรดี

แนะนำให้หยุดก่อน คิดก่อน ...
ประเด็นคือ อะไรละคือ DevOps ?
ทำไมต้องใช้ ?
ปัญหาของเราคืออะไร ?
หรือว่าเห็นคนอื่นทำ แล้วเขาบอกว่าดี ดังนั้นเราก็ต้องทำ ?
มาลองคิดเป็นขั้นตอนกันหน่อย ก่อนจะเริ่มต้น

ขั้นตอนที่ 0 ระบุปัญหาก่อนว่ามีอะไรบ้าง ?

จากนั้นจึงทำการเรียกลำดับตามความสำคัญหรือผลกระทบที่เกิดขึ้น
ว่าจะแก้ไขอะไรก่อนหลัง
แนะนำให้ค่อย ๆ แก้ไขทีละเรื่อง
ถ้ามันสำคัญหมด คงจะมั่วกันน่าดู 
เนื่องจากเราจะไร้ทิศทางมาก ๆ    

ถ้าไม่มีปัญหา จะปรับปรุงไปทำไม จริงไหม ?

ขั้นตอนที่ 1 ลดความหลากหลาย

สิ่งที่พบเจอบ่อยมาก ๆ ในการพัฒนา software คือ
ความหลากหลายของการทำงาน ไม่ว่าจะเป็น

• ขั้นตอนการทำงาน
• Environment ต่าง ๆ ที่ใช้งาน
• เครื่องมือที่หลายหลาย ตามใจใครหลาย ๆ คน
• การ configuration ที่ไร้ทิศทาง
• ข้อมูลที่หลายหลายชนิด อยู่หลายที่

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

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

ขั้นตอนที่ 2 ต้องรู้ขั้นตอนการทำงานตั้งแต่ต้นจนจบ

เราไม่สามารถจะปรับปรุงอะไรได้
ถ้าเราไม่รู้กระบวนการทำงานตั้งแต่ต้นจนจบ
เนื่องจากเรามักจะมีคนที่รู้เฉพาะจุดหรือบางส่วน
คำถามหรือแล้วภาพใหญ่ละ
บอกเลยว่า ไม่มีใครรู้หรือรู้ก็แบบลาง ๆ
ต้องทำการนัดประชุมกันใหญ่โต หรือใช้เวลานานมาก ๆ

ดังนั้นสิ่งที่ควรทำคือ
อะไรที่ไม่รู้ทำให้รู้ (มักจะไม่รู้ว่า ไม่รู้อะไร !!)
จากนั้นทำการสร้างเอกสาร เพื่ออธิบายการทำงานตั้งแต่ต้นจนจบไว้
จากนั้น share ให้ทุกคนที่เกี่ยวข้อง
จะได้ทำความเข้าใจ แก้ไขหรือปรับปรุงกันต่อไป
มันจะทำให้เราเห็นว่า การทำงานปัจจุบันเป็นอย่างไร
ตรงไหนมีปัญหา ตรงไหนที่มันเป็นคอขวด

ให้จำไว้ว่า ถ้าขั้นตอนมันห่วยแล้ว
จะเอาระบบการทำงานแบบอัตโนมัติมาใช้ มันก็ห่วย
ดังนั้นปรับปรุงการทำงานก่อนนะ

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

เมื่อถึงขั้นตอนตรงนี้ จะเห็นว่า

มันคือเรื่องพื้นฐานมาก ๆ ที่เรามักไม่ทำกัน ใช่ไหมนะ ?
ไม่ได้สนใจเทคโนโลยีหรือเครื่องมือหรือ framework อะไรเลย
มันคือเรื่องของการพูดคุย ทำงานร่วมกัน เปิดเผย
จากนั้นก็มาดูขั้นตอนการทำงานตั้งแต่ต้นจนจบ
เพื่อช่วยกันปรับปรุงให้ดีขึ้น
เป้าหมายหลักคือ การแก้ไขปัญหาที่ตั้งไว้ตั้งแต่ต้นนั่นเอง

ต่อจากนี้ต่อไป เริ่มนำเครื่องมือและเทคโนโลยีมาใช้แล้ว

ขั้นตอนที่ 3 เข้าสู่กระบวนการพัฒนาและส่งมอบ software

การพัฒนาและส่งมอบ software ที่ดีประกอบไปด้วย

• การจัดการ source code หรือ Source Control Management (SCM)
• กระบวนการ build ของ software
• กระบวนการ deploy software
• การ configuration หรือ provisioning environment ต่าง ๆ สำหรับการ deploy software

ซึ่งเราอาจจะต้องกำหนดการทำงานเหล่านี้ให้ชัดเจน
หรือดีที่สุดคือ ช่วยกันสร้างระบบที่ทำงานแบบอัตโนมัติขึ้นมา
เพื่อลดงานที่ต้องมีคนเข้าไปยุ่งเกี่ยวให้มากที่สุด
เพราะว่า มันคืองานที่ทำซ้ำ ๆ บ่อยมาก
และที่สำคัญคือ เพื่อลดปัญหาที่เกิดจากคนให้มากที่สุด
เรามักจะได้ยินคำว่า work on my machine !!

ขั้นตอนที่ 4 กระบวนการทดสอบแบบอัตโนมัติ

การทดสอบนั้นเป็นหัวใจของการพัฒนา software และ DevOps เลย
มันสะท้อนในเรื่องของคุณภาพ software ที่ส่งมอบมากพอสมควร
โดยการทดสอบควรต้องเป็นแบบอัตโนมัติให้ได้มากที่สุด
เพื่อช่วย validate ว่า software ของเรา
ยังคงทำงานได้อย่างถูกต้องตามที่คาดหวัง

ที่สำคัญต้องทำงานได้รวดเร็วด้วย
มิเช่นนั้น ปัญหาต่าง ๆ ก็ยังคงอยู่เสมอ มันน่ากลัวมาก ๆ
ถ้าเราทำการ deploy software บ่อย ๆ แต่ผิดเยอะบ่อย ๆ  !!!
มันไม่น่าจะใช่ผลที่เราต้องการใช่ไหม ?

เมื่อเราทำตามมาจนถึงขั้นตอนนี้แล้ว

เราได้ผ่านความต้องการพื้นฐานตามแนวคิด DevOps มาแล้ว
สามารถแก้ไขปัญหาที่เรากำหนดได้แล้ว
จากนี้ก็เป็นเรื่องที่เราต้องไปต่อแล้ว
ไม่ว่าจะเริ่มสร้างระบบอื่น ๆ ขึ้นมา เพื่อให้ใช้งานง่ายขึ้น
เช่นระบบแบบ self-service ไม่ต้องมาผ่านขั้นตอนที่มากมายหรือช้ากันแล้ว
อยากได้อะไรไปสร้างเองได้เลย
มันก็อยู่ที่ความต้องการขององค์กรต่อไปแล้ว

ขอเน้นว่า เรื่องพื้นฐานสำคัญมาก ๆ

ได้รับงานเล็ก ๆมาลองทำเล่นดู
นั่นคือ การดึงข้อมูลจาก web มาเพื่อใช้งานต่อไป
เนื่องจาก web ปลายทางไม่มี API เตรียมไว้ให้
ดังนั้นการดึงข้อมูลหรือเรียกว่า Web Scraping
จึงเป็นทางเลือกที่น่าสนใจ
แต่ก็ต้องระวังด้วยว่า web ปลายทางจะ block
หรือตรวจจับการดึงข้อมูลรูปแบบนี้หรือไม่

เมื่อได้รู้ความต้องการและปัญหาที่ต้องแก้ไขแล้ว

จึงมาถึงเครื่องมือที่ใช้งาน
ซึ่งจากที่เคยทำมามีเยอะเลย
ทั้งเรียกไปยังปลายทางตรง ๆ แล้วเอาข้อมูลมา processing ต่อ
หรือเปิด web browser แล้วตัดเอาข้อมูลใน element ที่ต้องการมา

โดยแนวทางที่เลือกคือ เปิด web browser นี่แหละ
แต่จะเป็น web browser ขึ้นมาก็น่าจะช้ามาก ๆ
ดังนั้นจึงเลือกเป็น headless mode ดีกว่า
และ library แรกที่เด้งมาจากในหัวเลยคือ Puppeteer นั่นเอง
ก็เลยใช้ซะ
ทำงานผ่าน DevTool protocol  สำหรับควบคุม Google Chrome เท่านั้น
ซึ่งเร็วแน่นอน !!

การใช้งานก็ไม่ได้ยากอะไร ใคร ๆ ก็เขียนได้

โดยมีขั้นตอนการทำงานดังนี้

• เปิด browser ขึ้นมา ซึ่งสามารถกำหนด option ต่าง ๆ ไปได้ เช่น timeout เป็นต้น
• ไปยังหน้าหรือ URL ของ web ที่เราต้องการ แน่นอนว่า ใส่ option ไปได้อีก
• ทำการเข้าถึง element ที่เราต้องการนำข้อมูลมาใช้งาน โดยสามารถเข้าถึงได้ด้วย selector ของ element นั้น ๆ ตรงนี้ก็ต้องใช้ความเข้าในเรื่อง Web และ DOM กันนิดหน่อย แต่ไม่ยากจนเกินไป
• สุดท้ายก็อย่างลืมปิด web browser ด้วยนะ

แสดงตัวอย่าง code ง่าย ๆ ดังนี้

เขียน code จบงานภายใน 10-20 บรรทัดเท่านั้น
ที่เหลือก็อยู่ความต้องการของเราแล้วว่าจะเอาไปทำอะไรต่อไป
ซึ่งไม่ยากเท่าไรนัก

สรุปแล้วแนวทางนี้ถูกสร้างขึ้นมาภายใน 10 นาที

จากนั้นก็ตกแต่งให้สวยงามและให้ได้ผลตามที่ต้องการอีกเล็กน้อย
สุดท้ายก็ run งาน ในส่วนนี้แหละที่ใช้เวลาเป็นวัน
เนื่องจากข้อมูลเยอะ และระบบปลายทางช้ามาก ๆ
แถมการทำงานของ code ที่ผมเขียนยังเป็นแบบ sequencial
ดังนั้นก็ยิ่งช้าไปกันใหญ่ แต่ก็ถือว่าตอบโจทย์และเพียงพอต่อการใช้งานแล้ว

ขอให้สนุกกับก่ีเขียน code

เห็นรูปใน time line เรื่อง Bug fixing Ways
เลยนำมาสรุปและ share นิดหน่อย
คำถามคือ
ปัจจุบันในการพัฒนา software นั้น
เมื่อเจอ bug แล้วเราทำการแก้ไขอย่างไรบ้าง ?

ปกติขั้นตอนการแก้ไข bug มักจะประกอบไปด้วย

• เวลาในการเจอ
• เวลาในการมบันทึก
• เวลาในการแจ้ง
• เวลาคุยปัญหา
• เวลาไปหาปัญหา นั่นคือ ไป debug 
• เวลาทำความเข้าใจการทำงานส่วนงานนั้น ๆ หรือ code ส่วนนั้น ๆ
• เวลาในการแก้ไข แน่นอนว่า ต้องทดสอบด้วย
• เวลาในการ deploy เพื่อดูว่าทำงานได้ถูกต้องหรือไม่ จากนั้นก็เข้าสู่พอธีกรรมขึ้น production server
• วัดผลการทำงานจริง ๆ เช่น monitoring ดูซะ

นี่คือสิ่งที่ต้องทำหรือไม่นะ ?

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

ต่อมาถ้าใช้เวลานาน ๆ แล้ว
คำถามคือ ขั้นตอนไหนใช้เวลานานที่สุด ?
ถ้ารู้ก็น่าจะต้องแก้ไขตรงส่วนนั้นใช่ไหม ?
ยกตัวอย่างเช่น
ถ้าเจอช้าหลังจากที่สร้างหรือ deploy ก็ทำให้รู้เร็ว ๆ สิเออ
หรือต้องไปนั่งไล่ดูปัญหา ก็ทำระบบที่บอกจุดที่เป้นปัญหาเลยดีไหม ?

กลับมาที่รูปขำ ๆ เป็นแนวทางที่เรา ๆ ทำกันอยู่ไหม  ?

และมันดีไหมนะ ?

• ไปหาข้อมูลจาก log file จำนวนมากและมีขนาดใหญ่ ( tail และ grep กันไหม)
• สาย debug ก็ทำการใส่ breaking point ไว้เพียบ แล้ว debug กันไปเรื่อย ๆ
• สายค้นหา แล้วก็ไปเจอวิธีแก้ไขจาก stackoverflow จากนั้นก็ copy มาใส่เลย แก้ได้แล้ว จบ !!
• เรียกใหม่ซะว่า Not a bug, it’s a feature !!

แสดงดังรูป

ปัจจุบันเรามีวิธีหรือขั้นตอนการแก้ไข bug อย่างไรกันบ้างนะ ?
อีกอย่างเรื่อง bug vs defect vs incident มันต่างกันอย่างไรนะ ?

วันนี้คุยเรื่องการประกาศตัวแปรใน JavaScript นิดหน่อย
ซึ่งแนะนำว่าให้ประกาศด้วยการใช้ keyword const เป็นค่า default
เหตุผลคืออะไร ?
จึงทำการอธิบายไว้นิดหน่อย

เนื่องจากปกติการประกาศตัวแปรใน JavaScript นั้นทำอย่างไรก็ได้ สายชิว

ยกตัวอย่างเช่น

แต่แนะนำว่าเราควรใช้ strict mode จะดีกว่า

แน่นอนว่า code ที่เขียนไว้พังแน่นอน ดังนี้

ดังนั้นสิ่งที่ต้องทำคือ ประกาศตัวแปรให้ถูกต้อง ซึ่งประกอบไปด้วย

แต่ละแบบนั้นมีขอบเขตการทำงานดังนี้

• var มีขอบเขตการทำงานในระดับ function และ global แก้ไขค่าได้ และสามารถอ้างอิงหรือใช้งานก่อนการประกาศได้ !!
• let มีขอบเขตการทำงานในระดับ block แก้ไขค่าได้ ไม่สามารถอ้างอิงก่อนการประกาศได้
• const จะมีลักษณะเดียวกับ let แต่ const ไม่สามารถเปลี่ยนแปลงค่าได้ ยกเว้นเป็น object เช่นพวก array/map เป็นต้น สามารถแก้ไขค่าได้ แต่ไม่สามารถ initial ใหม่ได้

ตัวที่แปลกประหลาดกว่าตัวอื่นคือ var

ไม่แนะนำให้ใช้เลย
มาดูตัวอย่างที่มักจะพบเจอคือ

ใช้งานก่อนการประกาศได้ด้วย แต่ค่าที่ได้คือ undefined ซึ่งไม่ error ด้วย !!
แถมตัวแปรที่ประกาศด้วย var คือ i นั้น
สามารถถูกใช้งานนอก for loop ได้อีกด้วย
เนื่องจาก var นั้นจะมีขอบเขตการทำงานในระดับ function นั่นเอง !!
งงดีไหมละ ?
ดังนั้น var ก็ไม่ควรใช้ ถ้าไม่เข้าใจหรือรู้จักมันดีพอ !!
หรืออย่าใช้เลยดีกว่า

ส่วน let นั้นเพิ่มเข้ามาใน ES6

เพื่อแก้ไขความมึนงงของ var และลดขอบเขตการทำงานอยู่ใน block scope เท่านั้น
และไม่สามารถใช้งานก่อนทำการประกาศได้

ส่วน const นั้นก็เพิ่มเข้ามาใน ES6 เหมือนกับ let นั่นเอง

โดยที่ const ย่อมาจาก constant หรือค่าคงที่
แต่ไม่สามารถ reassign ค่าได้เท่านั้นเอง

แต่ความแปลกของ const คือ เราสามารถแก้ไขได้

ถ้าตัวแปรที่ประกาศมี data type เป็น array หรือ object แล้ว
สามารถเข้าไปแก้ไขค่าได้ เช่นการเพิ่มหรือลบ element ต่าง ๆ
เนื่องจาก const จะอ้างอิงตำแหน่งใน memory ของตัวแปรนั้น ๆ เท่านั้น
แต่ถ้าเอาตัวแปรมา reassign ให้กัน จะทำไม่ได้นะ !!
ยกตัวอย่างเช่น

จะสังเกตได้ว่า var นี่ไม่ควรใช้อย่างยิ่ง

ส่วนถ้าให้แนะนำควรใช้ const เป็นค่าเริ่มต้นเลย
เพื่อลดปัญหาหรือ side effect ต่าง ๆ 
ส่วน let ใช้เมื่อจำเป็นเท่านั้น

ไปเจอรูปนี้มา อธิบายได้ชัดเจนและเข้าใจง่ายดี

Reference Websites

• https://mrfrontend.org/2019/08/how-javascript-scoping-var-let-const-variables-works
• https://dev.to/sandy8111112004/javascript-var-let-const-41he

จากบทความเรื่อง 5 Characteristics of a DevOps Organization
อธิบายคุณลักษณะของการนำ DevOps ไปใช้ในองค์กร มีเป้าหมายเพื่อ

• ปรับปรุงการทำงานร่วมกันให้ราบรื่นมากยิ่งขึ้น
• นำระบบการทำงานแบบ automation มาใช้มากขึ้น
• คุณกันบนพื้นฐานของข้อมูลและหลักฐาน มากกว่า gut feeling
• Fail fast และ Fail safe

จึงทำการแปลและสรุปไว้นิดหน่อย
มาดูว่ามีอะไรที่น่าสนใจบ้าง

1. Product-Based Teams Over Component Teams

บ่อยครั้งเราจะพบว่า ในการสร้าง product หนึ่ง ๆ นั้น
ต้องมีทีมจำนวนมาก มาพูดคุยกัน  ตกลงกัน วางแผนร่วมกัน
แต่ละทีมก็ไปทำงานของตนเอง
เมื่อถึงวันที่กำหนดก็นำมารวมกัน
งานบางอย่างต้องขอ approve
งานบางอย่างต้องรอใครบางคน
เยอะไปหมด !!!

ต้องเสียเวลาไปมากกับการทำงานรูปแบบนี้
และก่อให้เกิด drama ต่าง ๆ มากมาย
เรามักเรียกว่า เป้นการทำงานแบบ silo
หรือบางที่อาจจะเรียกว่า component team

แต่การทำงานตามแนวคิด DevOps นั้น

เพื่อแก้ไขปัญหานี้ ดังนั้นจึงแนะนำให้ทำงาน
ในรูปแบบ cross-functional team หรือ product-based team
นั่นคือในทีมจะมีคนที่มีความสามารถต่าง ๆ
ที่ช่วยให้ส่งมอบ product นั้น ๆ ได้
โดยลดปัญหาที่เกิดขึ้นจากรูปแบบที่อธิบายมาก่อนหน้า
แสดงดังรูป

ปล. มีอีก component team คือ DevOps team หรือเปล่านะ ?

2. Obsession With Automation Over Preoccupation With Manual Work

เป้าหมายหลัก ๆ ของ DevOps คือ การลดงานที่ทำซ้ำ ๆ หรือพวก manual process
ให้มาอยู่ในรูปแบบ automation ให้มากที่สุดเท่าที่จะทำได้
(แต่ manual ก็ยังมี)
เพื่อลดงานที่ต้องทำ
เพื่อลดปัญหาที่เกิดจากคน
เพื่อเพิ่มความเร็วในการทำงาน
เพื่อเพิ่มความสะดวกในการทำงาน
ส่งผลให้เราไปทำงานอื่น ๆ ได้มากขึ้น

ต้องเลือกเครื่องมือให้เหมาะกับงานนั้น ๆ ด้วย
ไม่ใช่นำเครื่องมือที่ทำงานแบบ automation มาตั้งก่อน !!

3. Evidence-Based Over Gut feel

หัวใจของ DevOps คือการวัดผลในทุก ๆ อย่าง ที่ทำลงไป และเกิดขึ้นมา
ต้องมีตัวเลขที่วัดผลได้เสมอ
ทั้งในเชิง business, service และ infrastructure
นั่นคือ การคิดและวางแผน ก่อนทำงาน
เพื่อนำข้อมูลเหล่านี้ มาช่วยในการตัดสินใจ
ไม่ใช่การตัดสินใจจากความรู้สึก ประสบการณ์ หรือ gut feeling !!

4. Teamwork Over Individual Work

แน่นอนว่า DevOps ต้องการการทำงานเป็นทีม
และต้องมี teamwork มากกว่า การทำงานคนเดียวหรือฉายเดี่ยว
ดังนั้นแต่ละคนต้องมีความเป็นมืออาชีพ และ มีความสามารถพอตัว

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

5. Fail Fast Over Delayed Learning

ความผิดพลาดเป็นส่วนหนึ่งของการเรียนรู้
ประเด็นคือ ใช้เวลาหลังจากสร้างนานเท่าไร กว่าจะรู้ว่ามัน work หรือ ไม่ work ?
ยิ่งใช้เวลานานเพียงใด นั่นคือปัญหา
ส่งผลให้แต่ละคนไม่อยากทำผิดพลาด !!

ดังนั้นสิ่งที่ต้องสร้างให้เกิดขึ้นคือ
ความผิดพลาดมันต้องเล็ก ส่งผลกระทบน้อย
นั่นคือ ทุก ๆ ครั้งที่มีการเปลี่ยนแปลงเกิดขึ้นมา
เราต้องรู้ได้ทันทีว่า มัน work หรือ ไม่ work นั่นเอง
หมายความว่า fail fast และ fail safe ด้วย

ไม่ใช่หาคนมานั่งจับผิดนะ !!
แต่มันคือการพยายามสร้าง feedback loop ที่มีประสิทธิภาพ
และเป็นอีกทางหนึ่งที่ automation process เข้ามามีบทบาทสำคัญ
แต่ถ้า automation มันเข้ามาแล้วทำให้เรารู้ผลช้าลง
ก็ไม่น่าจะทำถูกนะเออ !!

จากบทความเรื่อง Coding with Feature Flags: How-to Guide and Best Practices
ทำการอธิบายเกี่ยวกับ Feature Flag ว่าคืออะไร
เป็นอย่างไรบ้าง
มีปัญหาอะไรที่ต้องได้รับการแก้ไข
มีรูปแบบการใช้งานอย่างไรบ้าง
จึงทำการสรุปสิ่งที่น่าสนใจไว้นิดหน่อย
ลองไปอ่านเพิ่มเติมและนำไปใช้งานกันดู 

อาจจะเรียกชื่ออื่น ๆ ได้อีก เช่น Feature toggle, swiching on/off เป็นต้น

สิ่งที่น่าสนใจคือ เมื่อใดเราจึงต้องใช้ Feature flag ด้วย

เริ่มด้วยเรื่องของ branching กัน
ถ้าใครเคยใช้ branching ใน version control ต่าง ๆ 
ยกตัวอย่างเช่น CSV และ subversion
จะพบว่า การสร้าง branch ขึ้นมานั้น
ต้องคิดให้ดี ๆ  เพราะว่าใช้ resource เท่าตัวเสมอ
ทำให้จำนวน branch ไม่เยอะมากนัก
หรือบางที่อาจจะทำการจัดการและพัฒนาแบบ Trunk-based development
คือมี branch เดียวนั่นเอง

แต่เมื่อเกิด Git ขึ้นมาซึ่งทำให้การสร้าง branch มันง่ายและไม่ใช้ resource น้อย

จึงก่อให้เกิด branch จำนวนมากขึ้นมา
ทั้ง master
ทั้ง develop
ทั้ง release
ทั้ง fix
ทั้ง feature branch
ทั้ง experiment

เมื่อจำนวน branch เยอะขึ้น
เรื่องของการ merge จึงสำคัญขึ้นอย่างมาก
ต้องทำด้วยความระมัดระวัง
ยิ่งในทีมมีสมาชิกจำนวนมาก
แน่นอนว่า active branch ก็เยอะ ยิ่งต้องระวังให้มาก ๆ

ดังนั้นจึงมีการคิดและสร้างวิธีการมากมายเพื่อมาจัดการ

ยกตัวอย่างวิธีการที่ได้รับความนิยมคือ Git Flow
ซึ่งในการทำงานและจัดการ
ก็ยังต้องการการพุดคุย
เพื่อให้มันตรงกับความต้องการ
บางครั้งมันทำให้เกิดความปวดหัวในการจัดการอีกด้วย
ทั้งเรื่องข้อขัดแย้งที่เกิดจากการ merge
ทั้งเรื่องของการวางแผนในการแยก branch
ทั้งเรื่องของการสร้าง Continuous Integration มาเพื่อช่วยตรวจสอบสิ่งที่เปลี่ยนแปลง

แต่ปัญหาจริง ๆ ที่เราเห็นอาจจะไม่ใช่การแตก branch

ปัญหาที่แท้จริงคือ branch ที่สร้าง มีอายุนานเกินไป
ดังนั้น ถ้าอายุของ branch สั้น ๆ หรือ ไม่ต้องสร้าง branch ขึ้นมา
ก็ไม่น่าจะมีปัญหา หรือ มีปัญหาน้อยลงนะ
เพราะว่า เราทำงานกันบน branch เดียวกันไปเลย
หรือเราทำงานบน code ชุดเดียวกัน
ไม่น่ามีปัญหาเรื่องการ merge ใช่ไหม ?

ถ้ามีเพียง branch เดียว ปัญหาก็ตามมาอีก

• พัฒนา feature จำนวนมากพร้อมกัน แต่ release หรือ deploy ไม่พร้อมกัน การแตก branch ไปน่าจะดีกว่าไหม ?
• พัฒนา feature เพื่อทดลอง ถ้าไม่ work ก็จะได้ลบ code หรือ feature ทิ้งไปได้ง่าย ๆ

หนึ่งในวิธีการแก้ไขคือ Feature Flag นั่นเอง
เพื่อทำการแยกแต่ละ feature อย่างชัดเจน
สามารถกำหนดว่าจะเปิดหรือปิดแต่ละ feature ได้เลย
นั่นคือ เราสามารถ deploy code ที่ไม่เสร็จขึ้นได้ด้วย
แต่ feature นั้น ๆ ยังปิดอยู่
แต่เราต้องวางแผนกันก่อนนนะ มิเช่นนั้นเละแน่นอน

อีกหนึ่งที่สำคัญมาก ๆ ของ Feature Flag คือ

จำนวน feature flag ที่ทำการจัดการนั้นต้องไม่เยอะ
Feature อะไรที่มันขึ้นไปแล้ว ก็เอา feature flag ออกไปซะ
ใช้เท่าที่จำเป็นเท่านั้น
อะไรที่ไม่ใช้ก็ลบไปบ้าง
มิเช่นนั้น ก็จะเกิดความซับซ้อนยากต่อการจัดการ
เช่นเดียวกับ branch เยอะ ๆ อีกนั่นเอง

สำหรับ Cypress นั้นคือ End-to-End testing สำหรับ Fronted developer 
ซึ่งปกตินั้นจะทดสอบในระบบที่ run บน Google Chrome และ  Electron เท่านั้น
แต่ถ้าไปดูใน roadmap ของการพัฒนา feature ต่าง ๆ ของ Cypress
จะพบว่ามีเรื่อง Firefox support ด้วย
แน่นอนว่ามีทั้ง Issue#1096 และ. PR#1359 บอกไว้ด้วย

ถ้าใครใจร้อนก็ไปลองทดสอบกับเขากันได้เลยนะ
ไม่ยากเลยถ้าอ่าน comment ต่าง ๆ รู้เรื่องบ้าง
ก็สามารถลองทดสอบไปด้วยกับเขาเลย

วิธีการที่ง่ายที่สุดคือ 

ทำการติดตั้งแบบ Pre-release version นั่นเอง
หรือไปดูใน PR#1359 ก็ได้
เราสามารถทำการลอง run ตามได้เลย
แนะนำให้ดูใน comment ล่าสุด
จะเป็นการ run แบบอัตโนมัติ ซึ่ง run OS Linux นะ

ทำการกำหนด environment variable ชื่อว่า CYPRESS_INSTALL_BINARY
ของ cypress ใน version ที่กำลังทดสอบ
จากนั้นก็ทำการติดตั้ง 
ซึ่งถ้าเป็นชาว Linux ไม่น่ามีปัญหาอะไร
สามารถใช้งาน $cyprees run --browser firefox ได้เลย

แต่ถ้าไม่ได้ใช้ Linux ก็แนะนำให้ใช้งานผ่าน Docker ไปเลย
แน่นอนว่าทาง Cypress ก็ได้เตรียม Docker Image ไว้ให้ด้วย
แต่ต้องไป build เองนะ !!
สามารถทำการ clone ได้จาก Github::Cypress Docker Image
ใน branch Firefox-27

เมื่อทุกอย่างพร้อมก็เอามา run project เราได้เลย

ด้วยการสร้าง Dockerfile ดังนี้

จากนั้นก็ทำการ build ได้เลย
ผลการทำงานเป็นดังนี้

เท่าที่ทดลองก็ยังไม่ stable นะครับ
แต่ก็พอเห็นภาพว่าจะเป็นอย่างไร
ใครที่รอไม่ได้ ก็ลองนำมา build ใช้เองพลาง ๆ ไปก่อนครับ

ก่อนหน้านี้ในการดู image และ container
หรือการจัดการเรื่องต่าง ๆ กับ Docker Desktop
น่าจะใช้งานทั้งผ่าน command line และ User Interface
ซึ่ง User Interface นั้นก็คือ Kitematic

แต่ใน Docker Desktop 2.2.0 นั้นได้ปล่อย Dashboard ออกมา
แน่นอนว่าถูกยัดเข้าในเลย ไม่ต้องไป download แยกอีกแล้ว
ซึ่งมาแทนที่เลย 
ดังนั้นมาดูกันว่ามีความสามารถอะไรบ้าง ?

ดูใน menu ของ Docker Desktop จะเห็นเลย

ความสามารถก็เช่นเดียวกับ Kitematic
คือสามารถจัดการ container ต่าง ๆได้เลย
ทั้ง restart, stop และ delete
แถมดู container ต่าง ๆ แยกตามแต่ละกลุ่ม
หรือจาก docker compose ได้เลย
สะดวกใช้ได้เลย แสดงดังรูป

ในแต่ละ container ก็สามารถเข้าไปดู log, inspect และ stat ได้ดังรูป

ง่ายดีนะครับ ลองใช้กันดู

วันนี้ทำการเขียน RESTful API ด้วยภาษา Go
ซึ่งมีการใช้ข้อมูลร่วมกัน จัดเก็บในรูปแบบของ map
การทำงานนั้นเป็นปกติมาก ๆ
แต่เมื่อทำการลองยิง performance ดูหน่อยเท่านั้น
ก็เจอ Runtime error ดังนี้
fatal error: concurrent map read and map write

เริ่มจาก code ที่เป็นปัญหาดังนี้

ซึ่งใช้งานข้อมูลจากตัวแปรชนิด map

เป็น code ชุดที่เกิดปัญหานั่นเอง
ก็ลองไปหาต้นเหตุ ก็เจอว่า map นั้น
ไม่ปลอดภัยสำหรับการแก้ไขข้อมูลพร้อม ๆ กัน
แต่ถ้าอ่านอย่างเดียวไม่เป็นไร

การแก้ไขปัญหานี้แบบง่าย ๆ คือ

ถ้าทำการแก้ไขพร้อม ๆ กัน
ดังนั้นก็ lock/unlock หรือ Mutex กันไปเลย
สามารถแก้ไขปัญหาได้ แต่แลกมาด้วยความเร็วที่ช้าลง
แต่เป็นวิธีการที่ง่ายนะ เขียน code ได้ดังนี้ 
เพิ่มนิดเดียว

หรืออาจจะนำ go channel เข้ามาใช้เพื่อแก้ไขปัญหานี้ก็ได้นะ

ซึ่งก็เพิ่มความซับซ้อนขึ้นมาอีกหน่อย ดังนี้

หรืออาจจะใช้ sync map ที่ทาง Go ได้เตรียมมาให้

ก็สามารถแก้ไขปัญหาได้เช่นกัน

ทั้งสามวิธีสามารถแก้ไขปัญหาได้

มาดูผลการทดสอบ performance ทั้งสองกันบ้าง

ขอให้สนุกกับการเขียน code นะครับ

ว่าง ๆ นั่งดู extension ที่น่าสนใจบน VS Code
ก็ไปเจอตัวนึงที่น่าสุดใจคือ Code :: Stat
ซึ่งเอาไว้ใช้สำหรับการดูสถิติการเขียน code ของเรานั่นเอง
แน่นอนว่า มันมีระบบกลางเก็บให้ แถมมี graph สรุปให้อีกด้วย
สำหรับนักพัฒนาที่ชอบดูสถิติ น่าจะชอบเป็นอย่างมาก

ลองใช้งานกันดูครับ ใช้งานง่าย ๆ

เพียงไปสมัครสมาชิกที่ Code Stat
เพื่อไปสร้าง API Key เอามาใส่ใน VS Code
จากนั้นก็ใช้งานกันเลย

ระบบงานี่พัฒนาด้วย OpenFaaS นั้น
ในการ build และ deploy จะสร้าง container image ในรูปแบบของ OCI
นั่นทำให้เราสามารถ deploy ระบบได้หลากหลายวิธี
ยกตัวอย่างเช่น

• Docker
• Docker + Buildkit
• Buildkit standalone
• Img
• Pouch
• Podman
• Buildah
• K3s
• Kanico

เยอะไปไหนนะ ?
แต่เรามาลอง deploy ด้วยบางตัวกันนิดหน่อย

เริ่มด้วยวิธีมาตรฐานคือใช้ Docker + Dockerfile

ซึ่งผมใช้ middleware template ของภาษา Go

โดยไฟล์หลัก ๆ ที่ generate ขึ้นมาที่น่าสนใจคือ ไฟล์ /first/Dockerfile

การ build และ deploy ของ OpenFass นั้น
ก็ต้องใช้งาน Docker นั่นเอง
มาทำการ build และ run นิดหน่อยดังนี้

เท่านี้ก็ใช้งานได้แล้ว

มาลอง Deploy ด้วย Docker + Buildkit

แน่นอนว่าทำได้ แต่เราทำไปทำไม ?
มันมีข้อดีอะไรบ้าง ?
ครั้งแรกจะนานพอสมควร
แต่ว่าระบบ caching ดีมาก ๆ เร็วกว่าแบบปกติมาก ๆ ระบบ caching ดีมาก ๆ
ชอบเลย
ทำการ enable buildit ขึ้นมาได้ดังนี้

หรือลองใช้ Buildkit แบบ standalone ก็ได้

ซึ่งใช้ได้บน Linux เท่านั้น

จะได้ container image ที่เราสามารถนำไปสร้าง container ได้ต่อไป
จากที่ลองมาหลาย ๆ วิธี
เราจะได้เห็นรูปแบบที่หลากหลาย
และน่าสนใจมาก ๆ ลองเล่นกันดูครับ มันสนุกมาก ๆ

ตัวอย่าง code อยู่ที่นี่ GitHub::Up1