Saya mengusulkan untuk membicarakan kapan layanan mikro diperlukan, dan kapan tidak. Spoiler: itu tergantung pada proyek.

Kami, pengembang perangkat lunak, memiliki profesi yang agak menarik. Kita dapat dengan aman kode selama berhari-hari, dan kemudian membaca artikel tentang sesuatu - dan itu mempertanyakan seluruh pekerjaan kita, karena beberapa Netflix memberi tahu XYZ.

Sama seperti itu, karena pendapat satu orang atau perusahaan, Anda mulai meragukan semua yang telah Anda lakukan selama bertahun-tahun, bahkan jika semuanya bekerja dengan sempurna.

Anda bukan Google (kecuali Anda adalah Google)

Ketika kita membaca HackerNews dan situs berita lainnya, kita sering melihat pesan teknis dari Google, Netflix, Amazon dan Facebook, dan mereka suka berbicara tentang berapa banyak ratusan atau ribuan layanan yang mereka luncurkan. Mereka berbicara tentang manfaat melakukan sesuatu dengan cara mereka sendiri. Ini adalah tren beberapa tahun terakhir.

Tapi mari kita hadapi itu. Tidak mungkin Anda memiliki 1000 pengembang yang mengerjakan proyek besar dengan sejarah lebih dari 10 tahun.

Hanya karena Google melakukan ini bukan berarti Anda harus melakukannya juga.

Kami bekerja di galaksi yang sangat berbeda. Google dihadapkan dengan masalah yang mungkin tidak akan pernah kita temui, tetapi pada saat yang sama kita dapat melakukan hal-hal yang tidak bisa dilakukan Google.

Bagaimana sebagian besar proyek perangkat lunak dimulai?

Banyak proyek dimulai dengan satu orang yang melakukan semua pekerjaan. Ada sejuta contoh, tapi mari kita lihat Shopify. Awalnya, layanan ini menyandikan Tobias Lyutke (didasarkan pada Ruby on Rails dan masih, by the way, bekerja pada rails).

Apakah Anda pikir Tobias ragu-ragu, dengan susah payah memikirkan arsitektur ideal untuk layanan mikro, sebelum menulis baris pertama kode?

Tidak ada Saya tidak hadir ketika mengembangkan versi pertama Shopify, yang awalnya hanya toko online untuk snowboarding, tetapi jika Tobias mirip saya (pengembang biasa), prosesnya terlihat seperti ini:

1. Pelajari teknologi baru saat menulis produk asli.
2. Tulis kode yang agak non-standar (jahat), tetapi berfungsi penuh.
3. Lihat bagaimana semuanya bekerja bersama dan menjadi bersemangat.
4. Refactor seperti "terbakar dengan api" dan meningkatkan kode ketika terjadi masalah.
5. Ulangi siklus ini saat menambahkan fitur baru dan memulai di lingkungan produksi.

Ini mungkin tampak seperti siklus yang sangat sederhana, tetapi butuh sekitar 20 tahun pemrograman untuk mengetahui seberapa dalam itu.

Anda tidak menjadi lebih baik sebagai seorang programmer, secara teoritis memikirkan pengaturan optimal sebelum menulis baris kode pertama. Anda menjadi lebih baik dengan menulis banyak kode dengan niat absolut dan eksplisit untuk mengganti hampir semua yang Anda tulis dengan kode yang lebih baik, segera setelah Anda mulai mengalami masalah nyata.

Kode asli yang Anda ganti tidak membuang waktu atau usaha. Seiring waktu, ini sangat membantu Anda untuk meningkatkan level Anda. Ini adalah bahan rahasia.

Bicara tentang abstraksi kode

Sebagai pengembang, kita semua telah mendengar ungkapan "KERING: jangan ulangi diri Anda sendiri," dan secara keseluruhan itu adalah saran yang masuk akal untuk tidak melakukan pekerjaan itu lagi. Tetapi seringkali itu layak dilakukan.

Perlu diulang ketika Anda mencoba untuk abstrak sesuatu tanpa pemahaman penuh dan membuat apa yang disebut abstraksi bocor.

Saya biasanya melakukan pekerjaan tiga kali sebelum saya bahkan BERPIKIR tentang refactoring beberapa kode dan menghapus duplikat. Seringkali, hanya setelah waktu ke-4 atau ke-5 saya mengambil beberapa tindakan.

