Layanan Mikro vs. Legacy Terlihat Dalam Kasus Netflix

Layanan Mikro vs. Legacy Terlihat Dalam Kasus Netflix

Application Performance Monitoring

Artikel Lainnya
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Layanan mikro vs. Legacy Terlihat dalam Kasus Netflix. Mengapa perusahaan IT tersebut sekarang meninggalkan lingkungan lama dan memilih lingkungan layanan mikro? Sejak beberapa tahun yang lalu, banyak perusahaan IT telah beralih ke arsitektur layanan mikro dan dengan demikian memberikan layanan yang sesuai.

Contoh utamanya adalah perusahaan yang kita kenal seperti Netflix, Amazon, Google, Twitter, Coupang, 11st street, Baemin dan sebagainya. mari kita kembali ke pertanyaan awal. Mengapa perusahaan-perusahaan ini beralih ke lingkungan layanan mikro?

Jika Anda menginginkan jawaban atas pertanyaan ini, pertama-tama Anda harus mempertimbangkan lingkungan hukum.

Layanan mikro vs. Legacy

<Arsitektur Monolitik vs Layanan Mikro (Tom Hardin 2018)>

Layanan web dasar membangun aplikasi dan mendistribusikannya ke WAS (Web Application Server). Ini adalah sistem up-time yang beroperasi secara konsisten dengan konfigurasi ketersediaan tinggi (HA).

Arsitektur monolitik (warisan) mendukung pengembangan dan distribusi yang cepat dan mudah dan tidak ada masalah pada tahap awal, tetapi karena semakin banyak pengguna yang bergabung dengan layanan ini, cerita ini menjadi sama sekali berbeda. Akan ada lebih banyak logika bisnis dan fungsi-fungsi baru yang akan ditambahkan, sehingga ukuran aplikasi cenderung semakin meningkat.

Masalahnya adalah karena aplikasi dengan ukuran yang meningkat menyebabkan berbagai efek samping seperti pengulangan kode yang lebih tinggi, kerumitan dan kombinasi, sehingga akibatnya, akan ada sedikit kebebasan dalam membangun atau mendistribusikan atau memperbaiki dan memelihara, dan juga, seluruh layanan. dapat turun karena satu cacat kode kecil.

Jika terjadi kegagalan layanan, maka perusahaan jelas akan kehilangan kepercayaan dari pelanggan serta kerugian, sehingga reputasi dan prestasi mereka dapat terancam.

Baca juga : Fitur Aplikasi Performance Monitoring Jennifer

Lalu, mungkin, saya bisa mengajukan pertanyaan-pertanyaan ini.

1. Bukankah seharusnya kita dapat menggunakan sisa layanan secara normal kecuali untuk layanan yang bermasalah?

2.Apakah mungkin untuk menghapus layanan dengan masalah terlebih dahulu dan kemudian memulihkannya dengan cepat nanti?

Ya, mungkin. Namun, jika Anda mencermati perusahaan-perusahaan yang menemukan jawaban mereka sendiri untuk pertanyaan ini, Anda dapat yakin dengan solusinya.

Kemudian, kita mungkin harus melihat layanan mikro yang diadopsi oleh perusahaan IT terkemuka tersebut. Solusinya bisa ditemukan jika kita mampu mengelola bisnis service secara mandiri dalam skala kecil.

Sekarang, mari kita bahas Amazon dan Netflix. Amazon telah mempersiapkan layanan mikro selama 20 tahun dan Netflix telah berubah menjadi layanan mikro karena memiliki keterbatasan arsitektur monolitik.

Network of microservices service to service

Berikut ini adalah email yang dikirimkan Jeff Bezos, CEO Amazon kepada karyawannya pada tahun 2002.

Kesemuanya selanjutnya akan memaparkan data dan fungsionalitas mereka melalui antarmuka layanan.

Tim berkomunikasi harus satu sama lain melalui antarmuka ini.

Tidak akan ada bentuk lain dari komunikasi antarproses yang diizinkan: tidak ada penautan langsung, tidak ada pembacaan langsung dari penyimpanan data tim lain, tidak ada model memori bersama, tidak ada pintu belakang apa pun. Satu-satunya komunikasi yang diizinkan adalah melalui panggilan antarmuka layanan melalui jaringan.

