Catatan perev. : Artikel dengan hit sedang ini adalah ikhtisar perubahan kunci (2010-2019) di dunia bahasa pemrograman dan ekosistem teknologi terkait (perhatian khusus diberikan kepada Docker dan Kubernetes). Penulis aslinya adalah Cindy Sridharan, yang berspesialisasi dalam alat untuk pengembang dan sistem terdistribusi - khususnya, ia menulis buku "Distributed Systems Observability" - dan cukup populer di ruang internet di kalangan profesional TI yang sangat tertarik dengan topik cloud asli.
2019 telah berakhir, jadi saya ingin berbagi pemikiran saya tentang beberapa pencapaian teknologi dan inovasi terpenting dalam dekade terakhir. Selain itu, saya akan mencoba untuk melihat sedikit ke masa depan dan menguraikan masalah utama dan peluang dekade mendatang.
Saya ingin segera membuat reservasi bahwa dalam artikel ini saya tidak membahas perubahan dalam bidang-bidang seperti
ilmu data , kecerdasan buatan, teknik frontend, dll., Karena saya pribadi tidak memiliki cukup pengalaman di dalamnya.
Mengetik Strikes Kembali
Salah satu tren paling positif di tahun 2010-an adalah kebangkitan kembali bahasa-bahasa dengan tipifikasi statis. Namun, bahasa seperti itu tidak menghilang di mana saja (C ++ dan Java sedang diminati saat ini; mereka mendominasi sepuluh tahun yang lalu), namun, bahasa dengan pengetikan dinamis (dinamis) mengalami peningkatan popularitas yang signifikan setelah munculnya gerakan Ruby on Rails pada 2005. Pertumbuhan ini memuncak pada tahun 2009 dengan pembukaan kode sumber Node.js, menjadikan Javascript di server menjadi kenyataan.
Seiring waktu, bahasa dinamis telah kehilangan sebagian daya tariknya dalam pengembangan perangkat lunak server. Bahasa Go, dipopulerkan selama revolusi kontainer, tampaknya lebih baik diadaptasi untuk membuat server berkinerja tinggi, efisien sumber daya dengan pemrosesan informasi paralel (yang
disetujui oleh pencipta Node.js).
Rust, diperkenalkan pada 2010, termasuk kemajuan dalam
teori tipe dalam upaya untuk menjadi bahasa yang aman dan diketik. Pada paruh pertama dekade ini, sikap terhadap Rust di industri cukup keren, tetapi di babak kedua popularitasnya meningkat secara signifikan. Contoh penting penggunaan Rust termasuk penggunaannya untuk
Magic Pocket di Dropbox ,
AWS Firecracker (kami membicarakannya dalam artikel ini - kira-kira. Terjemahan) , kompiler WebAssembly Fastly awal dari Fastly (sekarang bagian dari Aliansi Bytecode), dll. Dalam situasi ketika Microsoft mempertimbangkan untuk menulis ulang beberapa bagian Windows ke Rust, dapat dikatakan bahwa pada tahun 2020 bahasa ini memiliki masa depan yang cerah.
Bahkan bahasa yang dinamis telah mendapatkan fitur baru seperti
tipe opsional . Mereka pertama kali diimplementasikan dalam TypeScript, bahasa yang memungkinkan Anda membuat kode yang diketik dan mengompilasinya dalam JavaScript. PHP, Ruby dan Python telah memperoleh sistem pengetikan opsional mereka sendiri (
mypy ,
Hack ), yang berhasil digunakan dalam
produksi .
SQL kembali ke NoSQL
NoSQL adalah teknologi lain yang jauh lebih populer di awal dekade daripada di akhir. Saya pikir ada dua alasan untuk ini.
Pertama, model NoSQL dengan kurangnya skema, transaksi dan jaminan konsistensi yang lebih lemah ternyata lebih sulit diimplementasikan daripada model SQL. Dalam sebuah
posting blog berjudul "
Mengapa Anda harus memilih konsistensi yang kuat, bila memungkinkan", Google menulis:
Salah satu hal yang kami pelajari di Google adalah bahwa kode aplikasi lebih sederhana dan waktu pengembangan lebih singkat jika para insinyur dapat mengandalkan penyimpanan yang ada untuk menangani transaksi yang kompleks dan menjaga ketertiban data. Mengutip dokumentasi asli untuk Spanner, "kami percaya bahwa lebih baik jika programmer menangani masalah kinerja aplikasi karena penyalahgunaan transaksi karena kemacetan terjadi daripada secara permanen mengingat tidak adanya transaksi."
Alasan kedua terkait dengan pertumbuhan database SQL terdistribusi "scalable" (seperti
Cloud Spanner dan
AWS Aurora ) di ruang cloud publik, serta alternatif Open Source seperti CockroachDB
(kami juga menulis tentang itu - kira-kira. Terjemahan) , yang banyak dipecahkan dari masalah teknis, karena yang basis SQL tradisional "tidak skala". Bahkan MongoDB, yang pernah menjadi lambang pergerakan NoSQL, sekarang
menawarkan transaksi terdistribusi.
Untuk situasi yang membutuhkan operasi baca dan tulis atom ke beberapa dokumen (dalam satu atau beberapa koleksi), MongoDB mendukung transaksi dengan banyak dokumen. Dalam kasus transaksi terdistribusi, transaksi dapat digunakan untuk banyak operasi, koleksi, database, dokumen, dan pecahan.
Streaming total
Apache Kafka, tanpa diragukan lagi, telah menjadi salah satu penemuan terpenting dalam dekade terakhir. Kode sumbernya dibuka pada Januari 2011, dan selama bertahun-tahun Kafka telah merevolusi cara bisnis data bekerja. Kafka digunakan di semua perusahaan tempat saya memiliki kesempatan untuk bekerja, mulai dari perusahaan pemula hingga perusahaan besar. Jaminan dan kasus penggunaan yang disediakan untuk mereka (pub-sub, stream, arsitektur berorientasi acara) digunakan dalam berbagai tugas: mulai dari mengatur penyimpanan data hingga pemantauan dan analisis streaming, yang banyak diminati di banyak bidang, seperti keuangan, kesehatan, sektor publik, ritel dan dll.
Integrasi yang berkelanjutan (dan penyebaran berkelanjutan yang lebih luas)
Integrasi Berkelanjutan tidak muncul dalam 10 tahun terakhir, tetapi selama dekade terakhir telah
menyebar sedemikian rupa sehingga telah menjadi bagian dari alur kerja standar (menjalankan tes pada semua permintaan tarik). Menjadi GitHub sebagai platform untuk mengembangkan dan menyimpan kode dan, yang lebih penting, mengembangkan alur kerja berdasarkan
aliran GitHub berarti melakukan pengujian sebelum menerima permintaan tarik ke master adalah
satu -
satunya alur kerja dalam pengembangan yang akrab bagi insinyur yang memulai karir mereka di sepuluh tahun terakhir.
Penyebaran Berkelanjutan (Continuous Deployment; mengerahkan setiap komit sebagaimana adanya dan ketika memasuki master) tidak seluas seperti integrasi berkelanjutan. Namun, dengan banyak API berbasis cloud yang berbeda untuk penyebaran, semakin populernya platform seperti Kubernetes (menyediakan API standar untuk penyebaran) dan munculnya multi-platform, alat multi-cloud seperti Spinnaker (dibangun di atas API standar ini), proses penyebaran menjadi lebih otomatis, ramping, dan ramping. umumnya lebih aman.
Wadah
Kontainer, mungkin, bisa disebut sebagai teknologi paling hype, dibahas, diiklankan, dan disalahpahami di tahun 2010-an. Di sisi lain, ini adalah salah satu inovasi paling penting pada dekade sebelumnya. Sebagian alasan dari semua hiruk-pikuk ini terletak pada sinyal campuran yang kami terima hampir di mana-mana. Sekarang hype telah sedikit tenang, beberapa saat telah mengambil nuansa yang lebih berbeda.
Wadah telah menjadi populer bukan karena mereka adalah cara terbaik untuk menjalankan aplikasi yang memenuhi kebutuhan komunitas pengembang global. Kontainer menjadi populer karena mereka berhasil masuk ke dalam permintaan pemasaran untuk alat yang memecahkan masalah yang sama sekali berbeda. Docker ternyata menjadi alat pengembangan yang luar biasa untuk menyelesaikan masalah kompatibilitas yang mendesak (“berfungsi pada mesin saya”).
Lebih tepatnya,
gambar Docker membuat revolusi karena memecahkan masalah paritas antara lingkungan dan memastikan portabilitas sebenarnya tidak hanya file aplikasi, tetapi juga semua perangkat lunak dan dependensi operasionalnya. Fakta bahwa alat ini entah bagaimana memacu popularitas "wadah", yang sebenarnya merupakan detail implementasi tingkat sangat rendah, bagi saya mungkin merupakan misteri utama dekade terakhir.
Tanpa server
Saya bertaruh bahwa penampilan komputasi "tanpa server" bahkan lebih penting daripada wadah, karena benar-benar memungkinkan Anda untuk mewujudkan impian komputasi
on-demand . Selama lima tahun terakhir, saya telah mengamati ekspansi bertahap dari cakupan pendekatan tanpa server (menambahkan dukungan untuk bahasa dan runtime baru). Munculnya produk-produk seperti Azure Durable Functions tampaknya menjadi langkah pasti menuju implementasi fungsi stateful (secara bersamaan menyelesaikan
beberapa masalah terkait dengan pembatasan FaaS). Saya akan mengamati dengan penuh minat bagaimana paradigma baru ini akan berkembang di tahun-tahun mendatang.
Otomasi
Mungkin komunitas insinyur operasi mendapat manfaat paling besar dari tren ini, karena dialah yang memungkinkan implementasi konsep seperti "infrastruktur sebagai kode" (IaC). Selain itu, semangat untuk otomasi bertepatan dengan pertumbuhan "budaya SRE", yang tujuannya adalah pendekatan yang lebih berorientasi pada program untuk operasi.
API Universal
Fitur aneh lainnya dalam dekade terakhir adalah fikasi API dari berbagai tugas pengembangan. API yang baik dan fleksibel memungkinkan pengembang untuk membuat alur kerja dan alat inovatif yang, pada gilirannya, membantu pemeliharaan dan meningkatkan kegunaan.
Selain itu, fiksi API adalah langkah pertama untuk fiksi SaaS dari beberapa fungsionalitas atau alat. Tren ini juga bertepatan dengan semakin populernya layanan microser: SaaS hanyalah layanan lain yang dapat Anda gunakan dengan menggunakan API. Saat ini ada banyak alat SaaS dan FOSS di berbagai bidang seperti pemantauan, pembayaran, penyeimbangan beban, integrasi berkelanjutan, peringatan,
penandaan fitur , CDN, rekayasa lalu lintas (mis. DNS), dll., yang berkembang dalam dekade terakhir.
Observabilitas
Perlu dicatat bahwa saat ini kami memiliki
banyak alat
canggih yang tersedia untuk memantau dan mendiagnosis perilaku aplikasi daripada sebelumnya. Sistem pemantauan Prometheus, yang menerima status Open Source pada tahun 2015, bisa disebut sebagai sistem pemantauan
terbaik yang pernah saya gunakan. Ini tidak sempurna, tetapi sejumlah besar hal diimplementasikan dengan cara yang sepenuhnya benar (misalnya, dukungan untuk
dimensi dalam kasus metrik).
Pelacakan terdistribusi adalah teknologi lain yang memasuki arus utama pada tahun 2010 berkat inisiatif seperti OpenTracing (dan penggantinya, OpenTelemetry). Meskipun penelusuran masih cukup sulit untuk digunakan, beberapa perkembangan terbaru memungkinkan kita untuk berharap bahwa pada tahun 2020 kita akan mengungkapkan potensi sebenarnya.
(Catatan perev.: Baca juga di blog kami terjemahan artikel " Penelusuran terdistribusi: kami melakukan segalanya yang salah " oleh penulis yang sama.)Mencari masa depan
Sayangnya, ada banyak titik sakit yang menunggu untuk diselesaikan dalam dekade mendatang. Berikut ini adalah pemikiran saya tentang mereka dan beberapa ide potensial tentang cara menghilangkannya.
Memecahkan Masalah Hukum Moore
Akhir dari hukum scaling Dennard dan tertinggal dari hukum Moore membutuhkan inovasi baru. John Hennessy, dalam
ceramahnya, menjelaskan mengapa arsitektur
khusus domain seperti TPU dapat menjadi salah satu solusi untuk masalah tertinggal di belakang hukum Moore. Toolkit seperti Google
MLIR sudah tampak seperti langkah maju yang baik dalam arah ini:
Compiler harus mendukung aplikasi baru, dengan mudah melakukan porting ke perangkat keras baru, mengikat banyak level abstraksi, dari bahasa yang dinamis, terkontrol hingga akselerator vektor dan perangkat penyimpanan yang dikendalikan program, sementara pada saat yang sama menyediakan sakelar tingkat tinggi untuk penyetelan otomatis, memberikan fungsionalitas yang adil -waktu, mendiagnosis dan mendistribusikan informasi debug tentang fungsi dan kinerja sistem di seluruh tumpukan, dan dalam banyak kasus menyediakan zvoditelnost cukup dekat dengan assembler tulisan tangan. Kami bermaksud untuk membagikan visi, kemajuan, dan rencana kami terkait pengembangan dan ketersediaan publik untuk infrastruktur kompilasi tersebut.
CI / CD
Meskipun semakin populernya CI telah menjadi salah satu tren utama tahun 2010-an, Jenkins masih menjadi standar emas CI.
Ruang ini sangat membutuhkan inovasi di bidang-bidang berikut:
- antarmuka pengguna (DSL untuk spesifikasi pengujian kode);
- detail implementasi yang akan membuatnya benar-benar terukur dan cepat;
- integrasi dengan berbagai lingkungan (pementasan, prod, dll.) untuk implementasi bentuk pengujian yang lebih maju;
- validasi dan penerapan berkelanjutan.
Alat Pengembang
Sebagai sebuah industri, kami mulai membuat perangkat lunak yang semakin kompleks dan mengesankan. Namun, ketika datang ke alat kita sendiri, kita dapat mengatakan bahwa situasinya bisa jauh lebih baik.
Pengeditan bersama dan jarak jauh (melalui ssh) telah mendapatkan popularitas, tetapi belum menjadi metode pengembangan standar baru. Jika Anda, seperti saya, menolak gagasan tentang
perlunya koneksi Internet permanen hanya untuk dapat melakukan pemrograman, maka bekerja melalui ssh pada mesin jarak jauh tidak mungkin cocok untuk Anda.
Lingkungan pengembangan lokal, terutama untuk insinyur yang bekerja pada arsitektur berorientasi layanan besar, masih tetap menjadi masalah. Beberapa proyek mencoba menyelesaikannya, dan saya akan tertarik untuk mengetahui seperti apa UX yang paling ergonomis untuk kasus penggunaan ini.
Ini juga akan menarik untuk mengembangkan konsep "lingkungan portabel" ke area pengembangan lainnya, seperti kesalahan reproduksi (atau
pengujian yang rapuh ) yang dihadapi dalam kondisi tertentu atau dengan pengaturan tertentu.
Saya juga ingin melihat lebih banyak inovasi di bidang-bidang seperti pencarian kode semantik dan peka konteks, alat yang memungkinkan Anda untuk menghubungkan insiden produksi dengan bagian spesifik dari basis kode, dll.
Komputasi (PaaS masa depan)
Di tengah hype umum tentang kontainer dan serverless di tahun 2010-an, berbagai solusi di cloud publik telah berkembang secara signifikan selama beberapa tahun terakhir.
Dalam hal ini, beberapa pertanyaan menarik muncul. Pertama-tama, daftar opsi yang tersedia di cloud publik terus bertambah. Penyedia layanan cloud memiliki staf dan sumber daya untuk dengan mudah mengikuti kemajuan terbaru di dunia Open Source dan merilis produk seperti pod tanpa server (saya curiga hanya dengan membuat runtime FaaS mereka sendiri yang kompatibel dengan OCI) atau yang lain barang mewah serupa.
Mereka yang menggunakan solusi cloud ini hanya bisa iri. Secara teori, penawaran cloud Kubernetes (GKE, EKS, EKS on Fargate, dll.) Menyediakan API penyedia cloud-independen untuk menjalankan beban kerja. Jika Anda menggunakan produk serupa (ECS, Fargate, Google Cloud Run, dll.), Maka Anda cenderung memaksimalkan penggunaan fungsi paling menarik yang ditawarkan oleh penyedia layanan. Selain itu, dengan munculnya produk baru atau paradigma komputasi, migrasi cenderung sederhana dan tanpa beban.
Mengingat seberapa cepat berbagai solusi tersebut berkembang (Saya sangat terkejut jika beberapa opsi baru tidak muncul dalam waktu dekat), tim "platform" kecil (tim yang terkait dengan infrastruktur dan bertanggung jawab untuk menciptakan platform di tempat untuk meluncurkan beban kerja di perusahaan) akan sangat sulit untuk bersaing dalam hal fungsi, kemudahan penggunaan dan keandalan secara keseluruhan. Tahun 2010 ditandai oleh Kubernetes sebagai alat untuk membuat PaaS (platform-as-a-service), sehingga tampaknya sama sekali tidak ada gunanya untuk membuat platform internal berdasarkan Kubernetes yang menawarkan pilihan, kesederhanaan, dan kebebasan yang sama yang tersedia di ruang cloud publik. Konsep PaaS berbasis wadah sebagai strategi Kubernetes sama saja dengan sengaja meninggalkan fitur cloud paling inovatif.
Jika Anda melihat kemampuan komputasi yang tersedia
saat ini , menjadi jelas bahwa membuat PaaS Anda sendiri hanya berdasarkan Kubernetes sama saja dengan mendorong diri Anda ke sudut (pendekatan yang tidak terlalu jauh ke depan, bukan?). Bahkan jika seseorang memutuskan untuk membuat PaaS kemas berdasarkan pada Kubernetes hari ini, dalam beberapa tahun akan terlihat usang dibandingkan dengan kemampuan cloud. Meskipun Kubernetes memulai keberadaannya sebagai proyek sumber terbuka, leluhur dan penginspirasi ideologisnya adalah alat internal Google yang sesuai. Namun, ini awalnya dikembangkan pada awal / pertengahan 2000-an, ketika lanskap komputasi benar-benar berbeda.
Selain itu, dalam arti yang sangat luas, perusahaan tidak boleh menjadi ahli dalam bekerja dengan kluster Kubernetes, juga tidak harus membuat dan memelihara pusat data mereka sendiri. Memberikan dasar komputasi yang andal adalah tujuan utama
penyedia layanan cloud .
Akhirnya, saya merasa bahwa kami sedikit mengalami kemunduran sebagai industri dalam hal
pengalaman interaksi (
UX ). Heroku diluncurkan pada 2007 dan masih menjadi salah satu platform yang
paling mudah digunakan . Tidak diragukan lagi, Kubernetes memiliki lebih banyak kekuatan, ekstensibilitas, dan kemampuan pemrograman, tetapi saya rindu betapa mudahnya untuk memulai dan menyebar ke Heroku. Untuk menggunakan platform ini, ketahuilah Git.
Semua ini membawa saya pada kesimpulan berikut: untuk bekerja, kita membutuhkan abstraksi yang lebih baik, tingkat yang lebih tinggi (ini terutama berlaku untuk
abstraksi dari tingkat tertinggi ).
API yang tepat di tingkat tertinggi
Docker adalah contoh yang bagus tentang perlunya pemisahan tugas yang lebih baik bersama dengan
implementasi API tingkat tertinggi yang benar .
Masalah Docker adalah bahwa (setidaknya) tujuan proyek ditetapkan terlalu global: semuanya demi memecahkan masalah kompatibilitas ("bekerja pada mesin saya") menggunakan teknologi wadah. Docker adalah format gambar, dan runtime dengan jaringan virtualnya sendiri, dan alat CLI, dan daemon root, dan banyak lagi. Bagaimanapun, pesan itu
lebih membingungkan, belum lagi "VM ringan", grup kontrol, ruang nama, berbagai masalah keamanan dan fitur yang dicampur dengan panggilan pemasaran "buat, kirim, jalankan aplikasi apa saja di mana saja."
Seperti halnya semua abstraksi yang baik, dibutuhkan waktu (juga pengalaman dan rasa sakit) untuk memecah berbagai masalah menjadi lapisan logis yang dapat dikombinasikan satu sama lain. Sayangnya, sebelum Docker berhasil mencapai kematangan seperti itu, Kubernetes memasuki pertarungan. Dia memonopoli siklus hype begitu banyak sehingga sekarang semua orang berusaha untuk mengikuti perubahan dalam ekosistem Kubernetes, dan ekosistem wadah memperoleh status sekunder.
Kubernetes berbagi dalam banyak hal masalah yang sama dengan Docker. Terlepas dari semua pembicaraan tentang abstraksi yang keren dan dapat dikompilasi,
pemisahan tugas yang berbeda menjadi beberapa lapisan tidak terlalu dienkapsulasi. Pada dasarnya, itu adalah wadah orkestra yang meluncurkan wadah di sekelompok mesin yang berbeda. Ini adalah tugas tingkat yang cukup rendah, hanya berlaku untuk insinyur yang mengoperasikan cluster. Kubernetes, di sisi lain, juga merupakan
abstraksi dari level tertinggi , alat CLI yang berinteraksi dengan pengguna melalui YAML.
Docker adalah (dan tetap) alat pengembangan yang
keren , terlepas dari segala kekurangannya. Dalam upaya untuk mengikuti semua "hares" segera, pengembangnya berhasil mengimplementasikan
abstraksi tingkat tertinggi dengan benar .
Dengan abstraksi tingkat tertinggi, maksud saya adalah subset dari fungsi di mana audiens target benar-benar tertarik (dalam hal ini, pengembang yang menghabiskan sebagian besar waktu mereka di lingkungan pengembangan lokal mereka) dan yang bekerja dengan sempurna "di luar kotak" .
Dockerfile dan utilitas
docker CLI harus menjadi contoh untuk membangun "antarmuka pengguna tingkat atas" yang bagus. Pengembang biasa dapat mulai bekerja dengan Docker tanpa mengetahui apa pun tentang seluk-beluk
implementasi, yang berkontribusi pada pengalaman operasional , seperti ruang nama, grup kontrol, batasan memori dan CPU, dll. Pada akhirnya, menulis Dockerfile tidak jauh berbeda dari menulis skrip shell.
Kubernetes dirancang untuk berbagai grup target:
- Administrator Cluster
- insinyur perangkat lunak yang terlibat dalam masalah infrastruktur, memperluas kemampuan Kubernetes dan membuat platform berdasarkannya;
- pengguna akhir berinteraksi dengan Kubernetes melalui
kubectl .
Pendekatan "one API cocok untuk semua" Kubernetes adalah "gunung kompleksitas" yang tidak dienkapsulasi tanpa indikasi bagaimana mengukurnya. Semua ini mengarah pada jalur pembelajaran yang panjang dan tidak masuk akal. Menurut Adam Jacob, “Docker memberi pengguna pengalaman transformatif yang belum dilampaui. Tanyakan siapa saja yang menggunakan K8 jika mereka ingin bekerja seperti
docker run pertama mereka. Jawabannya adalah "ya":
Saya akan mengatakan bahwa sebagian besar teknologi infrastruktur saat ini terlalu rendah (dan karena itu dianggap "terlalu rumit"). Kubernet diimplementasikan pada level yang cukup rendah. Pelacakan terdistribusi dalam
bentuk saat ini (banyak rentang dijahit bersama untuk membentuk jejak jejak) juga diterapkan pada tingkat yang terlalu rendah. Alat untuk pengembang yang menerapkan "abstraksi tingkat tertinggi", sebagai aturan, adalah yang paling sukses. Kesimpulan ini benar dalam sejumlah kasus yang mengejutkan (jika teknologinya terlalu kompleks atau sulit digunakan, maka "API tingkat tertinggi / UI" untuk teknologi ini belum dibuka).
Saat ini, ekosistem asli awan malu dengan fokusnya pada tingkat rendah. Sebagai sebuah industri, kita harus berinovasi, bereksperimen, dan mengajarkan bagaimana tingkat yang tepat dari "abstraksi maksimum, tertinggi" terlihat.
Perdagangan eceran
Pada 2010-an, pengalaman ritel digital nyaris tidak berubah. Di satu sisi, kemudahan berbelanja online seharusnya telah menyentuh toko-toko ritel klasik, dan di sisi lain, belanja online hampir tidak berubah dalam satu dekade.
Meskipun saya tidak memiliki pemikiran konkret mengenai perkembangan industri ini dalam dekade mendatang, saya akan sangat kecewa jika pada tahun 2030 kami melakukan pembelian dengan cara yang sama seperti yang kami lakukan pada tahun 2020.
Jurnalisme
Saya semakin kecewa dengan keadaan jurnalisme dunia. Semakin sulit menemukan sumber berita yang tidak memihak yang disiarkan secara objektif dan cermat. Sangat sering, batas antara berita itu sendiri dan pendapatnya dihapus. Sebagai aturan, informasi bias. Ini khususnya benar dalam kasus beberapa negara di mana secara historis tidak ada pemisahan antara berita dan pendapat tentang hal itu. Dalam sebuah artikel terbaru yang diterbitkan setelah pemilihan umum terakhir di Inggris, Alan Rusbridger, mantan editor The Guardian,
menulis :
Gagasan utama adalah bahwa selama bertahun-tahun saya melihat surat kabar Amerika dan merasa kasihan kepada rekan-rekan di sana, yang bertanggung jawab secara eksklusif untuk berita tersebut, memberikan komentar pada orang yang sama sekali berbeda. Namun, seiring berjalannya waktu, iba berubah menjadi iri. Sekarang saya berpikir bahwa semua surat kabar nasional Inggris harus memisahkan tanggung jawab atas berita dari tanggung jawab atas komentar. Sayangnya, pembaca rata-rata - terutama pembaca online - terlalu sulit untuk melihat perbedaannya.
Mengingat reputasi Lembah Silikon yang agak meragukan ketika menyangkut etika, dalam situasi apa pun saya tidak akan memercayai teknologi untuk "merevolusi" jurnalisme. Pada saat yang sama, saya (dan banyak teman saya) akan senang jika sumber berita yang adil, tidak memihak, dan dapat dipercaya akan muncul. Meskipun saya tidak bisa membayangkan bagaimana rupa platform itu, saya yakin di era ketika kebenaran semakin sulit untuk dilihat, kebutuhan akan jurnalisme yang jujur semakin tinggi.
Jejaring sosial
Jejaring sosial dan platform berita kolektif adalah sumber utama informasi bagi banyak orang di berbagai belahan dunia, dan kurangnya keakuratan dan keengganan beberapa platform untuk melakukan setidaknya verifikasi dasar fakta-fakta dasar yang mengarah pada konsekuensi mengerikan seperti genosida, campur tangan dalam pemilihan, dll.
Jejaring sosial juga merupakan alat media paling kuat yang pernah ada. Mereka secara radikal mengubah praktik politik. Mereka mengubah iklan. Mereka mengubah budaya pop (misalnya, itu adalah jejaring sosial yang memberikan kontribusi utama pada pengembangan budaya batal yang disebut
[ jejaring sosial
Ostracism - sekitar. Terjemahan] ). Para kritikus berpendapat bahwa media sosial ternyata menjadi lahan subur untuk perubahan cepat dan "berubah-ubah" dalam nilai-nilai moral, tetapi mereka juga memberikan kesempatan kepada para perwakilan kelompok yang terpinggirkan untuk bersatu (mereka belum pernah memiliki kesempatan seperti itu sebelumnya). Intinya, jejaring sosial telah mengubah cara orang berkomunikasi dan bagaimana mereka mengekspresikan diri di abad ke-21.
Namun, saya juga yakin bahwa jejaring sosial berkontribusi pada manifestasi impuls manusia terburuk. Perhatian dan perhatian sering diabaikan demi popularitas, dan menjadi hampir mustahil untuk mengungkapkan ketidaksetujuan yang beralasan dengan pendapat dan posisi tertentu. Polarisasi sering menjadi tidak terkendali, sebagai akibatnya, publik sama sekali tidak mendengar pendapat yang terpisah, sementara absolutis mengendalikan masalah etiket dan penerimaan online.
Saya bertanya pada diri sendiri, mungkinkah untuk menciptakan platform yang "lebih baik" yang dapat membantu meningkatkan kualitas diskusi? Setelah semua, justru apa yang mendorong "keterlibatan" yang sering membawa keuntungan utama ke platform ini. Seperti yang ditulis Kara Swisher di New York Times:
Keterlibatan digital dapat dikembangkan tanpa memicu kebencian dan intoleransi. Alasan sebagian besar jejaring sosial tampak sangat beracun adalah karena mereka diciptakan untuk kecepatan, viralitas, dan perhatian, bukan untuk konten dan akurasi.
Sangat disesalkan jika, dalam beberapa dekade, satu-satunya warisan jejaring sosial adalah erosi nuansa dan kecukupan dalam wacana publik.
PS dari penerjemah
Baca juga di blog kami: