การพัฒนา Cloud Native App สำหรับ Developer บน Sovereign Cloud

• Facebook
• Twitter
• Line

หลังจากที่เราทำความรู้จักกับ Sovereign Cloud เป็นที่เรียบร้อยแล้วทีนี้เรามาเริ่มแนะนำเครื่องมือ Dev ที่ Support บนนั้นกันบ้าง จริง ๆ ถ้าขึ้นชื่อว่า Cloud Native ไม่ว่าจะเป็น Public, Private, หรือ Sovereign จะใช้เครื่องมือในมุมของ Dev ที่คล้าย ๆ กัน จะมีข้อได้เปรียบกันบ้างบางจุดเช่น Sovereign Cloud จะลดโอกาสโดนกักอยู่ใน Platform ใด Platform หนึ่ง (Vendor Lock-in) เพราะ Tool ต่าง ๆ ที่ใช้ส่วนใหญ่จะเป็น Open Source แทบทั้งหมด วันนี้ผมจะมาแนะนำและปรับมุมมองจาก Software แบบเก่ามาเป็น Cloud Native กันมากขึ้นนะครับ 
 

ยกตัวอย่างให้เห็นภาพมากขึ้น 

บทความนี้ขออธิบาย Style Dev แบบถึงพริกถึงขิงละกันนะ จริง ๆ Cloud native โลกมันกว้างมาก เอาแค่เริ่มต้นกันก่อนพอให้เห็นภาพนะครับ ขอยกตัวอย่าง PHP เพราะเจ้า PHP เนี่ยมันอยู่คู่กับ Dev มาช้านาน เชื่อว่า Dev ส่วนใหญ่ภาษานี้คงผ่านมือกันมาพอสมควร แต่ก่อนอื่นขอ Recap Concept ของ Cloud Native สั้น ๆ โดยการจะเรียกว่า Cloud Native ได้ ต้องมีคุณสมบัติดังต่อไปนี้ (จำให้ขึ้นใจนะ) 

• Scalability ระบบต้องทำงานได้เสมอไม่ว่าคนจะใช้มากขึ้นหรือน้อยลง โดยไม่ต้องมาแก้ระบบเดิมที่ทำงานอยู่ 
• Loosely Coupled แต่ละบริการต้องอิสระต่อกันมากที่สุดหรือผูกกันมากที่สุด 
• Resilient ระบบต้องทนทานต่อการ Fail หรือถ้า Fail ต้อง Fail ที่เดียวไม่ใช่ทั้งหมดและกู้คืนขึ้นมาได้เร็วที่สุด 
• Manageable ง่ายต่อการเปลี่ยนแปลง Change, Reconfigure, และ Upgrade ได้ 
• Observable สามารถมองเห็นการทำงานทุกส่วนได้ง่าย ตรวจสอบข้อผิดพลาดส่วนต่าง ๆ ได้ทันที 

Source Code จาก Local สู่ GIT Server 

เริ่มต้นจากเวลาเราเขียน PHP เสร็จ Source Code ของเราต้องอยู่ในเครื่องเราอันดับแรก ทีนี้ถ้ามัน Dev หลายคนต้องทำอย่างไร? คำตอบง่าย ๆ คือ GIT Server ซึ่งเราใช้ GIT Server มาบริหารจัดการ ทั้งการกันการชนกันของ Code ทั้ง Version Control และดูแลสิ่งต่าง ๆ ก่อนที่ระบบของเราจะโดน Deploy ขึ้นไป ซึ่งการใช้ GIT นอกจากจะเป็นศูนย์รวมของ Source Code เรายังสามารถใส่ความสามารถต่าง ๆ ที่พึงมีลงไปใน GIT Server ได้ด้วย ถือเป็นหัวใจดวงแรกของ Cloud Native กันเลยหละ 

Deployment จาก FTP สู่ CI/CD  

