บันทึก. แปล: บทความนี้ซึ่งได้รับความนิยมในสื่อเป็นภาพรวมของการเปลี่ยนแปลงที่สำคัญ (2010-2019) ในโลกของภาษาการเขียนโปรแกรมและระบบนิเวศเทคโนโลยีที่เกี่ยวข้อง (โดยเน้นที่ Docker และ Kubernetes เป็นพิเศษ) ผู้เขียนต้นฉบับคือ Cindy Sridharan ซึ่งเชี่ยวชาญด้านเครื่องมือสำหรับนักพัฒนาและระบบแบบกระจาย โดยเฉพาะอย่างยิ่ง เธอเขียนหนังสือ "Distributed Systems Observability" และค่อนข้างเป็นที่นิยมบนอินเทอร์เน็ตในหมู่ผู้เชี่ยวชาญด้านไอที โดยเฉพาะอย่างยิ่งที่สนใจในหัวข้อเกี่ยวกับระบบคลาวด์
เมื่อใกล้จะถึงปี 2019 ฉันอยากจะแบ่งปันความคิดของฉันเกี่ยวกับความก้าวหน้าทางเทคโนโลยีและนวัตกรรมที่สำคัญที่สุดในทศวรรษที่ผ่านมา นอกจากนี้ ฉันจะพยายามมองไปในอนาคตเล็กน้อยและสรุปความท้าทายหลักและโอกาสสำหรับทศวรรษที่จะมาถึง
ฉันอยากจะบอกทันทีว่าในบทความนี้ฉันไม่ครอบคลุมถึงการเปลี่ยนแปลงในด้านต่างๆ เช่น วิทยาศาสตร์ข้อมูล (วิทยาศาสตร์ข้อมูล)ปัญญาประดิษฐ์ วิศวกรรมส่วนหน้า ฯลฯ เนื่องจากโดยส่วนตัวฉันไม่มีประสบการณ์เพียงพอ
พิมพ์โต้กลับ
หนึ่งในแนวโน้มที่เป็นบวกที่สุดของปี 2010 คือการฟื้นคืนชีพของภาษาที่พิมพ์แบบคงที่ แม้ว่าภาษาดังกล่าวจะไม่ได้หายไปไหน (C ++ และ Java เป็นที่ต้องการในปัจจุบัน พวกเขาครอบครองเมื่อสิบปีก่อน) แต่ภาษาที่พิมพ์แบบไดนามิก (ไดนามิก) ได้รับความนิยมเพิ่มขึ้นอย่างมากหลังจากการเกิดขึ้นของ Ruby on Rails ความเคลื่อนไหวในปี 2005 การเติบโตนี้ถึงจุดสูงสุดในปี 2009 ด้วยการค้นพบซอร์สโค้ด Node.js ซึ่งทำให้ Javascript-on-the-server เป็นจริง
เมื่อเวลาผ่านไป ภาษาไดนามิกได้สูญเสียความน่าสนใจบางประการในการพัฒนาซอฟต์แวร์เซิร์ฟเวอร์ ภาษา Go ซึ่งเป็นที่นิยมในช่วงการปฏิวัติคอนเทนเนอร์ ดูเหมือนจะเหมาะกว่าในการสร้างเซิร์ฟเวอร์ประสิทธิภาพสูงและประหยัดทรัพยากรพร้อมการประมวลผลข้อมูลแบบคู่ขนาน (ซึ่ง ผู้สร้าง Node.js เอง)
Rust เปิดตัวในปี 2010 รวมถึงความสำเร็จใน ในความพยายามที่จะเป็นภาษาที่ปลอดภัยและเป็นตัวพิมพ์ ในช่วงครึ่งแรกของทศวรรษ ทัศนคติต่อ Rust ในอุตสาหกรรมค่อนข้างอบอุ่น แต่ความนิยมเพิ่มขึ้นอย่างมากในช่วงครึ่งหลังของทศวรรษ ตัวอย่างที่โดดเด่นของวิธีการใช้ Rust ได้แก่ การใช้งาน , (เราพูดถึงเรื่องนี้ใน - ประมาณ แปล.)คอมไพเลอร์ WebAssembly รุ่นแรก จาก Fastly (ปัจจุบันเป็นส่วนหนึ่งของ bytecodealliance) และอื่นๆ เมื่อ Microsoft กำลังพิจารณาเขียนบางส่วนของระบบปฏิบัติการ Windows ใหม่ในรูปแบบ Rust จึงปลอดภัยที่จะกล่าวว่าภาษานี้มีอนาคตที่สดใสในปี 2020
แม้แต่ภาษาไดนามิกก็มีคุณสมบัติใหม่เช่น (เลือกประเภทได้). พวกมันถูกนำมาใช้ครั้งแรกใน TypeScript ซึ่งเป็นภาษาที่ให้คุณสร้างโค้ดแบบพิมพ์และคอมไพล์เป็น JavaScript PHP, Ruby และ Python ต่างก็มีระบบการพิมพ์ที่เป็นทางเลือก (, ) ซึ่งใช้สำเร็จแล้วใน .
ส่งคืน SQL เป็น NoSQL
NoSQL เป็นอีกหนึ่งเทคโนโลยีที่ได้รับความนิยมอย่างมากในช่วงต้นทศวรรษมากกว่าในตอนท้าย ฉันคิดว่ามีสองเหตุผลสำหรับเรื่องนี้
ประการแรก แบบจำลอง NoSQL ที่ไม่มีสคีมา ไม่มีธุรกรรม และการรับประกันความสอดคล้องที่อ่อนแอกว่า ได้รับการพิสูจน์แล้วว่านำไปใช้งานได้ยากกว่าแบบจำลอง SQL ใน หัวข้อ "เหตุใดจึงควรเลือกใช้ความสอดคล้องกันอย่างมากเมื่อทำได้" (เหตุใดคุณจึงควรเลือกความสม่ำเสมอที่แข็งแกร่ง ทุกครั้งที่ทำได้) Google เขียน:
สิ่งหนึ่งที่เราได้เรียนรู้ที่ Google คือโค้ดของแอปพลิเคชันนั้นง่ายกว่าและเวลาในการพัฒนาจะสั้นลง หากวิศวกรสามารถใช้พื้นที่เก็บข้อมูลที่มีอยู่เพื่อประมวลผลธุรกรรมที่ซับซ้อนและเก็บข้อมูลให้เป็นระเบียบ ในการอ้างอิงเอกสารต้นฉบับสำหรับ Spanner "เราเชื่อว่าเป็นการดีกว่าสำหรับโปรแกรมเมอร์ในการจัดการกับปัญหาประสิทธิภาพของแอปพลิเคชันเนื่องจากการทำธุรกรรมในทางที่ผิดเมื่อเกิดคอขวดขึ้น แทนที่จะคำนึงถึงการไม่มีธุรกรรมอยู่ในใจตลอดเวลา"
เหตุผลที่สองเกี่ยวข้องกับการเติบโตของฐานข้อมูล SQL แบบกระจาย "ปรับขนาดได้" (เช่น и ) ในระบบคลาวด์สาธารณะ รวมถึงทางเลือกโอเพ่นซอร์ส เช่น CockroachDB (เรากำลังพูดถึงเธอด้วย - ประมาณ แปล.)ซึ่งช่วยแก้ปัญหาทางเทคนิคหลายอย่างที่ทำให้ฐานข้อมูล SQL แบบดั้งเดิม "ไม่ปรับขนาด" แม้แต่ MongoDB ซึ่งครั้งหนึ่งเคยเป็นตัวอย่างที่ดีของการเคลื่อนไหวของ NoSQL ก็กลายเป็นปัจจุบัน การทำธุรกรรมแบบกระจาย
สำหรับสถานการณ์ที่ต้องการการอ่านและเขียน Atomic ในเอกสารหลายชุด (ชุดเดียวหรือหลายชุด) MongoDB รองรับการทำธุรกรรมหลายเอกสาร ในกรณีของธุรกรรมแบบกระจาย ธุรกรรมสามารถใช้สำหรับการดำเนินการหลายรายการ คอลเลกชัน ฐานข้อมูล เอกสาร และเศษส่วน
การสตรีมทั้งหมด
Apache Kafka เป็นหนึ่งในสิ่งประดิษฐ์ที่สำคัญที่สุดในทศวรรษที่ผ่านมาอย่างไม่ต้องสงสัย ซอร์สโค้ดเปิดตัวในเดือนมกราคม 2011 และในช่วงหลายปีที่ผ่านมา Kafka ได้ปฏิวัติวิธีการทำงานของธุรกิจข้อมูล คาฟคาถูกนำมาใช้ในทุกบริษัทที่ฉันเคยทำงานให้ ตั้งแต่สตาร์ทอัพไปจนถึงองค์กรขนาดใหญ่ การรับประกันและกรณีการใช้งาน (pub-sub, streams, event-driven architectures) ถูกนำมาใช้ในงานต่างๆ ตั้งแต่คลังข้อมูลไปจนถึงการตรวจสอบและการวิเคราะห์แบบสตรีมมิ่ง ซึ่งเป็นที่ต้องการในหลายด้าน เช่น การเงิน การดูแลสุขภาพ ภาครัฐ การค้าปลีก และอื่น ๆ
การผสานรวมอย่างต่อเนื่อง (และการปรับใช้อย่างต่อเนื่องในระดับที่น้อยกว่า)
การบูรณาการอย่างต่อเนื่อง (Continuous Integration) ไม่ปรากฏในช่วง 10 ปีที่ผ่านมา แต่เป็นในช่วงทศวรรษที่ผ่านมา แผ่ขยายออกไปถึงขนาดนั้นซึ่งกลายเป็นส่วนหนึ่งของเวิร์กโฟลว์มาตรฐาน (รันการทดสอบกับคำขอดึงข้อมูลทั้งหมด) การสร้าง GitHub เป็นแพลตฟอร์มการพัฒนาและโค้ดโฮสติ้ง และที่สำคัญกว่านั้นคือการพัฒนาเวิร์กโฟลว์ตาม หมายความว่าการทดสอบการทำงานก่อนที่คำขอดึงจะได้รับการยอมรับในต้นแบบคือ เท่านั้น เวิร์กโฟลว์ในการพัฒนา ซึ่งคุ้นเคยกับวิศวกรที่เริ่มต้นอาชีพในช่วง XNUMX ปีที่ผ่านมา
การปรับใช้อย่างต่อเนื่อง (การปรับใช้อย่างต่อเนื่อง; การปรับใช้แต่ละคอมมิชชันและเมื่อถึงมาสเตอร์) ไม่แพร่หลายเท่ากับการรวมอย่างต่อเนื่อง อย่างไรก็ตาม ด้วย API การปรับใช้ระบบคลาวด์ที่แตกต่างกันมากมาย ความนิยมที่เพิ่มขึ้นของแพลตฟอร์มอย่าง Kubernetes (ให้ API มาตรฐานสำหรับการปรับใช้) และการกำเนิดของเครื่องมือหลายแพลตฟอร์มและหลายคลาวด์อย่าง Spinnaker (สร้างขึ้นจาก API มาตรฐานเหล่านั้น) กระบวนการปรับใช้กลายเป็นอัตโนมัติมากขึ้น คล่องตัวขึ้น และปลอดภัยขึ้นโดยทั่วไป
ตู้คอนเทนเนอร์
ตู้คอนเทนเนอร์เป็นเทคโนโลยีที่ถูกพูดถึง โฆษณา และถูกเข้าใจผิดมากที่สุดในยุค 2010 ในทางกลับกัน มันเป็นหนึ่งในนวัตกรรมที่สำคัญที่สุดของทศวรรษที่ผ่านมา เหตุผลส่วนหนึ่งสำหรับเสียงขรมทั้งหมดนี้อยู่ในสัญญาณผสมที่เราได้รับจากเกือบทุกที่ ตอนนี้โฆษณาได้ลดลงเล็กน้อยแล้ว บางช่วงเวลาก็มีเฉดสีที่แตกต่างกันมากขึ้น
ตู้คอนเทนเนอร์ได้รับความนิยมไม่ใช่เพราะเป็นวิธีที่ดีที่สุดในการเปิดแอปพลิเคชันที่ตอบสนองความต้องการของชุมชนนักพัฒนาทั่วโลก ตู้คอนเทนเนอร์กลายเป็นที่นิยมเนื่องจากประสบความสำเร็จในคำขอทางการตลาดสำหรับเครื่องมือที่ช่วยแก้ปัญหาที่แตกต่างไปจากเดิมอย่างสิ้นเชิง นักเทียบท่าเปิดออก มหัศจรรย์ เครื่องมือการพัฒนาที่ช่วยแก้ปัญหาความเข้ากันได้ด่วน (“ใช้งานได้กับเครื่องของฉัน”)
แม่นยำยิ่งขึ้น เขาปฏิวัติ ภาพนักเทียบท่าเนื่องจากช่วยแก้ปัญหาความเท่าเทียมกันระหว่างสภาพแวดล้อมและมอบความสามารถในการพกพาที่แท้จริง ไม่เพียงแต่ของไฟล์แอปพลิเคชันเท่านั้น แต่ยังรวมถึงซอฟต์แวร์และการพึ่งพาการดำเนินงานทั้งหมดด้วย ความจริงที่ว่าเครื่องมือนี้กระตุ้นความนิยมของ "คอนเทนเนอร์" ซึ่งโดยพื้นฐานแล้วเป็นรายละเอียดการใช้งานระดับต่ำมาก ยังคงเป็นปริศนาหลักของทศวรรษที่ผ่านมาสำหรับฉัน
serverless
ฉันยินดีที่จะเดิมพันว่าการเกิดขึ้นของการประมวลผลแบบ "ไร้เซิร์ฟเวอร์" นั้นสำคัญยิ่งกว่าคอนเทนเนอร์เพราะมันทำให้ความฝันของการประมวลผลแบบออนดีมานด์เป็นจริง (On-Demand). ในช่วงห้าปีที่ผ่านมา ฉันได้เห็นการขยายตัวอย่างค่อยเป็นค่อยไปของวิธีการไร้เซิร์ฟเวอร์เพื่อรองรับภาษาและรันไทม์ใหม่ การเกิดขึ้นของผลิตภัณฑ์เช่น Azure Durable Functions ดูเหมือนจะเป็นขั้นตอนที่ถูกต้องในการนำฟังก์ชัน stateful ไปใช้ (พร้อมกับการชี้ขาด ที่เกี่ยวข้องกับข้อจำกัดของ FaaS) ฉันจะเฝ้าดูด้วยความสนใจว่ากระบวนทัศน์ใหม่นี้จะพัฒนาขึ้นอย่างไรในอีกไม่กี่ปีข้างหน้า
อัตโนมัติ
บางทีผู้ที่ได้ประโยชน์สูงสุดจากเทรนด์นี้ก็คือชุมชนวิศวกรรมปฏิบัติการ เนื่องจากได้ทำให้แนวคิดเช่นโครงสร้างพื้นฐานเป็นโค้ด (IaC) มีชีวิตขึ้นมา นอกจากนี้ ความหลงใหลในระบบอัตโนมัติยังสอดคล้องกับการเพิ่มขึ้นของ "วัฒนธรรม SRE" ซึ่งมีจุดมุ่งหมายเพื่อแนวทางการดำเนินงานที่เน้นซอฟต์แวร์เป็นศูนย์กลางมากขึ้น
Universal API-Fication
คุณสมบัติที่น่าสนใจอีกอย่างของทศวรรษที่ผ่านมาคือ API-fication ของงานพัฒนาต่างๆ API ที่ดีและยืดหยุ่นช่วยให้นักพัฒนาสามารถสร้างเวิร์กโฟลว์และเครื่องมือที่เป็นนวัตกรรมซึ่งจะช่วยในการบำรุงรักษาและปรับปรุงประสบการณ์ผู้ใช้
นอกจากนี้ API-fiction ยังเป็นก้าวแรกสู่ SaaS-fiction ของฟังก์ชันหรือเครื่องมือบางอย่าง แนวโน้มนี้ยังสอดคล้องกับความนิยมที่เพิ่มขึ้นของไมโครเซอร์วิส: SaaS กลายเป็นเพียงบริการอื่นที่คุณสามารถทำงานด้วยผ่าน API ขณะนี้มีเครื่องมือ SaaS และ FOSS มากมายในด้านต่างๆ เช่น การตรวจสอบ การชำระเงิน การจัดสรรภาระงาน การผสานรวมอย่างต่อเนื่อง การแจ้งเตือน การสลับฟังก์ชัน (การตั้งค่าสถานะคุณสมบัติ), CDN, วิศวกรรมจราจร (เช่น DNS) เป็นต้น ซึ่งเฟื่องฟูในทศวรรษที่ผ่านมา
ความสามารถในการสังเกต
คงจะทราบกันดีว่าวันนี้เรามี ก้าวหน้ากว่ามาก เครื่องมือในการตรวจสอบและวินิจฉัยพฤติกรรมของแอปพลิเคชันอย่างที่ไม่เคยเป็นมาก่อน ระบบตรวจสอบ Prometheus ซึ่งได้รับสถานะเป็น Open Source ในปี 2015 เรียกได้ว่าบางที ที่สุด ระบบตรวจสอบการทำงานของผู้ที่ผมมีโอกาสร่วมงานด้วย มันไม่สมบูรณ์แบบ แต่มีหลายสิ่งหลายอย่างในนั้นถูกนำไปใช้ในวิธีที่ถูกต้องอย่างสมบูรณ์ (เช่น การสนับสนุนสำหรับการวัด [มิติ] ในกรณีของเมตริก)
การติดตามแบบกระจายกลายเป็นอีกเทคโนโลยีหนึ่งที่กลายเป็นกระแสหลักในปี 2010 ด้วยความคิดริเริ่มเช่น OpenTracing (และผู้สืบทอด OpenTelemetry) แม้ว่าการติดตามจะยังคงใช้งานค่อนข้างยาก แต่การพัฒนาล่าสุดบางอย่างก็ทำให้เราหวังว่าเราจะปลดล็อกศักยภาพที่แท้จริงของมันได้ในปี 2020 (หมายเหตุการแปล: อ่านในบล็อกของเราด้วยการแปลบทความ “โดยผู้เขียนคนเดียวกัน)
มองไปสู่อนาคต
อนิจจามีจุดเจ็บปวดมากมายที่รอการแก้ไขในทศวรรษหน้า นี่คือความคิดของฉันเกี่ยวกับพวกเขาและแนวคิดที่เป็นไปได้บางประการเกี่ยวกับวิธีกำจัดพวกเขา
การแก้ปัญหากฎของมัวร์
การสิ้นสุดของกฎสเกลของเดนนาร์ดและการล้าหลังของกฎของมัวร์จำเป็นต้องมีนวัตกรรมใหม่ จอห์น เฮนเนสซี่ อธิบายว่าทำไมผู้ติดปัญหา (เฉพาะโดเมน) สถาปัตยกรรมเช่น TPU อาจเป็นทางออกหนึ่งสำหรับ Moore's Law lag ทัลไคท์ชอบ จาก Google ดูเหมือนจะเป็นก้าวที่ดีในทิศทางนี้:
คอมไพเลอร์ต้องรองรับแอปพลิเคชันใหม่ ย้ายพอร์ตไปยังฮาร์ดแวร์ใหม่ได้ง่าย รวมนามธรรมหลายระดับตั้งแต่ไดนามิก ภาษาที่มีการจัดการ ไปจนถึงตัวเร่งเวกเตอร์และอุปกรณ์เก็บข้อมูลที่ควบคุมด้วยซอฟต์แวร์ ในขณะที่ยังมีสวิตช์ระดับสูงสำหรับการปรับแต่งอัตโนมัติ - ในการทำงาน - เวลา การวินิจฉัยและการกระจายข้อมูลการดีบักเกี่ยวกับการทำงานและประสิทธิภาพของระบบทั่วทั้งสแตก และในกรณีส่วนใหญ่ให้ประสิทธิภาพใกล้เคียงกับแอสเซมเบลอร์ที่เขียนด้วยมือ เราตั้งใจที่จะแบ่งปันวิสัยทัศน์ ความคืบหน้า และแผนของเราสำหรับการพัฒนาและความพร้อมใช้งานสาธารณะของโครงสร้างพื้นฐานการรวบรวมดังกล่าว
CI / ซีดี
ในขณะที่การเพิ่มขึ้นของ CI เป็นหนึ่งในแนวโน้มที่ใหญ่ที่สุดของปี 2010 แต่เจนกินส์ยังคงเป็นมาตรฐานทองคำสำหรับ CI
พื้นที่นี้ต้องการนวัตกรรมอย่างมากในด้านต่อไปนี้:
- ส่วนติดต่อผู้ใช้ (DSL สำหรับข้อกำหนดการทดสอบการเข้ารหัส);
- รายละเอียดการใช้งานที่จะทำให้ปรับขนาดได้อย่างแท้จริงและรวดเร็ว
- การรวมเข้ากับสภาพแวดล้อมต่างๆ (staging, prod ฯลฯ) สำหรับรูปแบบการทดสอบขั้นสูงเพิ่มเติม
- การทดสอบและการปรับใช้อย่างต่อเนื่อง
เครื่องมือสำหรับนักพัฒนา
ในฐานะอุตสาหกรรม เราได้เริ่มสร้างซอฟต์แวร์ที่ซับซ้อนและน่าประทับใจมากขึ้นเรื่อยๆ อย่างไรก็ตาม เมื่อพูดถึงเครื่องมือของเราเอง สถานการณ์อาจดีขึ้นมาก
การแก้ไขร่วมกันและระยะไกล (ผ่าน ssh) ได้รับความนิยมบ้าง แต่ไม่เคยกลายเป็นวิธีมาตรฐานใหม่ในการพัฒนา ถ้าคุณปฏิเสธความคิดของ ต้องการ การเชื่อมต่ออินเทอร์เน็ตอย่างต่อเนื่องเพื่อให้สามารถเขียนโปรแกรมได้ ดังนั้นการทำงานผ่าน ssh บนเครื่องระยะไกลไม่น่าจะเหมาะกับคุณ
สภาพแวดล้อมการพัฒนาในท้องถิ่น โดยเฉพาะอย่างยิ่งสำหรับวิศวกรที่ทำงานบนสถาปัตยกรรมที่เน้นการบริการขนาดใหญ่ยังคงเป็นความท้าทาย บางโครงการกำลังพยายามแก้ปัญหานี้อยู่ และฉันสนใจที่จะทราบว่า UX ที่ออกแบบตามหลักสรีรศาสตร์มากที่สุดจะมีลักษณะอย่างไรสำหรับกรณีการใช้งานที่กำหนด
นอกจากนี้ยังเป็นเรื่องที่น่าสนใจที่จะขยายแนวคิดของ "สภาพแวดล้อมแบบพกพา" ไปยังพื้นที่อื่น ๆ ของการพัฒนา เช่น การสืบพันธุ์ของแมลง (หรือ ) เกิดขึ้นภายใต้เงื่อนไขบางอย่างหรือการตั้งค่าบางอย่าง
นอกจากนี้ ฉันยังต้องการเห็นนวัตกรรมเพิ่มเติมในด้านต่างๆ เช่น การค้นหารหัสเชิงความหมายและตามบริบท เครื่องมือในการจับคู่เหตุการณ์การผลิตกับส่วนเฉพาะของโค้ดเบส เป็นต้น
คอมพิวเตอร์ (อนาคตของ PaaS)
ท่ามกลางกระแสโฆษณาทั่วไปเกี่ยวกับคอนเทนเนอร์และเซิร์ฟเวอร์ไร้เซิร์ฟเวอร์ในช่วงปี 2010 ช่วงของโซลูชันในพื้นที่คลาวด์สาธารณะได้ขยายตัวอย่างมากในช่วงไม่กี่ปีที่ผ่านมา
สิ่งนี้ทำให้เกิดคำถามที่น่าสนใจหลายประการ ประการแรก รายการตัวเลือกที่มีอยู่ในระบบคลาวด์สาธารณะมีการเติบโตอย่างต่อเนื่อง ผู้ให้บริการระบบคลาวด์มีพนักงานและทรัพยากรเพื่อให้ทันกับการพัฒนาล่าสุดในโลกโอเพ่นซอร์สได้อย่างง่ายดายและปล่อยผลิตภัณฑ์เช่น "serverless pods" (ฉันสงสัยว่าเพียงแค่สร้างรันไทม์ FaaS ของตัวเองที่สอดคล้องกับ OCI) หรือสิ่งแปลก ๆ ที่คล้ายกัน
ผู้ที่ใช้โซลูชันคลาวด์เหล่านี้จะต้องอิจฉาเท่านั้น ในทางทฤษฎี ข้อเสนอระบบคลาวด์ของ Kubernetes (GKE, EKS, EKS บน Fargate เป็นต้น) ให้ API ที่ไม่ขึ้นกับผู้ให้บริการระบบคลาวด์สำหรับการเรียกใช้ปริมาณงาน หากคุณใช้ผลิตภัณฑ์ที่คล้ายคลึงกัน (ECS, Fargate, Google Cloud Run และอื่นๆ) คุณอาจได้ใช้คุณลักษณะที่น่าสนใจที่สุดจากผู้ให้บริการแล้ว นอกจากนี้ เมื่อมีผลิตภัณฑ์หรือกระบวนทัศน์ด้านคอมพิวเตอร์ใหม่ๆ เกิดขึ้น การย้ายข้อมูลก็น่าจะทำได้ง่ายและไม่ยุ่งยาก
เมื่อพิจารณาว่าโซลูชันเหล่านี้มีการพัฒนาอย่างรวดเร็วเพียงใด (ฉันจะแปลกใจมากถ้าไม่มีตัวเลือกใหม่ๆ ออกมาเร็วๆ นี้) ทีม "แพลตฟอร์ม" ขนาดเล็ก (ทีมที่เกี่ยวข้องกับโครงสร้างพื้นฐานและรับผิดชอบในการสร้างแพลตฟอร์มในองค์กร เพื่อรันบริษัทที่มีปริมาณงาน) จะแข่งขันได้ยากอย่างไม่น่าเชื่อในแง่ของฟังก์ชัน ใช้งานง่าย และความน่าเชื่อถือโดยรวม ตั้งแต่ช่วงปี 2010 เป็นต้นมา Kubernetes เต็มไปด้วยเครื่องมือสำหรับสร้าง PaaS (platform-as-a-service) ฉันคิดว่าการสร้างแพลตฟอร์มภายในโดยใช้ Kubernetes ที่มีตัวเลือก ความเรียบง่าย และอิสระแบบเดียวกันนั้นมีอยู่ใน คลาวด์สาธารณะ การคิดว่า PaaS ที่ใช้คอนเทนเนอร์เป็น "กลยุทธ์ Kubernetes" นั้นเท่ากับการจงใจหลีกเลี่ยงฟีเจอร์ที่เป็นนวัตกรรมที่สุดของระบบคลาวด์
มองที่มีอยู่ ในวันนี้ ความสามารถในการคำนวณ เป็นที่ชัดเจนว่าการสร้าง PaaS ของคุณเองโดยเฉพาะบน Kubernetes นั้นเทียบเท่ากับการขับรถเข้ามุมด้วยมือของคุณเอง (ไม่ใช่วิธีการที่มองการณ์ไกลเกินไปใช่ไหม) แม้ว่าใครจะตัดสินใจสร้าง PaaS แบบคอนเทนเนอร์โดยใช้ Kubernetes ในวันนี้ แต่ในอีกไม่กี่ปีข้างหน้าก็จะดูล้าสมัยเมื่อเทียบกับความสามารถของระบบคลาวด์ แม้ว่า Kubernetes จะเริ่มต้นจากการเป็นโครงการโอเพ่นซอร์ส แต่ต้นกำเนิดและแรงบันดาลใจเชิงอุดมการณ์คือเครื่องมือภายในของ Google ที่สอดคล้องกัน อย่างไรก็ตาม มันถูกพัฒนาขึ้นในช่วงต้น/กลางปี 2000 เมื่อภูมิทัศน์ของคอมพิวเตอร์แตกต่างไปจากเดิมอย่างสิ้นเชิง
นอกจากนี้ ในความหมายกว้างๆ บริษัทต่างๆ ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญในการทำงานกับคลัสเตอร์ Kubernetes และไม่ต้องอยู่ในธุรกิจด้านการสร้างและบำรุงรักษาศูนย์ข้อมูลของตนเอง การทำให้มั่นใจถึงพื้นฐานการประมวลผลที่เชื่อถือได้คือความท้าทายหลัก ผู้ให้บริการคลาวด์.
ในที่สุด ฉันรู้สึกว่าเราได้ถดถอยเล็กน้อยในฐานะอุตสาหกรรมในแง่ของ ประสบการณ์ปฏิสัมพันธ์ (). Heroku เปิดตัวในปี 2007 และยังคงเป็นหนึ่งในที่สุด ง่ายต่อการใช้ แพลตฟอร์ม ไม่ต้องสงสัยเลยว่า Kubernetes มีประสิทธิภาพมากกว่า ขยายได้ และตั้งโปรแกรมได้ แต่ฉันคิดถึงความง่ายในการเริ่มต้นและปรับใช้กับ Heroku หากต้องการใช้แพลตฟอร์มนี้ แค่รู้จัก Git ก็เพียงพอแล้ว
ทั้งหมดนี้ทำให้ฉันได้ข้อสรุปต่อไปนี้: เราต้องการสิ่งที่เป็นนามธรรมที่ดีกว่าและสูงกว่าเพื่อทำงานด้วย (โดยเฉพาะอย่างยิ่งสำหรับ นามธรรมในระดับสูงสุด).
API ระดับบนสุดที่เหมาะสม
นักเทียบท่าเป็นตัวอย่างที่ดีของความจำเป็นในการแยกข้อกังวลที่ดีขึ้นในเวลาเดียวกัน การใช้งาน API ระดับสูงสุดอย่างถูกต้อง.
ปัญหาของนักเทียบท่าคือ (อย่างน้อย) ในขั้นต้น โปรเจกต์ถูกตั้งเป้าหมายระดับโลกมากเกินไป: ทั้งหมดนี้เพื่อแก้ปัญหาความเข้ากันได้ ("ใช้งานได้กับเครื่องของฉัน") โดยใช้เทคโนโลยีคอนเทนเนอร์ นักเทียบท่าเป็นทั้งรูปแบบอิมเมจและรันไทม์ที่มีเครือข่ายเสมือนของตัวเอง และเครื่องมือ CLI และดีมอนที่ทำงานในฐานะรูท และอื่นๆ อีกมากมาย อย่างไรก็ตามข้อความคือ ขึ้น ความสับสน ไม่ต้องพูดถึง "VMs ที่มีน้ำหนักเบา", cgroups, เนมสเปซ, ปัญหาด้านความปลอดภัยและคุณสมบัติมากมายที่ผสมผสานกับการโทรทางการตลาดเพื่อ "สร้าง, จัดส่ง, เรียกใช้แอปพลิเคชันใดก็ได้"
เช่นเดียวกับนามธรรมที่ดีทั้งหมด มันต้องใช้เวลา (เช่นเดียวกับประสบการณ์และความเจ็บปวด) เพื่อแยกปัญหาต่างๆ ออกเป็นชั้นเชิงตรรกะที่สามารถรวมเข้าด้วยกันได้ อนิจจาก่อนที่นักเทียบท่าจะบรรลุวุฒิภาวะนั้น Kubernetes ก็เข้าสู่การต่อสู้ เขาผูกขาดวงจรโฆษณามากจนตอนนี้ทุกคนพยายามตามให้ทันการเปลี่ยนแปลงในระบบนิเวศ Kubernetes และระบบนิเวศของคอนเทนเนอร์ก็ได้รับสถานะรอง
Kubernetes แบ่งปันข้อกังวลเดียวกันกับ Docker ในหลาย ๆ ด้าน แม้จะมีการพูดคุยเกี่ยวกับสิ่งที่เป็นนามธรรมที่เจ๋งและเรียบเรียงได้ แยกงานออกเป็นชั้นๆ ไม่ห่อหุ้มอย่างดี แก่นแท้ของมันคือคอนเทนเนอร์ออร์เคสตราที่รันคอนเทนเนอร์บนคลัสเตอร์ของเครื่องต่างๆ นี่เป็นงานระดับต่ำ ใช้ได้กับวิศวกรที่รันคลัสเตอร์เท่านั้น ในทางกลับกัน Kubernetes ก็เช่นกัน นามธรรมของระดับสูงสุดซึ่งเป็นเครื่องมือ CLI ที่ผู้ใช้โต้ตอบผ่าน YAML
นักเทียบท่าเคยเป็น (และยังคงเป็นอยู่) เย็น เครื่องมือสำหรับการพัฒนาแม้จะมีข้อบกพร่องทั้งหมด ในความพยายามที่จะติดตาม "กระต่าย" ทั้งหมดในคราวเดียว นักพัฒนาซอฟต์แวร์สามารถดำเนินการได้อย่างถูกต้อง นามธรรมของระดับสูงสุด. โดยความเป็นนามธรรมในระดับสูงสุด ฉันหมายถึง ชุดย่อย ฟังก์ชันการทำงานที่กลุ่มเป้าหมายสนใจจริงๆ (ในกรณีนี้คือนักพัฒนาที่ใช้เวลาส่วนใหญ่ในสภาพแวดล้อมการพัฒนาท้องถิ่น) และใช้งานได้ดีเมื่อแกะกล่อง.
ยูทิลิตี้ Dockerfile และ CLI docker ควรเป็นตัวอย่างของการสร้าง "ส่วนติดต่อผู้ใช้ระดับสูงสุด" ที่ดี นักพัฒนาทั่วไปสามารถเริ่มต้นใช้งาน Docker ได้โดยไม่ต้องรู้อะไรเกี่ยวกับความซับซ้อน การใช้งานที่นำไปสู่ประสบการณ์การปฏิบัติงานเช่น namespaces, cgroups, memory และ CPU limits เป็นต้น ท้ายที่สุดแล้ว การเขียน Dockerfile ก็ไม่ได้แตกต่างจากการเขียนเชลล์สคริปต์มากนัก
Kubernetes ออกแบบมาสำหรับกลุ่มเป้าหมายที่แตกต่างกัน:
- ผู้ดูแลระบบคลัสเตอร์
- วิศวกรซอฟต์แวร์ที่เกี่ยวข้องกับปัญหาโครงสร้างพื้นฐาน การขยายขีดความสามารถของ Kubernetes และสร้างแพลตฟอร์มที่อิงจาก Kubernetes
- ผู้ใช้โต้ตอบกับ Kubernetes ผ่าน
kubectl.
แนวทาง “one API เหมาะกับทุกคน” ที่ดำเนินการโดย Kubernetes เป็นภูเขาที่ซับซ้อนซึ่งไม่ได้ระบุวิธีการปรับขนาด ทั้งหมดนี้นำไปสู่วิถีการเรียนรู้ที่ยาวนานโดยไม่จำเป็น ยังไง Adam Jacob กล่าวว่า “Docker ได้นำประสบการณ์ผู้ใช้ที่พลิกโฉมใหม่ซึ่งยังไม่มีใครเทียบได้ ถามใครก็ตามที่ใช้ K8 ว่าต้องการให้ใช้งานได้เหมือนครั้งแรกหรือไม่ docker run. คำตอบจะอยู่ในการยืนยัน":
ฉันจะเถียงว่าเทคโนโลยีโครงสร้างพื้นฐานจำนวนมากในปัจจุบันอยู่ในระดับต่ำเกินไป (และถือว่า "ซับซ้อนเกินไป") Kubernetes ใช้งานในระดับที่ค่อนข้างต่ำ การติดตามแบบกระจายในนั้น (ช่วงหลายช่วงต่อเข้าด้วยกันเพื่อสร้างการสืบค้นกลับ) จะถูกนำไปใช้ในระดับที่ต่ำมากเช่นกัน เครื่องมือสำหรับนักพัฒนาที่ใช้ "นามธรรมระดับสูงสุด" มักจะประสบความสำเร็จมากที่สุด ข้อสรุปนี้กลายเป็นจริงในหลายกรณีที่น่าแปลกใจ (หากเทคโนโลยีซับซ้อนเกินไปหรือใช้งานยาก แสดงว่ายังไม่มีการค้นพบ "API/UI ระดับสูงสุด" สำหรับเทคโนโลยีนั้น)
ตอนนี้ ระบบนิเวศเนทีฟบนคลาวด์กำลังหมกมุ่นอยู่กับระดับต่ำอย่างน่าอาย ในฐานะอุตสาหกรรม เราจำเป็นต้องคิดค้น ทดลอง และให้ความรู้ว่าระดับที่เหมาะสมของ "สิ่งที่เป็นนามธรรมขั้นสูงสุด" นั้นมีลักษณะอย่างไร
การค้าปลีก
ในปี 2010 ประสบการณ์การค้าปลีกแบบดิจิทัลแทบจะไม่เปลี่ยนแปลง ในแง่หนึ่ง ความง่ายดายในการช้อปปิ้งออนไลน์ควรที่จะเข้ามาแทนที่ร้านค้าปลีกแบบดั้งเดิม ในทางกลับกัน การช้อปปิ้งออนไลน์แทบไม่ได้เปลี่ยนแปลงโดยพื้นฐานในทศวรรษที่ผ่านมา
แม้ว่าฉันจะไม่ได้มีความคิดเจาะจงว่าอุตสาหกรรมนี้จะพัฒนาไปอย่างไรในทศวรรษหน้า แต่ฉันคงผิดหวังมากหากเราจับจ่ายในปี 2030 เหมือนที่เราทำในปี 2020
วารสารศาสตร์
ฉันรู้สึกไม่แยแสกับสถานะของการสื่อสารมวลชนทั่วโลกมากขึ้นเรื่อยๆ การหาสำนักข่าวที่เป็นกลางซึ่งมีวัตถุประสงค์และอวดรู้นั้นยากขึ้นเรื่อยๆ บ่อยครั้งที่ขอบเขตระหว่างข่าวและความคิดเห็นเกี่ยวกับข่าวนั้นเบลอ ตามกฎแล้ว ข้อมูลจะถูกนำเสนออย่างมีอคติ โดยเฉพาะอย่างยิ่งในบางประเทศซึ่งไม่เคยมีการแบ่งแยกระหว่างข่าวสารและความคิดเห็นในอดีต ในบทความล่าสุดที่ตีพิมพ์หลังการเลือกตั้งทั่วไปในสหราชอาณาจักรครั้งล่าสุด Alan Rusbridger อดีตบรรณาธิการของ The Guardian :
ประเด็นหลักคือเป็นเวลาหลายปีที่ฉันดูหนังสือพิมพ์อเมริกันและรู้สึกเสียใจกับเพื่อนร่วมงานที่นั่นซึ่งเป็นผู้รับผิดชอบข่าวแต่เพียงผู้เดียวโดยปล่อยให้ความเห็นต่างไปจากเดิมอย่างสิ้นเชิง อย่างไรก็ตาม เมื่อเวลาผ่านไป ความสงสารกลายเป็นความอิจฉา ตอนนี้ฉันคิดว่าหนังสือพิมพ์สัญชาติอังกฤษทุกฉบับควรแยกความรับผิดชอบต่อข่าวออกจากความรับผิดชอบในการวิจารณ์ อนิจจา มันยากเกินไปสำหรับผู้อ่านทั่วไป - โดยเฉพาะผู้อ่านออนไลน์ - ที่จะแยกแยะความแตกต่าง
ด้วยชื่อเสียงที่ค่อนข้างน่าสงสัยของ Silicon Valley ในด้านจริยธรรม ฉันคงไม่ไว้ใจเทคโนโลยีในการ "ปฏิวัติ" สื่อสารมวลชน ในเวลาเดียวกัน ฉัน (และคนรู้จักของฉันหลายคน) จะดีใจหากแหล่งข่าวที่เป็นกลาง ไม่สนใจ และน่าเชื่อถือปรากฏขึ้น แม้ว่าฉันจะไม่รู้ว่าแพลตฟอร์มดังกล่าวจะมีหน้าตาเป็นอย่างไร แต่ฉันแน่ใจว่าในยุคที่ความจริงเริ่มมองเห็นได้ยากขึ้นเรื่อย ๆ ความต้องการสื่อสารมวลชนที่ตรงไปตรงมามีมากขึ้นกว่าเดิม
เครือข่ายทางสังคม
โซเชียลเน็ตเวิร์กและแพลตฟอร์มข่าวร่วมกันเป็นแหล่งข้อมูลหลักสำหรับผู้คนจำนวนมากในส่วนต่างๆ ของโลก และการขาดความแม่นยำและไม่เต็มใจของบางแพลตฟอร์มในการดำเนินการตรวจสอบประวัติขั้นพื้นฐานเป็นอย่างน้อย นำไปสู่ผลลัพธ์ที่เลวร้าย เช่น การฆ่าล้างเผ่าพันธุ์ การแทรกแซงการเลือกตั้ง ฯลฯ
โซเชียลมีเดียยังเป็นเครื่องมือสื่อที่ทรงพลังที่สุดเท่าที่เคยมีมา พวกเขาเปลี่ยนแปลงการปฏิบัติทางการเมืองอย่างรุนแรง พวกเขาเปลี่ยนโฆษณา พวกเขาเปลี่ยนวัฒนธรรมป๊อป (เช่น การสนับสนุนหลักในการพัฒนาวัฒนธรรมที่เรียกว่าการยกเลิก [วัฒนธรรมการเหยียดหยาม - ประมาณ. แปล] สนับสนุนโดยเครือข่ายสังคม) นักวิจารณ์โต้แย้งว่าสื่อสังคมออนไลน์เป็นรากฐานอันอุดมสมบูรณ์สำหรับการเปลี่ยนแปลงอย่างรวดเร็วและ "ตามอำเภอใจ" ในค่านิยมทางศีลธรรม แต่ก็เปิดโอกาสให้กลุ่มคนชายขอบได้มารวมตัวกัน (ซึ่งพวกเขาไม่เคยมีมาก่อน) โดยพื้นฐานแล้ว สื่อสังคมออนไลน์ได้เปลี่ยนแปลงวิธีการสื่อสารและการแสดงออกของผู้คนในศตวรรษที่ XNUMX
อย่างไรก็ตาม ฉันยังเชื่อด้วยว่าสื่อสังคมออนไลน์มีส่วนช่วยในการแสดงออกถึงแรงกระตุ้นที่เลวร้ายที่สุดของมนุษย์ ความเอาใจใส่และความรอบคอบมักถูกละเลยเนื่องจากความนิยม และแทบจะเป็นไปไม่ได้เลยที่จะแสดงความไม่เห็นด้วยอย่างมีเหตุผลกับความคิดเห็นและจุดยืนบางอย่าง การแบ่งขั้วมักจะควบคุมไม่ได้ ปล่อยให้ประชาชนไม่รับฟังความคิดเห็นของแต่ละคน ในขณะที่ผู้นิยมสัมบูรณ์จะควบคุมประเด็นมารยาทออนไลน์และการยอมรับ
ฉันสงสัยว่าเป็นไปได้ไหมที่จะสร้างแพลตฟอร์มที่ "ดีกว่า" เพื่อปรับปรุงคุณภาพการอภิปราย ท้ายที่สุดแล้ว มันเป็นสิ่งที่ขับเคลื่อน "การมีส่วนร่วม" ซึ่งมักจะนำผลกำไรหลักมาสู่แพลตฟอร์มเหล่านี้ ยังไง Kara Swisher ใน New York Times:
เป็นไปได้ที่จะพัฒนาปฏิสัมพันธ์ทางดิจิทัลโดยไม่กระตุ้นความเกลียดชังและการไม่ยอมรับ เหตุผลที่เครือข่ายสังคมออนไลน์ส่วนใหญ่ดูเหมือนเป็นพิษก็เพราะพวกเขาสร้างขึ้นเพื่อความเร็ว กระแสนิยม และความสนใจ ไม่ใช่เนื้อหาและความถูกต้อง
คงจะน่าเสียดายอย่างยิ่งหากในอีกไม่กี่ทศวรรษ มรดกเพียงอย่างเดียวของโซเชียลมีเดียคือการกัดเซาะความแตกต่างเล็กน้อยและความเพียงพอในวาทกรรมสาธารณะ
ปล.จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «";
- «'
ที่มา: will.com