โครงสร้างพื้นฐานสมัยใหม่: ปัญหาและแนวโน้ม

ในตอนท้ายของเดือนพฤษภาคม เรา ได้จัดประชุมออนไลน์ในหัวข้อ “โครงสร้างพื้นฐานและคอนเทนเนอร์สมัยใหม่: ปัญหาและโอกาส”. เราได้พูดคุยเกี่ยวกับคอนเทนเนอร์ Kubernetes และการจัดระบบในหลักการ เกณฑ์ในการเลือกโครงสร้างพื้นฐาน และอื่นๆ อีกมากมาย ผู้เข้าร่วมแบ่งปันกรณีจากการปฏิบัติของตนเอง

ผู้เข้าร่วม:

• Evgeniy Potapov ซีอีโอของ ITSumma. ลูกค้ามากกว่าครึ่งหนึ่งกำลังเปลี่ยนมาใช้ Kubernetes อยู่แล้วหรือต้องการเปลี่ยนมาใช้ Kubernetes
• Dmitry Stolyarov, CTO "Flant". มีประสบการณ์ 10 ปีขึ้นไปในการทำงานกับระบบคอนเทนเนอร์
• Denis Remchukov (หรือที่รู้จักในชื่อ Eric Oldmann), COO argotech.io, อดีต RAO UES. เขาสัญญาว่าจะพูดคุยเกี่ยวกับคดีในองค์กรที่ "นองเลือด"
• Andrey Fedorovsky, CTO “News360.com”หลังจากซื้อบริษัทโดยผู้เล่นรายอื่น เขาจะรับผิดชอบโครงการ ML และ AI และโครงสร้างพื้นฐานจำนวนหนึ่ง
• อีวาน ครูลอฟ วิศวกรระบบ อดีต Booking.comคนเดียวกับที่ทำ Kubernetes ด้วยมือของเขาเองมากมาย

ธีม:

• ข้อมูลเชิงลึกของผู้เข้าร่วมเกี่ยวกับคอนเทนเนอร์และการจัดประสาน (Docker, Kubernetes ฯลฯ ) สิ่งที่ได้ทดลองในทางปฏิบัติหรือวิเคราะห์
• กรณี: บริษัทกำลังจัดทำแผนพัฒนาโครงสร้างพื้นฐานมาหลายปี มีการตัดสินใจอย่างไรว่าจะสร้าง (หรือย้ายโครงสร้างพื้นฐานปัจจุบัน) ไปยังคอนเทนเนอร์และ Kuber หรือไม่
• ปัญหาในโลก Cloud-Native อะไรที่ขาดหายไป ลองจินตนาการดูว่าพรุ่งนี้จะเกิดอะไรขึ้น

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

Kubernetes เป็นการตลาดมาตรฐานหรือเป็นเลิศอยู่แล้ว?

“เรามาถึงแล้ว (Kubernetes. - Ed.) ตอนที่ยังไม่มีใครรู้เรื่องนี้ เรามาหาเขาแม้ว่าเขาไม่อยู่ก็ตาม เราต้องการมันมาก่อน"- มิทรี สโตลยารอฟ

ภาพถ่ายจาก Reddit.com

5-10 ปีที่แล้วมีเครื่องมือมากมาย และไม่มีมาตรฐานเดียว มีผลิตภัณฑ์ใหม่ปรากฏขึ้นทุก ๆ หกเดือนหรือมากกว่าหนึ่งรายการ อันดับแรก Vagrant จากนั้น Salt, Chef, Puppet,... “และคุณสร้างโครงสร้างพื้นฐานของคุณใหม่ทุกๆ หกเดือน คุณมีผู้ดูแลระบบห้าคนที่ยุ่งอยู่กับการเขียนการกำหนดค่าใหม่อยู่ตลอดเวลา” Andrey Fedorovsky เล่า เขาเชื่อว่า Docker และ Kubernetes ได้ "เบียดเสียด" ส่วนที่เหลือ Docker ได้กลายเป็นมาตรฐานในช่วงห้าปีที่ผ่านมา Kubernetes ในช่วงสองปีที่ผ่านมา และนั่นเป็นสิ่งที่ดีสำหรับอุตสาหกรรม.

Dmitry Stolyarov และทีมของเขารัก Kuber พวกเขาต้องการเครื่องมือดังกล่าวก่อนที่มันจะปรากฏขึ้น และมาถึงโดยไม่มีใครรู้เกี่ยวกับมัน ในปัจจุบัน ด้วยเหตุผลด้านความสะดวก พวกเขาจะไม่รับลูกค้าหากพวกเขาเข้าใจว่าจะไม่นำ Kubernetes ไปใช้กับเขา ในขณะเดียวกัน ตามที่ Dmitry กล่าว บริษัทมี "เรื่องราวความสำเร็จอันยิ่งใหญ่มากมายเกี่ยวกับการสร้างมรดกอันเลวร้ายนี้ขึ้นมาใหม่"

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

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

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

