• Facebook
• Twitter
• Line

ในช่วงไม่กี่ปีที่ผ่านมา “Cloud Computing” ได้กลายเป็นหัวใจสำคัญของการทำธุรกิจแทบทุกด้าน ไม่ว่าจะเป็นสตาร์ทอัปเล็ก ๆ ไปจนถึงองค์กรขนาดใหญ่ ต่างก็ต้องการความสามารในการทำระบบที่รองรับการสเกลกันทั้งนั้น ซึ่งระบบคลาวด์นอกจากจะตอบโจทย์เรื่องการสเกลแล้ว ยังช่วยเรื่องของการลดค่าใช้จ่ายที่ไม่จำเป็นในการดูแลรักษา Infrastructure ของระบบอีกด้วย

อย่างไรก็ตามเมื่อธุรกิจเติบโตอย่างรวดเร็วแล้ว ก็มักจะมีความท้าทายที่เพิ่มขึ้นมาด้วย ไม่ว่าจะเป็นเรื่องของการจัดการกับข้อมูลมหาศาล (Big Data) หรือการที่เราต้องปรับแอป ปรับปรุงระบบ ปรับกลยุทธ์ต่าง ๆ เพื่อให้ตอบสนองกับความต้องการของลูกค้าได้อย่างทันท่วงที 

ซึ่งหลายคนอาจเคยได้ยินบ่อย ๆ ว่า “ระบบของเราถูกย้ายขึ้น Cloud แล้วนะ!” แต่ก็อาจยังไม่แน่ใจว่ามันคืออะไร  ต้องปรับโครงสร้างระบบอย่างไร หรือมีข้อดีข้อเสียอะไรบ้าง ในบทความนี้ เราจะพาทุกคนไปรู้จักกับ คำว่า Cloud-based กับ Cloud Native แบบเข้าใจง่าย ๆ สุด ๆ ว่ามันแตกต่างกันยังไง? พร้อมชวนมาหาโอกาสใหม่ ที่เราสามารถหยิบจับเลือกใช้ Cloud Native โดยเฉพาะผ่านโซลูชันยอดฮิตจากผู้ให้บริการระดับโลกจาก AWS (Amazon Web Services)

 

Cloud-based คืออะไร?

โดยเราจะมาเริ่มกันที่คำว่า “Cloud-based” ก่อนแล้วกันนะครับ สำหรับคำนี้ถ้าพูดให้เข้าใจกันง่าย ๆ ก็คือการที่ระบบหรือแอปพลิเคชันของเราถูก “ย้าย” ขึ้นไปทำงานบน Cloud แทนที่จะติดตั้งและรันบนเซิร์ฟเวอร์ในองค์กร (On-premises) อย่างเดียว ซึ่งแนวทางนี้อาจเริ่มต้นด้วยการย้ายงานบางส่วนขึ้นไปบนคลาวด์ของผู้ให้บริการก่อน อย่างเช่น AWS, Microsoft Azure หรือ Google Cloud Platform โดยหากเป็น Cloud-based ส่วนใหญ่จะไม่ได้มีการปรับเปลี่ยนโครงสร้างหรือ Architecture ของแอปไปมากนัก ของเดิมเป็นยังไง ก็ย้ายไปทั้งก้อน 

ตัวอย่าง Cloud-based แบบง่าย ๆ

