Vultr - Performance ดีสุด Support ดีมาก Feature ครบครัน แต่ไม่ค่อยเปิดเผยข้อมูลว่า Hardware ที่รองรับด้านล่างเป็นอะไรบ้าง ราคาน่าจะถูกสุดเพราะมี 20% Discount อยู่ตอนนี้ เป็นน้องใหม่จากบรรดา 3 เจ้า Feature ใหม่ๆ ถูกพัฒนาอย่างต่อเนื่องรวดเร็วมาก ผ่านไปไม่กี่เดือน Feature ใหม่งอกตรึม ที่สำคัญ มี Private Network ที่ลูกค้าคนอื่นเข้าถึงไม่ได้ด้วยนะ! API ให้ยิงน้อยที่สุดใน 3 เจ้า เนื่องจากยังเป็นน้องใหม่อยู่ รอดูอนาคตยาวๆ อ้อ มี Location ให้เลือกมากสุดในสามเจ้าด้วย

• ภาพรวม AWS ว่ามีบริการอะไรบ้าง
• วิธีการใช้งานทั่วๆ ไป

เมื่ออ่านจบแล้วขอเตือนก่อนว่า AWS จะให้บริการคุณฟรี 1 ปี โดย limit ค่าต่างๆ ไว้ หากใช้ไม่เกินต่อเดือน คุณจะไม่เสียเงิน แต่หากใช้เกินก็จะเสียเงินเฉพาะส่วนที่เกิน เหมือนจะดูดี แต่ทีนี้ปัญหาคือหากใครศึกษาไม่ละเอียดพออาจเข้าใจผิดได้ และพอหมด 1 ปีที่ให้ฟรีแล้ว ก็อาจจะเสียค่าบริการแบบแพงหู่ฉี่ ไม่รู้เรื่องเอาได้ง่ายๆ

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

1. Cloud ไม่ใช่พระเจ้า หลากหลายข้อดีของมันนั้น แลกมาซึ่งประสิทธิภาพที่ลดลง
2. การใช้ Server Hardware แล้วเสียเฉพาะค่า Colo + ค่าจ้าง System Admin ถูกที่สุดเสมอในการใช้งานระยะยาว รวมไปถึง Performance เทียบราคาแล้วจะดีกว่า Cloud แน่นอนอย่างไม่ต้องสงสัย
3. หากคุณต้องการแค่พื้นที่ส่วนตัว, OS ส่วนตัว แต่ไม่อยากยุ่งยากเรื่องค่าใช้จ่ายที่อาจบานปลาย แนะนำให้เช่า VPS จะ control ค่าใช้จ่ายได้ง่ายกว่า
4. Cloud ไม่ใช่การใช้งานส่วนตัว คุณ share ทรัพยากรร่วมกับผู้อื่นแทบทุกอย่าง แม้จะมี disk,OS แยกจากชาวบ้าน แต่คุณยังต้องแชร์ CPU, I/O กับชาวบ้านเสมอ โอกาสที่จะใช้งานได้เร็วกว่าเครื่องจริงมีน้อยมาก เนื่องจากทุกอย่างต้อง share กับชาวบ้านหมด
5. การใช้งาน Cloud คือการแลก Performance ที่แย่ลง (เพราะใช้ Virtual Machine และ share กับชาวบ้าน) กับความยืดหยุ่นในการออกแบบ Architecture ทาง hardware เพราะคุณจะมี hardware เสมือน (VM) กี่เครื่องก็ได้ สร้างเมื่อต้องการจะใช้ และลบเมื่อไม่ใช้ หากเป็นการใช้งานแบบนานๆ ใช้ที ไม่ต้องเปิดใช้ตลอด จะคุ้มแน่นอนเพราะคิดเป็นรายชั่วโมง ดีกว่าจ่ายค่าเช่า colo แล้วนานๆ ใช้ที
6. สิ่งที่เป็นปัญหาของ Cloud ทุกๆ เจ้าคือการเขียนอ่านลง disk จะมี performance แย่กว่าเครื่องจริงหลายเท่า ดังนั้นการใช้งาน Database หนักๆ IOPS เยอะๆ อาจไม่ใช่เรื่องดีนักบน Cloud
7. อย่างไรก็ตาม AWS ก็แก้ปัญหา IOPS ด้วยการออก EBS แบบ Provisioned IOPS ซึ่งสามารถแยก I/O ตัวเองออกจากคนอื่นได้ดีกว่าแบบปกติ ส่งผลให้การทำงานไม่ขึ้นๆ ลงๆ มีความเสถียรมากกว่าเดิม แต่ก็แลกมากับราคาที่สูงขึ้นพอสมควร โดยแบบ 4000 IOPS นั้น(สูงสุดในเดือนมิ.ย.56 นี้) ราคาจะตกเดือนละ $400 หรือ หมื่นสองพันบาท ลองคิดว่าเราซื้อ SSD 128GB มาใช้เองไม่เกินห้าพันแถมจ่ายครั้งเดียวจบ ยังไงราคาก็ต่างกันราวฟ้ากับเหว แถมได้ค่า IOPS เกินหมื่นอีกต่างหาก
8. จากการทดลองใช้ CPU รุ่นธรรมดานั้นช้ามาก ขนาดปรับเป็น High-CPU ขั้นแรกยังรู้สึกว่ารับได้ไม่มากเลย หากปรับสูงกว่านั้นก็จะเริ่มแพงมากแล้ว ซึ่งเลยจุดที่ไปเช่า VPS ถูกๆ เอาคุ้มกว่ามาก
9. ค่าใช้จ่ายคิดเป็นรายชั่วโมง เหมือนจะน้อย แต่ว่าจะมีค่าใช้จ่ายทั้งหมด 4 อย่างที่คุณต้องจ่ายแน่ๆ และประมาณการต่อเดือนลำบากมาก โดยส่วนที่แพงที่สุดคือ Bandwidth และ IOPS
   • ค่า CPU/Memory
   • ค่า Bandwidth -> ส่วนที่ประมาณได้ยากที่สุด และแพงที่สุด
   • ค่าปริมาณ Storage ที่ใช้งาน -> หน่วยเป็น GB
   • ค่า IOPS (ค่า I/O ยิ่งสูงยิ่งแพง) -> แพงรองลงมา และประมาณได้ยากเป็นอันดับสอง
