เปรียบเทียบ AWS vs Firebase

หลังจากที่เกม Duel Otters ใช้ AWS ไปแล้ว อยู่กับมันมาประมาณ 2 ปีแล้ว เกมใหม่ Mel Cadence ว่าจะใช้ Firebase เพื่อเทียบกันให้รู้ดำรู้แดงไปเลยว่าประสบการณ์ต่างกันยังไง (ราคาไม่ต่างกันมากพอที่จะคุ้มกับประสบการณ์)

หลักๆคือ AWS มีความเป็นจิ๊กซอว์สูงมาก คือต้องประกอบเอง แล้วก็หลายๆอย่างทำงานด้วยตัวมันเองไม่ได้เหมือนอย่างที่โฆษณา จะโดนโยนไปหน้านั้นหน้านี้เยอะ ส่วน Firebase ค่อนข้างสำเร็จรูปและ lock ราคามาให้ดูง่ายๆ ถ้าคิดจะพยายามลดราคาลงก็ทางเลือกน้อย

อยากจะทำระบบ upload/download save file

AWS : หลังจากโหลด Unity SDK มาแล้ว ก่อนอื่นต้องไปสร้าง Role ใน IAM และเข้า Cognito ไปสร้าง Federated Identities > User Pool เพื่อผูก Role เข้ากับ Pool ว่าถ้า unauthenticate แล้วได้ Role ไหน ใน Role นั้นๆ ไปสร้าง S3 bucket ขึ้นมา กลับไป IAM เพื่อเขียน policy ให้ถูก ว่า get, list, put ทำอะไรได้บ้าง ใน Unity ทีนี้ต้องไม่ลืมเลือก endpoint ให้ถูก ซึ่ง endpoint ของ Cognito กับ S3 ก็ดันเป็นคนละทวีปได้อีก ส่วน documentation .NET ก็นรก 

Firebase : 

อยากจะทำระบบ Login ด้วย e-mail

AWS : ทาง Amazon มี Cognito User Pool ให้ใช้แต่ดันไม่มี API ใน .NET SDK ถ้าจะใช้ login จากเจ้าอื่นอย่าง Auth0 หรือ Firebase ก็ต้องเสียเวลาแลก id token กันเพื่อให้กลายเป็น permission ของตาม Role แล้วก็ถ้าเกิน 50000 MAU จะเสียเงิน

Firebase : 

อยากจะ host เว็บไซต์เกม

AWS : ใน Route53 สามารถซื้อ domain name ได้ แล้วก็ตั้ง record ต่างๆเช่น CNAME, A, … ได้ ส่วนไฟล์เอาไว้ไหนสามารถเอาไว้ใน S3 ได้แต่ต้องตั้งชื่อ bucket ให้เป็นชื่อเว็บ แล้วก็เว็บที่ได้สถานที่อยู่ที่ๆ bucket อยู่ ถ้าอยากให้มันเร็วทุกที่ต้องไปทำ Cloudfront เพิ่ม แล้วก็ไม่มี SSL ถ้าอยากได้จะโดนบังคับให้ใช้ Cloudfront ส่วนการทำเว็บมีคอมมานด์ aws s3 sync ให้ใช้อัพโหลดของขึ้นได้ง่ายๆ

Firebase : ซื้อ domain name ไม่ได้ แต่ว่ามี auto CDN แล้วก็ auto SSL ให้อัตโนมัติ ไม่ต้องทำอะไรเลย ส่วนราคา host ของแพงกว่ากันแค่ 0.01$/GB ต่อเดือน

ส่วนการเอาโฟลเดอร์ขึ้นเว็บ ไม่เคยเห็นอะไร ggez เท่านี้อีกแล้ว

firebase login
firebase init
firebase deploy

เสร็จแล้ว! ขึ้นไปอยู่บนเน็ต! ได้ชื่อ .firebaseapp.com ทันที ได้ SSL ด้วย นี่ยังไม่ได้จ่ายตังไม่ได้ผูกบัตรอะไรทั้งสิ้น

แต่ถ้าไม่อยากเอาเว็บไว้ที่ root ก็คงยากขึ้นหน่อย จริงๆเว็บเกมควรอยู่ใต้เว็บบริษัทไง ก็เลยยังไม่ย้ายเว็บมา Firebase เพราะ sync ของ S3 มันเลือก sync เข้าไปตรงกลางของ bucket ที่เป็นส่วนของเกมนั้นๆได้

อยากประหยัดค่าเก็บของ optimize สถานที่เก็บ

AWS : ใน AWS S3 ตอนแรกเลือก region ให้ bucket แล้วเปลี่ยนไม่ได้อีกเลย แต่ละไฟล์สามารถเลือกแบบปกติ แบบ infrequent access หรือแบบ glacier สำหรับอยากเก็บอย่างเดียวเป็นหลัก ราคาต่างไปตาม region

Firebase : Bucket สามารถเลือก region และเปลี่ยนทีหลังได้ แต่ไฟล์ที่เก็บไปแล้วจะอยู่ที่เดิม ด้าน access จะมีผลกับทั้ง bucket เลือกได้ 4 แบบคือ multi-regional (ทำ CDN ให้เหมือนใช้คอมโบ S3 + Cloudfront เลือกได้ 3 แบบคือ asia, eu, us) แบบ regional (เหมือนใช้ S3 ปกติ) nearline และ coldline (เหมือน glacier)

ข้อมูลแบบ regional ย้ายมา multi-regional ไม่ได้ กลับกันก็ไม่ได้เหมือนกัน แต่ว่า nearline กับ coldline สามารถเก็บไว้ได้ทั้งสองแบบ

ทั้งคู่มี Northeastern Asia ซึ่งเหมาะกับเกมผมที่จะขายคนญี่ปุ่น 

