การเลือกเทคโนโลยีฐานข้อมูลแบบไร้เซิร์ฟเวอร์ใหม่ที่เอเจนซี่ (กรณีศึกษา)

บทความนี้ได้รับการสนับสนุนอย่างดีจากเพื่อนรักของเราที่ Fauna ซึ่งทำให้การทำงานกับข้อมูลการปฏิบัติงานมีประสิทธิผล ปรับขนาดได้ และปลอดภัยสำหรับทีมพัฒนาซอฟต์แวร์ทุกทีม ขอขอบคุณ!

การใช้เทคโนโลยีใหม่เป็นหนึ่งในการตัดสินใจที่ยากที่สุดสำหรับนักเทคโนโลยีในบทบาทความเป็นผู้นำ ซึ่งมักจะเป็นพื้นที่เสี่ยงที่ใหญ่และไม่สบายใจ ไม่ว่าคุณจะกำลังสร้างซอฟต์แวร์สำหรับองค์กรอื่นหรือภายในองค์กรของคุณเอง

ตลอด 12 ปีที่ผ่านมาในฐานะวิศวกรซอฟต์แวร์ ฉันพบว่าตัวเองอยู่ในตำแหน่งที่ต้อง ประเมินเทคโนโลยีใหม่ ที่เพิ่มความถี่ขึ้น นี่อาจเป็นเฟรมเวิร์กส่วนหน้าถัดไป ภาษาใหม่ หรือแม้แต่สถาปัตยกรรมใหม่ทั้งหมด เช่น แบบไร้เซิร์ฟเวอร์

ขั้นตอนการทดลองมักจะสนุกและน่าตื่นเต้น เป็นที่ที่วิศวกรซอฟต์แวร์อยู่ที่บ้านมากที่สุด โดยเปิดรับความแปลกใหม่และความสนุกสนานในช่วงเวลา "aha" ขณะที่คร่ำครวญแนวคิดใหม่ ในฐานะวิศวกร เราชอบที่จะคิดและปรับแต่ง แต่ด้วยประสบการณ์ที่เพียงพอ วิศวกรทุกคนได้เรียนรู้ว่าแม้แต่เทคโนโลยีที่เหลือเชื่อที่สุดก็ยังมีรอยตำหนิ คุณยังไม่พบพวกเขา

ตอนนี้ในฐานะผู้ร่วมก่อตั้งบริษัทครีเอทีฟเอเจนซี่ ฉันและฉันมักจะอยู่ในตำแหน่งที่ไม่เหมือนใครในการใช้เทคโนโลยีใหม่ เราเห็นโครงการกรีนฟิลด์จำนวนมากซึ่งกลายเป็นโอกาสที่ดีในการแนะนำสิ่งใหม่ โครงการเหล่านี้ยังมองเห็นระดับการแยกตัวทางเทคนิคจากองค์กรขนาดใหญ่ และมักจะได้รับภาระน้อยลงจากการตัดสินใจก่อนหน้านี้

ดังที่กล่าวไปแล้ว หัวหน้าหน่วยงานที่ดีได้รับความไว้วางใจให้ดูแลความคิดที่ยิ่งใหญ่ของคนอื่นและนำเสนอต่อโลก เราต้องรักษามันด้วยความระมัดระวังมากกว่าที่จะทำโครงการของเราเอง เมื่อใดก็ตามที่ฉันกำลังจะโทรหาเทคโนโลยีใหม่ ฉันมักจะไตร่ตรองความรู้ชิ้นนี้จากผู้ร่วมก่อตั้ง Stack Overflow Joel Spolski:

“คุณต้องเสียเหงื่อและเสียเลือดไปกับสิ่งนี้เป็นเวลาหนึ่งปีหรือสองปีก่อนที่คุณจะรู้ว่ามันดีพอหรือตระหนักว่าต่อให้คุณพยายามมากแค่ไหนคุณก็ทำไม่ได้…”

นี่คือความกลัว ที่ซึ่งไม่มีหัวหน้าฝ่ายเทคโนโลยีคนไหนอยากเข้าไปค้นหา การเลือกเทคโนโลยีใหม่สำหรับโครงการในโลกแห่งความเป็นจริงนั้นยากพอ แต่ในฐานะหน่วยงาน คุณต้องตัดสินใจร่วมกับโครงการของคนอื่น ความฝันของคนอื่น เงินของคนอื่น ที่เอเจนซี่ สิ่งสุดท้ายที่คุณต้องการคือค้นหาจุดบกพร่องเหล่านั้นใกล้เส้นตายสำหรับโครงการ ไทม์ไลน์และงบประมาณที่รัดกุมทำให้ แทบจะเป็นไปไม่ได้เลยที่จะย้อนกลับเส้นทาง หลังจากผ่านเกณฑ์ที่กำหนด ดังนั้นการค้นหาเทคโนโลยีไม่สามารถทำอะไรที่สำคัญหรือไม่น่าเชื่อถือสายเกินไปในโครงการอาจเป็นหายนะ

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

ดังที่กล่าวไปแล้ว หน่วยงานยังมีข้อจำกัดบางอย่างที่องค์กรเดียวอาจไม่มี เราต้องลำเอียงเพื่อประสิทธิภาพและความมั่นคง ชั่วโมงที่เรียกเก็บเงินได้มักจะเป็นหน่วยวัดสุดท้ายเมื่อโครงการเสร็จสมบูรณ์ ฉันเคยอยู่ที่บริษัท SaaS ที่ใช้เวลาหนึ่งหรือสองวันในการตั้งค่าหรือสร้างไปป์ไลน์ไม่ใช่เรื่องใหญ่

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

เมื่อประเมินเทคโนโลยีชิ้นใหม่ ฉันจะพิจารณาสามส่วนที่ครอบคลุม:

1. เทคโนโลยี
2. ประสบการณ์ของนักพัฒนา
3. ธุรกิจ

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

เทคโนโลยี

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

ฉันจะถามคำถามกับตัวเองเช่น:

1. อย่างน้อยก็แก้ปัญหาที่โซลูชันที่มีอยู่ของฉันทำอยู่หรือไม่
2. วิธีแก้ปัญหานี้ดีกว่าในทางใด?
3. ในทางใดที่เลวร้ายกว่ากัน?
4. สำหรับด้านที่แย่กว่านั้น จะต้องทำอย่างไรจึงจะเอาชนะข้อบกพร่องเหล่านั้นได้?
5. มันจะมาแทนที่เครื่องมือหลายอย่างหรือไม่?
6. เทคโนโลยีมีความเสถียรแค่ไหน?

ของเรา ทำไม?

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

ลองใช้ React เป็นตัวอย่าง เหตุใดเราจึงตัดสินใจใช้ React เมื่อ jQuery หรือ Vanilla JavaScript ทำงานอยู่? ในกรณีนี้ การใช้เฟรมเวิร์กเน้นว่าวิธีนี้เป็นวิธีที่ดีกว่ามากในการจัดการส่วนหน้าแบบเก็บสถานะ การสร้างสิ่งต่างๆ เช่น การกรองและการจัดเรียง คุณลักษณะด้วยการทำงานกับโครงสร้างข้อมูล แทนการจัดการ DOM โดยตรงนั้นเร็วขึ้นสำหรับเรา ซึ่งช่วยประหยัดเวลาและเพิ่มความเสถียรให้กับโซลูชันของเรา

typescript เป็นอีกตัวอย่างหนึ่งที่เราตัดสินใจนำมาใช้เนื่องจากเราพบว่าความเสถียรของโค้ดและความสามารถในการบำรุงรักษาเพิ่มขึ้น ด้วยการนำเทคโนโลยีใหม่มาใช้ มักจะไม่มีปัญหาที่ชัดเจนที่เราต้องการจะแก้ไข แต่เพียงแค่มองหาการรักษาให้เป็นปัจจุบันและค้นหาวิธีแก้ปัญหาที่มีประสิทธิภาพและมีเสถียรภาพมากกว่าที่เรากำลังใช้อยู่ในปัจจุบัน

ในกรณีของฐานข้อมูล เรากำลังพิจารณาที่จะย้ายไปยัง ตัวเลือกแบบไร้เซิร์ฟเวอร์ โดยเฉพาะ เราได้เห็นความสำเร็จมากมายกับแอปพลิเคชันแบบไร้เซิร์ฟเวอร์และการปรับใช้ซึ่งลดค่าใช้จ่ายของเราในฐานะองค์กร ด้านหนึ่งที่เรารู้สึกว่าขาดสิ่งนี้คือชั้นข้อมูลของเรา เราเห็นบริการต่างๆ เช่น Amazon Aurora, Fauna, Cosmos และ Firebase ที่ใช้หลักการแบบไร้เซิร์ฟเวอร์กับฐานข้อมูล และต้องการดูว่าถึงเวลาที่เราต้องก้าวกระโดดหรือไม่ ในกรณีนี้ เราต้องการลดค่าใช้จ่ายในการดำเนินงานและเพิ่มความเร็วและประสิทธิภาพในการพัฒนา

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

ที่เราเคยไป…

ในฐานะหน่วยงาน ก่อนหน้านี้เราได้ใช้ฐานข้อมูลที่หลากหลาย ซึ่งรวมถึงแต่ไม่จำกัดเพียง MySQL, PostgreSQL, MongoDB, DynamoDB, BigQuery และ Firebase Cloud Storage งานส่วนใหญ่ของเรามีศูนย์กลางอยู่ที่ฐานข้อมูลหลักสามฐานข้อมูล ได้แก่ PostgreSQL, MongoDB และ Firebase Realtime Database อันที่จริงแต่ละข้อเหล่านี้มีข้อเสนอแบบกึ่งเซิร์ฟเวอร์ แต่คุณสมบัติหลักบางประการของข้อเสนอที่ใหม่กว่าทำให้เราประเมินสมมติฐานก่อนหน้าของเราอีกครั้ง ลองมาดูประสบการณ์ในอดีตของเรากับสิ่งเหล่านี้ก่อน และเหตุผลที่เราเหลือการพิจารณาทางเลือกตั้งแต่แรก