10. AWS จะมีบริการเสริมเช่น RDS (MySQL Database), DNS, Load Balancer แต่ทั้งนี้ทั้งนั้นแนะนำว่าสร้าง OS มาติดตั้ง software เองดีกว่านะ (ถ้าทำเป็น) เพราะจะ config ได้มากกว่ามาก และราคาถูกกว่ามาก
11. หากต้องการประหยัดค่า Bandwidth อาจะพิจารณาใช้ CDN cloudflare.com ช่วยเพราะจ่ายเหมาเป็นรายเดือนช่วย cache static content
12. ข้อดีอย่างหนึ่งที่ผมชอบมากใน AWS คือ Elastic IP ซึ่งทำให้สามารถเรา setup server อีกเครื่องแยกต่างหาก แล้วเปลี่ยนการผูก IP จากเครื่อง A ไปเครื่อง B ได้เลยแบบไม่มี down time และไม่ต้องแก้ DNS เลย สะดวกมาก

ต่อไปเป็น Note สรุปการใช้งานของผมเองดังนี้

• EBS คือ Harddisk, S3 คือ SAN
• ข้อดีอย่างหนึ่งของ AWS คือเป็นรายใหญ่ มีหลาย Region ให้เลือกทั่วโลก สามารถ Copy AMI Image ข้าม Region ได้ ค่อนข้างสะดวกในการเปิด server หลายๆ ที่
• EBS แบบ Provisoned IOPS จะดีกว่าเฉพาะ Random Read/Write เท่านั้น การทำงานแบบ Sequential Read/Write จะทำได้พอๆ กับแบบ Standard ซึ่งถูกกว่า
• ระหว่าง Backup AMI ระบบจะปิด Image เพื่อ Backup อัตโนมัติ ระหว่างปิดเว็บจะใช้งานไม่ได้ ต้องระวังตรงจุดนี้
• การ Stop Instace จะทำให้เราไม่ต้องจ่ายค่า CPU/Memory แต่เรายังต้องจ่ายค่า Storage ที่เก็บพื้นที่ใช้งานนั้นไปเรื่อยๆ จนกว่าจะ Terminate Server ทิ้ง
• หาก AWS ไม่สามารถตอบสนองการใช้งาน IOPS ที่เราต้องการได้ (ยังใช้งาน disk หนักเกินขนาดอยู่) มีทางเลือกคือทำ Raid 0 ใน EBS ต่อหลายๆ ตัวเพื่อเพิ่ม performance I/O ได้
• หาก AWS ล่มใน Region ใด Region หนึ่ง เป็นความรับผิดชอบของเจ้าของเว็บเองที่ต้องมี Mirror site ที่คนละ Region ไว้เองด้วย (AWS ก็ล่มได้นะ ไม่ใช่ไม่เคยล่ม และเคยล่มมากกว่า 1 ครั้งด้วย)
• Raid 10 ยังจำเป็นอยู่หาก AWS ล่มไปบางส่วน จะยังคงมี disk บางส่วนที่ยังทำงานได้
• การใช้ SSH Keys access เข้าเครื่อง Server ต้องใช้ puttygen เปิดไฟล์ที่ดาวน์โหลดมาจาก AWS เลือก Type เป็น SSH-1 (RSA) แล้วจึงกดเซพ private key ถึงจะสามารถนำ private key นั้นๆ ไปใช้งานได้ด้วย username ubuntu
• การแก้ไข port firewall ที่เปิดปิด สามารถแก้ไขได้ไที่ Network & Security -> Security Group เพิ่ม Inbound ส่วนที่ต้องการเช่น 22, 80, 443, 3306 ลงไป

