การเลือกใช้ระบบคลาวด์ (Cloud Computing)

DinoQ Entrepreneur Platform 2015/12 ( info@dinoq.com )

ผมไม่ขอกล่าวเกี่ยวกับที่มา และความหมายของการประมวลแบบผลกลุ่มเมฆ (Cloud Computing) นะครับ เพราะมีคนเขียนบทความเยอะแล้ว ขอข้ามไปรูปแบบการให้บริการของการประมวลแบบผลกลุ่มเมฆเลย (จากประสบการณ์ผม อ่านทฎษฏีเยอะ รู้เยอะแล้วจะงง แนะนำให้อ่านพอเป็นแนวทาง แล้วลองทำดูว่าเป็นอย่างไร หลังๆค่อยไปอ่านทฎษฏีก็ได้ จะเข้าใจง่ายกว่าเดิม)

รูปแบบของ cloud แบ่งออกเป็น 3 แบบ คือ

1. IaaS (Infrastructure as a Service) คือ การให้บริการด้านโครงสร้างพื้นฐาน ซึ่งเป็นการให้บริการฮาร์ดแวร์สำหรับเซิร์ฟเวอร์ สตอเรจ ระบบเครือข่ายและระบบรักษาความปลอดภัย ในรูปแบบเวอร์ชวลไลเซชัน (virtualization) โดยการใช้งานทั้งหมดจะทำผ่านเว็บเบราว์เซอร์ เมื่อเราทำการซื้อบริการแล้วจะได้เครื่องเซิร์ฟเวอร์เปล่าๆมาหนึ่งเครื่อง จะทำการลงโปรแกรมอะไรก็แล้วแต่เรา นอกจากนี้เรายังสามารถจัดการระบบเครือข่ายสำหรับเครื่องเซิร์ฟเวอร์ของเราได้

2. PaaS (Platform as a Service) เป็นบริการด้านแพลตฟอร์มที่รองรับการทำงานของแอพพลิเคชัน

3. SaaS ( Software as a Service) เป็นการให้บริการซอฟต์แวร์แอพพลิเคชันให้แก่ผู้ใช้งาน โดยคิดค่าบริการเป็นลิขสิทธิ์ของผู้ใช้ หรือตามปริมาณการใช้งาน

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

IaaS ต้องมีงานที่ต้องทำมากสุดตั้งแต่ OS ขึ้นมาเลย โดยที่ทางผู้ให้บริการจะมีเพียงเครื่องเปล่าๆให้ ยกตัวอย่างเช่น Google Compute Engine, Amazon EC2, Azure Vitual Machine, Digital Ocean และอื่นๆ

PaaS ผู้ให้บริการโดยมากจะมี Web หรือ Application Server ไว้ให้ติดตั้งแอพพลิเคชันที่คุณพัฒนาลงไป รวมถึงมี Database Server ไว้เก็บข้อมูลของแอพพลิเคชันด้วย โดยทั้ง Application Server หรือ Database Server นี้ผู้ใช้จะมีหน้าที่แค่ใช้งานในส่วนของการดูแลรักษาผู้ให้บริการจะจัดการให้ ยกตัวอย่างเช่น Google App Engine, Gooele Big Table, Azure WebApp, Azure DocumentDB, Amazon Beantalks, DynamoDB และอื่นๆ

SaaS คือแอพพลิเคชันสำเร็จรูปที่พร้อมใช้งานทันที ไม่ต้องมีการพัฒนา หรือติดตั้งใดๆ ยกตัวอย่างเช่น Google App, Saleforce, Office 365 และอื่นๆ

โดยส่วนตัวผมชอบใช้ SaaS ในกรณีที่เป็นแอพพลิเคชันที่มีมาตรฐานชัดเจนในท้องตลาดอยู่แล้ว แต่ถ้าเป็นแอพพลิเคชัน ที่ต้องพัฒนาใหม่ก็ต้อง PaaS เลยครับ