โดยทั่วไปเราเลือก PostgreSQL สำหรับโครงการขนาดใหญ่และระยะยาว เนื่องจากเป็นมาตรฐานทองคำที่ผ่านการทดสอบการต่อสู้สำหรับเกือบทุกอย่าง รองรับการทำธุรกรรมแบบคลาสสิก ข้อมูลมาตรฐาน และเป็นไปตามข้อกำหนดของ ACID มีเครื่องมือและ ORM มากมายในเกือบทุกภาษา และยังสามารถใช้เป็นฐานข้อมูล Ad-hoc NoSQL ด้วยการสนับสนุนคอลัมน์ JSON มันรวมเข้ากับเฟรมเวิร์ก ไลบรารี และภาษาโปรแกรมที่มีอยู่มากมาย ทำให้กลายเป็นอุปกรณ์พกพาไปได้ทุกที่อย่างแท้จริง นอกจากนี้ยังเป็นโอเพ่นซอร์สและด้วยเหตุนี้จึงไม่ทำให้เราถูกขังอยู่ในผู้ขายรายใดรายหนึ่ง อย่างที่พวกเขาพูดกัน ไม่มีใครถูกไล่ออกเพราะเลือก Postgres

ดังที่กล่าวไปแล้ว เราค่อยๆ พบว่าตัวเองใช้ PostgreSQL น้อยลงเรื่อยๆ เมื่อเรากลายเป็นร้านค้าที่เน้นโหนดมากขึ้น เราพบว่า ORM's สำหรับ Node นั้นขาดความดแจ่มใสและต้องการการสืบค้นที่กำหนดเองมากขึ้น (แม้ว่าตอนนี้จะมีปัญหาน้อยลงแล้วก็ตาม) และ NoSQL รู้สึกว่ามีความเหมาะสมตามธรรมชาติมากขึ้นเมื่อทำงานในรันไทม์ JavaScript หรือ TypeScript ดังที่กล่าวไปแล้ว เรามักมีโครงการที่สามารถทำได้อย่างรวดเร็วด้วย การสร้างแบบจำลองเชิงสัมพันธ์แบบคลาสสิก เช่น เวิร์กโฟลว์อีคอมเมิร์ซ อย่างไรก็ตาม การจัดการกับการตั้งค่าฐานข้อมูลในเครื่อง การรวมขั้นตอนการทดสอบระหว่างทีม และการโยกย้ายถิ่นฐานเป็นสิ่งที่เราไม่ชอบและยินดีที่จะทิ้งไว้เบื้องหลัง เนื่องจาก NoSQL ฐานข้อมูลบนคลาวด์กลายเป็นที่นิยมมากขึ้น

MongoDB ได้เพิ่มฐานข้อมูลของเรามากขึ้นเมื่อเรานำ Node.js เป็นแบ็กเอนด์ที่เราต้องการ การทำงานกับ MongoDB Atlas ช่วยให้พัฒนาและทดสอบฐานข้อมูลได้อย่างรวดเร็วซึ่งทีมของเราสามารถใช้ได้ ชั่วขณะหนึ่ง MongoDB ไม่สอดคล้องกับ ACID ไม่สนับสนุนธุรกรรม และไม่สนับสนุนการดำเนินการที่เหมือนการเข้าร่วมภายในมากเกินไป ดังนั้นสำหรับแอปพลิเคชันอีคอมเมิร์ซ เรายังคงใช้ Postgres บ่อยที่สุด ดังที่กล่าวไปแล้ว มีห้องสมุดมากมายที่เข้ากันได้ ภาษาคิวรีของ Mongo และการรองรับ JSON ระดับเฟิร์สคลาสทำให้เรามีความเร็วและประสิทธิภาพที่เราไม่เคยเจอกับฐานข้อมูลเชิงสัมพันธ์ MongoDB ได้เพิ่มการรองรับสำหรับธุรกรรม ACID เมื่อเร็ว ๆ นี้ แต่นี่เป็นเหตุผลหลักที่เราเลือกใช้ Postgres แทนเป็นเวลานาน