สรุปแล้วการใช้งาน Cloud ข้อดีหลักๆ คือใช้เพื่อทดสอบว่า Application ที่เราทำขึ้นนั้น ใช้งานหนักไปในด้านไหน และหากมีคนเข้าเยอะๆ จนนิ่งเมื่อไร จึงค่อยพิจารณาซื้อ hardware จริงให้รองรับจำนวนคนเข้าได้พอดี จะดีที่สุดเพราะถึงแม้ hardware จริงจะราคาถูกกว่าเช่า cloud แต่ข้อเสียของ hardware คือจะ upgrade ทีนึงต้องวิ่งไปที่ Data Center อยู่ดี ที่เป็นหลัการที่ Zynga ใช้ครับ ส่วนใครอยากใช้ cloud และไม่เกี่ยงว่ามันตั้งอยู่ที่ US แนะนำให้ลอง Joyent นะครับ คิดเป็นรายชั่วโมง และไม่มี hidden cost มากมายทั้ง Bandwidth, Storage, IOPS แบบ aws และที่สำคัญ ถูกกว่ามากเมื่อเทียบ performance ที่ได้รับ หากใช้แบบ SmartOS (เป็น Solaris) จะยิ่งได้ performance เทียบเคียงเครื่องจริงเลยละครับ (เสียอย่างเดียวให้พื้นที่ HDD น้อยไปหน่อย) ขอให้โชคดีทุกคนครับ

องค์ประกอบจำเป็นสำหรับนำ application ขึ้น Facebook

รูปแสดง Architecture ของเกม facebook ทั่วๆ ไป

ขั้นตอนการสร้าง application บน facebook ด้วย Heroku

1. เข้าไปที่ www.facebook.com/developers (หากยังไม่ยืนยันตัวตนผ่าน SMS facebook จะไม่อนุญาตให้เราสร้าง app ใหม่)
2. คลิก Create New App ทางมุมขวาบน

New App

3. จะปรากฏดังรูป คลิกที่ปุ่ม Get Started ในกรอบ Cloud Services

4. เลือก Heroku และคลิก Next (ในอนาคต Facebook อาจมี Cloud เจ้าอื่นให้เลือกนอกจาก Heroku เช่นกัน)

5. เลือกประเภท application ที่เราจะสร้าง (PHP, Pyhton, Ruby,Node.js) ซึ่งในบทความนี้ให้เลือกเป็น PHP และอีเมล์ที่เราจะใช้ในการสมัคร account Heroku (แยกต่างหากออกจาก Facebook Account) และคลิก Create

