ปัญหาขั้นตอนการทำงานของนักพัฒนาที่ไม่มีใครพูดถึง

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

แม้จะมีความก้าวหน้าทั้งหมดนี้ ทีมวิศวกรรมหลายทีมยังคงใช้เวลาอย่างน่าประหลาดใจในการต่อสู้กับเครื่องมือของพวกเขา ไม่ใช่เพราะเครื่องมือเหล่านั้นไม่ดี ส่วนใหญ่แล้วเครื่องมือเหล่านี้ยอดเยี่ยมในการแก้ปัญหาเฉพาะด้าน ความท้าทายคือกระบวนการพัฒนาสมัยใหม่แทบจะไม่เกี่ยวข้องกับปัญหาเพียงอย่างเดียว

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

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

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

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

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

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

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

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

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

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

นักพัฒนาทำงานกับ PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Redis และ MongoDB เป็นประจำ พวกเขาเปรียบเทียบโครงสร้างข้อมูล ตรวจสอบการย้ายข้อมูล แก้ไขปัญหาด้านประสิทธิภาพ สร้างเอกสาร และใช้ AI มากขึ้นเรื่อยๆ เพื่อเร่งการพัฒนาคำสั่งค้นหา DataraDB นำเวิร์กโฟลว์เหล่านี้เข้าสู่สภาพแวดล้อมที่ทันสมัยและมีประสิทธิภาพสูง ซึ่งมุ่งเน้นไปที่งานวิศวกรรมในชีวิตประจำวันที่เป็นประโยชน์จริง แทนที่จะเป็นเพียงการเรียกดูฐานข้อมูลเท่านั้น

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

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

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

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

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