เมื่อก่อนเวลาเรา Code เสร็จเราจะใช้เครื่องมือคู่ใจอย่าง FTP ในการเอา File ไปวางบน Server ใช่ไหมครับแค่นั้นก็จบปิ้ง !!!! แต่เดี๋ยวก่อน ถ้าคุณแก้และเทสมาก ๆ  ในเครื่อง แล้วคุณต้องมานั่งจำใช่ไหมว่าคุณแก้ File อะไรไปบ้างและในการเอาขึ้นแต่ละครั้งเนี่ย ถ้าอัปเองบ่อยครั้งที่อัปไม่ครบหรืออัปผิด แล้วเห้ย นี่มัน Production นะจะเอาขึ้นแบบผิดพลาดได้อย่างไร? ตัวช่วยในกระบวนการนี้และถือเป็นพระเอกหนึ่งในหัวใจของ Cloud native เลยนั่นคือ CI/CD ครับ โดย CI/CD ของ GIT เองก็มีแล้วแต่เจ้าที่ใช้หรือจะใช้แบรนด์ดังอย่างพวก JENKIN ก็ไม่มีปัญหา โดยเราใช้กระบวนการฝั่ง CD ในการเขียน Script ช่วย Deploy จาก GIT ได้ทันที เพราะเวลาเราอัป Code ขึ้น Git ตัว Git เองรู้อยู่แล้วว่า File ไหน Change หรือ File ไหนโดนแก้ไข และยังสามารถเรียกคืน Version ต่าง ๆ ได้ทันทีกับทุก Version ทำให้อุ่นใจไปได้อีก (Resilient) (Manageable) และด้วยความที่มันเป็น ROBOT ตัวนึงประเด็นความผิดพลาดจากการทำงานด้วยมือจึงน้อยลงมากอีกด้วย 

จาก Unit Test สู่ Continuous Integration 

ถ้ายกตัวอย่าง PHP ปกติเวลาเราทำ Test Script เราก็จะทำให้ใช้คนเดียว แต่ถ้าคนทำเยอะขึ้น Test Script ก็จะมีความสลับซับซ้อนมากขึ้น ครั้นจะไปรันคนเดียวมันก็ทำได้ แต่จะเสียเวลา ซึ่งจะดีกว่าไหมที่ Commit Code หลังเลิกงานแล้วปล่อยให้ ROBOT (ตัวเดียวกับข้างบน) ช่วยเราทดสอบทั้งหมด ทั้งของเราและของคนอื่นด้วย นี่เป็นที่มาของ Part CI ในส่วน CI/CD ซึ่ง CI ย่อมาจาก Continuous Integration เป็นกระบวนการนำ Source Code ไปใช้ต่อ ไม่ว่าจะเป็นการ Build และ Test Check ความเข้ากันได้ ซึ่งที่พีคคือสมัยนี้ Check ไปถึง Code Quality (มี Software Check การเขียนของเราว่า Optimal ไหม) และ Security Check ได้อีกด้วย !!! เราสามารถใส่สิ่งที่ต้องการทำกับ Code ในขั้นตอนนี้ได้เลย และด้วยความเป็น Script ทำให้ไม่ต้องมานั่งรอคนมาช่วย Review ทุกครั้ง ปัญหาบางอย่างจะสามารถถูกค้นพบได้ในขั้นตอนนี้เลย 

จาก Webserver สู่ Container 

สามหัวข้อด้านบนคือการเตรียมการจากระบบเดิมเข้าสู่โลกใหม่ หัวข้อนี้จะเริ่มต้นจากเอา PHP Webserver ที่ Deploy จาก Webserver แบบเดิมที่ลงบน Linux หรือ ลงบน Windows Server มารันบนสถาปัตยกรรม Container ซึ่งข้อดีในการทำแบบนี้มีหลายประการมาก 

1. สืบเนื่องจากภาษาแต่ละภาษาจะมีกระบวนการเตรียม LIB ที่ใช้ไม่เหมือนกัน ยกตัวอย่าง PHP Stack ที่เราใช้ก็จะต้องลง APACHE, PHP, SQL ซึ่งในกรณีของ PHP ต้องลง PHP Version เดียวกันด้วย ซึ่งเป็นเรื่องยากมากที่ Dev จะต้องเตรียมเครื่องของตัวเองให้รองรับ Lib บน Server ที่มีความหลากหลายสูง นั่นคือ Pain Point ที่ทำให้เกิด Concept Container ในยุคแรก ๆ ก่อนที่จะมีข้อดีอื่น ๆ ตามมาและกลายเป็น Cloud Native อย่างปัจจุบัน เราจะ Pack รวม Software ที่ใช้ทุกอย่างลง Container ของเรา แล้วจับมา Run ได้ทั้งตอน Dev ตอน Test รวมถึงตอน Deploy ด้วย 