6. ตอนนี้ทาง Heroku จะสร้างหน้า Example Application ขึ้นมาให้โดยอัตโนมัติ ให้คลิก Allow App เพิ่อดำเนินการต่อไป

7. ปรากฏหน้า Example Application ที่เสร็จแล้วพร้อมใช้งานของ Heroku ขึ้นมา

8. คลิก link confirm การสมัครสมาชิกของ Heroku ที่ส่งเข้าอีเมล์ของคุณ

9. ตั้งรหัสผ่านเพื่อใช้งาน Heroku

10. Download Heroku Toolbelt ที่ http://devcenter.heroku.com/articles/facebook (แต่ละ OS จะมีขั้นตอนการ install ไม่เหมือนกัน)

11. ขั้นต่อไปคือเปิด Command Prompt ขึ้นมาสำหรับ Windows ซึ่งถ้าเป็น Linux หรือ Mac ก็เปิด Terminal/Shell ขึ้นมาได้เลยครับ แล้วพิมพ์ heroku login และกรอกข้อมูลอีเมล์และรหัสผ่านไป เสร็จแล้วตัว heroku toolbelt จะสร้างและ upload public key ไปให้บน heroku server โดยอัตโนมัติ

12. Copy private key และ public key ที่ถูกสร้างขึ้นอัตโนมัติชื่อ id_rsa และ id_rsa.pub ในข้อ 11 จาก C:\Users\User ของคุณ\.ssh ไปยัง C:\Program Files\Git\.ssh (ต้องสั่ง Show hidden file เสียก่อน)

13. ข้อเสีย(หรือข้อดี?) อย่างหนึ่งของ heroku คือการใช้ upload file ใดๆ ขึ้น server ของ heroku จะไม่มี FTP หรือ ssh ให้ใช้งานเลยแม้แต่น้อย ต้อง push code ผ่าน Git ของ heroku เท่านั้น (Git คือ software version control ประเภทหนึ่ง เทียบได้กับ Subversion หรือ SVN) โดยก่อนอื่นต้อง git clone ไฟล์ที่ตัว heroku สร้างให้อัตโนมัติมาลงเครื่องของเราก่อน ซึ่งให้แก้ furious-robot-218 เป็นชื่อ project ของเราที่ Heroku ตั้งชื่อให้ตอนสร้างแทน

14. แก้ไขไฟล์ index.php โดยทดลองเพิ่มข้อความอะไรก็ได้เพื่อทดสอบการแก้ไขไฟล์ให้แสดงผลต่างไปจากเดิมที่เห็นก่อนหน้านี้ เช่นพิมพ์ข้อความ Welcome to my new app เพิ่มเข้าไป

15. สั่ง git commit -am “comment ที่ใช้เตือนความจำคุณเอง”

16. สั่ง git push heroku หากสำเร็จจะปรากฏข้อความในลักษณะดังภาพ หากล้มเหลวและขึ้นว่า Permission denied ให้ตรวจสอบขั้นตอนที่ 11-12 ดีๆ อีกครั้ง

17. เมื่อสำเร็จและกลับไปดูที่ www.facebook.com/developers อีกครั้งแล้วคลิกที่ app ที่เราพึ่งสร้างจะพบว่าที่ตัว facebook นั้นกรอก URL ไปยัง Heroku ให้เองแล้วอัตโนมัติ

18. Heroku นั้นจะสร้าง application บน facebook ในรูปแบบ Website ให้อัตโนมัติ (ตัวเว็บอยู่นอกกรอบ facebook แค่ขอดึงใช้งานข้อมูล friend ต่างๆ เฉยๆ) หากเราต้องการให้เป็น application ที่อยู่ในกรอบ facebook (เรียกว่า Canvas app) ให้ copy ข้อความใน Site URL มาใส่ยังช่อง App on Facebook ในส่วน Secure Canvas URL เอาเองนะครับ (ส่วนช่อง Canvas URL ก็ให้กรอกเหมือนกัน แค่เปลี่ยนจาก https เป็น http เท่านั้น) หรือหากต้องการสร้าง application ให้ tab บน page ของคุณก็ไปกรอกที่ช่อง Page Tab แทนครับ