Tidak masalah teknologi apa yang mereka gunakan. HTTP, Corba, Pubsub, protokol khusus — tidak masalah. Bezos tidak peduli.

Semua antarmuka layanan, tanpa terkecuali, harus dirancang dari bawah ke atas agar dapat dieksternalisasi. Dengan kata lain, tim harus merencanakan dan merancang agar dapat memaparkan antarmuka kepada pengembang di dunia luar. Tidak ada habisnya.

Siapapun yang tidak melakukan ini akan kena jepret.

Terima kasih; semoga harimu menyenangkan!

<Email Jeff Bezo pada tahun 2002>

Pada email di atas, 1) sampai 5) memuat konsep MSA. Anehnya, di masa lalu yang sangat jauh, 20 tahun yang lalu, mereka sudah berbicara tentang layanan mikro ketika mereka berada di era layanan monolitik.

Platform internal yang diimplementasikan dengan cara ini menjadi tulang punggung cloud Amazon yang sangat kita kenal saat Amazon web service (AWS) dirilis pada tahun 2006.

Netflik

Sekarang, mari kita bahas mengapa Netflix meninggalkan arsitektur monolitik dan beralih ke layanan cloud dan lingkungan MSA. Sama seperti perusahaan IT lainnya, Netflix pada awalnya menggunakan layanan monolitik berdasarkan data pusat dan relasional DB. Semakin banyak pengguna yang berlangganan, kinerja layanan mulai tertinggal, maka mereka memilih melakukan scale-up untuk meningkatkan kapasitas kinerja. Namun, pada tahun 2007, karena terjadi masalah serius pada DB, aplikasi dalam layanan terputus, dan pengiriman DVD tertunda selama 3 hari.

Akibat kecelakaan ini, Netflix menyadari pembatasan peningkatan skala dan mulai mengalihkan bisnisnya ke cloud AWS yang dapat memfasilitasi peningkatan skala untuk layanan yang lebih andal. Selain itu, mereka memperkenalkan arsitektur MSA untuk memfasilitasi distribusi aplikasi yang mudah dan cepat.

Dengan kerja keras selama 8 tahun, Netflix menyelesaikan migrasi dari pusat data ke cloud dan mulai menikmati berbagai keuntungan sebagai hasilnya.

Misalnya, ada  peningkatan 8 kali lipat dalam jumlah pengguna  layanan streaming dibandingkan tahun 2008 dan  sekitar 1.000 kali peningkatan jumlah materi yang dilihat  selama 8 tahun, yang menunjukkan penggunaan layanan yang sangat aktif oleh anggota.

Mounthly streaming hours

Tentu saja, bukanlah masalah hitam dan putih untuk mengatakan "layanan mikro selalu baik". 

Tentunya, ada beberapa kelemahan dari layanan mikro, dan ada beberapa pertimbangan yang harus dibuat saat memperkenalkannya, tetapi kami dapat memahami mengapa perusahaan IT memimpin untuk meninggalkan lingkungan lama dan beralih ke cloud dan MSA seperti yang terlihat pada kasus Netflix .

Berikut rumusan kelebihan dan kekurangan serta karakteristik transisi MSA (Micro Service Architecture).

Tentu saja, bukanlah masalah hitam dan putih untuk mengatakan "layanan mikro selalu baik". 

Fitur  MSA

  • Ukuran layanan kecil dan proses operasi independen
  • HTTP RestAPI digunakan untuk panggilan bersama
  • Implementasi berorientasi fungsi bisnis
  • Mesin distribusi otomatis untuk distribusi pekerjaan
  • Manajemen fokus pusat minimal
  • Dapat menggunakan bahasa pemrograman dan teknologi penyimpanan data yang cocok untuk layanan tersebut.

keunggulan MSA

  • Ini adalah layanan independen, sehingga dapat mendukung pemulihan yang cepat tanpa memengaruhi layanan lain saat terjadi masalah.
  • Ukuran layanan kecil, sehingga hanya mungkin untuk memperluas layanan yang diperlukan untuk perluasan yang efisien.
  • Peningkatan kecepatan dan produktivitas layanan dibandingkan dengan monolitik.
  • Distribusi cepat dan sering. (Metode pengembangan perangkat lunak DevOps dan Agile digunakan)
  • Aplikasi teknologi baru dan peningkatan versi perpustakaan dengan mudah.
  • Dapat menggunakan bahasa pengembangan dan DB yang dioptimalkan untuk layanan.

Kelemahan MSA

  • Panggilan antar layanan dilakukan melalui komunikasi, sehingga dapat terjadi overhead transmisi jaringan.
  • Diperlukan teknologi pemrosesan transaksi terdistribusi.
  • Dapat menggunakan teknologi yang berbeda di setiap layanan, sehingga lebih banyak teknologi yang dibutuhkan.
  • Teknologi penyimpanan data yang berbeda digunakan untuk setiap layanan, sehingga redundansi data harus diperbolehkan.
  • Banyak distribusi dan rilis seiring bertambahnya jumlah layanan, jadi kami harus mengotomatiskan setiap tugas.
  • Tingkat kematangan tim yang tinggi diperlukan untuk mengelola MSA.

Pertimbangan untuk memperkenalkan MSA

  • Apakah layanan saat ini cukup untuk MSA?
  • Apakah diperlukan distribusi yang cepat dan sering?
  • Apakah ini layanan yang sensitif terhadap kinerja?
  • Apakah layanan memiliki transaksi terdistribusi?
  • Bisakah kita membuka redundansi data?
  • Apakah ada tim ahli untuk mengelola layanan MSA?

Sekarang, mari kita bicara tentang layanan pemantauan kinerja yang dapat digunakan untuk memantau MSA dan layanan mikro. Lalu, bagaimana solusi pemantauan kinerja APM Jennifer yang tersedia di platform C?

Dasboard Apm Jennifer

Hal terbesar tentang layanan mikro adalah HTTP Rest API yang digunakan untuk komunikasi timbal balik. Jika ada bahasa optimal yang dapat memproses layanan, maka tidak ada batasan pengembangan bahasa seperti Java, PHP, .NET, Python dan sebagainya, dan setiap layanan independen berkomunikasi dengan layanan lain untuk menghasilkan transaksi besar-besaran. Karena fitur layanan mikro, APM umum sulit dipantau.

Jennifer empat platform seperti Java, PHP, .NET dan Python dan dioptimalkan dengan desain arsitektur yang dapat diperluas untuk cloud atau lingkungan transaksi skala besar, dan penggunaan file DB yang dikembangkan secara independen dan teknologi minimisasi beban WAS dapat memfasilitasi pemantauan waktu nyata dari kinerja dan transaksi data.

Arsitektur apm jennifer

Keunggulannya antara lain dapat dengan cepat menemukan layanan yang bermasalah melalui agen dan mencari solusi serta melihat sekilas interaksi layanan. Ini juga bagus untuk dapat melakukan tracking waktu nyata dari setiap transaksi yang diproses dalam layanan mikro dan kontainer (AWS, Docker, dan K&S).

Layanan mikro vs. Legacy

<aplikasi server JENNIFER Mircro>

Layanan mikro vs. Legacy

<Dasbor pemantauan waktu nyata JENNIFER>

Selain itu, dimungkinkan untuk melacak layanan mikro tertentu dengan tertundanya kinerja tanpa memengaruhi setiap transaksi bisnis yang diproses pada basis layanan mikro. Penting juga untuk dicatat bahwa Anda dapat menggunakan fungsi Jennifer's SFR (Stack Fight Recorder) untuk menganalisis penyebab mendasar dari masalah kinerja di setiap platform.

Layanan mikro vs. Legacy

Sejauh ini, kami telah membahas fungsi utama APM Jennifer.

Kita dapat mengatakan, APM Jennifer  ① dapat melakukan pemantauan aplikasi secara real time dan menganalisis data transaksi dan  ② memprediksi masalah untuk mempertahankan kondisi optimal.

Saya yakin Anda semua tahu bahwa APM Jennifer adalah produk nomor satu di Korea dengan pangsa pasar terbesar di pasar APM Korea. 

Sumber