MongoDB ยังแนะนำให้เรารู้จักกับความยืดหยุ่นในระดับใหม่ ท่ามกลางโครงการเอเจนซี่ ข้อกำหนดต่างๆ ย่อมมีการเปลี่ยนแปลง ไม่ว่าคุณจะป้องกันมันยากแค่ไหน ก็มี ข้อกำหนดด้านข้อมูลในนาทีสุดท้าย อยู่เสมอ ด้วยฐานข้อมูล NoSQL โดยทั่วไป ความยืดหยุ่นของโครงสร้างข้อมูลทำให้การเปลี่ยนแปลงประเภทนั้นรุนแรงน้อยลง เราไม่ได้ลงเอยด้วยโฟลเดอร์ที่เต็มไปด้วยไฟล์การโยกย้ายเพื่อจัดการที่เพิ่มและลบและเพิ่มคอลัมน์อีกครั้งก่อนที่โครงการจะเห็นแสงตะวัน

ในฐานะบริการ Mongo Atlas ก็ค่อนข้างใกล้เคียงกับสิ่งที่เราต้องการในบริการฐานข้อมูลบนคลาวด์ ฉันชอบคิดว่า Atlas เป็นข้อเสนอ แบบกึ่ง ไม่มีเซิร์ฟเวอร์ เนื่องจากคุณยังมีค่าใช้จ่ายในการดำเนินการในการจัดการ คุณต้องจัดเตรียมฐานข้อมูลขนาดหนึ่งและเลือกจำนวนหน่วยความจำล่วงหน้า สิ่งเหล่านี้จะไม่ปรับขนาดสำหรับคุณโดยอัตโนมัติ ดังนั้น คุณจะต้องตรวจสอบเมื่อถึงเวลาที่จะเพิ่มพื้นที่หรือหน่วยความจำให้มากขึ้น ในฐานข้อมูลแบบไร้เซิร์ฟเวอร์อย่างแท้จริง ทั้งหมดนี้จะเกิดขึ้นโดยอัตโนมัติและตามความต้องการ

เรายังใช้ฐานข้อมูลเรียลไทม์ของ Firebase สำหรับบางโปรเจ็กต์ด้วย นี่เป็นข้อเสนอแบบไร้เซิร์ฟเวอร์ที่ฐานข้อมูลขยายขนาดขึ้นและลงตามต้องการ และด้วย การกำหนดราคาแบบจ่ายตามการใช้ งาน มันจึงสมเหตุสมผลสำหรับแอปพลิเคชันที่ไม่ทราบมาตราส่วนล่วงหน้าและงบประมาณมีจำกัด เราใช้สิ่งนี้แทน MongoDB สำหรับโปรเจ็กต์อายุสั้นที่มีข้อกำหนดด้านข้อมูลอย่างง่าย

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

โดยทั่วไป ทั้ง MongoDB และ Firebase ต่างก็ให้ ความสำคัญกับข้อมูลที่ ไม่ปกติ และไม่สามารถเข้าถึงธุรกรรมที่มีประสิทธิภาพได้ เรามักจะพบเวิร์กโฟลว์จำนวนมากที่ง่ายต่อการสร้างโมเดลในฐานข้อมูลเชิงสัมพันธ์ ซึ่งทำให้โค้ดที่ซับซ้อนขึ้นที่ชั้นแอปพลิเคชันด้วย คู่หู NoSQL หากเราได้รับความยืดหยุ่นและความสะดวกของข้อเสนอ NoSQL เหล่านี้ด้วยความแข็งแกร่งและการสร้างแบบจำลองเชิงสัมพันธ์ของฐานข้อมูล SQL แบบเดิม เราจะพบว่าคู่กันที่ยอดเยี่ยมจริงๆ เรารู้สึกว่า MongoDB มี API และความสามารถที่ดีกว่า แต่ Firebase มีโมเดลแบบไร้เซิร์ฟเวอร์อย่างแท้จริงในการดำเนินงาน

อุดมคติของเรา

ณ จุดนี้ เราสามารถเริ่มดูว่าเราจะพิจารณาตัวเลือกใหม่ๆ อะไรบ้าง เราได้กำหนดโซลูชันก่อนหน้านี้ไว้อย่างชัดเจน และเราได้ระบุสิ่งที่สำคัญสำหรับเราอย่างน้อยต้องมีในโซลูชันใหม่ของเรา เราไม่เพียงแต่มีข้อกำหนดพื้นฐานหรือชุดข้อกำหนดขั้นต่ำเท่านั้น แต่ยังมีชุดของปัญหาที่เราต้องการให้โซลูชันใหม่บรรเทาทุกข์ให้กับเราด้วย นี่คือ ข้อกำหนดทางเทคนิค ที่เรามี:

1. ทำงานแบบไร้เซิร์ฟเวอร์ด้วยมาตราส่วนตามความต้องการ
2. การสร้างแบบจำลองที่ยืดหยุ่น (แบบไม่มีสคีมา)
3. ไม่มีการพึ่งพาการโยกย้ายถิ่นฐานหรือ ORMs
4. ธุรกรรมที่สอดคล้องกับ ACID
5. รองรับความสัมพันธ์และข้อมูลที่ทำให้เป็นมาตรฐาน
6. ทำงานร่วมกับทั้งแบ็กเอนด์แบบไม่มีเซิร์ฟเวอร์และแบบเดิม

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

ตัวอย่างจากโดเมนอื่นคือถ้าคุณต้องการให้มีการตรวจสอบความถูกต้องของ typescript ในการแสดงเทมเพลตของคุณ คุณต้องใช้ TSX และ React หากคุณเลือกใช้ตัวเลือกต่างๆ เช่น Svelte หรือ Vue คุณสามารถทำสิ่งนี้ได้ — บางส่วนแต่ไม่ทั้งหมด — ผ่านการ แสดงเทมเพลต ดังนั้น โซลูชันที่ให้รอยเท้าขนาดเล็กและความเร็วของ Svelte ด้วยการตรวจสอบประเภทระดับเทมเพลตของ React และ TypeScript อาจเพียงพอสำหรับการนำไปใช้ แม้ว่าจะขาดคุณสมบัติอื่นก็ตาม ความสมดุลของความต้องการและความต้องการจะเปลี่ยนจากโครงการหนึ่งไปอีกโครงการหนึ่ง มันขึ้นอยู่กับคุณแล้วที่จะรู้ว่ามูลค่าจะอยู่ที่ใดและตัดสินใจว่าจะทำเครื่องหมายจุดที่สำคัญที่สุดในการวิเคราะห์ของคุณอย่างไร

ตอนนี้เราสามารถดูโซลูชันและดูว่ามีการประเมินเทียบกับโซลูชันที่ต้องการอย่างไร Fauna เป็น โซลูชันฐานข้อมูลแบบไร้เซิร์ฟเวอร์ ซึ่งมีขนาดตามความต้องการพร้อมการกระจายทั่วโลก เป็นฐานข้อมูลแบบไม่มีสคีมา ซึ่งจัดเตรียมธุรกรรมที่สอดคล้องกับ ACID และสนับสนุนการสืบค้นเชิงสัมพันธ์และข้อมูลที่ทำให้เป็นมาตรฐานเป็นคุณลักษณะ Fauna สามารถใช้ได้ทั้งในแอปพลิเคชันแบบไร้เซิร์ฟเวอร์และแบ็กเอนด์แบบดั้งเดิม และให้ไลบรารี่สามารถทำงานกับภาษายอดนิยมได้ Fauna ยังจัดเตรียมเวิร์กโฟลว์สำหรับการรับรองความถูกต้องรวมถึงการเช่าหลายรายที่ง่ายและมีประสิทธิภาพ คุณลักษณะเหล่านี้เป็นทั้งคุณลักษณะเพิ่มเติมที่ควรทราบเนื่องจากอาจเป็นปัจจัยที่โยกเยกเมื่อเทคโนโลยีทั้งสองแบบจมูกต่อจมูกในการประเมินของเรา

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

ในโลกของเอเจนซี่ การ ล็อคอินของผู้ขาย เป็นสิ่งที่เราต้องจับตาดูอย่างใกล้ชิด ไม่มากเพราะราคา แต่ความสามารถในการดำรงอยู่ของธุรกิจพื้นฐานนั้นสำคัญ การเปลี่ยนฐานข้อมูลในโครงการที่อยู่ในระหว่างการพัฒนาหรืออายุไม่กี่ปีนั้นทั้งความหายนะสำหรับหน่วยงาน บ่อยครั้งที่ลูกค้าจะต้องรับผิดชอบในเรื่องนี้ ซึ่งไม่ใช่การสนทนาที่น่ายินดี

จุดอ่อนอีกประการหนึ่งที่เรากังวลคือการมุ่งเน้นที่ JAMstack ในขณะที่เรารัก JAMstack เราพบว่าตนเองกำลังสร้างเว็บแอปพลิเคชันแบบดั้งเดิมที่หลากหลายขึ้นบ่อยขึ้น เราต้องการให้แน่ใจว่า Fauna ยังคงสนับสนุนกรณีการใช้งานเหล่านั้นต่อไป ในอดีตเราเคยมีประสบการณ์ที่ไม่ดีกับผู้ให้บริการโฮสติ้งที่ใช้งาน JAMstack แบบ all-in และสุดท้ายเราต้องย้ายไซต์จำนวนมากออกจากบริการ ดังนั้นเราจึงต้องการรู้สึกมั่นใจว่ากรณีการใช้งานทั้งหมดจะยังคงเห็นต่อไป การสนับสนุนที่มั่นคง ในตอนนี้ ดูเหมือนว่าจะเป็นเช่นนั้นแล้ว และเวิร์กโฟลว์แบบไร้เซิร์ฟเวอร์ที่ Fauna จัดหาให้สามารถเสริมแอปพลิเคชันแบบเดิม ๆ ได้ค่อนข้างดี

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

ประสบการณ์ของนักพัฒนา