ขอให้ทุกคนสนุกกับการสร้าง App บน facebook นะครับ

เอาหล่ะ! ว่าแล้วก็มาเริ่มเข้าประเด็นกันเลยดีกว่า

ทำไมถึงไม่ใช้ Server ตั้งที่ไทย

1. ลูกค้าหลักๆ (US , UK , Europe) เข้าถึง Server ในประเทศเราได้ช้ามาก

2. ผู้บริการในไทยมักเจอปัญหาเรื่องความไม่เสถียรอยู่บ่อยมาก Server ล่ม ถูกยิง เจอไวรัส เป็นประจำ

3. ในไทยยังไม่ให้บริการ Server ประสิทธิภาพสูง Grid/Cloud

ประเภทของ Server ต่างประเทศ

1. Over sale hosting (โฆษณาเกินจริง)

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

HostMonster – http://www.hostmonster.com/

Blue Host - http://www.bluehost.com/

Hostgator – http://www.hostgator.com/

และอื่นๆที่มีอยู่ล้นตลาด โดย Host ประเภทนี้มักจะโฆษณาให้ดูเว่อร์ๆไว้ เช่น พื้นที่/Bandwidth Unlimit , ใช้กี่ Account/Domain ก็ได้ โดยราคาจะอยู่ที่ราคา 5$ – 10$ ต่อเดือน (ซึ่งราคานี้ในไทยถือว่าแพงแล้ว)

จากหน้าฉากที่บอกว่าใช้เท่าไหรก็ได้ แต่เบื้องหลังมักจะมีข้อยกเว้นอยู่ คือ โดยส่วนใหญ่ Host พวกนี้จะจำกัดการใช้ CPU (ซึ่งมีทั้งบอกและไม่บอก) ถ้าดีหน่อย อย่างมากก็จะปิดเว็ปเราไปซักพัก แต่เท่าที่อ่านมา บางคนก็เจอถึงขั้นปิด Account ไปเลยก็มี

และ Host พวกนี้มักจะมีพวก Coupon ที่ใช้ลดราคาอยู่เสมอๆ ซึ่งลดจริงบ้าง ไม่จริงบ้าง หรือเงื่อนไขเยอะมากบ้าง ต้องลองศึกษาดุครับ โดยเวปประจำที่ผมเข้าก็เป็น RetailmeNot ซึ่ง Coupon เยอะมาก และมี User feedback ว่าอันไหนใช้ได้ไม่ได้ ทำให้เลือก Coupon ได้ง่าย

- เหมาะกับ

1. สำหรับคนที่ใช้งานปานกลาง ใช้งานที่เน้นพื้นที่เก็บข้อมูลเยอะๆ

2. เวปที่คนเข้าไปเยอะมากนัก เช่น Web portfolio , เวปส่วนตัว

- ไม่เหมาะกับ

1. เวปที่ต้องการใข้งาน Process มากๆ เช่น Game , WordPress / Webboard ที่คนเข้าเยอะ

2. เวปที่ต้องการ Customize เยอะๆ เนื่องจาก ส่วนใหญ่เวปพวกนี้จะไม่อนุญาติให้เราเปลี่ยนแปลงอะไรมากนัก

2. Dedicated Server / VPS (Virtual Private Server)

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

Hostgator – http://www.hostgator.com/

Media Temple – https://www.mediatemple.net/

Slice Host – http://www.slicehost.com/

iWeb – http://iweb.com/

Softlayer – http://softlayer.com/

ประเภทนี้ก็มีเยอะพอๆกับแบบแรก ราคาจะอยู่ที่ช่าง 50$ – 200$ ต่อเดือน โดยเมื่อเราสมัครใช้บริการแล้วเราจะได้เครื่องส่วนตัวของเราเองมา 1 เครื่อง ซึ่งถ้าเป็น Dedicated จะเป็นแบบ Physical คือเครื่องจริงๆ ส่วนแบบ VPS จะเป็นแบบ Virtual ซึ่ง 1 เครื่องอาจจะแบ่งเป็นหลายเครื่อง Virtual อีกที

ข้อดีข้อเสียของ Dedicated และ VPS