Anda benar-benar perlu melihat beberapa kali bagaimana Anda menduplikasi kode dalam situasi yang berbeda sebelum menjadi jelas apa yang harus diterjemahkan ke dalam variabel dan menghapus dari tempat-tempat di mana kode ini awalnya ditulis.

Tingkat abstraksi, dari kode yang disematkan ke perpustakaan eksternal:

1. Tulis kode sebaris.
2. Gandakan kode di beberapa tempat berbeda.
3. Ekstrak kode duplikat dalam fungsi, dll.
4. Gunakan abstraksi ini untuk sementara waktu.
5. Lihat bagaimana kode ini berinteraksi dengan kode lainnya.
6. Ekstrak fungsionalitas umum ke perpustakaan internal.
7. Untuk waktu yang lama gunakan perpustakaan internal.
8. Benar-benar mengerti bagaimana semua bagian itu bersatu.
9. Buat perpustakaan eksternal (sumber terbuka, dll.), Jika itu masuk akal.

Intinya adalah bahwa Anda tidak dapat "menciptakan" perpustakaan atau kerangka kerja yang baik. Hampir semua alat yang sangat sukses yang kita gunakan saat ini berasal dari proyek dunia nyata. Di sana, alat favorit kami diekstraksi dari kasus nyata penggunaan internal.

Rails adalah contoh yang bagus. DHH (penulis Rails) tidak bangun suatu hari dan berkata: "Oh! Saatnya membuat model /, pengontrol / dan direktori views /!. ”

Tidak. Dia mengembangkan Basecamp (produk asli), kemudian templat tertentu muncul, dan templat ini digeneralisasi dan kemudian diekstraksi dari Basecamp di Rails. Proses ini masih berlangsung hari ini, dan menurut saya, ini adalah satu-satunya alasan mengapa Rails tetap sukses.

Ini adalah badai ideal abstraksi yang dikelola dengan sangat baik (baca: tidak dikembangkan secara teoritis) dikombinasikan dengan bahasa pemrograman yang memungkinkan Anda untuk menulis kode yang menarik. Ini juga menjelaskan mengapa hampir semua kerangka kerja seperti "Rails, hanya di XYZ" tidak berfungsi. Mereka melewatkan komponen kunci rantai abstraksi dan berpikir mereka bisa menduplikasi Rails.

Dari abstraksi hingga layanan mikro

Bagi saya, layanan mikro hanyalah tingkat abstraksi yang lain. Ini belum tentu langkah 10 dalam daftar di atas, karena tidak semua perpustakaan dirancang untuk layanan-mikro, tetapi pada tingkat konseptual sepertinya itu.

Layanan Microsoft tidak berada di tempat Anda memulai, sama seperti Anda tidak akan mencoba membuat perpustakaan open source eksternal yang sempurna tepat sebelum Anda menulis setidaknya satu baris kode. Saat ini, Anda bahkan tidak tahu apa yang sedang Anda kembangkan.

Arsitektur berbasis microservice adalah apa yang bisa diubah oleh proyek seiring waktu ketika Anda mengalami masalah nyata.

Mungkin Anda tidak akan pernah menghadapi masalah ini, dan banyak dari mereka dapat diselesaikan secara berbeda. Lihatlah Basecamp dan Shopify. Keduanya bekerja dengan baik sebagai aplikasi monolitik.

Saya tidak berpikir siapa pun akan menyebut mereka kecil, meskipun mereka tidak bekerja pada skala Google.

Shopify menghasilkan $ 17 juta per bulan dengan monolit

Pada pertengahan 2018, Shopify telah mengumumkan kepada publik bahwa lebih dari 600.000 toko online beroperasi di platform mereka.

Shopify adalah aplikasi SaaS yang memiliki tarif termurah $ 29 per bulan, dan saya merasa bahwa banyak perusahaan memilih tarif $ 79 per bulan. Dalam kasus apa pun, bahkan jika 600.000 pelanggan menggunakan paket termurah seharga $ 29, ini adalah penghasilan $ 17,4 juta per bulan hanya dari lini SaaS bisnis mereka.

Aplikasi Basecamp adalah aplikasi monolitik hebat lainnya. Yang menarik tentang Basecamp adalah mereka hanya memiliki sekitar 50 karyawan, dan hanya beberapa dari mereka yang merupakan pengembang perangkat lunak yang bekerja pada produk utama.