การตัดสินด้านประสบการณ์ของเทคโนโลยีใหม่อาจเป็นสิ่งที่ยากที่สุดในสามด้านเนื่องจากเป็นเรื่องส่วนตัว นอกจากนี้ยังจะมีความแปรปรวนในแต่ละทีม ตัวอย่างเช่น หากคุณถามโปรแกรมเมอร์ Ruby, โปรแกรมเมอร์ Python และโปรแกรมเมอร์ Rust เกี่ยวกับความคิดเห็นของพวกเขาเกี่ยวกับคุณลักษณะภาษาต่างๆ คุณจะได้รับคำตอบค่อนข้างมาก ดังนั้น ก่อนที่คุณจะเริ่มตัดสินประสบการณ์ คุณต้องตัดสินใจก่อนว่าคุณลักษณะใดที่สำคัญที่สุดสำหรับทีมของคุณโดยรวม

สำหรับเอเจนซี่ ฉันคิดว่ามี ปัญหาคอขวดที่สำคัญสองประการ ที่เกี่ยวกับประสบการณ์ของนักพัฒนา:

1. ตั้งค่าเวลาและการกำหนดค่า
2. ความสามารถในการเรียนรู้

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

ตั้งค่าเวลาและการกำหนดค่า

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

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

สิ่งหนึ่งที่ดีในการทำงานกับแพลตฟอร์มระบบคลาวด์ที่ไม่ใช่โอเพ่นซอร์สคือพวกเขาเป็นเจ้าของการตั้งค่าและการกำหนดค่าทั้งหมด แม้ว่าข้อเสียของสิ่งนี้คือการล็อคอินของผู้ขาย แต่ข้อดีคือเครื่องมือประเภทนี้มักจะทำในสิ่งที่พวกเขาได้รับการตั้งค่าให้ทำได้ดี ไม่มีการแก้ไขสภาพแวดล้อม ไม่มีการตั้งค่าในเครื่อง และไม่มีไปป์ไลน์การปรับใช้ นอกจากนี้เรายังมีการตัดสินใจน้อยลง

นี่คือ เสน่ห์ของเซิร์ฟเวอร์ไร้เซิร์ฟเวอร์ โดยเนื้อแท้ โดยทั่วไป Serverless มีการพึ่งพาบริการและเครื่องมือที่เป็นกรรมสิทธิ์มากขึ้น เราแลกเปลี่ยนความยืดหยุ่นของการโฮสต์และซอร์สโค้ดเพื่อให้เรามีเสถียรภาพมากขึ้นและมุ่งเน้นไปที่ปัญหาของโดเมนธุรกิจที่เรากำลังพยายามแก้ไข นอกจากนี้ ฉันยังจะทราบด้วยว่าเมื่อประเมินเทคโนโลยีและรู้สึกว่าอาจจำเป็นต้องย้ายออกจากแพลตฟอร์ม ซึ่งมักจะเป็นสัญญาณที่ไม่ดีในตอนแรก

ในกรณีของฐานข้อมูล การตั้งค่า set-it-and-forget-it นั้นเหมาะอย่างยิ่งเมื่อทำงานกับไคลเอนต์ที่ฐานข้อมูลอาจมีความคลุมเครือ เรามีลูกค้าที่ไม่แน่ใจว่าโปรแกรมหรือแอปพลิเคชันจะได้รับความนิยมเพียงใด เรามีลูกค้าที่ทางเทคนิคแล้วเราไม่ได้ทำสัญญาให้การสนับสนุนในลักษณะนี้ แต่ถึงกระนั้นก็โทรหาเราด้วยความตื่นตระหนกเมื่อพวกเขาต้องการให้เราปรับขนาดฐานข้อมูลหรือแอปพลิเคชันของพวกเขา

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

คุณจะไม่มีวันสูญเสียข้อมูล คุณไม่ต้องกังวลกับการจำลองข้อมูลในเครือข่าย หรือจัดเตรียมฐานข้อมูลและเครื่องขนาดใหญ่ขึ้นเพื่อใช้งาน ทั้งหมดนี้ก็ใช้ได้ เรามุ่งเน้นที่ปัญหาทางธุรกิจในมือเท่านั้น สถาปัตยกรรมทางเทคนิคและขนาดจะได้รับการจัดการเสมอ สำหรับทีมพัฒนาของเรา นี่เป็นชัยชนะครั้งใหญ่ เรามีการฝึกซ้อมดับเพลิง การเฝ้าติดตาม และการเปลี่ยนบริบทน้อยลง

ความสามารถในการเรียนรู้

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

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

สิ่งที่ฉันมองหาโดยเฉพาะที่นี่คือวิธีที่เราสามารถใช้ประโยชน์จากความรู้และรูปแบบที่เรารู้อยู่แล้วเพื่อช่วยย่นช่วงการเรียนรู้ให้สั้นลง ตัวอย่างเช่น ด้วยฐานข้อมูลแบบไร้เซิร์ฟเวอร์ แทบไม่มีช่วงการเรียนรู้ใดๆ สำหรับการตั้งค่าในระบบคลาวด์และนำไปใช้งาน เมื่อพูดถึงการใช้ฐานข้อมูล สิ่งหนึ่งที่ฉันชอบคือเมื่อเรายังคงสามารถใช้ประโยชน์จากการเรียนรู้ ฐานข้อมูลเชิงสัมพันธ์ เป็นเวลาหลายปี และนำการเรียนรู้เหล่านั้นไปใช้กับการตั้งค่าใหม่ของเรา ในกรณีนี้ เรากำลังเรียนรู้วิธีการใช้เครื่องมือใหม่ แต่ไม่ได้บังคับให้เราต้องคิดใหม่เกี่ยวกับการสร้างแบบจำลองข้อมูลของเราตั้งแต่ต้น

จากตัวอย่างนี้ เมื่อใช้ Firebase, MongoDB และ DynamoDB เราพบว่า สนับสนุนข้อมูลที่ ไม่ปกติ แทนที่จะพยายามรวมเอกสารต่างๆ สิ่งนี้ทำให้เกิดความขัดแย้งทางปัญญาอย่างมากเมื่อสร้างแบบจำลองข้อมูลของเราในขณะที่เราต้องคิดในแง่ของรูปแบบการเข้าถึงมากกว่าหน่วยงานทางธุรกิจ ในอีกด้านหนึ่งของ Fauna นี้ช่วยให้เราสามารถใช้ประโยชน์จากความรู้เชิงสัมพันธ์ที่สั่งสมมานานหลายปี เช่นเดียวกับความชอบของเราสำหรับข้อมูลที่ทำให้เป็นมาตรฐาน เมื่อพูดถึงการสร้างแบบจำลองข้อมูล

ส่วนที่เราต้องคุ้นเคยคือการ ใช้ดัชนี และภาษาการสืบค้นใหม่เพื่อนำชิ้นส่วนเหล่านั้นมารวมกัน โดยทั่วไปแล้ว ฉันพบว่าการรักษาแนวคิดที่เป็นส่วนหนึ่งของกระบวนทัศน์การออกแบบซอฟต์แวร์ที่ใหญ่ขึ้นทำให้ทีมพัฒนาง่ายขึ้นในแง่ของความสามารถในการเรียนรู้และการนำไปใช้

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

ธุรกิจ

ในส่วนนี้ เราต้องดูว่าเทคโนโลยีใหม่ตอบ สนองความต้องการทางธุรกิจ ของเราได้อย่างไร ซึ่งรวมถึงคำถามเช่น:

• สามารถกำหนดราคาและรวมเข้ากับแผนการสนับสนุนของเราได้ง่ายเพียงใด?
• เราสามารถเปลี่ยนเป็นลูกค้าได้อย่างง่ายดายหรือไม่?
• ลูกค้าสามารถเข้าร่วมเครื่องมือนี้ได้หรือไม่หากจำเป็น
• เครื่องมือนี้ช่วยประหยัดเวลาได้จริงแค่ไหน ถ้ามี?

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

ในเรื่องนี้ เรามี ผู้รับเหมา DevOps ที่พร้อมเสมอ แต่อย่ารับพนักงานประจำตำแหน่งเหล่านี้ ซึ่งหมายความว่าเราไม่สามารถพึ่งพาวิศวกร DevOps ให้พร้อมที่จะก้าวไปสู่ปัญหาที่ไม่คาดคิด สำหรับเรา เราทราบราคาโฮสติ้งที่ดีขึ้นโดยไปที่ AWS โดยตรง แต่เราก็ทราบด้วยว่าการใช้ Heroku ทำให้เราวางใจพนักงานที่มีอยู่เพื่อแก้ปัญหาส่วนใหญ่ได้ เว้นแต่ว่าเรามีลูกค้า เราจำเป็นต้องสนับสนุนระยะยาวกับความต้องการแบ็กเอนด์ที่เฉพาะเจาะจง เราต้องการค่าเริ่มต้นเป็นแพลตฟอร์มที่มีการจัดการเป็นบริการ

ฐานข้อมูลก็ไม่มีข้อยกเว้น เราชอบที่จะใช้บริการเช่น Mongo Atlas หรือ Heroku Postgres เพื่อให้กระบวนการนี้ง่ายที่สุด เมื่อเราเริ่มเห็นสแต็กเฮดของเรามากขึ้นเรื่อยๆ เกี่ยวกับเครื่องมือไร้เซิร์ฟเวอร์ เช่น Vercel, Netlify หรือ AWS Lambda ฐานข้อมูลของเราต้องพัฒนาไปพร้อม ๆ กับสิ่งนั้น ฐานข้อมูล แบบไร้เซิร์ฟเวอร์ เช่น Firebase, DynamoDB และ Fauna นั้นยอดเยี่ยมเพราะรวมเข้ากับแอปแบบไร้เซิร์ฟเวอร์ได้ดี แต่ยังช่วยให้ธุรกิจของเราไม่ต้องเตรียมการและปรับขนาดอย่างสมบูรณ์

โซลูชันเหล่านี้ยังทำงานได้ดีสำหรับแอปพลิเคชันแบบเดิม โดยที่เราไม่มีแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ แต่เรายังสามารถใช้ประโยชน์จากประสิทธิภาพแบบไร้เซิร์ฟเวอร์ได้ที่ระดับฐานข้อมูล ในฐานะธุรกิจ เราจะมีประสิทธิผลมากกว่าในการเรียนรู้ฐานข้อมูลเดียวที่สามารถนำไปใช้กับทั้งสองโลกมากกว่าการสลับบริบท ซึ่งคล้ายกับการตัดสินใจของเราที่จะใช้ Node และ isomorphic JavaScript (และ TypeScript)

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

เป็นเรื่องยากที่จะแปลเป็นตัวเลขที่แน่นอนแม้กระทั่งสำหรับวิศวกร เนื่องจากเรามักจะสร้างแอปพลิเคชันที่เรา ไม่แน่ใจว่าการใช้งานจะเป็น อย่างไร เรามักจะต้องสร้างระดับด้วยตัวเอง แต่ตัวแปรมากมายที่นำมาใช้ในการคำนวณต้นทุนของแลมบ์ดาอาจเป็นเรื่องยากที่จะคาดเดา ในท้ายที่สุด สำหรับผลิตภัณฑ์ SaaS โมเดลการกำหนดราคาแบบจ่ายตามการใช้งานนั้นยอดเยี่ยม แต่สำหรับเอเจนซี่ นักบัญชีชอบตัวเลขที่เป็นรูปธรรมและคาดการณ์ได้มากขึ้น

เมื่อพูดถึง Fauna สิ่งนี้คลุมเครือมากกว่าการพูดฐานข้อมูล MySQL มาตรฐานที่มีโฮสติ้งอัตราคงที่สำหรับพื้นที่ที่กำหนดไว้ ข้อดีคือ Fauna ให้เครื่องคิดเลขที่ดีที่เราสามารถใช้เพื่อรวบรวมแผนการกำหนดราคาของเราเองได้

อีกแง่มุมที่ยากของ Serverless คือผู้ให้บริการเหล่านี้จำนวนมาก ไม่อนุญาตให้แบ่ง แอปพลิเคชันแต่ละรายการที่โฮสต์โดยง่าย ตัวอย่างเช่น แพลตฟอร์ม Heroku ทำให้สิ่งนี้ค่อนข้างง่ายโดยการสร้างไปป์ไลน์และทีมใหม่ เราสามารถป้อนบัตรเครดิตของลูกค้าให้พวกเขาได้ในกรณีที่พวกเขาไม่ต้องการใช้แผนโฮสติ้งของเรา ทั้งหมดนี้สามารถทำได้ภายในแดชบอร์ดเดียวกัน ดังนั้นเราจึงไม่จำเป็นต้องสร้างข้อมูลเข้าสู่ระบบหลายรายการ

เมื่อพูดถึงเครื่องมือไร้เซิร์ฟเวอร์อื่น ๆ สิ่งนี้ยากกว่ามาก ในการประเมินฐานข้อมูลแบบไร้เซิร์ฟเวอร์ Firebase รองรับ การแบ่งการชำระเงินตามโครงการ ในกรณีของ Fauna หรือ DynamoDB เป็นไปไม่ได้ ดังนั้นเราจึงต้องดำเนินการตรวจสอบการใช้งานในแดชบอร์ด และหากลูกค้าต้องการออกจากบริการของเรา เราจะต้องโอนฐานข้อมูลไปยังบัญชีของตนเอง

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

บทสรุป

การนำเทคโนโลยีใหม่มาใช้เป็นหน่วยงานอาจเป็นเรื่องยาก ในขณะที่เราอยู่ในตำแหน่งที่ไม่เหมือนใครในการทำงานกับโครงการสีเขียวใหม่ที่มีโอกาสสำหรับเทคโนโลยีใหม่ เราต้องพิจารณาการลงทุนระยะยาวของสิ่งเหล่านี้ด้วย พวกเขาจะทำอย่างไร? คนของเราจะมีประสิทธิภาพและสนุกกับการใช้พวกเขาหรือไม่? Can we incorporate them into our business offering?

You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it's important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses – the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.

After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity , however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.

Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you'll find levels of productivity you hadn't realized before with existing databases.

When we first use a new technology on a project, we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds understanding of the technology, we start using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past.

In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don't get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.

อ่านเพิ่มเติม

• Serverless Database Wishlist - What's Missing Today
• Relational NoSQL: Yes, that is an option
• Concerning toolkits - A great piece about the merits of zero configuration on developer experience