- Dedicated ดีกว่าด้านประสิทธิภาพ เนื่องจาก VPS มี VM ที่มาจัดการระบบเป็น Overhead อีกที

- VPS มักจะถูกกว่า Dedicated

- VPS มีความยืดหยุ่นในการใช้งานกว่า เช่นเรื่อง การเปิดปิดเครื่อง การขยายขนาด / ประสิทธิภาพเคร่ือง ทำได้ในทันที

เหมาะกับ

1. ผู้มีเงินทุนพอสมควร เพราะราคาก็ไม่ถูกเท่านัก

2. ต้องพอมีความรู้ด้าน Server / Linux พอสมควร เพื่อจะได้ใช้ความสามารถเครื่องได้เต็มที่

3. เว็ปที่ต้องใช้ Process สูงๆมากๆ อย่างเช่น Game

ไม่เหมาะกับ

1. ผู้ที่ไม่ความรู้เรื่อง Server เลย

2. ผู้ต้องการความยืดหยุ่นสูงเหมือน Grid / Cloud , ต้องการเปลี่ยนโครงสร้าง Server Farm บ่อย

3. Grid Hosting / Managed Cloud hosting

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

MediaTemple (gs) http://mediatemple.net/ (20$/month)

Rackspace’s Cloud site http://www.rackspacecloud.com/ (100$+/month)

Host แบบนี้ดูเผินๆจะคล้ายแบบ Hosting ทั่วไป แต่จริงๆแล้ว เบื้องหลังมันถูกรันด้วย Cloud/Gird ขนาดใหญ่ ซึ่งทำให้คุณสามารถขยาย Website ของคุณได้อย่างต่อเนื่อง โดยไม่จำเป็นต้องมีความรู้ด้าน Server มากนัก โดยทางผู้ให้บริการจะทำการจัดการไว้ให้เกือบทั้งหมดแล้ว (แต่เราก็ยังเข้าไป Customize ได้) ซึ่งข้อดีของ Host แบบนี้คือสามารถรองรับ Digg Effect / CPU Busting – ตัวอย่างเช่นเมื่อมีคนเข้าเวปเรามากอย่างไม่คาดคิด จากเวปไซต์ต่างๆเช่นจาก Digg.com ซึ่งหากเป็น Host ทั่วไปเราก็จะโดนแบน Account ไปหรือไม่ Server ก็ล่มไปเลย แต่หากเป็น Host แบบนี้มันจะอนุญาติให้เราใช้ CPU อันทรงพลังของ Cloud/Grid ได้ชั่วคราว ทำให้เวปเราสามารถใช้งานได้ปกติได้ในช่วงที่มีคนเข้ามหาศาล โดยที่เราไม่จำเป็นต้องหา Server ที่เกินความจำเป็น เพราะหลังจากเกิด Digg Effect จำนวนคนก็จะกลับมาสู่สภาวะปกติอยู่ดี

เหมาะกับ

1. ผู้ที่ต้องการความเสถียรของ เว็ปไซต์ สูงมากๆ

2. สามารถจำกัดการใช้งาน เว็ปไซต์ ได้พอสมควร เนื่องจาก Host ประเภทนี้มักจะมี Limit ด้านการใช้ CPU / Bandwidth ไว้ ซึ่งหากใช้เกินกว่าที่กำหนด ก็จะคิดเพิ่มตามจริง

ไม่เหมาะกับ

1. เว็ปไซต์ ที่กิน Process มากๆ เพราะ CPU limit มักจะไม่พอการใช้งาน (รวมทั้ง BandWidth ด้วย)

2.ผู้ที่ต้องการ ออกแบบโครงสร้าง Server Farm เอง

4. Cloud Hosting

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

Amazon EC2 – http://aws.amazon.com/ec2/

Gogrid – http://www.gogrid.com/

Joyent – http://www.joyent.com/

Softlayer’s Cloud layer – http://softlayer.com/

Rackspace Cloud - http://www.rackspacecloud.com/cloud_hosting_products/servers