สำหรับ IaaS ไม่จำเป็นจริงๆ ไม่อยากใช้ครับ ไม่ค่อยลดงานเลย

แต่ต้องยอมรับว่าความรู้ความเข้าใจเรื่อง Cloud Computing ในธรกิจในประเทศไทยยังมีข้อจำกัดมาก และการใช้ Cloud Computing จะกระทบวัฒนธรรมองค์กร และแนวคิดขององค์กรค่อนข้างแยะ และคนไอทีในประเทศไทยเรามักจะรับความเสี่ยงได้น้อย (บางบริษัทไม่อยากรับความเสี่ยงเลย โยนให้เวนเดอร์ซะงั้น)

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

ผลจากการที่ไอที่เราไม่ยอมรับความเสี่ยงเลยทำให้การนำ Cloud Computing มาใช้ในประเทศไทยถูกจำกัดอยู่ที่ 2 แบบใหญ่ๆ ดังนี้

  1. ย้ายระบบเดิมขึ้นมาบน IaaS Cloud โดยมีลักษณะการทำงานแบบเดิมตั้งแต่โหมดพัฒนา จนถึงโหมดโปรดัคท์ชั่น ในแบบนี้จะทำให้ข้อดีของการใช้ Cloud ลดลงไปแยะที่เดียว งานต่างๆก็แทบไม่ลดลงเลย
  2. ย้ายไปใช้ SaaS Cloud เลย แบบนี้ดีมาก แต่ปัญหาคือระบบเหล่านี้ค่อนข้างจำกัดมีไม่มาก โดยถ้าคิดเป็นเปอร์เซ็นของระบบทั้งหมดในองค์กร ก็ไม่น่าจะเกิน 5–10 เปอร์เซ็น

ส่วนมากบริษัทใดๆก็ตามมักจะมีแอพพลิเคชันที่พัฒนาขึ้นมาใช้งานเอง โดยเฉพาะกับธุรกิจของบริษัทนั้น ซึ่งแอพพลิเคชันเหล่านี้เองมีมากถึงกว่า 80 เปอร์เซ็นในองค์กร ดังนั้น Cloud Computing ที่องค์กรต่างควรจะนำมาใช้ที่สุดควรเป็น PaaS Cloud

แต่ก็นั่นแหละในปัจจุบันนนี้ PaaS Cloud ยังถือว่าอยู่ในช่วงเริ่มต้นยังยึดติดกับแพลตฟอร์ม, ภาษา และวิธีการเดิมๆอยู่มาก ยังไม่มีผู้ให้บริการเจ้าใดนำเสนอเฟรมเวิร์กใหม่ๆ ที่ฉีกจากแนวเดิมได้

ผมขอแบ่ง PaaS Cloud ออกเป็น 4 ส่วนใหญ่ๆแบบนี้นะครับ ส่วนแรกคือส่วนที่รองรับการทำงานของโค้ดที่เราเขียน ขอเรียกว่า Runtime Container นะครับ ส่วนที่สองคือแพลตฟอร์ม เฟรมเวิร์ก และเครื่องมือในการพัฒนาแอพพลิเคชัน ขอเรียกว่า Application Development Tool ส่วนที่สามคือที่เก็บข้อมูลซึ่งเราจะไม่เรียกว่าระบบฐานข้อมูล(Database System)หล่ะ เพราะเราจะมองเป็นบริการ(Service) ผมขอเรียกว่า Data as a Service (DaaS) นะครับ และส่วนสุดท้ายคือบริการรอบข้างที่สนับสนุนการพัฒนาแอพพลิเคชัน เช่น Cache, Queue, Mail service หรือ บริการอื่นๆอีก ผมขอเรียกว่า Supporting Services นะครับ

เมื่อแยกออกมาแบบนี้ก็ง่ายหล่ะ ในการเปรียบเทียบ PaaS Cloud ในท้องตลาด ผมขอยกตัวอย่างแค่บางตัวเพื่อให้เห็นภาพ นะครับ