Saya ingin mengatakan bahwa Anda bisa SANGAT jauh tanpa turun ke lubang kelinci microservices. Jangan membuat layanan microser saja.

Kapan sebaiknya layanan microser digunakan?

Itu semua tergantung pada keputusan Anda. Ini hanyalah salah satu dari hal-hal di mana Anda tidak akan google "microservices melawan monolith". Jika Anda benar-benar membutuhkan layanan microser, Anda sudah tahu tentang itu.

Tetapi mungkin ada situasi di mana Anda memiliki banyak pengembang yang paling cocok untuk mengerjakan bagian aplikasi secara individual. Kehadiran lusinan tim yang mengerjakan berbagai komponen produk secara terpisah adalah salah satu alasan yang masuk akal untuk menggunakannya untuk layanan-layanan mikro.

Ingatlah bahwa jika Anda memiliki tim kecil yang tumbuh lambat dari waktu ke waktu, Anda dapat mulai dengan satu atau dua layanan mikro. Dalam situasi seperti itu, Anda mungkin tidak boleh memecah monolith sekaligus menjadi 100 layanan mikro, mulai dari penggalian.

Apakah game ini sepadan dengan lilin?

Perlu juga disebutkan bahwa transisi ke layanan-layanan mikro disertai dengan serangkaian masalahnya sendiri. Anda mengubah satu masalah untuk yang lain, jadi Anda perlu mempertimbangkan pro dan kontra apakah game ini layak untuk lilin khusus untuk proyek Anda.

Salah satu masalah utama adalah pemantauan. Tiba-tiba, Anda mendapatkan banyak layanan yang dapat ditulis pada tumpukan teknologi yang berbeda, dijalankan pada beberapa mesin - dan Anda perlu cara untuk melacaknya secara detail.

Ini adalah tugas yang sulit, karena idealnya kami ingin semua layanan microser menggunakan layanan pemantauan tunggal.

Anda mungkin tidak ingin mengembangkan alat sendiri, karena ini dengan sendirinya dapat berubah menjadi karya yang lengkap. Inilah alasan keberhasilan perusahaan seperti LightStep . Ini adalah salah satu layanan pemantauan paling menarik yang saya temui.

Produk mereka lebih fokus pada aplikasi skala besar (bisa dimengerti mengapa), tetapi juga berfungsi untuk proyek-proyek kecil. Baru-baru ini saya mendengar tentang mereka karena disajikan pada Cloud Field Day 4 .

Bagaimanapun, pemantauan hanyalah satu dari banyak kesulitan, tetapi saya memutuskan untuk menyebutkannya karena itu adalah salah satu masalah yang paling menyakitkan.

Pikiran terakhir

Pada dasarnya, saya menulis artikel ini karena dua alasan:

Pertama , dua minggu lalu saya mengunjungi Cloud Field Day 4 dan secara tidak sengaja berpartisipasi dalam podcast grup tentang topik terkait. Itu harus dirilis dalam beberapa bulan, tetapi di sini saya ingin memikirkan beberapa poin.

Kedua , sebagai penulis kursus online, saya mendapatkan banyak pertanyaan tentang cara membuat aplikasi saya sendiri.

Banyak pengembang "membeku", mencoba memecah aplikasi mereka menjadi layanan yang terisolasi bahkan sebelum mereka menulis baris kode pertama. Sampai pada titik bahwa sejak awal mereka mencoba menggunakan beberapa database untuk komponen aplikasi.

Momen ini mencegah mereka bergerak maju, dan sebagai kolega pembangunan, saya tahu betapa sulitnya terjebak dalam keragu-raguan (saya memilikinya!).

Ngomong-ngomong, saat ini saya sedang mengerjakan aplikasi SaaS yang agak besar - sebuah platform untuk menyelenggarakan kursus-kursus khusus. Saat ini saya sedang mengerjakan proyek sendiri, dan Anda dapat yakin bahwa saya baru saja membuka editor dan mulai menulis kode pada hari pertama.

Saya akan menyimpan proyek ini sebagai aplikasi yang sepenuhnya monolitik, sampai masuk akal untuk mengimplementasikan layanan-layanan microser, tetapi naluri saya mengatakan bahwa momen seperti itu tidak akan pernah datang.

Apa yang Anda pikirkan tentang ini? Beri tahu saya di komentar.