Hosting ที่กำลังเป็น Trend ในยุคหน้า เทคโนโลยี Cloud กำลังเป็นที่จับตามองของผู้ที่ต้องการ Server ที่ประสิทธิภาพและความยืดหยุ่นสูง ซึ่งเหมาะกับทั้งเวปขนาดใหญ่มากๆ หรือ เวปขนาดกลางๆ เนื่องจาก Slogan หลักของ Cloud hosting ที่นิยมใช้กันคือ “Pay as you go!” หรือว่า จ่ายเท่าที่ใช้ โดยมีทั้งเป็น ต่อชั่วโมง / ต่อเดือน คิดตาม CPU / ตาม Bandwidth ตามแต่ละเจ้า ซึ่งรูปแบบการคิดเงินยังไม่ค่อยเป็นมาตราฐานมาก เนื่องจากตลาดนี้ค่อนข้างใหม่

จุดเด่นของ Cloud Hosting อีกอย่างคือ คุณสามารถจำลองรูปแบบ Server Farm ของคุณเองบน Cloud ได้อย่างง่ายดาย เพียงไม่กี่คลิกคุณก็จะได้เครื่อง Web server / Database server / Load Balance เข้ามาในระบบ Cloud แล้ว เหมาะแก่การลองทดสอบโครงสร้างของ Server Farm สำหรับ Website ขนาดใหญ่ ที่ต้องใช้ Web server หลายตัว , Database Server แบบ Replicate , มี Load balance , มี Cloud storage และอื่นๆ ได้ โดยคุณเสียเงินตามที่คุณได้ใช้จริงๆเท่านั้น

เหมาะกับ

1. ผู้ที่ต้องการความเสถียรของ เว็ปไซต์ สูงมากๆ , กิน Process มากๆ

2.ผู้ที่มีกำลังจ่ายพอสมควร โดยขึ้นกับปริมาณการใช้งานจริง

3. ผู้ที่อยากศึกษาระบบ Cloud และ การทำ Server Farm

ไม่เหมาะกับ

1. เว็ปไซต์ขนาดเล็ก และ กลาง ทั่วไปๆ

2. เว็ปไซต์ที่ต้องการ Bandwidth สูงมากๆ กว่า 2 TB ต่อเดือน (Direct Download)

5. CDN (Content Delivery Network)

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

Softlayer’s Cloud layer CDN – http://softlayer.com/

เนื่องจาก ความช้าของ Website ส่วนใหญ่แล้วจริงๆเกิดการส่งข้อมูล ภาพ / Javascript / Css ที่ช้า ทำให้เว็ปเกิดอาการหน่วง ทำให้คสเข้าเวปเกิดอาการ “เซง” อีกทั้ง Internet เริ่มแพร่หลายในประเทศสารขัณฑ์ เอ้ย เผยแพร่ไปทั่วโลก ซึ่งเนตภายในประเทศนั่นย่อมเร็วกว่าต่างประเทศแน่นอน

จึงทำให้เกิดบริการนี้ขึ้น ซึ่งระบบ CDN (Content Delivery Network) จะทำงานโดยนำไฟล์ข้อมูลของแจกกระจายไปยัง Server ต่างๆทั่วโลกอัตโนมัติ และเมื่อผู้ใช้เข้ามาดึงข้อมูลทาง CDN ก็จะเลือก Server ที่ใกล้กลับผู้ใช้คนนั้นที่สุดให้ทันที

เหมาะกับ

1. เว็ปไซต์ที่ต้องการความรวดเร็วในการทำงานสูง

2. เว็ปไซต์ที่เน้นให้บริการคนทั่วโลก

ไม่เหมาะกับ

1. เว็ปไซต์ขนาดเล็ก และ กลาง ทั่วไปๆ

2. เว็ปไซต์ที่ต้องการ Bandwidth สูงมากๆ

จริงๆมีข้อมูลละเอียดกว่านี้ แต่เนื่องเวลาไม่เอื้ออำนวย (นี่ก็เกือบ 2 ชั่วโมงแล้ว – -) ขอยกยอดไปก่อนหล่ะกันครับ >w<  ใครสนใจข้อมูลเพิ่มก็ลองเข้า WebhostingTalk หาข้อมูลดูครับ เวปนี้ข้อมูลแน่นใช้ได้เลย (แต่ข้อมูลเรื่อง Cloud hosting ยังน้อย เพราะยังใหม่มาก)