Amazon Beanstalk มันคือ Runtime Container ที่มีความสามารถในการจัดการเรื่องทำให้แอพพลิเคชันทำงานได้ตลอดเวลา (HA), ทำให้แอพพลิเคชันรองรับการทำงานที่เพิ่มขึ้นได้ (Scale ability) และ ทำกระจายการทำงานภายในระบบ (Load balancing) ให้ด้วย ซึ่งการทำงานทั้งหลายเหล่านี้เราไม่ต้องดูแลในรายละเอียด แค่ทำการปรับแต่งผ่านหน้าเว็บเท่านั้น สะดวกสบายมาก แต่สำหรับ Amazon Beanstalk ในส่วน Application Development Tool จะไม่มีอะไรพิเศษ โดยจะใช้เครื่องมือ ที่มีอยู่แล้วโดยสามารถเลือกแพลตฟอร์มได้ดังนี้ Java, PHP, GO, Python และสำหรับ Data as a Service ทาง Amzon มีให้หลายตัวเลย ทั้ง Amzon RDS ที่เป็น MySQL และ Oracle database และ Amazon DynamoDB ที่เป็น NoSQL ซึ่งเหมือนกับ Beantalks นั่นคือ การทำงานของมันเราไม่ต้องดูแลในรายละเอียด แค่ทำการปรับแต่งผ่านหน้าเว็บ และเรียกใช้งานเท่านั้น ในส่วนของ Supporting Services ทาง Amazon ก็มีบริการต่างๆที่คอยสนับสนุนอยู่ครบ จนเกินพอ

Amazon EC2, Digital Ocean อันนี้ทำเองหมด เลือกเอง ติดตั้งเอง ตามสะดวก ไม่ถือว่าเป็น PaaS นะครับ เพราะมันคือ IaaS

Google App Engine มันคือ Runtime Container แต่ของ Google จะดีกว่า Amazon ตรงที่ไม่ได้เอา App Server แบบเดิมๆมาใช้เลยเหมือน Amazon แต่มีการปรับปรุงและพัฒนาร่วมกับเฟรมเวิร์ก ทำให้พัฒนาได้ง่ายขึ้น นอกจากนั้นยังมีการพัฒนาให้ Runtime Container ทำงานร่วมกับ Data as a Service ผลิตภัณฑ์คือ Google Data Store และ Supporting Services ให้ใช้ได้ง่ายขึ้นอีกด้วย สรุปคือมุมมองของ Google App Engine จะเหมือนมี environment ส่วนตัวของแต่ละแอพพลิเคชันแยกออกจากกัน โดยแต่ละแอพพลิเคชันจะมี Data as a Service และ Supporting Services ของมันเอง ซึ่งจะแตกต่างจากเจ้าอื่นๆในตลาด แต่ปัญหาของ Google App Engine คือเมื่อ Google ได้พัฒนาต่อยอดจากมาตรฐานดังที่ได้กล่าวมาแล้ว ทำให้การพัฒนาแอพพลิเคชันลำบากมากขึ้น เพราะไม่สามารถพัฒนาโดยอ้างมาตรฐานเพียงอย่างเดียวได้

Azure WebApp มันคือ Runtime Container แต่ของ Microsoft โดยแนวคิดจะคล้ายๆกับแนวทางของ Amazon Beantalks แต่จะเพิ่มความสามารถขึ้นมากกว่า เพราะ Microsoft พยายามผสานแนวคิดของ Google App Engine เข้ามาด้วย แต่ยังอยากจะคงความเป็นมาตรฐานด้วยโดยสามารถเลือกแพลตฟอร์มได้ดังนี้ Java, PHP, GO, .Net ในส่วน Application Development Tool ถ้าเป็นแพลตฟอร์ม .Net จะมีเครื่องมือและสิ่งอำนวยความสดวกครบครัน แต่ถ้าเป็นแพลตฟอร์มอื่นๆก็จะไม่มีอะไรพิเศษ สำหรับ Data as a Service ทาง Microsoft มีให้หลายตัวเลย ทั้ง Azure SQL ที่เป็น MySQL และ SQL Server database และ Azure DocumentDB, Azure Table Storage ที่เป็น NoSQL ในส่วนของ Supporting Services ทาง Microsoft ก็มีบริการต่างๆที่คอยสนับสนุนอยู่ครบ