ปัญหาฐานข้อมูลไร้สัญชาติ

ภาพถ่ายโดย ทวิตเตอร์: @jankolario บน Unsplash

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

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

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

ผู้เข้าร่วมมีตติ้งถูกแบ่งออกเป็นสองค่าย

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

แม้แต่ฐานข้อมูลบนคลาวด์สมัยใหม่ เช่น MongoDB และ Cassandra หรือคิวข้อความ เช่น Kafka หรือ RabbitMQ ก็จำเป็นต้องมีการจัดเก็บข้อมูลถาวรภายนอก Kubernetes

Evgeniy แย้ง: “ฐานทัพใน Kubera นั้นเป็นพื้นที่ใกล้เคียงรัสเซียหรือใกล้กับองค์กร ซึ่งเกี่ยวข้องกับความจริงที่ว่าไม่มีการนำระบบคลาวด์มาใช้ในรัสเซีย” บริษัทขนาดเล็กหรือขนาดกลางในโลกตะวันตกคือคลาวด์ ฐานข้อมูล Amazon RDS ใช้งานง่ายกว่าการซ่อมแซม Kubernetes ด้วยตัวเอง ในรัสเซีย พวกเขาใช้ Kuber “ในองค์กร” และย้ายฐานไปยัง Kuber เมื่อพวกเขากำลังพยายามกำจัดสวนสัตว์

มิทรียังไม่เห็นด้วยกับข้อความที่ว่าไม่สามารถเก็บฐานข้อมูลใน Kubernetes ได้: “ฐานแตกต่างจากฐาน และถ้าคุณผลักดันฐานข้อมูลเชิงสัมพันธ์ขนาดยักษ์ ก็ไม่ว่าในกรณีใด หากคุณผลักดันบางสิ่งที่มีขนาดเล็กและเป็นเมฆพื้นเมือง ซึ่งเตรียมพร้อมทางจิตใจสำหรับชีวิตกึ่งชั่วคราว ทุกอย่างจะเรียบร้อยดี” Dmitry ยังกล่าวอีกว่าเครื่องมือการจัดการฐานข้อมูลยังไม่พร้อมสำหรับ Docker หรือ Kuber ดังนั้นจึงเกิดปัญหาใหญ่ขึ้น

ในทางกลับกัน Ivan มั่นใจว่าแม้ว่าเราจะแยกออกจากแนวคิดเรื่อง stateful และ stateless แต่ระบบนิเวศของโซลูชันระดับองค์กรใน Kubernetes ยังไม่พร้อม Kuber ทำให้การรักษาข้อกำหนดด้านกฎหมายและข้อบังคับเป็นเรื่องยาก ตัวอย่างเช่น เป็นไปไม่ได้ที่จะสร้างโซลูชันการจัดหาข้อมูลระบุตัวตนที่จำเป็นต้องมีการรับประกันการระบุเซิร์ฟเวอร์ที่เข้มงวด ไปจนถึงฮาร์ดแวร์ที่เสียบเข้าไปในเซิร์ฟเวอร์ พื้นที่นี้กำลังพัฒนา แต่ยังไม่มีวิธีแก้ปัญหา
ผู้เข้าร่วมไม่สามารถตกลงกันได้จึงไม่มีการสรุปในส่วนนี้ ลองยกตัวอย่างเชิงปฏิบัติสองสามตัวอย่าง

กรณีที่ 1. การรักษาความปลอดภัยทางไซเบอร์ของ “mega-regulator” ที่มีฐานอยู่นอก Kubera

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

กรณีที่ 2 การย้ายฐานข้อมูล Booking.com บางส่วนไปยัง Kubernetes

ใน Booking.com ฐานข้อมูลหลักคือ MySQL พร้อมการจำลองแบบอะซิงโครนัส - มีฐานข้อมูลหลักและลำดับชั้นของทาสทั้งหมด เมื่ออีวานออกจากบริษัท ก็มีการเปิดตัวโครงการเพื่อขนย้ายทาสที่อาจ "ถูกยิง" โดยได้รับความเสียหาย

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

ฐานข้อมูลประเภทที่สามคือบริการค้นหาของ Booking.com โดยแต่ละโหนดบริการเป็นฐานข้อมูล ความพยายามที่จะถ่ายโอนบริการค้นหาไปยัง Kuber ล้มเหลวเนื่องจากแต่ละโหนดมีพื้นที่เก็บข้อมูลในเครื่อง 60-80 GB ซึ่งยากต่อการ "ยก" และ "อุ่นเครื่อง"

เป็นผลให้เครื่องมือค้นหาไม่ได้ถูกโอนไปยัง Kubernetes และ Ivan ไม่คิดว่าจะมีความพยายามใหม่ในอนาคตอันใกล้นี้ ฐานข้อมูล MySQL ถูกถ่ายโอนไปครึ่งหนึ่ง: มีเพียงทาสเท่านั้นที่ไม่กลัวที่จะถูก "ยิง" แคสแซนดราปรับตัวได้อย่างสมบูรณ์แบบ

การเลือกโครงสร้างพื้นฐานเป็นงานที่ไม่มีวิธีแก้ปัญหาทั่วไป

ภาพถ่ายโดย มานูเอล ไกซิงเกอร์ จาก Pexels

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

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

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

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

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

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

เดนิสสรุปเกณฑ์หลักสองประการ - ความสามารถในการปรับขนาดและความเสถียรของการดำเนินงาน เขาจะเลือกเครื่องมือที่เหมาะสมกับงานที่สุด “มันอาจเป็นชื่อที่ไม่มีชื่อมาคุกเข่าลง และมี Nutanix Community Edition อยู่ด้วย นี่อาจเป็นบรรทัดที่สองในรูปแบบของแอปพลิเคชันบน Kuber ที่มีฐานข้อมูลบนแบ็กเอนด์ ซึ่งได้รับการจำลองแบบและระบุพารามิเตอร์ RTO และ RPO" (วัตถุประสงค์เวลา/จุดการกู้คืน - ประมาณ).

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

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

การประเมินการใช้งาน Kubernetes

ผู้ฟัง Anton Zhbankov ถามคำถามกับดักผู้ขอโทษของ Kubernetes: คุณเลือกและดำเนินการศึกษาความเป็นไปได้อย่างไร ทำไมต้อง Kubernetes ทำไมไม่ใช้เครื่องเสมือนเป็นต้น?

ภาพถ่ายโดย ทัตยานา เอเรมินา บน Unsplash

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

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

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

สิ่งที่รอเราอยู่

ภาพถ่ายโดย ดรูว์ บีเมอร์ บน Unsplash

เมื่อเทคโนโลยีพัฒนาไป ชิ้นส่วนที่แตกต่างกันมากขึ้นเรื่อยๆ ก็ปรากฏขึ้น และจากนั้นก็เกิดช่วงเปลี่ยนผ่าน ผู้ขายก็ปรากฏว่าได้ฆ่าแป้งมากพอที่จะให้ทุกอย่างมารวมกันในเครื่องมือชิ้นเดียว

คุณคิดว่าจะมีเวลาที่จะมีเครื่องมืออย่าง Ubuntu สำหรับโลก Linux หรือไม่ เพราะเหตุใด บางทีเครื่องมือคอนเทนเนอร์และการจัดประสานเดียวอาจรวม Kuber ไว้ด้วย จะทำให้การสร้างระบบคลาวด์ภายในองค์กรเป็นเรื่องง่าย

Ivan ให้คำตอบว่า “ตอนนี้ Google กำลังสร้าง Anthos ซึ่งเป็นข้อเสนอแบบแพ็คเกจที่ใช้ระบบคลาวด์และรวมถึง Kuber, Service Mesh, การตรวจสอบ – ฮาร์ดแวร์ทั้งหมดที่จำเป็นสำหรับไมโครเซอร์วิสในองค์กร” เราเกือบจะอยู่ในอนาคตแล้ว”

เดนิสยังกล่าวถึง Nutanix และ VMWare ด้วยผลิตภัณฑ์ vRealize Suite ซึ่งสามารถรับมือกับงานที่คล้ายกันได้โดยไม่ต้องมีคอนเทนเนอร์

Dmitry แบ่งปันความคิดเห็นของเขาว่าการลด "ความเจ็บปวด" และการลดภาษีเป็นสองส่วนที่เราสามารถคาดหวังการปรับปรุงได้

เพื่อสรุปการอภิปราย เราเน้นปัญหาต่อไปนี้ของโครงสร้างพื้นฐานสมัยใหม่:

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

  ข้อสรุปที่เหลือขึ้นอยู่กับคุณ ยังคงมีความรู้สึกว่าไม่ใช่เรื่องง่ายที่ชุดค่าผสม Docker + Kubernetes จะกลายเป็นส่วน "ศูนย์กลาง" ของระบบ ตัวอย่างเช่น ระบบปฏิบัติการจะถูกติดตั้งบนฮาร์ดแวร์ก่อน ซึ่งไม่สามารถพูดถึงคอนเทนเนอร์และการจัดประสานได้ บางทีในอนาคตระบบปฏิบัติการและคอนเทนเนอร์อาจรวมเข้ากับซอฟต์แวร์การจัดการระบบคลาวด์

  
  ภาพถ่ายโดย Gabriel Santos Fotografia จาก Pexels

  ฉันขอถือโอกาสนี้ทักทายแม่และเตือนว่าเรามีกลุ่ม Facebook “การจัดการและพัฒนาโครงการไอทีขนาดใหญ่”, ช่อง @feedmeto พร้อมสิ่งพิมพ์ที่น่าสนใจจากบล็อกเทคโนโลยีต่างๆ และช่องของฉัน @rybakalexeyที่ฉันพูดถึงการจัดการการพัฒนาในบริษัทผลิตภัณฑ์

ที่มา: will.com