Pada 22 dan 23 November, konferensi DotNext 2018 berikutnya untuk pecinta .NET diadakan di Moskow. Nama saya Maxim Smirnov, saya mengepalai .NET Competence Center di Alfa-Bank dan ingin menyajikan kepada Anda versi teks dari salah satu wawancara yang diambil di sela-sela DotNext.
Tentang kehidupan dan petualangan di bank kami, tentang koeksistensi dengan Jawa dan masalah implementasi - di bawah potongan.
Berapa. NET di Alpha secara umum dan mengapa kita membutuhkannya
Baru-baru ini, kami telah tumbuh cukup nyata dalam hal menggunakan .NET. Jika sekitar 5 tahun yang lalu tidak ada begitu banyak anak perusahaan di Alpha (terutama dalam aplikasi perusahaan, pinjaman untuk bisnis perusahaan, investasi, dll.), Sekitar 16-20 orang diatasi dengan beban seperti itu. Dan sekarang bank secara aktif mengembangkan segmen bisnis korporasi menengah dan menengah, yang telah menjadi pendorong yang baik untuk pengembangan sistem kredit.
Dan kami menghadapi pilihan - baik untuk menulis ulang semua ini di Jawa, yang secara historis selalu menjadi titik kuat kami, dan masih berlaku di ritel, atau untuk terus mengembangkan semuanya di .NET, di mana kami harus menyewa banyak donor dan maju ke depan dengan teknologi yang sama serupa untuk arsitektur layanan mikro seperti di Jawa.
Tentu saja, langkah seperti itu langsung terancam, karena risiko [menerapkan kira-kira teknologi baru. Ed.]. Tetapi kami dapat mengambil risiko ini pada diri kami sendiri, kami membuktikan kepada kolega kami bahwa .NET dapat bekerja dengan cukup baik pada kluster yang sama dan solusi infrastruktur yang membuat Java terasa hebat. Di sini saya merujuk pada apa yang disebut kluster "united front" kami, Apache Mesos - Marathon. Dan kami mulai membuat keputusan di garis depan, termasuk bagian tengah untuk mereka. Bagian depan tetap sama seperti di Jawa, bagian tengah tetap di suatu tempat di Jawa, di suatu tempat di .NET.
Dan kita pergi - 5 tahun yang lalu maksimum 20 orang diatasi dengan .NET, dan sekarang ada begitu banyak tugas yang kita miliki 75 orang pemberani. Dan kita terus berkembang - sekarang kita mencari
arsitek dan lebih banyak
pengembang . Meskipun Jawa masih total, satu setengah sampai dua, karena Jawa secara stabil mendominasi bisnis ritel dan massa. Kami berada di .NET dikuasai dalam kerangka kerja rata-rata korporat dan regional, ditambah saluran elektronik, tentu saja.
Periksa - buktikan - implementasikan
Agar sesuatu dapat bekerja secara berkelanjutan, perlu untuk menerapkan hal ini dalam proses bank. Untuk menerapkannya secara normal, Anda perlu membuktikan kepada semua orang yang bertanggung jawab bahwa ini tidak akan merusak keadaan saat ini dan implementasi akan membawa banyak nilai tambah.
Yang paling sulit adalah dengan infrastruktur. Kami memiliki persyaratan nyata yang diperkuat dari mereka - bahwa semua ini akan terungkap di buruh pelabuhan dan bekerja secara normal di Linux. Dan di sini perlu dicatat bahwa pada saat itu masih belum ada. NET Core 2.0, maka hanya ada versi pertama, di mana tidak ada semua kebaikan yang dirilis di yang kedua, secara umum, ternyata kita sendiri tidak tahu persis dengan yang mana kita mungkin menemukan gunung es, tetapi mereka mengatakan bahwa kita akan melakukan segalanya sebagaimana mestinya. Kami dapat membuktikan hal ini kepada bisnis dengan meluncurkan pilot pertama - Alfa-Credit, aplikasi untuk pinjaman online, menerbitkan tahapan dan banyak lagi.
Kemudian para pendukung harus membuktikan kelayakan ide tersebut. Mereka perlu menjelaskan bahwa mereka sendiri tidak perlu tahu .NET untuk menemani wadah kami (untuk beberapa alasan mereka yakin sebaliknya). Mereka membuktikan kepada mereka bahwa tidak akan ada masalah kinerja, saya adalah salah satu yang pertama yang mengumpulkan semua ini di sebuah cluster - kami menempatkan wadah, menghapus banyak metrik darinya, mengamati berapa banyak memuat CPU, dibandingkan semua ini dengan Java. Kami baru saja memasukkan kode Java dalam sebuah wadah yang mengeluarkan bantuan untuk pelanggan ritel. Ya, untuk kemurnian percobaan, kami membuat layanan yang sama sekali berbeda, tetapi pada .NET, sehingga kami dapat dengan jujur membandingkannya dalam hal kinerja, kecepatan respons, dan pemuatan memori. Saya menulis stress test untuk semua ini, sebagai hasilnya - semuanya bekerja untuk kami, dan saat ini 6 tim bekerja dalam mode ini.
Sekarang kita perlahan-lahan menyingkirkan Legacy - kita membungkusnya dalam layanan dan secara fungsional menulis ulang ke layanan microser.
.NET Core VS .NET Framework
Saya akan memperhatikan lagi bahwa kami menerapkan .NET Core. Oleh karena itu, masih ada sejumlah masalah dalam arti bahwa ada beberapa hal keren dalam kerangka .NET, tetapi mereka tidak dalam. NET Core, dan masih tidak. Misalnya, layanan SOAP.
Bayangkan saja. Anda adalah bank, Anda memiliki satu sistem yang menggunakan yang lain. Dan dia terbiasa dengan SABUN untuk dikonsumsi, dan Anda tidak memilikinya. Umumnya. Kami tidak menemukan implementasi normal tunggal layanan WCF dengan SOAP dan hal serupa. Mungkin mereka terlihat buruk, semuanya mungkin. Oleh karena itu, saya harus membuang dan menulis lapisan pada .NET Framework.
Rake set kedua adalah REST API. Tidak ada masalah dengan layanan baru di mana itu diterapkan. Dan memaksa layanan lama untuk menggunakan REST API alih-alih SOAP adalah cerita lain, saya harus menulis ulang semua sistem dependen lainnya. Dan lagi, lapisan, tambalan, kruk.
Dan juga komunikasi dengan antrian. Kami secara aktif menggunakan IBM MQ di Alpha, bus perusahaan yang khas untuk antrian pesan. Klien di bawah .NET Framework ada, asli dari IBM. Tetapi mereka tidak memiliki klien untuk .NET Core. Dan, sejauh yang kami tahu, itu tidak direncanakan. hanya ada implementasi pada protokol AMQP terbuka, kami mencoba berkomunikasi dengan antrian dengan bantuannya, tetapi ada sejumlah masalah juga. Solusi? Ya, lagi lapisannya.
Secara umum, kami memiliki iterasi dalam upaya untuk mendapatkan semua hal ini bekerja secara normal melalui protokol AMQP dan tidak bodoh. Tetapi orang-orang dari IBM berhenti berlangganan kepada kami, kata mereka, maaf, teman-teman, tetapi dia tidak menyukai kami, begitu juga dia. Dan mereka hanya akan menggunakan protokol milik untuk alasan tertentu. Secara umum, kita sekarang duduk dan berpikir bagaimana mengulang semua ini. Kemungkinan besar, kami akan menulis klien kami alih-alih yang IBM, ini adalah sumber terbuka.
Depan, .NET dan NodeJS
Untuk sebagian besar, kami menggunakan Bereaksi JS untuk bagian depan, ia bekerja dengan node secara normal. Ketika kami pertama kali memulai, kami memiliki sejumlah proyek MVC lama. Di sana, saya harus meneruskan bagian depan sehingga rendering sisi server menjadi normal, melalui ReactJS.NET.
Sekarang kami menghindari ini, kami memutuskan untuk memisahkan lalat dari cutlets, pada akhirnya ternyata ada front terpisah dengan node, dan bahwa NodeJS menggunakan layanan kami pada api sisanya di aplikasi web. Dan, sebenarnya, itu saja. Di .NET, kami sudah menerapkan tengah. Dan kami tidak membuat tautan yang ketat, seperti yang saya amati dengan .NET dan Angular, bahwa kami tidak dapat memisahkannya sama sekali, karena kami berupaya mengembangkan spesialisasi pada orang.
Jika Anda tahu benar front murni, maka Anda dapat dengan aman pergi dengan tim java untuk menulis front untuk itu. Ini nyaman, sehingga Anda dapat mengalir dari satu tim ke tim lainnya. Dan jika Anda tahu tumpukan penuh, Anda dapat membuat aplikasi ujung ke ujung. Dan backend dengan .NET, dan tengah, dan bagian depan pada reaksi. Di sini kami memiliki standar teknologi terpadu.
Integrasi ponsel
Kami tidak punya banyak. Di mana ada, itu hanya menggunakan layanan kami di api web. Kami sendiri tidak menulis aplikasi seluler di .NET, bahkan tidak ada upaya. Yang asli masih lebih baik untuk dilakukan. Jika Anda bisa langsung mengambil dan menulis yang asli, lebih baik segera mengambil dan menulis. Ya, ada hal-hal berguna seperti Microsoft Xamarin, tetapi itu masuk akal ketika Anda membutuhkan awal yang cepat dan universal. Tetapi jika ada pertanyaan dengan kenyamanan aplikasi untuk setiap platform, dengan kinerja, Anda masih akan pergi dan Anda biasanya akan menulis asli. Dan kami memiliki yang asli pada awalnya.
Tentang resistensi terhadap yang baru
Ketika Anda memiliki perusahaan besar (dan bahkan hanya beberapa tim), Anda akan selalu tidak puas dengan pengenalan alat baru. Biasanya selalu, ini normal. Artis yang melihat ini, dan itu saja.
Ketika Anda memperkenalkan sesuatu yang tidak terlalu populer dari atas, atau sesuatu yang tidak disukai pengembang, orang akan selalu menemukan banyak cara untuk menyabot proses, dan bahkan menunjukkan dalam proses itu betapa bodohnya Anda yang memulai semua ini. Itu seperti itu ketika kami memperkenalkan StyleCop untuk .NET. Namun seiring waktu, semua orang tetap menerimanya dan sekarang aktif menggunakannya. Argumen sederhana membantu - pengaturan dari StyleCop adalah hal yang sangat umum. Hasilnya indah dan kurang lebih jelas untuk kode semua orang. Meskipun, saya curiga, beberapa pengembang masih menajamkan gigi. Bagaimanapun, setiap orang memiliki standar mereka sendiri, setiap orang memiliki pemahaman mereka sendiri tentang keindahan kode, mereka sendiri editor dan trik.
Hal serupa juga dikalahkan di seri Silicon Valley. Di sana, mereka berdebat tentang apa yang harus digunakan - tab atau spasi. Secara pribadi, saya tidak peduli, tetapi, seperti yang ditunjukkan oleh latihan, bagi sebagian orang, dan ini bisa menjadi awal untuk holivar.
Tentu saja, jika Anda menulis semuanya dalam visual, pertanyaan ini umumnya dihapus.
Seseorang di sini menulis kode dalam Visual Studio, sementara yang lain tidak. Ketika kami beralih ke cluster, ternyata ada sejumlah teknologi yang tidak berfungsi di Windows. Misalnya, Ansible. Ada bagian klien di Windows, tetapi bagian server tidak bisa lagi dinaikkan. Oleh karena itu, pergi dan ambil mesin virtual di Linux, atau lakukan saja semuanya di server Linux.
Secara umum, kita hidup seperti itu. Jika Anda memiliki pertanyaan tentang .NET di bank, dan .NET pada prinsipnya - tulis, saya akan dengan senang hati menjawab.