ขั้นตอนการเลือกใช้ PaaS Cloud

ขั้นตอนแรก คุณต้องเลือกก่อนว่าจะใช้แพลตฟอร์ม และภาษาอะไรในการพัฒนา ซึ่งปัจจุบันภาษาที่นิยมบน Cloud ไม่น่าจะเกินนี้ Java, .Net, PHP, GO, JavaScript (Node.js) และ Python

ขั้นที่สอง เลือกระบบฐานข้อมูลส่วนมากที่นิยมบน Cloud ก็เป็น MySQL, Oracle, SQL Server และในสายของ NoSQL เช่น MongoDB, CloudDB, Cassandra, Amazon DynamoDB, Google Big Table, Azure Storage Table และ Azure DocumentDB

ขั้นที่สาม เลือกที่ที่จะนำโค้ดของเราไปทำงาน ซึ่งโดยมากก็คือ Web หรือ Application Server นั่นเอง และก็อย่างที่บอก ผมชอบนำโค้ดไปทำงานบน PaaS Cloud เพราะช่วยลดงานผมได้มาก

ผมขอยกตัวอย่างการตัดสินใจใช้งานระบบ Cloud ของผมเองนะครับ จากอดีตผมเคยใช้ Cloud หลายเจ้า ไม่ว่าเป็น Amzon, Google, Digital Ocean, SoftLayer, BlueMix และ Azure ทำให้เห็นพัฒนาการและเหตุผลในการตัดสินใจ เผื่อจะมีประโยชน์กับท่านอื่นๆ

อ้อ ระบบผมเป็น Java นะครับ ทำงานได้ทั้งบน Tomcat, Jetty หรือ Glassfish (จริงๆก็ทำงานได้บน WebSphere, WebLogic และ JBoos ด้วย แต่ไม่ค่อยเห็นบน Cloud เลยไม่ขอกล่าวถึง นะครับ)

และสามารถทำงานได้กับระบบฐานข้อมูลทั้ง MySQL, Oracle, MongoDB, Google Big Table, Amzon DynamoDB, Azure Storage Table และ Azure DocumentDB

นอกจากนี้ยังมีการเก็บไฟล์ข้อมูล ที่ทำงานได้บนทั้ง Local disk, MySQL, Oracle, MongoDB, Azure Storage BLOB และ Google Storage

แรกสุดผมใช้ Amazon EC2 ที่ลง Tomcat และ MySQL และเก็บไฟล์ลง MySQL เลย ที่เลือกใช้เพราะตอนผมทำแรกๆประมาณ 5–6 ปีก่อน ซึ่งต้องบอกว่าตัวเลือกมีไม่มาก และ Amazon ดูดีสุดตอนนั้น (ก่อนหน้านั้นผมวาง Server ที่ CAT Telecom ครับ)

ต่อมาใช้ Amazon Beanstalk และ Amazon RDS MySQL เพราะอยากใช้ PaaS ครับ จะได้ลดงานติดตั้งโปรแกรมต่างๆ และการกำหนดค่าเบื้องต้น (กินแรงผมมากแค่เรียนรู้การติดตั้งโปรแกรมและการกำหนดค่าเบื้องต้น ก็เสียเวลาแย่แล้ว) ก็ดีขึ้นแต่ไม่ได้เท่าที่คิดไว้ Tomcat บน Beanstalk เรื่องมากกว่าที่คิด และไม่เสถียรเลย งานลดลงในส่วน Database แต่ฝั่ง Tomcat ไม่ค่อยได้ประโยชน์มากนัก Beantalks ทำหน้าที่เป็นแค่ตัว deploy จัดการอะไรไม่ค่อยได้

