Technology

เป็นเรื่องที่เกี่ยวกับสายงานที่ทำ ใครหลุดเข้ามาอ่าน อาจจะงงงวย

4 วิธีจัดการ Versioning และ Environment ของ AWS Lambda Function โดยไม่ต้องแก้ไขโค้ด

เป็นเรื่องสำคัญที่เรามักมองข้ามไป ว่าจะจัดการ Lambda Function อย่างไรให้ใช้ได้กับ Environment ต่างๆ เช่น Development, UAT, Production และต้องไม่กระทบกับการใช้งานของผู้ใช้ด้วย ดังนั้น สิ่งที่ต้องดูต่อ คือ เราต้องกำหนด Lambda Function Version ให้แต่ละ Environment ด้วยใช่หรือไม่?

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

Continue reading “4 วิธีจัดการ Versioning และ Environment ของ AWS Lambda Function โดยไม่ต้องแก้ไขโค้ด” »

ทดสอบ .NET AWS Lambda ด้วย AWS .NET Mock Lambda Test Tool

ปัญหาหลักของของเขียน Serverless ต่างๆ คือจะทดสอบโค้ดตัวเองอย่างไร ไม่ให้เสียเงินค่า Compute และ Request ตลอดเวลา ยิ่งถ้าโค้ดนั้นไม่มี Unit Test แล้ว ยิ่งยาก เพราะเราไม่สามารถจำลอง Serverless Runtime ได้เอง

ตัว AWS Lambda เอง เลยออกเครื่องมือตัวหนึ่งสำหรับชาว .Net ชื่อว่า AWS .NET Mock Lambda Test Tool เป็นเครื่องมือที่ช่วยให้นักพัฒนาสามารถทดสอบ Business Logic ของโค้ดตัวเองได้ง่ายๆ ไม่โดนคิดเงิน และคล้ายกับที่ทำงานบน AWS ด้วย

Continue reading “ทดสอบ .NET AWS Lambda ด้วย AWS .NET Mock Lambda Test Tool” »

วิธีง่ายๆ สำหรับทำ AWS Lambda Layers ที่เป็น C# .Net Core

ใน Best Practices ของการทำ AWS Lambda Function มีอยู่ข้อหนึ่งที่บอกว่า “Control the dependencies in your function’s deployment package.” คือ แนะนำให้เราควบคุมและจัดการกับ Library ที่ Funtion ของเราต้องใช้งาน

Continue reading “วิธีง่ายๆ สำหรับทำ AWS Lambda Layers ที่เป็น C# .Net Core” »

มาลอง Code Coverage บน .Net Core 2+ ด้วย coverlet

ใครที่เขียนโค้ดด้วย .Net Core 2+ และทำ CI/CD บน Linux ค่อนข้างยุ่งยากหน่อย เพราะหาเครื่องมือสำหรับตรวจสอบ Code Coverage ฟรีๆ ดีๆ ได้น้อยเหลือเกิน ที่ผมเคยใช้ดีๆ ก็มี minicover จนเพิ่งมาลองเล่นอีกตัว ชื่อ coverlet ใช้งานได้ง่ายกว่าเยอะมาก เพราะมันทำงานร่วมกับ MSTest ได้เลย

Continue reading “มาลอง Code Coverage บน .Net Core 2+ ด้วย coverlet” »

อยากทำ The Twelve Factors จะเริ่มต้นอย่างไรดี และต้องเรียนรู้อะไรบ้าง

มาเพิ่มเติมจากบล็อกที่แล้วที่ผมได้เขียน “สรุปแนวคิด THE TWELVE FACTORS ในภาพเดียวจบ” เพื่อให้เห็นภาพได้ชัดเจนขึ้นว่า ถ้าต้องการทำ The Twelve Factors เราต้องเรียนรู้อะไรบ้าง

บล็อกเก่าผมวาดด้วยมืออาจจะอ่านไม่ค่อยออก บล็อกนี้เลยขอทำจากโปรแกรมแทน น่าจะดูดีขึ้น ฮ่าๆ

1. ขึงด้วยภาพ System Architecture เดิมๆ ของคุณ

ถ้าลองเอาภาพโครงสร้าง System Architecture มากางดู น่าจะคล้ายๆภาพนี้ ซึ่งผมขอแนะนำให้คุณลองประกอบภาพให้เป็นแบบ End to End หมายความว่า ตั้งแต่ Developer เขียนโค้ดเสร็จ ยาวไปจนถึง ขึ้น Production Environment และมีลูกค้าเข้ามาใช้งาน

