Catatan. terjemahan: Artikel ini, yang menjadi hit di Medium, merupakan ikhtisar perubahan penting (2010-2019) dalam dunia bahasa pemrograman dan ekosistem teknologi terkait (dengan fokus khusus pada Docker dan Kubernetes). Penulis aslinya adalah Cindy Sridharan, yang berspesialisasi dalam alat pengembang dan sistem terdistribusi - khususnya, ia menulis buku “Distributed Systems Observability” - dan cukup populer di dunia Internet di kalangan spesialis TI, terutama yang tertarik pada topik cloud native.
Menjelang berakhirnya tahun 2019, saya ingin berbagi pemikiran saya tentang beberapa kemajuan dan inovasi teknologi terpenting dalam satu dekade terakhir. Selain itu, saya akan mencoba melihat sedikit ke masa depan dan menguraikan masalah dan peluang utama pada dekade mendatang.
Saya ingin memperjelas bahwa dalam artikel ini saya tidak membahas perubahan di bidang seperti ilmu data (ilmu data), kecerdasan buatan, rekayasa frontend, dll., karena saya pribadi tidak memiliki pengalaman yang cukup di dalamnya.
Tipifikasi Menyerang Kembali
Salah satu tren paling positif di tahun 2010-an adalah kebangkitan bahasa yang diketik secara statis. Namun, bahasa seperti itu tidak pernah hilang (C++ dan Java masih diminati saat ini; mereka mendominasi sepuluh tahun yang lalu), namun bahasa yang diketik secara dinamis (dinamika) mengalami peningkatan popularitas yang signifikan setelah munculnya gerakan Ruby on Rails pada tahun 2005 . Pertumbuhan ini mencapai puncaknya pada tahun 2009 dengan open source Node.js, yang menjadikan Javascript-on-the-server menjadi kenyataan.
Seiring waktu, bahasa dinamis telah kehilangan sebagian daya tariknya dalam bidang pembuatan perangkat lunak server. Bahasa Go, yang dipopulerkan selama revolusi container, tampaknya lebih cocok untuk menciptakan server pemrosesan paralel yang berkinerja tinggi, hemat sumber daya, dan paralel (yang dengannya pencipta Node.js sendiri).
Rust, diperkenalkan pada tahun 2010, mencakup kemajuan dalam dalam upaya untuk menjadi bahasa yang aman dan mengetik. Pada paruh pertama dekade ini, penerimaan industri terhadap Rust agak suam-suam kuku, namun popularitasnya meningkat secara signifikan pada paruh kedua. Kasus penggunaan penting untuk Rust termasuk penggunaannya untuk , (kita membicarakannya di - kira-kira. terjemahkan), kompiler WebAssembly awal dari Fastly (sekarang bagian dari bytecodealliance), dll. Dengan Microsoft mempertimbangkan kemungkinan untuk menulis ulang beberapa bagian OS Windows di Rust, dapat dikatakan bahwa bahasa ini memiliki masa depan cerah di tahun 2020-an.
Bahkan bahasa dinamis mendapat fitur baru seperti (tipe opsional). Mereka pertama kali diimplementasikan dalam TypeScript, sebuah bahasa yang memungkinkan Anda membuat kode yang diketik dan mengompilasinya ke dalam JavaScript. PHP, Ruby dan Python memiliki sistem pengetikan opsionalnya sendiri (, ), yang berhasil digunakan di .
Mengembalikan SQL ke NoSQL
NoSQL adalah teknologi lain yang jauh lebih populer di awal dekade ini dibandingkan di akhir dekade ini. Menurut saya, ada dua alasan untuk hal ini.
Pertama, model NoSQL, dengan kurangnya skema, transaksi, dan jaminan konsistensi yang lebih lemah, ternyata lebih sulit diterapkan dibandingkan model SQL. DI DALAM dengan judul "Mengapa Anda sebaiknya memilih konsistensi yang kuat jika memungkinkan" (Mengapa Anda harus memilih konsistensi yang kuat, bila memungkinkan) Google menulis:
Salah satu hal yang kami pelajari di Google adalah kode aplikasi lebih sederhana dan waktu pengembangan lebih singkat ketika teknisi dapat mengandalkan penyimpanan yang ada untuk menangani transaksi kompleks dan menjaga ketertiban data. Mengutip dokumentasi asli Spanner, “Kami percaya bahwa lebih baik bagi programmer untuk menangani masalah kinerja aplikasi karena penyalahgunaan transaksi ketika kemacetan muncul, daripada terus-menerus mengingat tidak adanya transaksi.”
Alasan kedua adalah karena munculnya database SQL terdistribusi "scale-out" (seperti и ) di ruang cloud publik, serta alternatif Open Source seperti CockroachDB (kita juga membicarakan dia - kira-kira. terjemahkan), yang memecahkan banyak masalah teknis yang menyebabkan database SQL tradisional “tidak dapat diskalakan”. Bahkan MongoDB, yang pernah menjadi lambang gerakan NoSQL, kini menjadi contohnya transaksi terdistribusi.
Untuk situasi yang memerlukan pembacaan dan penulisan atomik di beberapa dokumen (di satu atau lebih koleksi), MongoDB mendukung transaksi multi-dokumen. Dalam kasus transaksi terdistribusi, transaksi dapat digunakan di berbagai operasi, koleksi, database, dokumen, dan pecahan.
Streaming total
Apache Kafka tidak diragukan lagi adalah salah satu penemuan terpenting dalam dekade terakhir. Kode sumbernya dibuka pada bulan Januari 2011, dan selama bertahun-tahun, Kafka telah merevolusi cara bisnis bekerja dengan data. Kafka telah digunakan di setiap perusahaan tempat saya bekerja, mulai dari startup hingga perusahaan besar. Jaminan dan kasus penggunaan yang diberikannya (pub-sub, stream, arsitektur berbasis peristiwa) digunakan dalam berbagai tugas, mulai dari penyimpanan data hingga pemantauan dan analisis streaming, yang dibutuhkan di banyak bidang seperti keuangan, layanan kesehatan, sektor publik, ritel dan lain-lain.
Integrasi Berkelanjutan (dan pada tingkat yang lebih rendah, Penerapan Berkelanjutan)
Integrasi Berkelanjutan tidak muncul dalam 10 tahun terakhir, tetapi dalam satu dekade terakhir telah menyebar sedemikian rupa, yang menjadi bagian dari alur kerja standar (menjalankan pengujian pada semua permintaan tarik). Membangun GitHub sebagai platform untuk mengembangkan dan menyimpan kode dan, yang lebih penting, mengembangkan alur kerja berdasarkan berarti menjalankan tes sebelum menerima permintaan tarik ke master adalah satu-satunya alur kerja dalam pengembangan, familiar bagi para insinyur yang memulai karir mereka dalam sepuluh tahun terakhir.
Penerapan Berkelanjutan (menerapkan setiap penerapan saat mencapai master) tidak seluas integrasi berkelanjutan. Namun, dengan banyaknya API cloud yang berbeda untuk penerapan, semakin populernya platform seperti Kubernetes (yang menyediakan API terstandar untuk penerapan), dan munculnya alat multi-platform dan multi-cloud seperti Spinnaker (dibangun di atas alat-alat terstandarisasi tersebut). API), proses penerapan menjadi lebih otomatis, efisien, dan, secara umum, lebih aman.
Wadah
Kontainer mungkin merupakan teknologi yang paling digemari, didiskusikan, diiklankan, dan disalahpahami pada tahun 2010-an. Di sisi lain, ini adalah salah satu inovasi terpenting pada dekade sebelumnya. Salah satu alasan dari semua hiruk-pikuk ini terletak pada sinyal beragam yang kami terima dari hampir semua tempat. Kini setelah hype tersebut sedikit mereda, beberapa hal menjadi fokus yang lebih tajam.
Kontainer menjadi populer bukan karena merupakan cara terbaik untuk menjalankan aplikasi yang memenuhi kebutuhan komunitas pengembang global. Kontainer menjadi populer karena berhasil memenuhi permintaan pemasaran untuk alat tertentu yang memecahkan masalah yang sama sekali berbeda. Docker ternyata fantastis alat pengembangan yang memecahkan masalah kompatibilitas yang mendesak (“berfungsi di mesin saya”).
Lebih tepatnya, revolusi telah terjadi gambar buruh pelabuhan, karena ini memecahkan masalah paritas antar lingkungan dan memberikan portabilitas yang sebenarnya tidak hanya pada file aplikasi, tetapi juga semua perangkat lunak dan ketergantungan pengoperasiannya. Fakta bahwa alat ini entah bagaimana mendorong popularitas “container”, yang pada dasarnya merupakan detail implementasi tingkat rendah, bagi saya mungkin tetap menjadi misteri utama dalam dekade terakhir.
Tanpa Server
Saya berani bertaruh bahwa munculnya komputasi "tanpa server" bahkan lebih penting daripada container karena hal ini benar-benar mewujudkan impian komputasi on-demand menjadi kenyataan. (On-demand). Selama lima tahun terakhir, saya telah melihat pendekatan tanpa server secara bertahap memperluas cakupannya dengan menambahkan dukungan untuk bahasa dan runtime baru. Kemunculan produk seperti Azure Durable Functions tampaknya menjadi langkah tepat menuju implementasi fungsi stateful (sekaligus merupakan langkah yang menentukan). terkait dengan batasan FaaS). Saya akan mengamati dengan penuh minat bagaimana paradigma baru ini berkembang di tahun-tahun mendatang.
Otomasi
Mungkin penerima manfaat terbesar dari tren ini adalah komunitas teknik operasi, karena hal ini telah memungkinkan konsep seperti infrastruktur sebagai kode (IaC) menjadi kenyataan. Selain itu, minat terhadap otomatisasi bertepatan dengan munculnya “budaya SRE”, yang bertujuan untuk mengambil pendekatan operasional yang lebih berpusat pada perangkat lunak.
Fiksi API universal
Fitur menarik lainnya dalam dekade terakhir adalah fiksiasi API pada berbagai tugas pembangunan. API yang baik dan fleksibel memungkinkan pengembang menciptakan alur kerja dan alat inovatif, yang pada gilirannya membantu pemeliharaan dan meningkatkan pengalaman pengguna.
Selain itu, fiksi API adalah langkah pertama menuju fiksi SaaS dari beberapa fungsi atau alat. Tren ini juga bertepatan dengan meningkatnya popularitas layanan mikro: SaaS telah menjadi layanan lain yang dapat diakses melalui API. Sekarang ada banyak alat SaaS dan FOSS yang tersedia di berbagai bidang seperti pemantauan, pembayaran, penyeimbangan beban, integrasi berkelanjutan, peringatan, peralihan fitur (penandaan fitur), CDN, rekayasa lalu lintas (misalnya DNS), dll., yang berkembang pesat dalam dekade terakhir.
kemampuan observasi
Perlu dicatat bahwa saat ini kita memiliki akses ke sana jauh lebih maju alat untuk memantau dan mendiagnosis perilaku aplikasi dibandingkan sebelumnya. Sistem pemantauan Prometheus, yang menerima status Open Source pada tahun 2015, mungkin bisa disebut demikian terbaik sistem pemantauan dari orang-orang yang pernah bekerja dengan saya. Ini tidak sempurna, namun banyak hal yang diterapkan dengan cara yang benar (misalnya, dukungan untuk pengukuran [kematraan] dalam hal metrik).
Penelusuran terdistribusi adalah teknologi lain yang mulai populer pada tahun 2010-an, berkat inisiatif seperti OpenTracing (dan penggantinya OpenTelemetry). Meski penelusuran masih cukup sulit untuk diterapkan, beberapa perkembangan terkini memberikan harapan bahwa kita akan membuka potensi sebenarnya di tahun 2020an. (Catatan: Baca juga di blog kami terjemahan artikel “"oleh penulis yang sama.)
Melihat ke masa depan
Sayangnya, masih banyak permasalahan yang menunggu penyelesaian pada dekade mendatang. Berikut adalah pemikiran saya tentang hal tersebut dan beberapa ide potensial tentang cara menghilangkannya.
Memecahkan Masalah Hukum Moore
Berakhirnya hukum penskalaan Dennard dan keterbelakangan hukum Moore memerlukan inovasi baru. John Hennessy masuk menjelaskan mengapa masalah pecandu (khusus domain) arsitektur seperti TPU mungkin menjadi salah satu solusi terhadap masalah ketertinggalan Hukum Moore. Toolkit seperti dari Google tampaknya merupakan langkah maju yang baik ke arah ini:
Kompiler harus mendukung aplikasi baru, mudah di-porting ke perangkat keras baru, menghubungkan beberapa lapisan abstraksi mulai dari bahasa yang dinamis dan terkelola hingga akselerator vektor dan perangkat penyimpanan yang dikontrol perangkat lunak, sekaligus menyediakan sakelar tingkat tinggi untuk penyetelan otomatis, menyediakan hanya- dalam fungsionalitas -waktu, diagnostik, dan mendistribusikan informasi debug tentang fungsi dan kinerja sistem di seluruh tumpukan, sementara dalam banyak kasus memberikan kinerja yang cukup dekat dengan assembler yang ditulis tangan. Kami bermaksud untuk membagikan visi, kemajuan, dan rencana kami untuk pengembangan dan ketersediaan publik atas infrastruktur kompilasi tersebut.
CI / CD
Meskipun kebangkitan CI telah menjadi salah satu tren terbesar di tahun 2010-an, Jenkins masih menjadi standar terbaik bagi CI.
Ruang ini sangat membutuhkan inovasi di bidang-bidang berikut:
- antarmuka pengguna (DSL untuk spesifikasi pengujian pengkodean);
- rincian implementasi yang akan membuatnya benar-benar terukur dan cepat;
- integrasi dengan berbagai lingkungan (staging, prod, dll.) untuk mengimplementasikan bentuk pengujian yang lebih maju;
- pengujian dan penerapan berkelanjutan.
Alat pengembang
Sebagai sebuah industri, kami telah mulai menciptakan perangkat lunak yang semakin kompleks dan mengesankan. Namun, jika menyangkut alat yang kita miliki, situasinya bisa menjadi jauh lebih baik.
Pengeditan kolaboratif dan jarak jauh (melalui ssh) mendapatkan popularitas, tetapi tidak pernah menjadi cara standar pengembangan baru. Jika Anda, seperti saya, menolak gagasan itu kebutuhan koneksi permanen ke Internet hanya untuk dapat melakukan pemrograman, maka bekerja melalui ssh pada mesin jarak jauh sepertinya tidak cocok untuk Anda.
Lingkungan pengembangan lokal, terutama bagi para insinyur yang bekerja pada arsitektur besar yang berorientasi layanan, masih merupakan tantangan. Beberapa proyek mencoba menyelesaikan masalah ini, dan saya tertarik untuk mengetahui seperti apa UX yang paling ergonomis untuk kasus penggunaan tertentu.
Menarik juga untuk memperluas konsep "lingkungan portabel" ke bidang pengembangan lain seperti reproduksi bug (atau ) yang terjadi pada kondisi atau pengaturan tertentu.
Saya juga ingin melihat lebih banyak inovasi di bidang seperti pencarian kode semantik dan peka konteks, alat untuk menghubungkan insiden produksi dengan bagian tertentu dari basis kode, dll.
Komputasi (masa depan PaaS)
Mengikuti tren container dan tanpa server pada tahun 2010-an, rangkaian solusi di ruang cloud publik telah berkembang secara signifikan dalam beberapa tahun terakhir.
Hal ini menimbulkan beberapa pertanyaan menarik. Pertama-tama, daftar opsi yang tersedia di cloud publik terus bertambah. Penyedia layanan cloud memiliki staf dan sumber daya untuk dengan mudah mengikuti perkembangan terkini di dunia Open Source dan merilis produk seperti "pod tanpa server" (saya kira hanya dengan membuat runtime FaaS mereka sendiri yang sesuai dengan OCI) atau hal-hal mewah serupa lainnya.
Kita hanya bisa iri pada mereka yang menggunakan solusi cloud ini. Secara teori, penawaran cloud Kubernetes (GKE, EKS, EKS di Fargate, dll.) menyediakan API independen penyedia cloud untuk menjalankan beban kerja. Jika Anda menggunakan produk serupa (ECS, Fargate, Google Cloud Run, dll.), Anda mungkin sudah memanfaatkan fitur paling menarik yang ditawarkan oleh penyedia layanan. Selain itu, seiring dengan munculnya produk baru atau paradigma komputasi, migrasi kemungkinan besar akan dilakukan dengan sederhana dan bebas stres.
Mengingat betapa cepatnya berbagai solusi tersebut berkembang (saya akan 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 lokasi untuk menjalankan beban kerja perusahaan) akan sangat sulit bersaing dalam hal fungsionalitas, kemudahan penggunaan, dan keandalan secara keseluruhan. Tahun 2010-an telah melihat Kubernetes sebagai alat untuk membangun PaaS (platform-as-a-service), jadi sepertinya tidak ada gunanya bagi saya untuk membangun platform internal di atas Kubernetes yang menawarkan pilihan, kesederhanaan, dan kebebasan yang sama seperti yang tersedia di masyarakat. ruang awan. Membingkai PaaS berbasis container sebagai “strategi Kubernetes” sama saja dengan sengaja menghindari kemampuan paling inovatif dari cloud.
Jika dilihat dari ketersediaannya hari ini kemampuan komputasi, menjadi jelas bahwa membuat PaaS Anda sendiri hanya berdasarkan Kubernetes sama saja dengan membuat diri Anda terpojok (bukan pendekatan yang berpikiran maju, ya?). Bahkan jika seseorang memutuskan untuk membangun PaaS dalam container di Kubernetes saat ini, dalam beberapa tahun mendatang hal tersebut akan terlihat ketinggalan jaman dibandingkan dengan kemampuan cloud. Meskipun Kubernetes dimulai sebagai proyek sumber terbuka, nenek moyang dan inspirasinya adalah alat internal Google. Namun, ini awalnya dikembangkan pada awal/pertengahan tahun 2000an ketika lanskap komputasi benar-benar berbeda.
Selain itu, dalam arti luas, perusahaan tidak harus menjadi ahli dalam menjalankan klaster Kubernetes, juga tidak membangun dan memelihara pusat datanya sendiri. Menyediakan landasan komputasi yang andal merupakan tantangan utama penyedia layanan awan.
Terakhir, saya merasa kita telah sedikit mengalami kemunduran sebagai sebuah industri pengalaman interaksi (). Heroku diluncurkan pada tahun 2007 dan masih menjadi salah satu yang paling banyak mudah digunakan platform. Tidak dapat disangkal bahwa Kubernetes jauh lebih kuat, dapat diperluas, dan dapat diprogram, namun saya rindu betapa mudahnya untuk memulai dan menerapkannya ke Heroku. Untuk menggunakan platform ini, Anda hanya perlu mengetahui Git.
Semua ini membawa saya pada kesimpulan berikut: kita memerlukan abstraksi yang lebih baik dan tingkat yang lebih tinggi agar dapat berfungsi (hal ini terutama berlaku untuk abstraksi tingkat tertinggi).
API yang tepat di level tertinggi
Docker adalah contoh yang bagus tentang perlunya pemisahan masalah yang lebih baik pada saat yang bersamaan implementasi yang benar dari API tingkat tertinggi.
Masalah dengan Docker adalah (setidaknya) pada awalnya proyek tersebut memiliki tujuan yang terlalu luas: semuanya demi menyelesaikan masalah kompatibilitas (“berfungsi di mesin saya”) menggunakan teknologi container. Docker adalah format gambar, runtime dengan jaringan virtualnya sendiri, alat CLI, daemon yang berjalan sebagai root, dan banyak lagi. Bagaimanapun, pertukaran pesan terjadi lebih membingungkan, belum lagi "VM ringan", cgroup, namespace, berbagai masalah keamanan dan fitur yang bercampur dengan panggilan pemasaran untuk "membangun, mengirimkan, menjalankan aplikasi apa pun di mana pun".
Seperti semua abstraksi yang baik, dibutuhkan waktu (dan pengalaman serta kesakitan) untuk memecah berbagai masalah menjadi lapisan logis yang dapat digabungkan satu sama lain. Sayangnya, sebelum Docker mencapai kematangan serupa, Kubernetes ikut campur. Ini sangat memonopoli siklus hype sehingga sekarang semua orang berusaha mengikuti perubahan dalam ekosistem Kubernetes, dan ekosistem container mengambil status sekunder.
Kubernetes mempunyai banyak masalah yang sama seperti Docker. Untuk semua pembicaraan tentang abstraksi yang keren dan dapat disusun, memisahkan tugas yang berbeda ke dalam beberapa lapisan tidak terbungkus dengan baik. Pada intinya, ini adalah orkestrator container yang menjalankan container pada sekelompok mesin yang berbeda. Ini adalah tugas tingkat rendah, hanya berlaku untuk insinyur yang mengoperasikan cluster. Di sisi lain, Kubernetes juga demikian abstraksi tingkat tertinggi, alat CLI yang berinteraksi dengan pengguna melalui YAML.
Docker dulu (dan masih) Dingin alat pengembangan, terlepas dari segala kekurangannya. Dalam upaya untuk mengimbangi semua "kelinci" sekaligus, pengembangnya berhasil menerapkannya dengan benar abstraksi pada tingkat tertinggi. Yang saya maksud dengan abstraksi pada tingkat tertinggi himpunan bagian fungsionalitas yang benar-benar diminati oleh audiens target (dalam hal ini, pengembang yang menghabiskan sebagian besar waktunya di lingkungan pengembangan lokal) dan bekerja dengan sangat baik..
Utilitas Dockerfile dan CLI docker harus menjadi contoh bagaimana membangun “pengalaman pengguna tingkat tertinggi” yang baik. Pengembang biasa dapat mulai bekerja dengan Docker tanpa mengetahui apa pun tentang seluk-beluknya implementasi yang berkontribusi pada pengalaman operasionalseperti namespace, cgroup, batas memori dan CPU, dll. Pada akhirnya, menulis Dockerfile tidak jauh berbeda dengan menulis skrip shell.
Kubernetes ditujukan untuk kelompok sasaran yang berbeda:
- administrator klaster;
- insinyur perangkat lunak yang menangani masalah infrastruktur, memperluas kemampuan Kubernetes dan membuat platform berdasarkan infrastruktur tersebut;
- pengguna akhir berinteraksi dengan Kubernetes melalui
kubectl.
Pendekatan "satu API untuk semua" Kubernetes menyajikan "segunung kompleksitas" yang tidak terenkapsulasi secara memadai tanpa panduan tentang cara menskalakannya. Semua ini mengarah pada proses pembelajaran yang berlarut-larut dan tidak dapat dibenarkan. Bagaimana Adam Jacob, “Docker menghadirkan pengalaman pengguna transformatif yang belum pernah dilampaui. Tanyakan kepada siapa pun yang menggunakan K8 apakah mereka ingin KXNUMX berfungsi seperti yang pertama docker run. Jawabannya adalah ya":
Saya berpendapat bahwa sebagian besar teknologi infrastruktur saat ini berada pada tingkat yang terlalu rendah (dan oleh karena itu dianggap "terlalu rumit"). Kubernetes diimplementasikan pada level yang cukup rendah. Penelusuran terdistribusi di dalamnya (banyak bentang yang digabungkan untuk membentuk tampilan jejak) juga diterapkan pada level yang terlalu rendah. Alat pengembang yang menerapkan “abstraksi tingkat tertinggi” cenderung paling berhasil. Kesimpulan ini berlaku dalam sejumlah kasus yang mengejutkan (jika teknologinya terlalu rumit atau sulit digunakan, maka “API/UI tingkat tertinggi” untuk teknologi tersebut belum ditemukan).
Saat ini, ekosistem cloud native membingungkan karena tingkat fokusnya yang rendah. Sebagai sebuah industri, kita harus berinovasi, bereksperimen, dan mendidik tentang seperti apa tingkat “abstraksi maksimum dan tertinggi” yang tepat.
eceran
Pada tahun 2010-an, pengalaman ritel digital sebagian besar masih tidak berubah. Di satu sisi, kemudahan belanja online seharusnya sudah melanda toko ritel tradisional, di sisi lain, belanja online secara fundamental hampir tidak berubah dalam satu dekade.
Meskipun saya tidak memiliki pemikiran khusus tentang bagaimana industri ini akan berkembang dalam dekade berikutnya, saya akan sangat kecewa jika kita berbelanja pada tahun 2030 dengan cara yang sama seperti yang kita lakukan pada tahun 2020.
Jurnalisme
Saya semakin kecewa dengan keadaan jurnalisme global. Kini semakin sulit menemukan sumber berita yang tidak memihak dan memberitakan secara obyektif dan cermat. Seringkali batas antara berita itu sendiri dan opini mengenainya menjadi kabur. Biasanya, informasi disajikan secara bias. Hal ini terutama terjadi di beberapa negara yang secara historis tidak ada pemisahan antara berita dan opini. Dalam artikel baru-baru ini yang diterbitkan setelah pemilihan umum Inggris yang lalu, Alan Rusbridger, mantan editor The Guardian, :
Poin utamanya adalah selama bertahun-tahun saya membaca surat kabar Amerika dan merasa kasihan pada rekan-rekan saya di sana, yang bertanggung jawab penuh atas berita tersebut, menyerahkan komentar kepada orang yang sama sekali berbeda. Namun, seiring berjalannya waktu, rasa kasihan berubah menjadi rasa iri. Saya sekarang berpikir bahwa semua surat kabar nasional Inggris harus memisahkan tanggung jawab mereka atas berita dari tanggung jawab mereka atas komentar. Sayangnya, terlalu sulit bagi pembaca rata-rata—terutama pembaca daring—untuk membedakannya.
Mengingat reputasi Silicon Valley yang agak meragukan dalam hal etika, saya tidak akan pernah mempercayai teknologi untuk "merevolusi" jurnalisme. Meski begitu, saya (dan banyak teman saya) akan senang jika ada sumber berita yang tidak memihak, tidak memihak, dan dapat dipercaya. Meskipun saya tidak tahu seperti apa platform tersebut, saya yakin bahwa di era di mana kebenaran semakin sulit untuk dilihat, kebutuhan akan jurnalisme yang jujur semakin besar.
Jaringan Sosial
Media sosial dan platform berita komunitas adalah sumber informasi utama bagi banyak orang di seluruh dunia, dan kurangnya akurasi serta keengganan beberapa platform untuk melakukan pengecekan fakta dasar telah menyebabkan konsekuensi yang sangat buruk seperti genosida, campur tangan pemilu, dan banyak lagi. .
Media sosial juga merupakan alat media paling kuat yang pernah ada. Mereka secara radikal mengubah praktik politik. Mereka mengubah iklannya. Mereka mengubah budaya pop (misalnya, kontribusi utama terhadap perkembangan yang disebut budaya pembatalan [budaya pengucilan - kira-kira. terjemahan.] jaringan sosial berkontribusi). Kritikus berpendapat bahwa media sosial telah terbukti menjadi lahan subur bagi perubahan nilai-nilai moral yang cepat dan berubah-ubah, namun media sosial juga memberikan kesempatan kepada kelompok marginal untuk berorganisasi dengan cara yang belum pernah mereka lakukan sebelumnya. Intinya, media sosial telah mengubah cara orang berkomunikasi dan mengekspresikan diri di abad ke-21.
Namun, saya juga percaya bahwa media sosial memunculkan dorongan hati manusia yang paling buruk. Pertimbangan dan perhatian sering kali diabaikan demi popularitas, dan menjadi hampir mustahil untuk mengungkapkan ketidaksetujuan yang masuk akal terhadap pendapat dan posisi tertentu. Polarisasi sering kali menjadi tidak terkendali, sehingga masyarakat tidak mendengarkan opini individu, sementara kaum absolut mengontrol masalah etiket dan penerimaan online.
Saya bertanya-tanya apakah mungkin untuk menciptakan platform yang “lebih baik” yang mendorong diskusi berkualitas lebih baik? Bagaimanapun, hal inilah yang mendorong “keterlibatan” yang sering kali mendatangkan keuntungan utama bagi platform ini. Bagaimana Kara Swisher di New York Times:
Interaksi digital dapat dikembangkan tanpa menimbulkan kebencian dan intoleransi. Alasan mengapa sebagian besar situs media sosial terlihat sangat beracun adalah karena situs tersebut dibuat untuk kecepatan, viralitas, dan perhatian, bukan konten dan akurasi.
Akan sangat disayangkan jika, dalam beberapa dekade, satu-satunya warisan media sosial adalah terkikisnya nuansa dan kesesuaian dalam wacana publik.
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com