Data science

ความเป็นคู่ของ DBaaS: เพื่อนหรือศัตรู?

คลิกเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับผู้แต่ง Matt Yonkovit ไฟป่าเป็นพลังอันทรงพลังของธรรมชาติ สามารถทำลายล้างได้อย่างมหาศาล แต่ยังมีศักยภาพที่จะทำให้เกิดชีวิตใหม่และอำนวยความสะดวกในการเติบโตในเชิงบวก ข้อเสนอฐานข้อมูลในฐานะบริการบนคลาวด์มีความคล้ายคลึงกัน พลังของระบบคลาวด์ได้เปลี่ยนแปลงโครงสร้างพื้นฐานด้านเทคโนโลยีของเรา ไม่มีที่ใดที่ชัดเจนไปกว่าการเพิ่มขึ้นของข้อเสนอฐานข้อมูลบนคลาวด์ ข้อเสนออันทรงพลังเหล่านี้ (เช่น Amazon Aurora, Azure SQL, Google Cloud SQL และ MongoDB Atlas) ได้กลายเป็นวิธียอดนิยมอย่างรวดเร็วสำหรับผู้คนในการเรียกใช้ฐานข้อมูลของตนในระบบคลาวด์ นอกจากนี้ยังมีความท้าทายและปัญหาที่อาจเกิดขึ้นหากไม่ได้ใช้หรือปรับใช้อย่างถูกต้อง ใน Magic Quadrant ล่าสุด Gartner ได้ตั้งสมมติฐานเชิงกลยุทธ์ว่า 20% ของฐานข้อมูลทั้งหมดจะถูกปรับใช้หรือย้ายไปยังแพลตฟอร์มคลาวด์ โดยมีเพียง 5% เท่านั้นที่ถือว่าส่งกลับประเทศ สู่ภายในองค์กร โดย 2023 การตั้งค่าสำหรับการจัดการข้อมูลในระบบคลาวด์จะลดจำนวนผู้ขายที่อยู่รอบ ๆ ในขณะที่มัลติคลาวด์จะทำให้สิ่งต่าง ๆ ซับซ้อนมากขึ้นเกี่ยวกับการกำกับดูแลข้อมูลและการผสานรวม นักพัฒนามักมีความสัมพันธ์ที่ไม่ค่อยดี (อย่างดีที่สุด) กับฐานข้อมูลของตน ฐานข้อมูลถือเป็นสิ่งชั่วร้ายที่จำเป็นต่อการสร้างแอปพลิเคชัน ความขัดแย้งระหว่าง DBA และนักพัฒนามักเกิดจากแต่ละกลุ่มมีเป้าหมายและผลลัพธ์ที่แตกต่างกัน DBA ต้องคำนึงถึงความยั่งยืน ความปลอดภัย ความพร้อมใช้งาน และความสามารถในการปรับขนาดในระยะยาว ในทางกลับกัน ผู้พัฒนาคิดเกี่ยวกับคุณสมบัติ กำหนดการวางจำหน่าย และผู้ใช้ Database-as-a-service (DBaaS) สัญญาว่าจะขจัดความกังวลเกี่ยวกับความยั่งยืน ความปลอดภัย และความพร้อมใช้งานโดยอัตโนมัติ มันทำให้อำนาจในการเลือกและใช้งานฐานข้อมูลอยู่ในมือของนักพัฒนา ทำให้พวกเขาเคลื่อนไหวอย่างรวดเร็วและเก็บเกี่ยวรางวัล แต่ในขณะที่โซลูชันฐานข้อมูลเป็นบริการช่วยขจัดงานทางโลกส่วนใหญ่ในการกำหนดค่าและใช้งานฐานข้อมูล พวกเขามักจะมุ่งเน้นไปที่ผลไม้ที่แขวนอยู่ต่ำสุด สิ่งนี้ทำให้กิจกรรมฐานข้อมูลการบริหารหรือการแก้ไขปัญหาที่ซับซ้อนมากขึ้นสำหรับนักพัฒนาและ/หรือ DBA ตัวอย่างเช่น คุณอาจมีเครื่องมือในการสำรองข้อมูลหรือเข้ารหัสข้อมูลของคุณ แต่คุณตั้งค่าอย่างถูกต้องหรือหลีกเลี่ยงข้อผิดพลาดทั่วไปหรือไม่ ในช่วงไม่กี่ปีที่ผ่านมา หลายบริษัทได้พาดหัวข่าวเพราะข้อมูลของพวกเขาตกไปอยู่ในมือของแฮกเกอร์ อย่างไรก็ตาม ตรงกันข้ามกับแบบแผนของแฮ็กเกอร์คอมพิวเตอร์ที่คอยดักฟังโค้ดในแล็ปท็อปอย่างเมามัน การละเมิดเหล่านี้มักเป็นผลมาจากบริษัทต่างๆ ที่ไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด หรือไม่เข้าใจข้อจำกัดของเทคโนโลยีที่พวกเขาปรับใช้ แหล่งที่มาของการรั่วไหลที่พบบ่อยที่สุดอย่างหนึ่งคือบัคเก็ต S3 ที่ไม่มีการป้องกันซึ่งมีไฟล์สำรอง เพียงเพราะคุณสามารถคลิกปุ่มสำรองข้อมูลไม่ได้หมายความว่าข้อมูลสำรองของคุณได้รับการเข้ารหัสหรือป้องกันอย่างเหมาะสม ในบางกรณีสามารถกู้คืนได้ นี่คือเหตุผลที่คุณยังต้องการแหล่งข้อมูลที่มุ่งมั่นและมีความรู้พร้อมให้คำแนะนำเกี่ยวกับความเสี่ยงที่อาจเกิดขึ้น เนื่องจากปัญหาเหล่านี้กำลังเกิดขึ้นบ่อยขึ้น ผู้จำหน่ายฐานข้อมูลและผู้ให้บริการระบบคลาวด์จึงเพิ่มคุณสมบัติเพื่อช่วยบรรเทาหรือแก้ไขปัญหาเหล่านี้ อย่างไรก็ตาม ปัญหาที่ลึกที่สุดและมีผลกระทบมากที่สุดจำนวนมากยังคงอิงตามสถาปัตยกรรมของแอปพลิเคชันและวิธีตั้งค่าฐานข้อมูลสำหรับแอปพลิเคชันเฉพาะ นี่คือที่มาของแนวคิดเรื่อง “ความรับผิดชอบร่วมกัน” ผู้ให้บริการระบบคลาวด์มอบส่วนประกอบฐานข้อมูลพื้นฐานให้คุณเพื่อสร้างแอปพลิเคชันที่ปลอดภัยและปรับขนาดได้ ไม่ได้หมายความว่าแอปพลิเคชันของคุณสามารถปรับขนาดได้และปลอดภัย บ่อยครั้งที่เราพบว่าความคิด “ตั้งค่าและลืม” ต่อฐานข้อมูล (หรือมากกว่าความคิด “เป็นความรับผิดชอบของผู้ให้บริการของฉัน”) ทำให้ผู้ใช้มีค่าใช้จ่ายที่สูงขึ้นและทำงานเป็นจำนวนมากในระยะยาว รายงานล่าสุดจาก Andressen Horowitz เน้นย้ำถึงค่าใช้จ่ายที่อาจสูงขึ้นของระบบคลาวด์ จากประสบการณ์ของผม ต้นทุนฐานข้อมูลมักจะเป็นเปอร์เซ็นต์ที่สูงกว่าตามสัดส่วนของการใช้จ่ายทั้งหมดมากกว่าที่คุณคาดไว้ ค่าใช้จ่ายที่เพิ่มขึ้นเหล่านี้มักเป็นผลมาจากบริษัทต่างๆ ที่แก้ปัญหาฐานข้อมูลผ่านการปรับขนาดด้วยบัตรเครดิต (การย้ายไปยังขนาดอินสแตนซ์ถัดไป เพิ่มพื้นที่จัดเก็บ ฯลฯ) นี่เป็นเศรษฐกิจที่ผิดพลาดและสามารถหมุนวนได้อย่างรวดเร็ว ด้วยการใช้การออกแบบ การจัดการ และการสนับสนุนฐานข้อมูลที่เหมาะสม ต้นทุนสามารถลดลงได้ถึง % ค่าใช้จ่ายกันเป็นวินาที มีบางประเด็นสำคัญที่คุณควรคำนึงถึงเมื่อพิจารณาฐานข้อมูลในฐานะบริการ Database-as-a-service ดีสำหรับนักพัฒนาและผู้ใช้ และดียิ่งขึ้นสำหรับฐานข้อมูลและผู้จำหน่ายระบบคลาวด์ (โดยเฉพาะในพื้นที่โอเพ่นซอร์ส) อย่างไรก็ตาม สิ่งสำคัญที่ต้องตระหนักว่า คุณมักจะต้องแลกกับการควบคุมและการพกพา เพื่อความสะดวกในการติดตั้งและใช้งาน คุณอาจเคยได้ยินคำว่า “ล็อคอิน” ที่กล่าวถึงในชุมชนโอเพ่นซอร์ส การล็อคอินของผู้ขายหมายถึงสถานการณ์ที่คุณพบเมื่อคุณเริ่มใช้ผู้ขายและจบลงด้วยการติดอยู่กับพวกเขา เว้นแต่คุณจะผ่านกระบวนการที่ยาวนานและมีค่าใช้จ่ายสูงในการพัฒนาส่วนต่างๆ ของแอปพลิเคชันของคุณ (ลองนึกถึงเพลง “Hotel California”: “คุณสามารถเช็คอินได้ แต่คุณไม่สามารถออกไปได้”) Oracle ใน 1990 มีชื่อเสียงที่ไม่ดีในการกักขังผู้คนไว้ แล้วเล่นเกมด้วยใบอนุญาตและค่าใช้จ่าย อันที่จริง ประสบการณ์เชิงลบนั้นเป็นแรงผลักดันให้คนในองค์กรเริ่มสำรวจฐานข้อมูลโอเพนซอร์สเป็นทางเลือก หากเราไม่ระวัง DBaaS อาจส่งผลให้มีการล็อคอินในระดับสูงสุด 20 ปีที่ผ่านมา โอเพ่นซอร์สเป็นหนึ่งในเครื่องมือที่ทรงพลังที่สุดที่ผู้ใช้มีในการต่อต้านการล็อคอินและการฉ้อฉลในอุตสาหกรรมเทคโนโลยี โดยเฉพาะอย่างยิ่งในพื้นที่ฐานข้อมูล ตัวอย่างเช่น หากคุณต้องการเรียกใช้ MySQL หรือ PostgreSQL คุณมีตัวเลือก คุณสามารถเลือกวิธีเรียกใช้ ตำแหน่งที่คุณเรียกใช้ และประเภทของสแต็กที่คุณใช้ คุณสามารถปรับใช้ MySQL บน Azure Compute ได้ในวันนี้ และในสัปดาห์หน้า คุณสามารถปรับใช้ MySQL เดียวกันบน AWS EC2 และมีประสบการณ์ที่คล้ายคลึงกัน การพกพาระดับนี้มีประโยชน์อย่างยิ่งสำหรับแอปพลิเคชันใหม่เหล่านั้นที่ออกแบบมาเป็น “คลาวด์เนทีฟ” โดยที่แอปพลิเคชันเองก็สามารถพกพาได้มากขึ้นผ่านการออกแบบ การเพิ่มขึ้นของแอปพลิเคชันระบบคลาวด์ที่ทำงานบนคอนเทนเนอร์ผ่าน Kubernetes แยกแอปพลิเคชันออกจากผู้ให้บริการโครงสร้างพื้นฐาน การพกพาและความสามารถในการทำงานได้ทุกที่กลายเป็นความคาดหวังของการออกแบบแอปพลิเคชันบนระบบคลาวด์ อย่างไรก็ตาม คุณค่าบางประการของการพกพานี้มาจากทั้งการออกแบบโอเพ่นซอร์สและแอปพลิเคชันสามารถชดเชยหรือบดบังได้ด้วยการเติบโตของข้อเสนอฐานข้อมูลในฐานะบริการ ผู้ให้บริการระบบคลาวด์หลายรายเสนอข้อเสนอ DBaaS ที่คล้ายคลึงกัน แต่ไม่เหมือนกันทุกประการ ซึ่งจะจำกัดความสามารถในการพกพา Amazon Aurora มีข้อแตกต่างของคุณสมบัติและปัญหาความเข้ากันได้กับ MySQL เวอร์ชันต่างๆ พวกเขาใกล้เคียงกัน แต่ไม่ 100% เหมือนกัน … ดังนั้นการอ้างสิทธิ์ของ Aurora ว่าเป็น “โอเพ่นซอร์สที่เข้ากันได้” แต่ละขั้นตอนใน MySQL หรือ PostgreSQL DBaaS ของผู้ขายทำให้การย้ายไปยังผู้ขายรายอื่นหรือแม้แต่เวอร์ชันที่มีการจัดการของคุณเองยากขึ้นเล็กน้อย นี่อาจเป็นปัญหาหรือไม่ก็ได้ ขึ้นอยู่กับระดับการพกพาที่แอปพลิเคชันของคุณต้องการ หากคุณสบายใจที่จะทำงานบนผู้ให้บริการระบบคลาวด์เพียงรายเดียว ข้อเสนอ DBaaS เหล่านี้จำนวนมากสามารถให้คุณค่าที่ดีได้ด้วยการเร่งความเร็วในการจัดการและปรับใช้ นอกเหนือจากความแตกต่างทางเทคนิคแล้ว ผู้จำหน่ายฐานข้อมูลจำนวนมากยังปกป้องกระแสรายได้ “ในฐานะบริการ” ของตนด้วยการย้ายไปยังใบอนุญาตฐานข้อมูลที่ไม่ใช่โอเพ่นซอร์สภายใต้หน้ากากเพื่อป้องกันไม่ให้ผู้ให้บริการระบบคลาวด์ขโมยธุรกิจและสร้างรายได้จากงานเดิมของตน Server Side Public License (SSPL) เป็นตัวอย่างที่ชัดเจนของสิ่งนี้ MongoDB สร้างใบอนุญาตนี้เพื่อแยกผู้อื่นออกจากการสร้างข้อเสนอ “เป็นบริการ” ที่แข่งขันกับ MongoDB (โดยเฉพาะผลิตภัณฑ์ Atlas ของพวกเขา) และ MongoDB ไม่ใช่คนเดียว Elastic เพิ่งเปลี่ยนใบอนุญาตด้วยเหตุผลเดียวกัน การเคลื่อนไหวเหล่านี้จำกัดตัวเลือกของผู้ใช้ ผลลัพธ์ที่ได้คือ แทนที่จะใช้ซอฟต์แวร์โอเพนซอร์ซ ตอนนี้เรามีผู้จำหน่ายรายเดียวที่ให้บริการฐานข้อมูลที่มีการจัดการอัตโนมัติโดยมีค่าธรรมเนียม ผู้จำหน่ายฐานข้อมูลรายเดียวกันกำลังปรับปรุง DBaaS ของตนด้วยคุณสมบัติและตัวเลือกพิเศษเฉพาะ ตัวอย่างเช่น Atlas ได้ประกาศบริการใหม่ Atlas Online Archive ที่อนุญาตให้จัดเก็บข้อมูลที่ใช้น้อยใน S3 หรือที่จัดเก็บข้อมูลที่ช้ากว่า สิ่งนี้สามารถลดต้นทุนได้อย่างดีและช่วยเร่งประสิทธิภาพด้วยการแยกระบบที่มีข้อมูลที่ไม่ได้ใช้ ในฐานะที่เป็นคุณลักษณะในตัว ผู้ใช้ควรใช้ประโยชน์จากคุณลักษณะนี้ เนื่องจากเป็นวิธีที่ง่าย สม่ำเสมอ และดูเหมือนราบรื่นในการจัดการกับปัญหาที่มีมาช้านาน ดังที่ได้กล่าวไว้ นี่เป็นตัวอย่างการซื้อขายที่ “ง่าย” เพื่อการพกพาและการควบคุมในอนาคต บริษัท/แอปพลิเคชันสามารถทำสิ่งที่คล้ายคลึงกันได้โดยการสร้างรูทีนการเก็บถาวรหรือกระบวนการเพื่อจัดการกับสิ่งนี้ แต่ในปัจจุบันไม่มีโอเพ่นซอร์สที่เทียบเท่ากับคุณลักษณะนี้ ดังนั้น หากคุณตัดสินใจที่จะหยุดจ่ายเงินสำหรับ MongoDB Atlas คุณจะสูญเสียการเข้าถึงและจะต้องเขียนส่วนต่างๆ ของแอปพลิเคชันของคุณใหม่เพื่อจัดการกับฟังก์ชันที่ขาดหายไปในขณะนี้ ซึ่งคล้ายกับซอฟต์แวร์ที่เป็นกรรมสิทธิ์อื่นๆ (อีกครั้ง ให้คิดว่า Oracle ใน '90' ประโยชน์มหาศาลของโอเพ่นซอร์สคือหากเราไม่เห็นคุณค่าในการจ่ายเงินให้กับผู้ขายหรือการสมัครรับข้อมูล เรามีตัวเลือกในการนำธุรกิจของเราไปที่อื่น หากคุณไม่พึงพอใจกับผู้ให้บริการ PostgreSQL ของคุณ มีตัวเลือกอีกมากมายให้เลือก เนื่องจากผู้ค้าโอเพ่นซอร์ส (หรือก่อนหน้านี้เป็นโอเพ่นซอร์ส) ย้ายลงมาตามเส้นทาง DBaaS ฟีเจอร์ เครื่องมือ และซอฟต์แวร์ของพวกเขาจะพร้อมใช้งานผ่านข้อเสนอ DBaaS เท่านั้น ซึ่งหมายความว่าผู้ใช้ที่ต้องการปรับใช้เวอร์ชันของตนเองจะค่อยๆ เหลือเวอร์ชันที่เก่ากว่า มีความสามารถน้อยกว่า และมีคุณลักษณะน้อยกว่า นอกจากนี้ยังมีความเสี่ยงที่นวัตกรรมจะชะลอตัวลง เนื่องจากการมีส่วนร่วมของชุมชนในซอฟต์แวร์ DBaaS นั้นเป็นไปไม่ได้จริงๆ (คุณไม่มีสิทธิ์เข้าถึงโค้ดแบบเต็ม) DBaaS ไม่ดีหรือไม่? เลขที่! ไม่เลย. DBaaS ให้ประโยชน์ที่ยอดเยี่ยมแก่ผู้ใช้และผู้ขาย ฐานข้อมูลใดๆ ที่สร้างขึ้นในวันนี้จะพิจารณา Cloud-native และ DBaaS เสนอวิธีการปรับใช้แบบ go-to ผู้ใช้สามารถเริ่มต้นได้อย่างง่ายดาย มุ่งเน้นที่นวัตกรรมสำหรับธุรกิจของพวกเขา และรับประสบการณ์ที่สอดคล้องกัน ทั้งหมดนี้เป็นชัยชนะครั้งใหญ่ อย่างไรก็ตาม ชัยชนะเหล่านี้ไม่ได้ขัดขืนความจำเป็นในการมีความเชี่ยวชาญและความรู้พร้อมให้คำแนะนำวิธีที่ดีที่สุดในการออกแบบและสร้างส่วนต่อประสานระหว่างแอปพลิเคชันและฐานข้อมูล การเพิกเฉยต่อช่องว่างความรู้ที่สำคัญเหล่านี้ทำให้เกิดความเสี่ยง (เช่น ต้นทุนที่สูงขึ้นและการหยุดทำงานและการรั่วไหลที่อาจเกิดขึ้น) สิ่งสำคัญคือต้องเข้าใจด้วยว่าคุณอาจไม่มีอุปกรณ์พกพาที่คุณคุ้นเคยอีกต่อไป ในโลกใหม่นี้ คุณไม่เพียงแต่มุ่งมั่นที่จะใช้เทคโนโลยีเท่านั้น แต่ยังเป็นผู้ขายอีกด้วย วิธีที่ชุมชนมีวิวัฒนาการและทิศทางของ DBaaS จะเป็นตัวกำหนดว่าผู้ขายรายใดที่ถือว่าน่าเชื่อถือ และผู้ขายรายใดจะเป็นคำเตือนเตือนใจของคนรุ่นต่อไป

  • บ้าน
  • Business
  • Data science
  • Marketing
  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Back to top button