2. ด้วยความที่มันมัดรวมใน Container ทำให้เราแปะ Version ได้ง่าย ซึ่งการแปะ Version นี้ไม่ได้แปะแค่ Source Code เท่านั้นแต่แปะไปถึง Version ของ Runtime และ Software ที่เป็น LIB อยู่ภายในทำให้เราสามารถ Upgrade LIB ตัวไหนก็ได้ภายในเพราะมันสามารถ Change หรือ Revert ได้ทั้ง Runtime เลย รวมถึง Version ของ PHP ด้วย !!!! 

3. ในเมื่อมันมี Runtime ข้างในด้วย เราก็สามารถรัน Docker ตัวนี้กี่ครั้งพร้อมกันก็ได้ !!!! ใช่แล้วครับ มันสามารถแยกตัวมันเองออกมาย่อย ๆ กี่ตัวก็ได้ (Scalability) 

4. ในเมื่อรันพร้อมกันกี่ตัวก็ได้ เวลาล่ม มันก็ยังมีตัวสำรองมารองรับได้ทันที (Resilient) 

จาก Services to Microservice 

จริง ๆ หลังจาก Container ก็มีสิ่งที่ต้องเตรียมอีกพอสมควร แต่ผมอยากให้เรากลับมามองวิธีการวาง Structure ของ Software เราร่วมด้วย สมัยก่อนเวลาเขียน Webservice ซักตัว เราก็จะแบ่งเป็น Module ย่อย ๆ ข้างในใช่ไหมครับเช่น สมาชิก ระบบบริการจัดการข่าว กระดานข่าว ระบบการจัดการคลังสินค้า ในมุมมอง PHP สิ่งเหล่านี้สามารถเขียนรวมไว้ที่เดียวได้ไม่ยากนัก แต่เวลาผ่านไปเราเรียนรู้ว่ากระดานข่าว อาจมีการใช้งานหนักกว่าหน้าจัดการข้อมูลหรือหน้าจัดการคลังสินค้าอาจมีการใช้เยอะมากจน Module อื่นทำงานไม่ได้ 

Microservice จึงอุบัติขึ้น !!!! 

จากข้อก่อนหน้านี้ที่เราสามารถ Pack อะไรก็ได้ลงไปบน Container งั้นเราก็ Pack บางส่วนของ Service ใส่ลงไปแยกกันก็ได้ แต่มีข้อแม้คือ State Control เราต้องทำ Stateless หรือไม่ก็ต้องหาตัวกลางพวก Redist มาช่วยเก็บ State แทนเพราะ Service ต่าง ๆ แยกจากกันไม่ได้ด้วยเมื่ออยู่บน PHP_SESSION เดียวกันแล้ว แต่ข้อดีคือถ้าส่วนไหนทำงานหนักมากจนล่มเราสามารถ Restart Service ตัวนั้นออกมาแค่ส่วนเดียวไม่มีผลกระทบต่อหน้าอื่น ๆ เลย (Resilient) และข้อดีอีกอย่างคือเราสามารถ Monitor หรือ LOG ในระดับ Container ได้โดยไม่จำเป็นต้องใส่ Code พิเศษใด ๆ เพิ่มเติมใน Code มากเกินความจำเป็น 

หวังว่าทุกท่านจะเข้าใจกลไกกันได้มากขึ้นนะครับ โดยท่านที่สนใจบริการของ Cloud HM เราพร้อมให้บริการตั้งแต่ Sovereign Cloud บนเทคโนโลยีของ VMware รวมถึง VMware Tanzu ที่ตอบโจทย์การทำ Cloud Native Application โดยเฉพาะด้วยบริการมากมายตั้งแต่  Application Platform และ Kubernetes โดยเป็น Platform มาตรฐานที่ใช้ในหลายประเทศ มีความเสถียรและปลอดภัยสูง สามารถติดต่อเราได้ผ่านช่องทางนี้เลยนะครับ ขอบคุณครับ 

— Cloud HM