และใช้ Google App Enging และ Google Data Store (Big Table) อันนี้ทำตั้งนานเป็นเดือนเลย ทำงานบนเครื่องตัวเองที่เป็น Local ได้ พอขึ้นบน App Engine Cloud ติดปัญหาเยอะมาก เพราะ App Engine JVM ถูก Google ทำการปรับแต่งทำให้ใช้บาง API ไม่ได้ สรุปยกเลิก เปลืองเวลาเกินไป

และใช้ Google Compute Enging และ Google Data Store (Big Table) ส่วนไฟล์ข้อมูลเก็บที่ Google Storage แบบนี้ดีขึ้นหน่อยทำงานได้ดี และการปรับไปใช้ NoSQL ทำให้สามารถข้ามขีดจำกัดเรื่องขนาดของข้อมูล และการที่มีโครงสร้างข้อมูลที่ยืดหยุ่นของ NoSQL ทำให้ผมทำ Data API ของระบบผมเองได้ง่ายขึ้น วิธีเขียนเป็นธรรมชาติมากขึ้น (NoSQL API จะมีอารมณ์คล้ายๆกับ Hibernate API โดยมองเป็น Object)

และใช้ Digital Ocean โดยสร้าง Virtual machine ที่ลง Tomcat และ MongoDB ที่ใช้จริงๆแล้วมีเหตุผลเดียวเรื่องราคาเลย พร้อมกับปรับมาใช้ MongoDB ใช้ได้ไม่ถึงกับดี รับได้ตรงราคาถูกนี่แหละ เหมาะกับ Startup หรือ Pilot project ที่เพิ่งเริมต้นเลย

และใช้ SoftLayer โดยสร้าง Vitual machine ที่ลง Tomcat และ MongoDB จริงๆแล้วที่ย้ายมาใช้เพราะได้โปรโมชั่นมาใช้ฟรี 1 ปี และได้เครื่องที่แรงๆด้วย สรุปการใช้งานเป็น IaaS เหมือนๆกับ Amazon แต่ใช้ยากกว่า จะว่าใช้ยากที่สุดในหมู่ IaaS เจ้าใหญ่ๆก็ว่าได้

และใช้ BlueMix ใช้ Liberty (Application server ที่เป็นเวอร์ชั่นตัวเล็กของ WebSphere) กับ MongoDB ได้มาพร้อมๆกับ SoftLayer เท่าที่ลองใช้ดูตอนนั้น (ประมาณปี 2014) มันเหมือนยังทำไม่เสร็จ แนวทางยังไม่ชัดเจน แต่ของครบมีทุกอย่างแต่ประกอบกันไม่ติด ยังไม่สามารถทำให้เป็นเนื้อเดียวกันภายในแพลตฟอร์มได้ พยายามใช้อยู่เกือบเดือน แต่ก็ล้มเลิกไป เสียเวลา

และใช้ Azure Virtual machine ที่ลง Tomcat และ MongoDB ก็เช่นเคยครับ ได้โปรโมชั่นของ Micosoft มา สรุปทำงานได้ไม่เสถียร เพราะ VM ของ Microsoft จะมีรอบตัดการทำงาน (น่าจะทุกๆ 2 ชั่วโมงถ้าจำไม่ผิด) ซึ่งทำให้แอพพลิเคชัน ที่เป็น Java ซึ่งจะทำการรันทำงานครั้งแรกนาน จะทำบ่อยๆครั้งขึ้น ยิ่งบวกกับไปดึงข้อมูลจาก MongoDB ครั้งแรกด้วยแล้ว เป็นนาทีเลย ใช้งานจริงไม่ได้