เพราะอะไร ทำไมต้อง End to End? เพราะบางทีภาพของ System Architecture มันทับซ้อนกับ Network Architecture อยู่ และมักมีเพียงการเชื่อมโยงของ Server ว่าอะไรเชื่อมต่ออย่างไร แต่ไม่มีส่วนไหนไปเชื่อมโยงกับ Development Process, Support Process เลย แล้วจะรู้ได้อย่างไรว่า Source Code จะมาถูก Build และ Deployment เข้าสู่ Environment มันมีที่มาที่ไปอย่างไร

ถ้าบอกว่าองค์กรเราอยากเป็น DevOps ภาพพวกนี้ควรต้องมีอย่างแรกเลย และ Development Team กับ Infrastructure Team ต้องทำงานร่วมกันอย่างดูดดื่มด้วยนะ


ภาพจาก http://www.myifew.com (ผมวาดเอง ไม่แปะเครดิตให้รก แต่ถ้าเอาไปใช้ หรือลอกต่อ รบกวนใส่อ้างอิงด้วยนะ)

2. เชื่อมต่อกับ The Twelve Factor ในแต่ละข้อ

เมื่อได้ภาพ System Architecture ทั้งหมด ให้ลองไปทำความเข้าใจเรื่องของ The Twelve Factor และลองพิจารณาดูว่า ข้อไหน ควรต้องไป Implement ในตำแหน่งไหนบ้าง, หรือกำหนดว่าภาพสุดท้ายที่เราต้องการ ควรเป็นแบบไหน

ภาพจาก http://www.myifew.com (ผมวาดเอง ไม่แปะเครดิตให้รก แต่ถ้าเอาไปใช้ หรือลอกต่อ รบกวนใส่อ้างอิงด้วยนะ)

3. ระบุ Practices ที่จะทำให้เกิดผลลัพธ์

ขั้นตอนสุดท้าย น่าจะยากที่สุด และเจ็บปวดที่สุดแล้วหละครับ

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

ซึ่งก็นับว่าโชคดีนิดหนึ่งที่เว็บต้นฉบับอย่าง 12factors.net ได้พูดถึง Practices และเครื่องมือที่จะทำให้ได้ในแต่ละข้อได้บ้างแล้ว อย่างเช่น เรื่องของ Codebase

ภาพจาก https://12factor.net/codebase

ในหน้าที่อธิบาย Codebase มีการอธิบายอยู่สามแบบที่ผมตีกรอบไว้

กรอบสีแดง: บอกไว้ชัดๆเลยว่า ใช้เครื่องมืออะไร, แต่! เครื่องมือแต่ละตัวมันมี Practices ประกอบการใช้อยู่นะ เช่น ใช้ Git จะใช้ให้ดี คุณควรต้องรู้เรื่องการจัดการ Branch ต่างๆ (Branch Strategy)

กรอบสีน้ำเงิน: กล่าวถึงหัวข้อที่เกี่ยวข้องใน The Twelve Factors และ/หรือ หัวข้อ Practices อื่นๆ ที่คุณสามารถเอาชื่อพวกนี้ไปค้นคว้าต่อได้ เช่น  Dependency Management คืออะไร ทำอย่างไร ใช้เครื่องมืออะไร

กรอบสีเขียว: อันนี้ต้องตีความให้ออกว่าเป้าหมายคืออะไร อย่างในตัวอย่าง คือใช้ Source Code ที่โปรแกรมเมอร์ทุกคนทำเสร็จพร้อมรวมโค้ดกันเรียบร้อยแล้ว และต้องอยู่บนที่ที่เดียวกัน (Single Repository) และโค้ดนั้นต้องพร้อม Deploy ไปหลายๆ Environment ได้ด้วย… เออ นั่นหละครับ ปัญหาคือ โค้ดโปรแกรมเมอร์รวมกันแล้วมันทำงานได้ไหม? ต้องทดสอบก่อนไหม? ทดสอบอย่างไร? แล้ว config ที่ถูกตั้งไว้ของโปรแกรมเมอร์แต่ละเครื่องไม่เหมือนกันทำอย่างไร? แล้ว config ของแต่ละ Envinronment ก็ไม่เหมือนกันด้วย จะทำอย่างไร? …

ภาพด้านล่างเป็นตัวอย่าง Practices ที่ผมลองเชื่อมโยงให้เข้ากับ The Twelve Factors และถูกใช้งานจริงกับบริษัทลูกค้า, ลองเอาไปพิจารณาดูครับ

 

ภาพจาก http://www.myifew.com (ผมวาดเอง ไม่แปะเครดิตให้รก แต่ถ้าเอาไปใช้ หรือลอกต่อ รบกวนใส่อ้างอิงด้วยนะ)

สุดท้ายยังเหลืออีกข้อที่ผมค้างอยู่ ที่บอกว่าเจ็บปวดที่สุด และก็ท้าทายที่สุด คือ

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

ขอให้โชคดี มีชัย อ่านบล็อกนี้แล้ว นอนหลับฝันดี…