ให้เรานึกถึงองค์กรที่เคยติดตั้งซอฟต์แวร์ ยกตัวอย่างเป็น CRM ระบบนี้รันอยู่บนเซิร์ฟเวอร์ในออฟฟิศ เมื่อมีคนใช้เยอะขึ้นเซิร์ฟเวอร์ทำงานหนัก เราก็มองหาโซลูชันที่สามารถสเกลได้ การใช้คลาวด์เลยเป็นคำตอบ สมมติว่าเราอยากย้ายไปทั้งก้อน เหมือนไปเช่าเครื่องบนคลาวด์ เราก็สามารถเลือกบริการที่เอาไว้สร้าง Virtual Machine โดยถ้าเราใช้เป็นของ AWS ก็สามารถเลือกใช้เป็น Amazon EC2 (Elastic Compute Cloud) ได้ โดยส่วนใหญ่แอปที่นิยมทำลักษณะนี้จะเป็นการ “ย้าย” ระบบขึ้นไป แต่ยังคงสถาปัตยกรรม (Architecture) แบบเดิม แต่เปลี่ยน “ที่ตั้ง” ของเซิร์ฟเวอร์เท่านั้น

อีกตัวอย่างหากธุรกิจของเราอยากย้ายแค่ฐานข้อมูลจากในเซิร์ฟเวอร์ในองค์กรขึ้นไปใช้เป็น Amazon RDS แทนการดูแลเซิร์ฟเวอร์ Database ในออฟฟิศก็ได้เช่นกัน แบบนี้ก็จะเป็นการลดค่าใช้จ่ายด้านฮาร์ดแวร์และค่าไฟ รวมถึงได้ประโยชน์จากความเสถียรและการ Scale อัตโนมัติบน Cloud อีกด้วย 

 

สรุปแล้ว Cloud-based ก็คือการนำระบบที่เคยอยู่ในรูปแบบ On-premises ขึ้นไปรันบนสภาพแวดล้อมของ Cloud เพื่อให้เราได้ใช้ความสามารถของคลาวด์ ความสะดวกในการสเกล ลดภาระการดูแล Infrastructure เอง แต่ไม่ได้เปลี่ยนแปลงการออกแบบหรือโครงสร้างของแอปนั่นเอง 

 

Cloud Native คืออะไร?

ต่อมาเรามาดูกับแนวคิดที่ก้าวไปไกลกว่าแค่การ “ย้าย” ขึ้นคลาวด์เฉย ๆ กันดีกว่าครับ กับคำว่า “Cloud Native” โดยแนวคิดนี้เราจะมีเป้าหมายหลักของคือการออกแบบและพัฒนาแอปพลิเคชันให้สามารถใช้ประโยชน์จากคลาวด์ได้สูงสุด เรียกว่าออกแบบแอปมาเพื่อใช้บนคลาวด์โดยเฉพาะ โดยส่วนใหญ่แล้วทำแอปเพื่อรองรับ Cloud Native จะมีการปรับกระบวนการออกแบบสถาปัตยกรรม ให้สอดรับกับคุณสมบัติของคลาวด์ เช่น เรื่องของความยืดหยุ่น (Elasticity), การขยายตัว (Scalability), การปรับทรัพยากรแบบอัตโนมัติ (Auto Scaling) และการใช้บริการรูปแบบ Microservices หรือ Serverless เป็นหลัก

ตัวอย่าง Cloud Native แบบชัด ๆ

อย่างเช่นเรามีทีมพัฒนาซอฟต์แวร์ที่ออกแบบแอปแบบ Microservices เราก็ต้องมีการแยกให้เป็น Service เล็ก ๆ ทำการแพ็คแต่ละ Service เป็น Containers เพื่อให้มั่นใจได้ว่าแอปเราจะรันได้ในทุก ๆ สภาพแวดล้อมแบบไม่มีปัญหาหรือจะใช้สถาปัตกรรมในรูปแบบ Serverless ที่ชื่อเหมือนไม่มีเซิร์ฟเวอร์ แต่จริง ๆ แล้วเป็นการที่เราแตกแอปออกเป็นฟังก์ชันเล็ก ๆ มีหน้าที่เฉพาะตัว แล้วก็ทำการ Deploy ฟังก์ชันเหล่านี้ไปยังคลาวด์ผู้ให้บริการ ซึ่งการใช้งานบริการรูปแบบ Serverless อย่างบน AWS Lambda การคิดค่าบริการก็จะคิดตามจำนวนการใช้งาน ใช้มากจ่ายมาก (เว็บฮอต ลูกค้าเยอะ) ใช้น้อยจ่ายน้อย ไม่โดนใช้เลยก็ไม่ต้องจ่าย ส่วนเรื่องของการสเกลแทบจะไม่ต้องห่วงเลย เพราะการใช้งานในรูปแบบ Cloud Native ออกแบบมาเพื่อให้เหมาะสำหรับการสเกลแบบอัตโนมัติอยู่แล้ว 