และใช้ Azure WebApp และ Azure Virtual machine ที่ลง MongoDB แบบนี้ดีขึ้นจากใช้ Azure Virtual machine ที่ลง Tomcat นิดหน่อย แต่ก็ใช้งานจริงไม่ได้อยู่ดี

และใช้ Amazon Beanstalk และ Amazon EC2 ที่ลง MongoDB พยายามกลับไปใช้ Amazon ก็ดูเหมือนจะดี แต่ Beanstalk ก็ยังไม่ได้เรื่องอยู่ดี

และใช้ Amazon Beanstalk และ Amazon DynamoDB พยายามอีกครั้ง การเขียนใช้งาน DynamoDB ถ้าเปรียบเทียบกับ MongoDB แล้วคนละโลกเลย DynamoDB ดูยุ่งยาก และโบราณกว่ามาก ขอข้ามหล่ะ

และใช้ Azure WebApp และ Azure DocumentDB เก็บข้อมูลไฟล์ไว้ที่ Azure Storage BLOB แบบนี้ดูดีมาก ปัญหาการทำงานช้าครังแรกกับ MongoDB หายไป และ DocumentDB นี่พอๆกับ MongoDB เลย ตัว API ยังกับลอกกันมาที่เดียว แต่ Microsoft ยัดเรื่อง Transaction Management เข้ามาให้ด้วย ตอนนี้เกือบสมบูรณ์หล่ะ ติดปัญหาอย่างเดียวคือ โมเดลการคิดเงินของ DocumentDB ไม่อำนวยก์ต่อระบบผมเลย เพราะคิดตามจำนวน Collection (Table) ที่ใช้ ซึ่งระบบผมจะขยาย Collection ไปเรื่อยๆซะด้วยสิ แบบนี้เป็นอันตกไป

ดังนั้นหวยจึงมาลงกับแบบสุดท้าย คือใช้ Azure WebApp และ Azure Storage Table เก็บข้อมูลไฟล์ไว้ที่ Azure Storage BLOB ถึง Azure Storage Table ความสามารถจะไม่เจ๋งเท่า DocumentDB แต่ก็สามารถรองรับขอบเขตงานที่ผมต้องการได้พร้อมทั้งราคาถูกมาก (เมื่อเทียบกับเจ้าอื่นๆ) แน่นอนว่าการเขียน API ง่ายกว่า DynamoDB ซึ่งพอฟัดพอเหวี่ยงกับ MongoDB กับ Google Data Storage แต่เรื่องความสามารถของ Azure Storage Table ยังถือว่า ด้อยกว่า MongoDB กับ Google Data Storage ซึ่งผมกับมองว่า Azure Storage Table นี่น่าจะลอก Cassandra มา

สรุปตอนนี้ ที่ผมคิดว่าเหมาะสุด น่าจะเป็น Azure WebApp, Azure Storage Table + Azure Storage BLOB ถ้า โมเดลการเก็บเงินของ Azure DocumentDB ดีขึ้นคงย้ายไป หรือ หาก Google App Engine สามารถปรับให้รองรับมาตรฐาน J2EE ได้ดีกว่าเดิม ก็อาจจะย้ายไป Google ครับ

ท้ายสุดผมขอสรุปแบบนี้ นะครับ

Amazon เป็นเจ้าพ่อ IaaS ส่วน Microsoft เป็น PaaS ที่มาแรง ส่วน Google ยังเป็นผู้นำด้าน Innovation (แต่ล้ำไปหน่อยขนาดมาตรฐานยังตามไม่ทันแก) ส่วนเจ้าพ่อ SaaS ไม่อยู่ในกลุ่มนี้นะครับ เค้าคือ Saleforce

หากมีคำถามหรือข้อเสนอแนะ ติดต่อมาที่ info@dinoq.com นะครับ

ดูบทความอื่นๆ กดลิ้งค์เลยครับ