สรุปสาระสำคัญ
การตรวจสอบความปลอดภัยระดับองค์กร, ข้อบังคับด้านการปฏิบัติตามกฎระเบียบ, และข้อกำหนดการคงอยู่ในประเทศของข้อมูล กำลังขัดขวางการนำ Postman มาใช้งานและกระตุ้นให้เกิดการย้ายออกจาก Postman รูปแบบที่เกิดขึ้นซ้ำๆ ก็คือ: สถาปัตยกรรมแบบคลาวด์เป็นหลักขัดแย้งกับนโยบายที่กำหนดให้ข้อมูลต้องอยู่ภายในองค์กร และ Postman ไม่มีตัวเลือกแบบติดตั้งเอง การติดตั้ง Apidog แบบองค์กรที่โฮสต์เองกำลังกลายเป็นทางเลือกที่องค์กรเหล่านี้เลือกใช้
บทนำ
Postman สร้างตำแหน่งที่โดดเด่นในตลาดเครื่องมือ API มานานกว่าทศวรรษ ผลกระทบจากเครือข่ายนั้นมีนัยสำคัญ: ผู้ใช้ 30 ล้านคน, คอลเล็กชัน API สาธารณะที่กว้างขวาง, การผสานรวมกับแพลตฟอร์ม CI/CD ที่สำคัญทุกแห่ง, และชุดคุณสมบัติที่ขยายเกินกว่าการทดสอบคำขอแบบง่ายๆ ไปสู่การออกแบบ API, เอกสารประกอบ, และการตรวจสอบ
แต่ในช่วงไม่กี่ปีที่ผ่านมา แนวโน้มตรงกันข้ามได้เกิดขึ้นในบัญชีองค์กร ทีมรักษาความปลอดภัยและการปฏิบัติตามกฎระเบียบกำลังตรวจสอบเครื่องมือสำหรับนักพัฒนาด้วยความเข้มงวดใหม่ และสถาปัตยกรรมแบบคลาวด์เป็นหลักของ Postman ไม่ผ่านการตรวจสอบเหล่านั้นในองค์กรจำนวนมากขึ้นเรื่อยๆ
ปัญหาเป็นเรื่องของโครงสร้าง ผลิตภัณฑ์ของ Postman สร้างขึ้นเพื่อการทำงานร่วมกันบนคลาวด์ พื้นที่ทำงาน, ทีม, สภาพแวดล้อม, และการซิงค์คอลเล็กชัน ล้วนต้องการให้ข้อมูลอยู่บนเซิร์ฟเวอร์ของ Postman ซึ่งสมเหตุสมผลเมื่อผลิตภัณฑ์มุ่งเป้าไปที่นักพัฒนาแต่ละคนและทีมขนาดเล็ก เมื่อมันก้าวไปสู่ตลาดระดับองค์กรที่จัดการข้อมูลที่ละเอียดอ่อน สถาปัตยกรรมเดียวกันที่ช่วยให้เกิดการทำงานร่วมกันก็กลายเป็นข้อจำกัดในสภาพแวดล้อมที่มีการควบคุมและคำนึงถึงความปลอดภัย
ปัจจัยที่ 1: การตรวจสอบของทีมรักษาความปลอดภัยขัดขวางการนำไปใช้
สถานการณ์ที่พบบ่อยที่สุดที่กระตุ้นให้เกิดการย้ายจาก Postman คือการตรวจสอบความปลอดภัย เมื่อองค์กรพัฒนาโปรแกรมรักษาความปลอดภัยซอฟต์แวร์ให้สมบูรณ์ขึ้น เครื่องมือสำหรับนักพัฒนาก็จะอยู่ภายใต้การตรวจสอบเดียวกันกับโครงสร้างพื้นฐานการผลิต
กระบวนการตรวจสอบมักจะเป็นดังนี้: ทีมวิศวกรรมต้องการขยายการใช้งาน Postman, ย้ายจากบัญชีส่วนบุคคลไปยังบัญชีองค์กรที่ใช้ร่วมกัน, หรือทำให้เป็นทางการในชุดเครื่องมือการพัฒนา ทีมรักษาความปลอดภัยจะตรวจสอบเครื่องมือนี้โดยเป็นส่วนหนึ่งของการประเมินผู้ขาย การตรวจสอบเผยให้เห็นว่าการซิงค์บนคลาวด์ของ Postman ส่งเนื้อหาคำขอ, ตัวแปรสภาพแวดล้อม (รวมถึงข้อมูลประจำตัว), และข้อมูลการตอบกลับไปยังเซิร์ฟเวอร์ของ Postman ในสหรัฐอเมริกา
ทีมรักษาความปลอดภัยตั้งคำถามว่า: นโยบายการจัดการข้อมูลของเราอนุญาตให้จัดเก็บข้อมูลคำขอ API ที่มีปลายทางภายในและข้อมูลประจำตัวในคลาวด์ของบุคคลที่สามหรือไม่ สำหรับองค์กรที่มีนโยบายการจัดประเภทข้อมูลที่จัดประเภทข้อมูลประจำตัว API และข้อมูลระบบภายในเป็นความลับหรือละเอียดอ่อน คำตอบมักจะเป็นไม่
การตอบสนองของ Postman ต่อข้อกังวลนี้คือการรับรอง SOC 2 Type II และเอกสารความปลอดภัยระดับองค์กร สำหรับบางองค์กร นี่เพียงพอแล้ว สำหรับองค์กรอื่น การรับรองไม่ครอบคลุมถึงข้อกังวลด้านสถาปัตยกรรมพื้นฐาน: แม้แต่ผู้ขายที่ได้รับการรับรอง SOC 2 ก็ยังสามารถเข้าถึงข้อมูลของคุณได้เมื่อทำงานในคลาวด์ของพวกเขา
ข้อสรุปของทีมรักษาความปลอดภัยคือ Postman ในฐานะผลิตภัณฑ์ SaaS แบบคลาวด์เป็นหลักที่ไม่มีตัวเลือกการโฮสต์เอง ไม่สามารถใช้สำหรับงานที่เกี่ยวข้องกับระบบภายในที่ละเอียดอ่อนได้ ทีมวิศวกรรมจึงต้องมองหาทางเลือกอื่นที่ผ่านการตรวจสอบ
ปัจจัยที่ 2: ข้อกำหนดการปฏิบัติตามกฎระเบียบสำหรับการคงอยู่ในประเทศของข้อมูล
ข้อกำหนดการปฏิบัติตามกฎระเบียบได้กลายเป็นปัจจัยสำคัญในการย้ายเครื่องมือ โดยเฉพาะอย่างยิ่งในอุตสาหกรรมที่มีกฎการคงอยู่ในประเทศของข้อมูลที่เข้มงวด
องค์กรในยุโรปภายใต้ GDPR GDPR สร้างความขัดแย้งให้กับบริการคลาวด์ในสหรัฐฯ ในขณะที่ข้อสัญญามาตรฐาน (Standard Contractual Clauses) ให้กลไกทางกฎหมายสำหรับการถ่ายโอนข้อมูลระหว่างสหภาพยุโรปและสหรัฐฯ องค์กรที่มีข้อมูลที่ละเอียดอ่อนเป็นพิเศษอาจต้องการหลีกเลี่ยงความซับซ้อนนั้นโดยใช้เครื่องมือที่เก็บข้อมูลไว้ในยุโรป Postman ไม่มีบริการคงอยู่ในประเทศของข้อมูลในภูมิภาค EU หรือตัวเลือกการโฮสต์เอง ดังนั้นจึงไม่มีทางที่จะเก็บข้อมูลไว้ใน EU ได้
บริการทางการเงินภายใต้คำแนะนำของ FFIEC และ OCC หน่วยงานกำกับดูแลธนาคารของสหรัฐฯ ได้เน้นย้ำถึงการคงอยู่ในประเทศของข้อมูลและการจัดการความเสี่ยงจากบุคคลที่สามมากขึ้นเรื่อยๆ ธนาคารและสถาบันการเงินที่อยู่ภายใต้การกำกับดูแลของ OCC หรือ FDIC กำลังตรวจสอบว่าข้อมูลระบบที่ละเอียดอ่อน (ซึ่งอาจรวมถึงข้อมูลประจำตัว API สำหรับระบบทางการเงิน) ควรถูกจัดเก็บในคลาวด์ของบุคคลที่สามหรือไม่
ผู้รับเหมาภาครัฐภายใต้ CMMC โครงการรับรอง Cybersecurity Maturity Model Certification สำหรับผู้รับเหมาด้านกลาโหมของสหรัฐฯ กำหนดข้อกำหนดสำหรับการจัดการข้อมูลที่ไม่เป็นความลับที่ได้รับการควบคุม (Controlled Unclassified Information - CUI) การจัดเก็บ CUI ในเครื่องมือคลาวด์เชิงพาณิชย์ที่ไม่ใช่บริการที่ได้รับอนุญาตจาก FedRAMP อาจละเมิดข้อกำหนดของ CMMC Postman ไม่ได้รับการอนุญาตจาก FedRAMP
บริการสุขภาพภายใต้ HIPAA ตามที่กล่าวไว้ในบทความการตรวจสอบการปฏิบัติตามกฎระเบียบ Postman เสนอ BAA สำหรับ HIPAA แต่รูปแบบการซิงค์บนคลาวด์ยังคงหมายความว่า PHI ในคำขอทดสอบจะเดินทางไปยังเซิร์ฟเวอร์ของ Postman องค์กรที่มีโปรแกรม HIPAA ที่เข้มงวดอาจต้องการเครื่องมือที่กำจัดกระแสข้อมูลนั้นโดยสิ้นเชิง
จุดร่วมในบริบทการปฏิบัติตามกฎระเบียบเหล่านี้: องค์กรจำเป็นต้องควบคุมว่าข้อมูลไหลไปที่ใด และสถาปัตยกรรมของ Postman ทำให้สิ่งนั้นเป็นไปไม่ได้
ปัจจัยที่ 3: ต้นทุนในขนาดที่ใหญ่ขึ้น
ความปลอดภัยและการปฏิบัติตามกฎระเบียบไม่ใช่ปัจจัยขับเคลื่อนเพียงอย่างเดียว ต้นทุนล้วนๆ ก็เป็นปัจจัยเช่นกันเมื่อองค์กรวิศวกรรมมีขนาดใหญ่ขึ้น
ราคาองค์กรของ Postman คิดเป็นต่อผู้ใช้ต่อเดือน สำหรับทีมขนาดเล็ก ต้นทุนนั้นเล็กน้อย สำหรับองค์กรวิศวกรรมที่มีนักพัฒนาหลายร้อยหรือหลายพันคน ต้นทุนจะสูงมาก องค์กรที่วิเคราะห์ต้นทุนในขนาดที่ใหญ่ขึ้นบางครั้งพบว่าการติดตั้งทางเลือกที่โฮสต์เองเพียงครั้งเดียวช่วยประหยัดค่าใช้จ่ายได้อย่างมากในช่วงหลายปี
การพิจารณาต้นทุนนี้มีความเกี่ยวข้องเป็นพิเศษสำหรับองค์กรที่กำลังลงทุนในโครงสร้างพื้นฐานแพลตฟอร์มภายในอยู่แล้ว การเพิ่มการติดตั้งเครื่องมือ API ไปยังคลัสเตอร์ Kubernetes หรือฟาร์มเซิร์ฟเวอร์ภายในที่มีอยู่มีต้นทุนส่วนเพิ่มเมื่อเทียบกับค่าธรรมเนียม SaaS ต่อผู้ใช้ที่เกิดขึ้นซ้ำๆ
ปัจจัยด้านต้นทุนไม่ค่อยเกิดขึ้นเพียงลำพัง องค์กรที่ย้ายเนื่องจากเหตุผลด้านต้นทุนมักจะอ้างถึงข้อกังวลด้านความปลอดภัยหรือการปฏิบัติตามกฎระเบียบด้วย ต้นทุนเป็นตัวเร่งที่กระตุ้นให้เกิดการตรวจสอบอย่างเป็นทางการ ซึ่งจะเผยให้เห็นปัญหาด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบ
ปัจจัยที่ 4: การค้นพบของ CloudSEK และผลที่ตามมา
การค้นพบของ CloudSEK ในปี 2023 ที่มีพื้นที่ทำงาน Postman สาธารณะกว่า 30,000 แห่งรั่วไหลคีย์ API มีผลกระทบเฉพาะต่อทีมรักษาความปลอดภัยขององค์กร มันเป็นตัวอย่างที่เป็นรูปธรรมของการตั้งค่า Postman ที่ผิดพลาดซึ่งนำไปสู่การเปิดเผยข้อมูลประจำตัวในวงกว้าง
เมื่อทีมรักษาความปลอดภัยเห็นรายงาน พวกเขาได้ตั้งคำถามที่ชัดเจนกับองค์กรของตนเองว่า: เรามีพื้นที่ทำงานสาธารณะที่มีข้อมูลประจำตัวหรือไม่ หลายคนพบว่าพวกเขามี กระบวนการตรวจสอบที่ตามมานำไปสู่การแก้ไข แต่ยังนำไปสู่การประเมินใหม่ว่าสถาปัตยกรรมเริ่มต้นของ Postman เข้ากันได้กับความอดทนต่อความเสี่ยงขององค์กรหรือไม่
การค้นพบนี้ยังให้หลักฐานที่เป็นรูปธรรมแก่ทีมรักษาความปลอดภัยเพื่อนำไปใช้ในการสนทนากับผู้นำด้านวิศวกรรมเกี่ยวกับความเสี่ยงของเครื่องมือสำหรับนักพัฒนา ข้อกังวลที่เป็นนามธรรมเกี่ยวกับ “ข้อมูลประจำตัวที่ซิงค์บนคลาวด์” นั้นยากที่จะดำเนินการ รายงานที่อ้างถึงบริษัทที่เฉพาะเจาะจงที่มีคีย์ API ถูกเปิดเผย พร้อมกลไกในการตรวจสอบการเปิดเผยของตนเอง สามารถนำไปดำเนินการได้
สำหรับบางองค์กร การตรวจสอบไม่พบพื้นที่ทำงานสาธารณะที่มีข้อมูลประจำตัว พวกเขาได้เข้มงวดนโยบายและยังคงใช้ Postman ต่อไป สำหรับองค์กรอื่น การตรวจสอบพบการเปิดเผย และประสบการณ์การค้นพบว่าข้อมูลประจำตัวสำหรับการผลิตสามารถเข้าถึงได้โดยใครก็ตามที่ค้นหาเครือข่าย Postman API นั้นเป็นแรงจูงใจที่เพียงพอในการย้าย
รูปแบบการย้ายข้อมูล: สิ่งที่องค์กรทำจริง
องค์กรที่ย้ายออกจาก Postman cloud จะปฏิบัติตามรูปแบบที่สามารถจดจำได้
ระยะที่ 1: ตัวกระตุ้นด้านความปลอดภัยหรือการปฏิบัติตามกฎระเบียบ การตรวจสอบความปลอดภัย, การค้นพบจากการตรวจสอบ, ข้อกำหนดการปฏิบัติตามกฎระเบียบ, หรือเหตุการณ์ (เช่น การพบพื้นที่ทำงานที่เปิดเผย) กระตุ้นให้เกิดการประเมินเครื่องมือสำหรับนักพัฒนาอย่างเป็นทางการ
ระยะที่ 2: การรวบรวมข้อกำหนด ทีมรักษาความปลอดภัยกำหนดข้อกำหนด โดยทั่วไป: การคงอยู่ในประเทศของข้อมูล, ไม่มีการซิงค์ข้อมูลประจำตัวบนคลาวด์, ตัวเลือกการติดตั้งแบบโฮสต์เอง, คุณสมบัติการทำงานร่วมกันของทีม, ความเข้ากันได้กับคอลเล็กชัน Postman (สำหรับการย้าย), และการสนับสนุนระดับองค์กร
ระยะที่ 3: การประเมินผล เครื่องมือผู้สมัครจะถูกประเมินเทียบกับข้อกำหนด Bruno มักจะไม่ผ่านการประเมินสำหรับทีมขนาดใหญ่เนื่องจากขาดคุณสมบัติการทำงานร่วมกันแบบรวมศูนย์ Hoppscotch แบบโฮสต์เองได้รับการประเมิน แต่อาจถูกลดความสำคัญลงหากทีมขาดขีดความสามารถด้าน DevOps หรือต้องการคุณสมบัติที่ Hoppscotch ไม่มี Apidog แบบโฮสต์เองเป็นทางเลือกที่พบบ่อยที่สุดสำหรับทีมที่ต้องการคุณสมบัติครบถ้วน (การออกแบบ, การทดสอบ, เอกสารประกอบ, การจำลอง) พร้อมการโฮสต์เอง
ระยะที่ 4: การนำร่อง ทีมวิศวกรรมกลุ่มย่อยจะใช้เครื่องมือผู้สมัครควบคู่ไปกับ Postman เป็นเวลา 30-90 วัน คอลเล็กชัน Postman จะถูกส่งออกและนำเข้า เวิร์กโฟลว์ได้รับการตรวจสอบความถูกต้อง
ระยะที่ 5: การย้ายข้อมูล คอลเล็กชันจะถูกย้าย, สภาพแวดล้อมจะถูกสร้างขึ้นใหม่ด้วยข้อมูลประจำตัวที่สะอาด (การย้ายเป็นช่วงเวลาที่ดีในการหมุนเวียนคีย์), และบัญชี Postman จะถูกยกเลิกการจัดสรร
สิ่งที่องค์กรเหล่านี้เลือกใช้แทน
ภูมิทัศน์ทางเลือกได้เติบโตจนถึงจุดที่ทีมองค์กรมีตัวเลือกที่ใช้การได้
Apidog แบบโฮสต์เอง ทางเลือกที่พบบ่อยที่สุดสำหรับองค์กรที่ต้องการคงความสามารถแพลตฟอร์มเต็มรูปแบบของ Postman (ไม่ใช่แค่การทดสอบคำขอ แต่รวมถึงการออกแบบ API, เอกสารประกอบ และการจำลอง) ในขณะที่ยังคงข้อมูลไว้ในโครงสร้างพื้นฐานของตนเอง
การติดตั้งแบบโฮสต์เองทำงานบน Docker และสามารถติดตั้งได้ทั้งในสถานที่, ในคลาวด์ส่วนตัว, หรือในภูมิภาคคลาวด์ที่ระบุ คุณสมบัติการทำงานร่วมกันของทีมทำงานเหมือนกับเวอร์ชันคลาวด์ แต่การซิงค์จะไปที่เซิร์ฟเวอร์ภายในของคุณ การคงอยู่ในประเทศของข้อมูลอยู่ภายใต้การควบคุมของคุณอย่างเต็มที่
สำหรับการจัดซื้อจัดจ้างระดับองค์กร Apidog เสนอโมเดลใบอนุญาตแบบโฮสต์เองพร้อมการสนับสนุนเฉพาะ ซึ่งตรงตามข้อกำหนดการจัดการผู้ขายขององค์กรขนาดใหญ่
Bruno สำหรับทีมที่เน้นวิศวกรรม องค์กรที่มีวัฒนธรรม DevOps ที่แข็งแกร่งและเวิร์กโฟลว์ที่เน้น git บางครั้งเลือก Bruno เนื่องจากแนวทาง "collections-as-files" สอดคล้องกับหลักการ "infrastructure-as-code" คอลเล็กชันอยู่ร่วมกับโค้ดแอปพลิเคชันในคลังเดียวกัน การควบคุมเวอร์ชันคือ git ไม่ต้องบำรุงรักษาเซิร์ฟเวอร์
Bruno ทำงานได้ดีที่สุดเมื่อความต้องการหลักขององค์กรคือการทดสอบคำขอและทีมรู้สึกสบายใจกับประสบการณ์เครื่องมือที่เรียบง่ายกว่า
Hoppscotch แบบโฮสต์เอง โอเพนซอร์ส, สามารถติดตั้งเองได้, และทำงานบนเบราว์เซอร์ ดีสำหรับองค์กรที่ต้องการ UI บนเว็บที่เข้าถึงได้สำหรับสมาชิกในทีมโดยไม่ต้องติดตั้งแอปพลิเคชันเดสก์ท็อป ต้องการการลงทุนด้านการดำเนินงานมากกว่าตัวเลือก Apidog แบบโฮสต์เอง
สิ่งที่การย้ายข้อมูลที่ประสบความสำเร็จมีเหมือนกัน
องค์กรที่ย้ายออกจาก Postman cloud ได้สำเร็จมีแนวปฏิบัติหลายประการร่วมกัน
พวกเขาย้ายข้อมูลในฐานะโครงการ ไม่ใช่สิ่งที่ตามมาทีหลัง คอลเล็กชันไม่ได้ย้ายตัวเอง ตัวแปรสภาพแวดล้อมจะต้องป้อนใหม่ด้วยข้อมูลประจำตัวที่สะอาด สคริปต์ทดสอบอาจต้องมีการปรับเปลี่ยนสำหรับความแตกต่างใน API ของสคริปต์ การจัดสรรเวลาโครงการที่เหมาะสมนำไปสู่การย้ายข้อมูลที่สะอาดขึ้น
พวกเขาถือว่าการย้ายข้อมูลเป็นโอกาสในการทำความสะอาดข้อมูลประจำตัว กระบวนการย้ายข้อมูลต้องมีการป้อนตัวแปรสภาพแวดล้อมใหม่ นี่เป็นช่วงเวลาที่เหมาะสมในการหมุนเวียนคีย์ API และตรวจสอบให้แน่ใจว่าข้อมูลประจำตัวของนักพัฒนาถูกกำหนดขอบเขตอย่างถูกต้อง องค์กรที่ทำเช่นนี้จะออกมาจากการย้ายข้อมูลด้วยท่าทีข้อมูลประจำตัวที่สะอาดกว่าเดิม
พวกเขาฝึกอบรมทีมเกี่ยวกับโมเดลความปลอดภัยของเครื่องมือใหม่ การทำความเข้าใจว่าทำไมจึงเลือกใช้เครื่องมือนี้ และโมเดลข้อมูลของมันแตกต่างจาก Postman อย่างไร ช่วยให้ทีมวิศวกรรมตัดสินใจได้ดีขึ้น ทีมที่เข้าใจว่า "ข้อมูลของเราอยู่ภายในองค์กรเพราะมันซิงค์กับเซิร์ฟเวอร์ของเรา" มีแนวโน้มที่จะสร้างช่องโหว่ด้านความปลอดภัยน้อยกว่าทีมที่รู้เพียงแค่ "เราเปลี่ยนเครื่องมือแล้ว"
พวกเขากำหนดนโยบายที่ชัดเจนบนแพลตฟอร์มใหม่ การกำกับดูแลแบบเดียวกับที่จำเป็นสำหรับ Postman ก็จำเป็นสำหรับเครื่องมือใหม่: ใครสามารถเข้าถึงอะไรได้บ้าง, ข้อมูลประจำตัวใดถูกจัดเก็บไว้ที่ใด, และวิธีการจัดการการเข้าถึงพื้นที่ทำงาน การย้ายข้อมูลโดยไม่มีการปรับปรุงนโยบายเพียงแค่ย้ายความเสี่ยงเดียวกันไปยังแพลตฟอร์มอื่น
ช่องว่างของผลิตภัณฑ์ที่ Postman ยังไม่ได้แก้ไข
แนวโน้มการย้ายข้อมูลขององค์กรท้ายที่สุดแล้วเกิดจากช่องว่างของผลิตภัณฑ์: Postman ไม่ได้สร้างตัวเลือกการโฮสต์เอง
Postman แบบโฮสต์เองที่ทำงานบนโครงสร้างพื้นฐานของลูกค้าและซิงค์ข้อมูลภายในจะแก้ไขข้อกังวลเรื่องการคงอยู่ในประเทศของข้อมูล ในขณะที่ยังคงคุณสมบัติทั้งหมดที่ทำให้ Postman มีอำนาจเหนือกว่า ลูกค้าองค์กรหลายรายได้ร้องขอสิ่งนี้ต่อสาธารณะในฟอรัมข้อเสนอแนะของ Postman ตลอดหลายปีที่ผ่านมา ผลิตภัณฑ์ยังไม่ได้ไปในทิศทางนั้น
รูปแบบธุรกิจของ Postman ขึ้นอยู่กับการสมัครสมาชิกบนคลาวด์ ตัวเลือกการโฮสต์เองจะเปลี่ยนรายได้บางส่วนไปเป็นค่าใบอนุญาตแบบครั้งเดียวหรือรายปี และจะต้องสร้างและบำรุงรักษาโครงสร้างพื้นฐานการติดตั้งที่ Postman ไม่ได้ให้ความสำคัญ
ช่องว่างนี้ได้สร้างโอกาสให้กับ Apidog และทางเลือกอื่นๆ ความต้องการ "คุณสมบัติของ Postman, การติดตั้งแบบโฮสต์เอง" เป็นของจริงและ Postman เองก็ยังไม่สามารถตอบสนองได้
คำถามที่พบบ่อย
Postman กำลังสูญเสียลูกค้าองค์กรจากเรื่องนี้หรือไม่? รูปแบบของการย้ายข้อมูลที่ขับเคลื่อนด้วยการตรวจสอบความปลอดภัยนั้นเป็นของจริงและมีบันทึกไว้ในฟอรัมของนักพัฒนาและการสนทนาในชุมชน องค์กรขนาดใหญ่ที่มีโปรแกรมรักษาความปลอดภัยที่สมบูรณ์แล้วมีแนวโน้มที่จะพบกับข้อจำกัดทางสถาปัตยกรรมของ Postman มากที่สุด การที่ Postman กำลังสูญเสียลูกค้าสุทธิจากเรื่องนี้หรือไม่นั้นเป็นคำถามทางธุรกิจที่อยู่นอกเหนือขอบเขตของการวิเคราะห์นี้
คุณไม่สามารถปิดการซิงค์ของ Postman และใช้งานแบบโลคัลได้หรือ? Postman ได้นำ Scratch Pad ออกไปประมาณปี 2023 ซึ่งเป็นเส้นทางเดียวในการใช้งานแบบโลคัลอย่างสมบูรณ์ เวอร์ชันปัจจุบันต้องใช้บัญชีที่ลงชื่อเข้าใช้และซิงค์ข้อมูลโดยค่าเริ่มต้น สำหรับองค์กรที่ต้องการการควบคุมข้อมูลอย่างสมบูรณ์ มาตรการบรรเทาบางส่วนภายใน Postman ไม่เพียงพอ
การติดตั้ง Apidog แบบโฮสต์เองมีลักษณะการทำงานอย่างไร? ทำงานบน Docker Compose หรือ Kubernetes ต้องใช้ฐานข้อมูล PostgreSQL และ reverse proxy สำหรับการยุติ TLS ภาระการดำเนินงานเทียบได้กับการเรียกใช้เว็บแอปพลิเคชันที่มีความซับซ้อนปานกลาง ทีมที่มีวิศวกรแพลตฟอร์มภายในสามารถจัดการได้
จะเกิดอะไรขึ้นกับคอลเล็กชัน Postman ที่มีอยู่ระหว่างการย้ายข้อมูล? คอลเล็กชัน Postman ส่งออกเป็นรูปแบบ JSON Apidog, Bruno, Hoppscotch, และ Insomnia ล้วนนำเข้าจากรูปแบบคอลเล็กชัน Postman ได้ การนำเข้ามักจะสะอาดสำหรับคอลเล็กชัน ตัวแปรสภาพแวดล้อมจะต้องป้อนใหม่ด้วยตนเอง (ซึ่งเป็นแนวปฏิบัติที่ดีสำหรับการรักษาสุขอนามัยของข้อมูลประจำตัวอยู่แล้ว)
Apidog แบบโฮสต์เองรองรับ SSO และการยืนยันตัวตนระดับองค์กรหรือไม่? ข้อเสนอ Apidog แบบองค์กรที่โฮสต์เองรองรับการผสานรวม SSO ผ่าน SAML และ OIDC นี่เป็นข้อกำหนดสำหรับการติดตั้งระดับองค์กรส่วนใหญ่และมีให้ใช้งานในแผนองค์กร
การย้ายข้อมูล Postman โดยทั่วไปใช้เวลานานเท่าใด? สำหรับทีมวิศวกรรม 50 คนที่มีคอลเล็กชัน Postman 100-200 รายการ การย้ายข้อมูลโดยทั่วไปใช้เวลา 4-8 สัปดาห์นับตั้งแต่การตัดสินใจจนถึงการเปลี่ยนถ่ายทั้งหมด รวมถึงช่วงนำร่องและการฝึกอบรม ทีมขนาดใหญ่ที่มีคอลเล็กชันมากขึ้นจะใช้เวลานานขึ้น
องค์กรที่ย้ายออกจาก Postman cloud ไม่ได้ทำเช่นนั้นเพราะ Postman เป็นผลิตภัณฑ์ที่ไม่ดี พวกเขาทำเช่นนั้นเพราะสถาปัตยกรรมของผลิตภัณฑ์ไม่เข้ากับข้อกำหนดของพวกเขาอีกต่อไปเมื่อข้อกำหนดเหล่านั้นมีความสมบูรณ์มากขึ้น องค์กรที่ประสบความสำเร็จกับทางเลือก Postman คือองค์กรที่ถือว่าการย้ายข้อมูลเป็นโครงการที่มีข้อกำหนดที่ชัดเจน ไม่ใช่แค่การเปลี่ยนเครื่องมือ