จากที่เราพอจะรู้จัก Cloud Native ไปแล้ว เดี๋ยวผมจะพามาดูความสำเร็จ จากเว็บชื่อดังที่ไม่ว่าใครก็รู้จักอย่าง Netflix ที่เค้านำแนวคิด Cloud Native มาประยุกต์ใช้กับระบบของตัวเองอย่างมีประสิทธิภาพ โดยเฉพาะผ่านการใช้ AWS Lambda ซึ่งเป็นบริการ Serverless ยอดฮิตจาก AWS

อย่างในช่วง COVID-19 ที่พวกเราต้องต้องกักตัวอยู่บ้าน ไม่สามารถออกไปไหนได้ ช่วงเวลานั้นเป็นช่วงที่ทำให้ปริมาณการใช้งาน Netflix เพิ่มขึ้นอย่างมหาศาล แน่นอนทาง Netflix ก็ต้องรับมือกับปริมาณ Request ปริมาณข้อมูลที่เข้ามาอย่างท่วมท้น การใช้ AWS Lambda ช่วยให้ Netflix สามารถจัดการกับความต้องการนี้ได้อย่างยืดหยุ่น โดยเฉพาะงานด้านการประมวลผลข้อมูลขนาดใหญ่ (Big Data) การเข้ารหัสไฟล์สื่อ (Media Encoding) รวมถึงการตรวจสอบความถูกต้องของไฟล์ (File Validation) และการติดตามดูแลให้ระบบทุกส่วนทำงานได้ตามที่กำหนดไว้

ด้วยแนวทาง Cloud Native และ Serverless ที่ Netflix เลือกใช้ ทำให้บริษัทสามารถตอบสนองความต้องการของลูกค้าได้อย่างรวดเร็วและมีประสิทธิภาพ สร้างประสบการณ์การใช้งานที่ดีขึ้น และยังช่วยประหยัดค่าใช้จ่ายในการบริหารจัดการ Infrastructure แบบเดิม ๆ ได้เป็นอย่างดีอีกด้วย ซึ่งทั้งหมดนี้ผมสรุปเป็นตารางเปรียบเทียบความแตกต่างของทั้งคู่ให้เข้าใจง่าย ตามตารางด้านล่างนะครับ

ตารางเปรียบเทียบ Cloud-based vs. Cloud Native 

นอกจากเคสของ Netflix ที่ใช้ AWS Lambda แล้วหากธุรกิจของเราต้องการความคล่องตัวเพื่อตอบสนองลูกค้าให้เร็ว Cloud Native ก็จะทำให้ทีม DevOps สามารถปรับปรุง เปลี่ยนแปลง หรืออัปเดตโค้ดได้อย่างรวดเร็ว โดยใช้วิธีการที่เรียกว่า Continuous Integration/Continuous Delivery (CI/CD) และการทดสอบแบบอัตโนมัติ (Automated Testing) ทำให้เราสามารถสร้างฟีเจอร์ใหม่ ๆ ออกสู่ตลาดได้ไวมากยิ่งขึ้น (Time to Market) 

อย่างเช่นหากเราทำสตาร์ทอัปที่กำลังทดลองฟีเจอร์ใหม่บน Mobile App แล้วอยากปล่อยเวอร์ชัน Beta ทุกสัปดาห์เพื่อเก็บ Feedback ลูกค้า และปรับปรุงต่อได้ทันทีก็ใช้ความสามารถของ Cloud Native ทำให้แข่งขันในตลาดได้ไวกว่า พร้อมรับโอกาสใหม่ ๆ ก่อนใคร 

