ในโลกของการพัฒนา software มีเทคโนโลยีไม่กี่อย่างที่เปลี่ยนแปลงวิธีที่เราสร้างและ deploy applications อย่างยิ่งใหญ่เท่ากับ containers ในขณะที่หลายคนให้เครดิตกับการ packaging ที่สวยงามของ Docker หรือความสามารถในการ orchestration ของ Kubernetes แต่เรื่องราวจริงเบื้องหลังการปฏิวัติ container อยู่ที่บางสิ่งที่พื้นฐานกว่ามาก นั่นคือความยุ่งเหยิงอันเลวร้ายของการจัดการ dependency ที่รบกวนจิตใจ developer มานานหลายทศวรรษ ขณะที่ชุมชนทบทวนถึงการเปลี่ยนแปลงทางเทคโนโลยีนี้ ก็เห็นชัดว่า containers ไม่ได้เพียงแก้ปัญหาเรื่องการ deploy เท่านั้น แต่ยังช่วยเหลือ developer ให้พ้นจากนรก dependency อีกด้วย
ปัญหา Packaging ที่ให้กำเนิดอุตสาหกรรม
การเกิดขึ้นของ containers สามารถย้อนไปถึงอาการปวดหัวเรื้อรังที่หลอกหลอน developer ข้ามภาษา programming ต่าง ๆ นั่นคือความฝันร้ายของการจัดการ dependency ข้ามระบบที่แตกต่างกัน ปัญหา packaging ของ Python ความขัดแย้งเรื่องเวอร์ชันของ Ruby และความโกลาหลทั่วไปของ library dependencies ภาษา C/C++ ได้สร้างสิ่งที่ developer คนหนึ่งบรรยายไว้ว่า วิธีทำงานแบบดั้งเดิมของแอปพลิเคชัน Linux ส่วนใหญ่คือการกระจายตัวไปทั่ว filesystem ของคุณด้วยการอ้างอิงที่ hard coded ไปยัง absolute paths และพวกมันคาดหวังให้คุณจัดหา dependencies ทั้งหมดให้พวกมัน ข้อบกพร่องพื้นฐานในการออกแบบนี้เกี่ยวกับวิธีการกระจายแอปพลิเคชัน Linux ทำให้การ deploy ที่สม่ำเสมอข้ามสภาพแวดล้อมที่แตกต่างกันเกือบจะเป็นไปไม่ได้
ก่อนยุค containers developer ต้องเผชิญกับสิ่งที่ผู้ใช้คนหนึ่งเรียกว่า ช่วงเวลาประหลาดเมื่อ virtualization แบบง่าย ๆ ไม่ได้มีให้ทุกคนใช้ได้อย่างบ้าคลั่ง ทีมงานจะใช้เวลานับไม่ถ้วนพยายามทำให้เวอร์ชันที่ถูกต้องของ software ทำงานบนเซิร์ฟเวอร์เดียวกัน จัดการกับสิ่งที่เทียบเท่ากับ Python เวอร์ชันต่าง ๆ มากกว่า 5 เวอร์ชันกระจายไปทั่ว file system เพียงเพื่อรันโปรแกรมพื้นฐาน ปัญหาไม่ได้เป็นเพียงเทคนิคเท่านั้น แต่ยังเป็นวัฒนธรรม โดยมีผู้เชี่ยวชาญจำนวนมากที่มีอำนาจในการตัดสินใจมากเกินไปที่จะบังคับให้มีการเปลี่ยนแปลงเล็กน้อยของพวกเขาเองลงในเครื่องมือที่มีอยู่
ภาษาโปรแกรมที่ได้รับผลกระทบมากที่สุดจากปัญหา Dependency:
- Python (ความท้าทายด้านการจัดการแพ็กเกจและ virtual environment)
- Ruby (ความขัดแย้งในการจัดการเวอร์ชัน)
- Node.js (ความซับซ้อนของ dependency tree)
- C/C++ (ปัญหาความเข้ากันได้ของไลบรารี)
- Go (เมื่อใช้ CGO สำหรับการเชื่อมต่อกับ C)
จากโซลูชันการแยกตัวสู่การปฏิวัติการ Deployment
ในขณะที่ Google พัฒนา cgroups เพื่อการจัดการทรัพยากรอย่างมีประสิทธิภาพในโครงสร้างพื้นฐานโฆษณาและการค้นหาขนาดใหญ่ของพวกเขา ชุมชน developer โดยรวมกลับยอมรับ containers ด้วยเหตุผลที่แตกต่างกันโดยสิ้นเชิง สิ่งที่เริ่มต้นเป็นโซลูชันของ Google สำหรับ การบีบอัด workload ลงบนฮาร์ดแวร์ที่เป็นเนื้อเดียวกันให้มีประสิทธิภาพที่สุดเท่าที่จะเป็นไปได้ กลายเป็นทางรอดจากความฝันร้ายเรื่อง dependency ของ developer ทั่วไป คุณสมบัติการแยกตัวที่ทำให้ containers มีประโยชน์สำหรับขนาดของ Google กลายเป็นเรื่องรองเมื่อเทียบกับประโยชน์ด้าน packaging ที่แก้ปัญหาการพัฒนาที่พบเจอในชีวิตประจำวัน
ชุมชนตระหนักอย่างรวดเร็วว่า containers นำเสนอสิ่งที่มีค่ามากกว่าการแยกตัว นั่นคือความสม่ำเสมอ ดังที่ developer คนหนึ่งระบุไว้ ผมคิดว่าการคิดค้นที่สำคัญของ Docker คือ image มันทำให้ผู้คน deploy เวอร์ชันที่สม่ำเสมอของ software ของพวกเขา หรือดาวน์โหลด software จากภายนอก ความสม่ำเสมอนี้หมายความว่าในที่สุด developer สามารถสร้างแอปพลิเคชันที่จะทำงานในแบบเดียวกันบนเครื่องท้องถิ่นของพวกเขา ในสภาพแวดล้อมทดสอบ และใน production ซึ่งเป็นสิ่งที่เกือบเป็นไปไม่ได้ด้วยวิธีการจัดการแพ็กเกจแบบดั้งเดิม
ไทม์ไลน์วิวัฒนาการของคอนเทนเนอร์:
- ต้นทศวรรษ 2000: FreeBSD jails สำหรับการแยกบริการ
- 2006-2007: Linux cgroups พัฒนาโดย Google เพื่อการจัดการทรัพยากร
- 2013: Docker เกิดขึ้นจากแพลตฟอร์ม PaaS ของ dotCloud
- 2014: โปรเจกต์ Kubernetes เริ่มต้น
- 2015: การจัดการคอนเทนเนอร์กลายเป็นกระแสหลัก
- 2017+: คอนเทนเนอร์กลายเป็น "เทคโนโลยีที่น่าเบื่อ"
ประสบการณ์การพัฒนาที่เปลี่ยนทุกสิ่ง
ตรงข้ามกับข้อกล่าวหาบางอย่างที่ว่า Docker ไม่ได้ช่วยการพัฒนาจริง ๆ developer จำนวนมากพบว่า containers แปลงโฉม workflow ประจำวันของพวกเขา Developer คนหนึ่งแบ่งปันประสบการณ์ของพวกเขา: โปรเจกต์ทั้งหมดของฉันใช้ docker compose ซึ่งกำหนดค่าหลาย containers และรันเป็นสภาพแวดล้อมการพัฒนาบนเครื่องของฉัน source code ถูก mount เป็น volume compose file เดียวกันนี้ก็ถูกใช้สำหรับการ deploy ไปยัง production server ด้วย แนวทางนี้ขจัดปัญหา มันทำงานบนเครื่องของฉัน ที่ได้หลอกหลอนการพัฒนา software มานานหลายปี
การปรับปรุงประสบการณ์การพัฒนาไม่ได้เป็นเพียงเรื่องความสม่ำเสมอเท่านั้น แต่ยังเป็นเรื่องความเรียบง่าย แทนที่จะต้องต่อสู้กับการตั้งค่า virtual machine ที่ซับซ้อนหรือการติดตั้ง dependency ที่ละเอียดอ่อน developer สามารถใช้สิ่งที่ผู้ใช้คนหนึ่งเรียกว่า one-line install any linux distro userspace สิ่งนี้ลดอุปสรรคในการเริ่มต้นสำหรับการทดสอบข้ามสภาพแวดล้อมที่แตกต่างกันอย่างมาก และทำให้การ onboard สมาชิกทีมใหม่ง่ายขึ้นอย่างมีนัยสำคัญ
ประโยชน์หลักของ Container ที่นักพัฒนาระบุ:
- การจัดการ Dependency ข้ามระบบต่างๆ
- สภาพแวดล้อมที่สม่ำเสมอตั้งแต่การพัฒนาจนถึงการใช้งานจริง
- กระบวนการ Deployment ที่เรียบง่าย
- การทดสอบที่ง่ายดายข้าม Linux Distribution หลายๆ ตัว
- ลดปัญหา "มันทำงานได้บนเครื่องของฉัน" ลง
ผลที่ตามมาโดยไม่ตั้งใจและทิศทางในอนาคต
ในขณะที่ containers กลายเป็นกระแสหลัก พวกมันนำการเปลี่ยนแปลงที่คาดไม่ถึงมาสู่ภูมิทัศน์การพัฒนา software วัฒนธรรม DevOps ดั้งเดิมของการทำงานร่วมกันระหว่างทีม development และ operations ค่อย ๆ เปลี่ยนไปเป็นสิ่งที่บางคนมองว่าเป็น แค่บทบาท backend และตำแหน่งงานสำหรับผู้คนที่จัดการกับ Kubernetes และเทคโนโลยีการ deploy อื่น ๆ เทคโนโลยีที่ควรจะนำทีมต่างๆ มารวมกัน กลับสร้างความเชี่ยวชาญและความแบ่งแยกใหม่ขึ้นมา
เมื่อมองไปข้างหน้า ชุมชนเห็นว่า containers กำลังกลายเป็น เทคโนโลยีที่น่าเบื่อ ซึ่งเป็นสัญญาณของความ成熟มากกว่าที่จะล้าสมัย ด้วย AI ที่ดึงดูด งบประมาณการเปลี่ยนแปลง ทั้งหมด containers ได้ตกอยู่ในบทบาทของพวกเขาในฐานะโครงสร้างพื้นฐานพื้นฐาน การปฏิวัติที่เริ่มต้นเป็นโซลูชันสำหรับนรก dependency ตอนนี้ได้กลายเป็นแพลตฟอร์มที่มั่นคงซึ่งแอปพลิเคชันรุ่นต่อไปกำลังถูกสร้างขึ้น Containers ชนะไม่ใช่เพราะพวกมันเป็นโซลูชันที่สวยงามที่สุด แต่เพราะพวกมันแก้ปัญหาที่เจ็บปวดที่สุดที่ developer เผชิญในทุกวัน