Ketika kami menyadari bahwa akan membosankan bagi kami untuk mengadakan pertemuan berikutnya, kami memutuskan untuk mengubahnya menjadi sesuatu yang lebih penuh aksi. Yakni, dalam duel, dalam
duel antara dua pendekatan integrasi - ESB dan Terdistribusi - kehormatannya dipertahankan oleh para ahli kelas berat. Dalam posting ini kami akan memberi tahu Anda bagaimana pertempuran berlangsung dan mencari tahu pemenangnya.
Beberapa kata tentang format
Alexander Trekhlebov , arsitek perusahaan kami, berbicara untuk bus terpusat. Untuk desentralisasi - Andrey Trushkin, kepala pusat inovasi dan teknologi Promsvyazbank yang menjanjikan. Mereka bergiliran memberikan laporan tentang teknologi mereka dan menjawab berbagai pertanyaan, provokatif dan tidak terlalu. Begitulah adanya.
Mengapa ESB itu keren?
Untuk memulainya, Anda harus memasukkannya ke dalam pengetahuan dan menceritakan bagaimana semuanya dimulai. Banyak yang mungkin ingat bahwa pada tahap pertama semuanya terjadi tanpa integrasi, ketika setiap sistem berkomunikasi dan melakukan pengujian integrasinya dengan setiap sistem lainnya.
Dengan demikian, jika seseorang berhenti atau sesuatu terjadi padanya, maka tidak ada yang tahu bagaimana semua ini akan berhasil. Setiap komputer berinteraksi dengan beberapa server. Protokol apa, interaksi macam apa? Hanya orang yang bekerja dalam sistem yang mengetahui semua ini.
Lalu datanglah bus integrasi. Tampaknya bukan hanya seperti itu, tetapi karena protokol utama dan metode interaksi dikumpulkan di dalamnya dan mungkin untuk tidak memaksa sistem untuk menggambarkan hal-hal tertentu. Dia bisa berkomunikasi dengan mereka menggunakan algoritma internal.
Lebih jauh ternyata mereka paling sering berkomunikasi dengan bus melalui antrian atau melalui REST.
Namun, seiring waktu, kebutuhan akan bus dan REST dalam banyak kasus menghilang. Tapi itu tampak seperti kemunduran, pertanyaan-pertanyaan penting digantung lagi:
- Cara mengatur jika tidak ada ban. Di mana ini akan terjadi?
- Apa yang harus dilakukan dengan format data dan protokol?
Selain itu, kinerja dalam sistem terpusat jauh lebih baik daripada di Terdistribusi. Anda dapat mengandalkan kecepatan, volume, dan ketersediaan. Semua ini karena ini adalah satu sistem yang dilayani oleh tim tertentu.
Seberapa rentan sistem ini? Apa yang terjadi jika satu komputer diretas?Selalu ada redundansi dan sentralisasi. Jika ada yang salah, sistem akan berfungsi.
Siapa yang bertanggung jawab atas ban? Tim Anda atau pengembang pihak ketiga?Di tim internal, kami menyediakan layanan operasional, memberikan keandalan dan pemantauan. Jika sesuatu tidak berhasil, kami tahu ke mana harus mencari. Ada pertanyaan: "Apakah mungkin untuk memercayai vendor dalam kasus seperti itu dan tim pihak ketiga?" Pemantauan yang baik diperlukan di sini. Karena kualitas, bagaimanapun, adalah tanggung jawab tim internal.
Seiring pertumbuhan bus, layanan tidak menjadi terhubung. Apakah Anda mengubah layanan dengan rilis atau apa? Apa yang harus dilakukan dengan Agile?Di sini kita sampai pada pertanyaan mendasar.
Integrasi bukan aplikasi. Dulu bagian, tapi sekarang tidak. Pengembangan integrasi bukan pengembangan aplikasi. Ini adalah pengembangan interaksi integrasi atau pengembangan dalam kerangka proyek terpisah, tetapi tidak secara khusus dari satu aplikasi.
Kekhawatiran Anda yang gesit bisa dimengerti. Model ini digunakan ketika kita membuat sistem terpisah yang terhubung ke bus di suatu tempat di samping. Ketika saya bekerja di bank lain, ada sistem seperti itu: satu bulan pengujian, satu bulan pengembangan. Akibatnya, semua interaksi integrasi cepat diimplementasikan di bus. Bahkan lebih cepat daripada yang dijelaskan para analis, karena sistem pengembangannya cukup canggih dan sederhana. Dan lincah digunakan dalam pengembangan sistem akhir.
Berapa lama tim mencari layanan yang mereka butuhkan, dan di mana itu mencari?Setiap orang memiliki mimpi bahwa ada peta dunia di mana semua area bisnis utama tersebar di seluruh benua. Dan itu bahkan sebagian dilaksanakan. Analis pergi ke sana dan mulai berkeliaran dengan intens di seluruh benua, setelah beberapa waktu ia menemukan interaksi yang diperlukan. Lebih lanjut, jika semuanya cocok dengan sempurna, ia cukup menggunakannya. Jika tidak, jelaskan di TK tambahan apa yang dia butuhkan. Akan bagus untuk memiliki opsi seperti itu, tetapi sejauh ini sistem yang kurang nyaman yang membutuhkan lebih banyak waktu dan upaya untuk bekerja dengan mereka relevan.
Atau mungkin Service Mesh lebih keren?
Untuk memulainya, banyak yang benar-benar berubah dalam 3-4 tahun. Tetapi apa yang sebenarnya terjadi? Larangan yang sama yang semua pembicara ulangi secara teratur, dan yang juga tidak bisa kita lewati, telah terjadi: dunia sedang berubah.
Persyaratan untuk kecepatan perubahan menjadi sangat besar. Pada saat yang sama, persyaratan keandalan, persyaratan keselamatan tidak hilang di mana pun, dan persyaratan beban hanya meningkat. Seperti yang dapat kita lihat, semua orang berusaha untuk merebut pangsa pasar, yang pasti mengarah pada peningkatan beban pada sistem perusahaan dan, akibatnya, pada integrasi.
Memang, ESB pada suatu waktu sangat keren membantu sebagai template untuk implementasi teknis dalam hal desentralisasi aplikasi, alokasi logika antara aplikasi yang berbeda, perangkat terpadu untuk mengintegrasikan aplikasi di antara mereka sendiri. Anggap saja bersatu kondisional.
Sekarang mari kita bayangkan bahwa tidak ada 20 sistem di perusahaan - setelah semua, itu berusaha untuk pindah ke arsitektur yang disebut kata kunci “layanan mikro”. Dan apa itu layanan mikro? Ada banyak definisi, salah satunya secara berkala digunakan oleh Martin Fowler: ini adalah layanan yang dapat dikembangkan oleh pengembang menengah dalam satu sprint. Bayangkan berapa banyak layanan seperti itu akan ada di perusahaan besar. Sebagai contoh, Netflix memperkirakan jumlah layanan mikronya di 800-900. Pada prinsipnya, di perusahaan yang berupaya membangun ekosistem eksternal mitra, layanan ini dapat melebihi seribu. Namun masing-masing layanan ini dalam jangka panjang mampu menahan beban yang luar biasa dan harus berkembang secara mandiri.
Bagaimana dengan bus? Jika bus tetap kompleks umum di antara mereka, maka ternyata itu menjadi hambatan dan menunda pengembangan layanan. Bukan hanya karena dia menunggu layanan ini, tetapi karena dia berkembang sebagai tim yang terpisah, oleh orang-orang yang memiliki teknologi dan keterampilan yang sama.
Dan sekarang mari kita bayangkan: beberapa lusin tim produk sedang mengembangkan dan bekerja bersama kami. Dan masing-masing dari mereka melihat beberapa layanan. Dan bus itu dikendarai oleh dua tim. Secara alami, tim-tim ini dengan tingkat probabilitas yang tinggi tidak akan dapat mengembangkan integrasi ini dengan tingkat kecepatan dan kualitas yang diperlukan.
Timbul pertanyaan: "Bagaimana kita bisa memastikan kecepatan cepat yang sama tanpa kehilangan aksesibilitas, keamanan, dan sebagainya?" Jawabannya sangat sederhana: "Biarkan layanan ini berinteraksi secara langsung, tanpa perantara yang eksplisit."
Kemudian pertanyaan penting berikutnya muncul: "Bagaimana layanan belajar tentang satu sama lain?" Dan di sini jawabannya juga sangat sederhana: Anda dapat menemukan sebuah sistem dengan mana layanan itu sendiri akan melaporkan tentang diri mereka sendiri. Artinya, pada saat layanan dikembangkan, ia akan secara independen mempublikasikan informasi tentang dirinya dalam registri tertentu. Dan berdasarkan informasi ini, semua layanan akan dapat mulai berinteraksi dengannya.
Dengan demikian, konsep "kisi-kisi" layanan dibentuk - seperti yang awalnya disebut,
"service mesh" . Sebagai semacam tingkat menengah integrasi antara layanan, yang menyediakan integrasi seperti itu, seolah-olah solusi cloud.
Perusahaan-perusahaan besar sekarang mencoba untuk memecahkan masalah kecepatan pengembangan secara paralel - untuk menemukan solusi umum tertentu, didistribusikan dan sering tertanam. Dalam hal ini, setiap layanan menggunakan satu set pustaka siap pakai tertentu untuk secara otomatis menerbitkan informasi ke registri ketika penggelaran.
Seringkali muncul pertanyaan: "Tapi apa yang harus dilakukan dengan model data kanonik, sumbernya, sebagai aturan, adalah ESB, di mana begitu banyak uang dan usaha diinvestasikan untuk mengimplementasikan dan memeliharanya?" Bagaimanapun, dia adalah model yang digunakan standar. Berikut adalah pertanyaan balasan: “Dan apa manfaatnya bagi kita? Dan bukankah justru itu yang menghambat perkembangan kami? " Memang, saat mengembangkan layanan, modelnya semakin meluas. Akan selalu ada tantangan yang lebih baru.
Terus terang,
biaya menambahkan perangkat baru, mengatur interaksi, dll, sebagai suatu peraturan, secara signifikan lebih kecil daripada biaya mempertahankan model data ESB kanonik yang terbaru .
Juga, integrasi desentralisasi sebagian besar memastikan ketersediaan tinggi yang sama. Masing-masing layanan microser independen, termasuk dari layanan microser lainnya, tetapi sangat tergantung pada beban eksternal yang ditempatkan di atasnya. Digunakan secara paralel dengan integrasi juga dapat diimplementasikan secara teknologi secara mandiri.
Terkadang penggunaan ESB yang agak berat dalam kondisi modern tidak masuk akal, atau bahkan sebaliknya, mengurangi kualitas solusi. Aplikasi teknologi tanpa server, infrastruktur yang tidak beradaptasi dengan kebutuhan sesaat dari solusi yang dibuat, sudah di ambang pintu, tetapi disampaikan dalam bentuk yang tepat untuk layanan tertentu. Sekarang ini terlihat seperti sesuatu yang sangat jauh, tetapi dunia berubah, seperti yang telah dikatakan, cukup cepat.
Banyak vendor perangkat lunak yang menggunakan solusi integrasi mereka. Sudah ada kerangka kerja yang pada dasarnya mengimplementasikan konsep service mesh (Linkerd atau Istio yang sama). Hal yang sama sudah terjadi sebagai bagian dari hosting sejumlah besar proxy jaringan dan layanan integrasi layanan mesh. Banyak kesamaan dengan mesh layanan dan sistem orkestrasi wadah seperti Kubernetes.
Apakah mungkin untuk membangun Terdistribusi berdasarkan ESB? Yaitu, apakah mungkin membuat yang lain dari satu sistem? Dan jika demikian, apa gunanya perselisihan ini?Di sini Hegel dan "penolakan negasinya" muncul di pikiran. Ketika satu gagasan berulang di tingkat sejarah yang lebih tinggi. Menurut saya, untuk datang dari satu ke yang lain adalah mungkin. Pertanyaan lain adalah bagaimana kita akan melakukan ini. Memang, pada dasarnya, konsep layanan-mikro dan implementasinya dalam banyak hal mirip dengan konsep integrasi yang awalnya: interaksi layanan-mikro di antara mereka sendiri, masing-masing dengan masing-masing.
Apakah mungkin untuk datang ke integrasi sesuai dengan prinsip-prinsip grid, jika kita pergi dari ESB? Sebenarnya, Red Hat, sekarang IBM, sudah mengikuti prinsip yang sama. Lihat saja pemahaman mereka tentang konsep tumpukan integrasi dan integrasi fleksibel (Agile Integration). Mereka menawarkan sejumlah besar proxy integrasi yang tidak dibebani dengan logika. Yang paling penting adalah transparansi dan pengetahuan layanan yang dibutuhkan oleh semua pendatang baru dalam interaksi.
Apakah bank Anda memahami bahwa ESB telah bertahan lebih lama jika terus menginvestasikan anggaran yang signifikan di dalamnya?Terus terang, masalah anggaran adalah rahasia dagang. Adapun pendekatan yang digunakan, saat ini kami sedang mengembangkan paralel dari dua pendekatan. Di Promsvyazbank sebenarnya ada banyak sistem yang terkait dengan bus. Mereka masih terintegrasi melalui bus. Tetapi kami, pada bagian kami, memahami bahwa ESB adalah pendekatan yang tidak menjanjikan dan lebih efisien untuk berinvestasi dalam integrasi terdistribusi tanpa menggunakan bus. Ini adalah prioritas strategis kami sekarang.
Di mana tempat pemantauan bisnis dalam sistem terdistribusi?Dalam integrasi desentralisasi, keberadaan sejumlah besar layanan tidak mengecualikan keberadaan pemantauan bisnis. Semua ini dapat diletakkan di tingkat kerangka kerja masing-masing. Dengan demikian, pemantauan ini dapat menggabungkan informasi ke dalam penyimpanan tertentu yang bertanggung jawab atas data. Data-data ini dianalisis di sana, dan laporan ringkasan disiapkan.
Bagaimana Anda melihat rencana transisi ke integrasi desentralisasi?Transisi menuju integrasi terdesentralisasi masuk akal untuk dipertimbangkan dalam konteks transisi ke prinsip arsitektur baru. Ini adalah transisi kompleks yang tidak dapat terjadi sekaligus. Ya, Anda dapat mencoba menahannya dalam format "big bang", tetapi opsi skenario ini membawa risiko serius. Lebih logis adalah pilihan untuk membuat sirkuit baru secara paralel dengan yang sudah ada dan, seperti yang dibuat (dalam mode iteratif), memperkenalkan produk-produk baru di dalamnya. Ketika kontur arsitektur baru berkembang, produk-produk dari lanskap IT saat ini yang telah teruji oleh waktu dapat ditransfer ke sana. Jalan seperti itu cukup panjang - diperkirakan hingga 4-5 tahun - tetapi karena iterasi, dimungkinkan untuk mendapatkan hasil dalam mode operasi industri secara berurutan.
Siapa yang menang?
Setelah tiga putaran interaktif dengan presentasi, pertanyaan dan jawaban, para penonton bersembunyi untuk mengantisipasi pengumuman hasil akhir. Anda mungkin menyadari bahwa pemenang Pertempuran PSB adalah Andrey Trushkin dan sistem terdistribusi.
Sebagai kesimpulan, kami menawarkan video yang akan membantu untuk merasakan suasana pertempuran kami: