หากคุณยังคงสงสัยว่าสถาปัตยกรรมไมโครเซอร์วิสมีอิทธิพลต่อการพัฒนาแอปพลิเคชันในปัจจุบัน ถึงเวลาแล้วที่จะต้องเอาชนะมัน ตาม InfoBrief ใหม่ของ IDC เกี่ยวกับ ผลกระทบของการปรับแอปพลิเคชันให้ทันสมัยบนชั้นข้อมูล ซึ่งสนับสนุนโดย Redis 89% ของผู้ตอบแบบสำรวจองค์กร 300 รายในอเมริกาเหนือกำลังใช้ไมโครเซอร์วิสอยู่แล้ว และนั่นก็อยู่เหนือการคาดการณ์ของ IDC ในปี 2019 ที่ว่า “ภายในปี 2022 90% ของแอพใหม่ทั้งหมดจะมีสถาปัตยกรรมไมโครเซอร์วิส”
ปัจจุบันโมเมนตัมของ Microservices ไม่อาจปฏิเสธได้ โดยได้รับแรงหนุนจากความต้องการขององค์กรในการพัฒนา ปรับใช้ และอัปเดตแอปและบริการคุณภาพสูงอย่างรวดเร็วยิ่งขึ้น เพื่อตอบสนองความต้องการของลูกค้าและธุรกิจที่เพิ่มมากขึ้นเรื่อยๆ ตามข้อมูลของ InfoBrief “แอปไมโครเซอร์วิสถูกใช้ในบทบาทที่มีความสำคัญต่อธุรกิจอยู่แล้ว โดย 24% ของแอปไมโครเซอร์วิสระบุว่ามีความสำคัญต่อธุรกิจ” ตัวอย่างเช่น สำหรับแอปไมโครเซอร์วิสเกือบครึ่งหนึ่ง (42%) การหยุดทำงานทำให้สูญเสียรายได้
แต่นั่นไม่ได้หมายความว่าการปฏิวัติไมโครเซอร์วิสจะเสร็จสมบูรณ์ อันที่จริง มันเพิ่งเริ่มต้น จากผลสำรวจของ IDC พบว่าองค์กรทั้งหมดที่เปิดรับไมโครเซอร์วิสกำลังทำเช่นนั้น โดยมีเพียง 17% ของพอร์ตแอปของพวกเขาที่ย้ายออกจากเสาหินแล้ว Carl W. Olofson และ Gary Chen ผู้เขียน InfoBrief อธิบายสถานการณ์อย่างกระชับ:“แม้ว่าการพัฒนาแอปพลิเคชันบนไมโครเซอร์วิสจะยังอยู่ในช่วงเริ่มต้น แต่ความสำคัญในการพัฒนาในอนาคตนั้นชัดเจน”
เรียนรู้เพิ่มเติม: อ่าน Redis Microservices สำหรับ Dummies อีบุ๊ก
ชั้นข้อมูลผสานความซับซ้อนสำหรับสถาปัตยกรรมไมโครเซอร์วิส
ดังนั้น จะต้องทำอย่างไรจึงจะบรรลุผลตามคำมั่นสัญญาของสถาปัตยกรรมไมโครเซอร์วิส และองค์กรต่างๆ ต้องเผชิญกับความท้าทายอะไรบ้างเมื่อพวกเขายอมรับไมโครเซอร์วิส การนำไมโครเซอร์วิสมาใช้สามารถเพิ่มความซับซ้อนได้อย่างมาก โดยเฉพาะอย่างยิ่งเมื่อพูดถึงชั้นข้อมูล จากการสำรวจพบว่าเกือบครึ่งหนึ่งของแอพไมโครเซอร์วิสขององค์กร (47%) พึ่งพาฐานข้อมูล แต่เกือบหนึ่งในสามของผู้ตอบแบบสอบถาม (31.5%) กล่าวถึงการจัดการฐานข้อมูลว่าเป็นความท้าทายสามอันดับแรก “การแยกส่วนแอปพลิเคชันจะเพิ่มจำนวนองค์ประกอบทางลอจิคัลที่ต้องได้รับการจัดการอย่างทวีคูณ” ผู้เขียนกล่าว
ซึ่งอาจทำให้ข้อมูลถูกกักเก็บ ซับซ้อน และมีราคาแพง ทำให้องค์กรจำนวนมากสรุปได้ว่าการประสานกันเป็นสิ่งสำคัญในการปรับใช้ไมโครเซอร์วิส ดังนั้นจึงไม่น่าแปลกใจที่ประมาณหนึ่งในสามของผู้ตอบแบบสอบถามระบุว่าลดต้นทุนการจัดการและเพิ่มประสิทธิภาพการดำเนินงาน (35.6%) และสนับสนุนแอปพลิเคชันคลาวด์เนทีฟหรือไมโครเซอร์วิสรุ่นใหม่ (33.2%) เป็นตัวขับเคลื่อนสามอันดับแรกของการปรับใช้การประสานกัน
การเลือกฐานข้อมูลที่เหมาะสมสำหรับสถาปัตยกรรมไมโครเซอร์วิสของคุณ
ตัวอย่างเช่น โซลูชันอีคอมเมิร์ซอาจใช้บริการหลายอย่าง เช่น เซิร์ฟเวอร์แอปพลิเคชัน แคชเนื้อหา ที่เก็บเซสชัน แคตตาล็อกผลิตภัณฑ์ การค้นหาและการค้นพบ การประมวลผลคำสั่งซื้อ การปฏิบัติตามคำสั่งซื้อ การวิเคราะห์ และอื่นๆ อีกมากมาย และแต่ละบริการอาจมี ฐานข้อมูลของตัวเองดังแสดงในแผนภาพด้านล่าง:
คุณจะเลือกและสร้างแอปพลิเคชันด้วยสถาปัตยกรรมที่เหมาะสมได้อย่างไร คุณต้องมองหาลักษณะใด? การวิจัยชี้ให้เห็นถึงสี่สิ่งสำคัญที่ต้องมี มาดูกันดีกว่า:
1. ความสำคัญของประสิทธิภาพ
ตามที่ IDC ระบุไว้ “มากกว่า 95% ของผู้ตอบแบบสอบถามชอบประเภทฐานข้อมูลหรือประสิทธิภาพเป็นเกณฑ์” และเกือบครึ่งของผู้ตอบแบบสำรวจ (45%) อ้างถึงประสิทธิภาพเป็นปัจจัยสามอันดับแรก (ประเภทฐานข้อมูลต่อท้ายเท่านั้น) เมื่อเลือกฐานข้อมูล ไม่น่าแปลกใจเลยที่ประสิทธิภาพมีความสำคัญมาก เนื่องจากในสภาพแวดล้อมไมโครเซอร์วิส คุณต้องการทั้งประสิทธิภาพแบบเรียลไทม์และความสามารถในการปรับขนาดเพื่อที่จะส่งมอบสถาปัตยกรรมแบบกระจายได้อย่างเต็มที่
Redis ขึ้นชื่อว่าเป็นฐานข้อมูลที่ได้รับความนิยมสูงสุดติดต่อกัน 4 ปี เป็นที่รู้จักกันดีในด้านประสิทธิภาพการทำงานในระดับย่อยมิลลิวินาที ด้วยฐานข้อมูลที่มีเวลาแฝงต่ำของ Redis Enterprise คุณสามารถสร้างประสบการณ์ผู้ใช้แบบทันทีหรือทำการวิเคราะห์ตามเวลาจริงในขณะที่ยังคงรักษาพื้นที่ขนาดเล็กไว้ด้วยความสามารถในการปรับขนาดแบบออนดีมานด์ ตามที่ InfoBrief บันทึกไว้ว่า “สิ่งนี้บ่งชี้ว่าวิธีทำงานและดำเนินการของฐานข้อมูลมีความสำคัญต่อความสำเร็จในการพัฒนาแอปพลิเคชันไมโครเซอร์วิส”
เรียนรู้เพิ่มเติม: ดูใหม่ของเรา เวลาแฝงคือการหยุดทำงานครั้งใหม่ กระดาษสีขาว
2. พร้อมเสมอ
การสำรวจของ IDC เปิดเผยว่าเกือบหนึ่งในสี่ (24%) ของแอปพลิเคชันไมโครเซอร์วิสระดับองค์กรถูกใช้ไปแล้วในบทบาทที่สำคัญต่อธุรกิจ ซึ่งมีความพร้อมใช้งานสูงเป็นสิ่งสำคัญ โดยทั่วไป "สำหรับ 42% ของแอปไมโครเซอร์วิส การประสบปัญหาการหยุดทำงานส่งผลให้องค์กรสูญเสียรายได้โดยตรง" InfoBrief กล่าว ในขณะที่การหยุดทำงานในแอปที่เหลืออีก 58% จะทำให้ประสิทธิภาพการทำงานลดลง
นั่นเป็นปัญหาใหญ่ที่อาจเกิดขึ้นได้ เนื่องจากแม้ว่าสถาปัตยกรรมไมโครเซอร์วิสจะรวมบริการที่เชื่อมต่ออยู่มากมาย แต่ก็ต้องเผชิญกับความต้องการด้านประสิทธิภาพและความน่าเชื่อถือเช่นเดียวกับแนวทางการพัฒนาอื่นๆ การตรวจสอบให้มั่นใจว่าข้อมูลของคุณจะพร้อมใช้งานทั่วโลกอยู่เสมอเป็นความท้าทายอีกประการหนึ่ง ตัวอย่างเช่น เพื่อให้แน่ใจว่าแอปพลิเคชันของคุณยังคงใช้งานได้ตลอดเวลา คุณต้องมีฐานข้อมูลที่ทนทานต่อข้อผิดพลาดในทุกระดับ
เรียนรู้เพิ่มเติม: ดูว่า Redis Enterprise เป็นอย่างไร เทคโนโลยีที่มีความพร้อมใช้งานสูง รับประกันเวลาทำงานสี่-เก้า (99.99%)—และห้าเก้า (99.999%) ใน แอ็คทีฟ-แอ็คทีฟ การทำให้ใช้งานได้แบบกระจายตามพื้นที่
3. ใช้ประโยชน์จากโมเดลข้อมูลหลายตัวเพื่อสร้างแอปพลิเคชันที่ทันสมัย
นักพัฒนาใช้ประโยชน์จากสถาปัตยกรรมไมโครเซอร์วิสเพื่อสร้างแอปที่ดีขึ้น การเลือกโมเดลข้อมูลที่เหมาะสมเป็นสิ่งสำคัญสำหรับการเร่งเวลาออกสู่ตลาด และที่สำคัญกว่านั้นคือการปรับให้เหมาะสม รูปแบบการเข้าถึงข้อมูลและข้อกำหนดด้านประสิทธิภาพ ด้วยวิธีนี้ แต่ละบริการสามารถใช้ฐานข้อมูลที่สร้างขึ้นตามวัตถุประสงค์สำหรับโมเดลข้อมูลของตนเองได้
ไมโครเซอร์วิสอาจใช้แบบจำลองข้อมูลตามคีย์-ค่า กราฟ JSON อนุกรมเวลา และเครื่องมือค้นหา เป็นต้น แต่นั่นหมายความว่า “ไมโครเซอร์วิสจำนวนมากจะใช้ฐานข้อมูลต่อบริการ” บันทึกย่อของ InfoBrief ซึ่ง “เพิ่มจำนวนฐานข้อมูล จำนวนส่วนประกอบซอฟต์แวร์ที่เข้าถึงฐานข้อมูล และความจำเป็นในการรวมฐานข้อมูลในเวิร์กโฟลว์สมัยใหม่” ด้วยเหตุนี้ ดังที่กล่าวไว้ข้างต้น การจัดการฐานข้อมูลด้วยแอปไมโครเซอร์วิสจึงเป็นความท้าทายสามอันดับแรกสำหรับผู้ตอบแบบสอบถามเกือบหนึ่งในสาม (32%)
เพื่อลดความซับซ้อนนี้ ฐานข้อมูลของคุณควรสนับสนุนโมเดลข้อมูลหลายแบบ ทำให้ง่ายสำหรับสถาปนิกองค์กรในการเลือกรูปแบบข้อมูลที่เหมาะสมสำหรับแต่ละบริการโดยไม่ต้องเสียสละประสิทธิภาพหรือต้องเรียนรู้และบำรุงรักษาฐานข้อมูลต่างๆ มากมาย ซึ่งทำให้การดำเนินงานง่ายขึ้นและช่วยจำกัดการแพร่กระจายของเทคโนโลยี
เรียนรู้เพิ่มเติม: ดูกระดาษ สีขาวของเราที่ ความยืดหยุ่นของข้อมูลเชิงกลยุทธ์
4. ปรับใช้ได้ทุกที่
แม้ว่า DBaaS จะได้รับโมเมนตัม ข้อมูลองค์กรจำนวนมากยังคงอยู่ในองค์กร ทำให้องค์กรจำนวนมากใช้โครงสร้างพื้นฐานคลาวด์และไฮบริดที่หลากหลาย ดังที่แสดงในการสำรวจของ IDC ในสภาพแวดล้อมไมโครเซอร์วิส คุณต้องมีความสามารถในการปรับชั้นข้อมูลให้เหมาะสมเพื่อให้มีความยืดหยุ่นในการเรียกใช้ฐานข้อมูลของคุณโดยไม่มีไซโลหรือข้อมูลสูญหาย
แต่ตามที่ผู้เขียน IDC ชี้ให้เห็น "ฐานข้อมูลจำนวนมากไม่ได้ออกแบบมาให้เป็นระบบคลาวด์ เข้ากันได้กับคอนเทนเนอร์ หรือจัดการโดย Kubernetes" การบรรจุฐานข้อมูลภายในคอนเทนเนอร์เพียงอย่างเดียว ไม่ได้ทำให้เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิส ฐานข้อมูลต้องมีน้ำหนักเบาและปรับแต่งได้เพื่อตอบสนองความต้องการข้อมูลของคุณ
องค์กรต่างๆ ต้องการแพลตฟอร์มฐานข้อมูลที่มีรูปแบบการปรับใช้ที่ยืดหยุ่นเพื่อเรียกใช้ได้ทุกที่ที่ต้องการ ไม่ว่าจะเป็นในสถานที่หรือในคลาวด์ใดๆ ในสถาปัตยกรรมมัลติคลาวด์หรือไฮบริดคลาวด์ ในคอนเทนเนอร์ หรือเป็น Kubernetes Pod
เรียนรู้เพิ่มเติม: เช็คเอาท์ ตัวเลือกการปรับใช้ซอฟต์แวร์ Redis Enterprise
Redis Enterprise และไมโครเซอร์วิส
ตามรายงาน การเพิ่มขึ้นของสถาปัตยกรรมไมโครเซอร์วิสส่งผลกระทบอย่างมีนัยสำคัญต่อสถาปัตยกรรมชั้นข้อมูลที่ใช้เพื่อสนับสนุนบริการเหล่านี้ ดังนั้นองค์กรที่ต้องการพัฒนาแอปพลิเคชันโดยใช้สถาปัตยกรรมไมโครเซอร์วิสควรให้ความสนใจเป็นพิเศษกับความเป็นเลิศทางเทคนิคและเหมาะสมกับวัตถุประสงค์ นั่นคือสิ่งที่ Redis Enterprise โดดเด่น
Redis Enterprise นำเสนอประสิทธิภาพในระดับไมโครเซอร์วิส ให้เวลาแฝงระดับต่ำกว่ามิลลิวินาทีสำหรับประเภทข้อมูลและโมดูล Redis ทั้งหมด และความสามารถในการปรับขนาดทันทีและเชิงเส้นจนถึงปริมาณงานที่ต้องการ ออกแบบมาเพื่อความทนทานต่อข้อผิดพลาดและความยืดหยุ่น Redis Enterprise ใช้สถาปัตยกรรมคลัสเตอร์ที่ไม่มีการแชร์ข้อมูล และนำเสนอการเฟลโอเวอร์อัตโนมัติที่ระดับกระบวนการ สำหรับแต่ละโหนด และแม้แต่ข้ามโซนความพร้อมใช้งานของโครงสร้างพื้นฐาน ตลอดจนการคงอยู่แบบปรับได้และการกู้คืนจากความเสียหาย Redis Enterprise ยังช่วยให้นักพัฒนาสามารถเลือกโมเดลข้อมูลที่เหมาะสมกับความต้องการด้านประสิทธิภาพและการเข้าถึงข้อมูลมากที่สุดสำหรับการปรับใช้สถาปัตยกรรมไมโครเซอร์วิสของตน ในขณะที่ยังคงรักษาอินเทอร์เฟซการปฏิบัติงานแบบรวมเป็นหนึ่งเพื่อจำกัดการแผ่ขยายของเทคโนโลยีและทำให้การดำเนินงานง่ายขึ้น สิ่งสำคัญอย่างยิ่งคือ Redis Enterprise สามารถติดตั้งได้ทุกที่ ไม่ว่าจะเป็นบนแพลตฟอร์มระบบคลาวด์ ในองค์กร หรือในสถาปัตยกรรมคลาวด์แบบมัลติคลาวด์หรือไฮบริด
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับความสำคัญของชั้นข้อมูลในการปรับใช้ไมโครเซอร์วิส ให้ดาวน์โหลด IDC InfoBrief—ผลกระทบของการปรับแอปพลิเคชันให้ทันสมัยบนชั้นข้อมูล . และดูทรัพยากรสถาปัตยกรรมไมโครเซอร์วิสด้านล่างเพื่อดูข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับวิธีที่ Redis Enterprise เหมาะอย่างยิ่งสำหรับการปรับใช้ไมโครเซอร์วิส:
- Redis Enterprise สำหรับไมโครเซอร์วิส
- อีบุ๊ก Redis Microservices for Dummies
- Latency Is the New Outage สมุดปกขาว
- เอกสารรายงานความยืดหยุ่นของข้อมูลเชิงกลยุทธ์
- ตัวเลือกการปรับใช้ซอฟต์แวร์ Redis Enterprise
- วิธีที่ Redis ลดความซับซ้อนของรูปแบบการออกแบบ Microservices—บล็อกโพสต์ใหม่ของ Stack