แล้วก็ ที่ Google มีแต่ AWS ไม่มีคือ endpoint Taiwan ที่เป็นตรงกลางระหว่าง Asia NE (Tokyo) กับ SE (Singapore)

UI ตรงนี้ดูดีกว่าแล้วก็เร็วกว่ามาก

โครงสร้าง Unity API

AWS : เมธอดค่อนข้างมีความดิบเถื่อน ต้องสร้างตัวแปร Credentials ขึ้นมา login เอา Role แล้วสร้างตัวแปร S3 ขึ้นมา แล้วเอา Credentials ยัดใส่ แล้วจะสามารถ get, post อะไรงี้ได้โดยบอก path ให้มันแล้วรอดูผล มีระบบตอบรับเป็น call back เมื่อเกิด response ขึ้น

การประกอบเองในโค้ดนี่ก็รู้สึกเหมือนตอนอยู่ในเว็บ aws เลย แถมต้องเอารหัสของแต่ละบริการมาใส่ในโค้ดซึ่งแตกต่างกันไป ทำให้ในโค้ดมี string รหัสหลายอัน แล้วก็อย่าลืมใส่ endpoint ในโค้ดให้ถูกตามในเว็บด้วยไม่งั้นตาย (error ที่มาก็ไม่ได้บอกเลยว่า endpoint ผิด…)

ทุกอย่าง flat หมด คือไม่มีโฟลเดอร์ การที่เหมือน folder ที่แท้คือแค่ว่ามันเป็น string นำหน้าใน key เฉยๆ

อันนี้ตัวอยากโค้ดโหลดของจาก S3 ที่ประกอบขึ้นมาให้รองรับ callback ดีๆได้ ส่วนโชคชะตาทุกอย่างขึ้นอยู่กับ s3path แล้วก็ client ถ้าพิมพ์ผิด credentials ไม่พอ region endpoint ผิด role ที่ตั้งไว้ผิด หรือว่า permission bucket ผิด เตรียมตัวเสียเวลา 2 ชม.คลำหาว่าเป็นเพราะอะไรเพราะ error message มันกาก

Firebase : รู้สึก modern กว่ามากเพราะเริ่มจากการสร้าง reference ไปที่ๆนึงก่อน แล้วใช้ reference นั้นในการ upload/download แล้วก็เริ่มต้นง่ายมากแค่ใส่ bucket name เพราะ config ที่เหลืออยู่ในระบบ plist หมดแล้ว ไม่ต้อง hard code รหัสบ้าบอหลายตัว endpoint ก็ไม่ต้องใส่เพราะเข้าใจว่าจาก bucket url ทาง Firebase ก็รู้แล้วว่าอยู่ endpoint ไหน

API ที่ทำ reference รองรับคอนเซ็ปต์โฟลเดอร์ดี มี .Child .Parent ให้ใช้ มี .Name .Bucket ให้ใช้ ดีงาม ง่ายต่อการเขียนโปรแกรมคลุมอีกรอบ (แบบ ทำ reference ไว้รอที่โฟลเดอร์ก่อน จะอัพโหลดค่อยใช้ .Child ลงไปต่อได้ไรงี้)

รอตอบกลับใช้ System.Task ดู modern กว่า callback แถมมีใช้ IProgress ไว้ cancel ได้ ดู % อัพโหลดได้ ไม่ใช่รอลุ้นแบบของ AWS

Admin UI

AWS : โบราณ ใหม่แค่ S3

Firebase : Material design สวยสดชื่น มี animation เยียวยาจิตใจ

บทบรรยาย

จริงๆ AWS จะเป็นแบบ มีทุกอย่าง ส่วน Firebase จะมีแค่ subset ของ AWS ถ้าจะเทียบระดับเท่ากันจริง ต้อง Google Cloud Platform vs AWS แต่ฟีเจอร์ที่จะใช้ในเกมมันมีใน Firebase ครบเลยก็เลยเทียบกันได้…

ที่ Firebase ไม่มีก็ EC2 สำหรับเปิดเซิฟจริงๆ แต่ก็มี Functions ที่เป็นคล้ายๆ AWS Lambda แล้ว คิดว่าก็เหมาะดีที่จะเป็นอะไรที่ใช้ง่ายแต่ก็ยืดหยุ่นคล้ายเปิดเซิฟเอง สรุปคือถ้าสุดท้าย AWS ที่ customizable แล้วสุดท้ายในเกมใช้เท่า Firebase ด้านฟีเจอร์ก็ไม่มีปัญหา สุดท้ายก็จะเป็นด้านราคากับ usability ซึ่งดูๆแล้ว Firebase แพงกว่านิดแต่ที่เหลือดีต่อใจกว่าเยอะ…

ด้วยความจิ๊กซอว์ของ AWS มันเลยกลายเป็น price to pay เวลาเราอยากจะใช้แค่ “เท่าที่อยากได้” จริงๆไอ้เท่าที่อยากได้นี่แหละจุดขายที่ AWS ชอบเอามาพูด แต่ irony ที่ว่ามันละเอียดไปจนทำให้สุดท้ายต้องประกอบสิ่งที่ไม่ได้อยากจะแคร์ เพื่อให้ได้สิ่งที่อยากได้ (เช่นพวก role พวก IAM ก็เข้าใจว่าทำไมต้องทำได้ละเอียดขนาดนั้น เพราะมันไปเกี่ยวโยงกับทุกๆอย่างเลย แต่เราก็ไม่ได้ใช้ทุกๆอย่าง อย่างอื่น)

Firebase ที่ว่า “Everything you need to build and grow your app, all in one place.” เลยเป็น strong point มากๆ