แอปดีเริ่มคนใช้เยอะ Cloud Native ช่วยให้สามารถ Scale Up/Out และ Scale Down/In ได้แบบชิล ๆ เรียกว่าโตได้แบบไม่มีสะดุด ลดปัญหา “ระบบล่ม” ในช่วงที่ทราฟฟิกพุ่ง ธุรกิจกำลังปัง และไม่ต้องเสียค่าใช้จ่ายเกินความจำเป็นในบางฟีเจอร์ที่ไม่ค่อยได้มีการใช้งาน

ทีม Marketing จะจัดแคมเปญ Flash Sale ยังไงคนใช้เยอะแค่ไหนก็หมดห่วงเพราะระบบ Cloud Native สามารถเพิ่ม Container หรือ Serverless Functions ได้ทันทีแบบอัตโนมัติ

ส่วนเรื่องของการบริหารจัดการ ระบบ Cloud Native มักออกแบบมาให้เกิด Observability ในตัว ช่วยให้การมอนิเตอร์ติดตามปัญหาและแก้ไขบั๊กรวดเร็วขึ้น ด้วยเครื่องมือที่มีให้ใช้อยู่แล้ว เช่น ถ้าเราใช้ AWS ก็จะมี CloudWatch, CloudTrail หรือ X-Ray ให้ใช้ได้ อย่างเช่น เมื่อเราต้องการตรวจสอบการทำงานของแต่ละฟังก์ชันใน Microservices ก็สามารถเข้าไปดู Log หรือ Metrics แยกกันได้ เพื่อระบุปัญหาได้ตรงจุด ไม่ต้องแก้ไขแบบ “งมเข็ม” ในโค้ดก้อนใหญ่ ๆ

หรือถ้าบอกว่ายุคใหม่ เทรนด์ใหม่ต้องมีการเอา AI/ML หรือ IoT เข้ามาใช้ในระบบด้วย เมื่อระบบอยู่บน Cloud Native การนำเทคโนโลยีใหม่ ๆ เราก็สามารถเอาเทคโนโลยีเหล่านี้มาต่อได้ง่าย ๆ เพราะ Cloud Provider มักมีบริการเสริมหลากหลาย ช่วยให้ธุรกิจไม่จำเป็นต้องสร้างทุกอย่างจากศูนย์ อย่างถ้าเราเปิดร้านขายปลีกที่ต้องการวิเคราะห์พฤติกรรมลูกค้าแบบเรียลไทม์ ก็สามารถเชื่อมต่อ AWS Kinesis เพื่อสตรีมข้อมูลและใช้ AWS Glue หรือ AWS Athena เพื่อวิเคราะห์ข้อมูลได้ทันที

ถ้าอ่านมาถึงตรงนี้แล้วเริ่มสนใจว่า Cloud-based หรือ Cloud Native แบบไหนจะเหมาะกับธุรกิจของคุณกันแน่? อยากลองเอาคลาวด์มาใช้แต่ยังไม่รู้จะเริ่มยังไงดี Cloud HM ของเราก็พร้อมที่จะช่วยคุณวางแผนให้เหมาะกับเป้าหมายของธุรกิจ

 

ไม่ว่าจะอยากย้ายระบบเดิมขึ้นคลาวด์ หรือจะไปให้สุดกับ Cloud Native เพื่อให้ระบบที่สเกลได้เองแบบอัตโนมัติ ลดต้นทุน และทำให้ทีมพัฒนาแอปทำงานได้เร็วขึ้น เรามีโซลูชันที่ตอบโจทย์ ทั้ง AWS, Kubernetes, Serverless, DevOps, CI/CD และอีกเพียบ

 

อยากลองปรึกษา? คุยกับเราได้เลยที่นี่ 👉 Cloud HM