Pada kata-kata "open source", banyak yang tampaknya menjadi penggemar yang berkomitmen di malam hari untuk proyek favorit mereka, atau perusahaan kecil yang menghasilkan uang dengan mendukung produk terbuka. Tetapi jika Anda hanya memikirkan mereka, maka Anda akan kehilangan segmen komunitas yang penting dan menarik. Dulu kata "perusahaan" dan "sumber terbuka" tampaknya antonim, tetapi sekarang perusahaan besar tidak hanya secara aktif menggunakan proyek OSS, tetapi mereka sendiri akan berkontribusi pada mereka.
Seiring waktu, Sbertech semakin aktif dalam komunitas OSS, dan kami memutuskan untuk bertanya tentang hal itu. Bagaimana menggabungkan kekhususan perbankan yang ketat dengan semangat sumber terbuka kebebasan? Apa persyaratan untuk Open Source yang mungkin tidak dimiliki perusahaan lain? Apakah ada karyawan di Sbertech yang menulis open source sebagai tugas pekerjaan utama mereka? Apa rencana dan keinginan Anda untuk masa depan?
Anton Churaev , yang mengawasi Free & Open Source, memberi tahu kami tentang semua ini dan banyak lagi.
Oleg: Hai Anton. Mari kenalkan Anda sedikit tentang Khabrovites. Ceritakan tentang diri Anda: siapa Anda, apa yang Anda lakukan?Anton: Saya seorang insinyur yang berkembang hanya di waktu luangnya. Sekarang saya membangun praktik dan kompetensi Sbertech untuk pengembangan dan penerapan produk Free & Open Source. Anda perlu memahami bahwa ini adalah hal-hal yang sedikit berbeda.
- Ya, saya mengerti, beberapa kali ketika berbicara dengan Stallman saya menelepon Free as Open dan setelah itu saya mendengarkan ceramah yang saya ingat seumur hidup :-) Nah, apa posisi Anda?- Kurator pengembangan Free & Open Source. Dan penggemar open source :)
- Bisakah Anda memecahkan kode sedikit lagi tentang "kompetensi untuk implementasi Open Source"? Kedengarannya seperti semacam pengetahuan rahasia.- Hanya sedikit orang yang membayangkan apa arti Open Source bagi perusahaan. Di satu sisi, ini adalah inovasi dan tidak adanya kebutuhan untuk mengembangkan komoditas, fokus pada keunggulan kompetitif produk mereka, menggunakan kembali dan mengurangi biaya. Seringkali ini adalah proyek yang sebenarnya telah menjadi standar industri. Ambil Hadoop yang sama - semua orang tahu itu, semua orang tahu itu, sudah lama menjadi standar. Atau database yang paling umum - lima teratas adalah tiga produk open source - MySQL, PostgreSQL dan MongoDB.
Tetapi beberapa orang berpikir bahwa menggunakan OpenSource melibatkan banyak biaya tersembunyi. Ini bukan untuk mengatakan bahwa kami menemukan sesuatu open source dan menyelesaikan semua masalah kami. Misalnya, ada pertanyaan besar tentang "kebersihan hukum". Ketika bekerja dengan perangkat lunak vendor, semuanya sangat jelas: Saya mengambil lisensi, Anda mengerjakannya dan menggunakan dukungan. Ketika bekerja dengan Open Source, banyak yang tersisa di tangan pengembang dan pengguna. Dalam hal ini, masalah hukum dan hukum adalah salah satu tempat pertama. Selain itu, di Rusia ada nuansa. Jika di seluruh dunia konsep kekayaan intelektual cukup berkembang dan semua orang memahami bahwa sangat penting bahwa ada pemilik tertentu, maka secara historis di Rusia semuanya berubah secara berbeda. Di sini kita tidak begitu berhati-hati dan menghormati properti intelektual, meskipun ini sangat salah. Dan jika Anda tidak dapat memastikan "kebersihan" menggunakan Open Source, Anda tidak dapat memastikan kualitas penggunaannya.
- Bisakah saya mengklarifikasi? Apa status hukum lisensi GPL di Rusia? Misalnya, GPL tidak mengizinkan modifikasi pada hukum setempat dan tidak menunjukkan batasan teritorial. Oleh karena itu, perjanjian semacam itu tidak sesuai dengan rezim hukum yang didirikan di wilayah Federasi Rusia, dan ini sangat, sangat buruk.- Saya tidak ingin membagi lisensi menjadi beberapa zona. Sberbank adalah perusahaan global, sehingga perangkat lunaknya dapat digunakan baik di Amerika Serikat maupun di Uni Eropa. Dan, seperti yang saya pahami (saya bukan pengacara, tapi setahu saya), jika terjadi pelanggaran terhadap pembatasan lisensi pemegang hak cipta di wilayah, misalnya, AS, kami akan bertanggung jawab berdasarkan hukum Amerika Serikat Mengingat hal ini, Anda harus sangat berhati-hati dalam mendapatkan hak dan memenuhi persyaratan untuk kekayaan intelektual orang lain. Hormati penulis yang mengizinkan kami menggunakan karya kami, yang karenanya kami mempercepat, mengoptimalkan solusi, memecahkan masalah kami dan pada akhirnya memberikan layanan berkualitas kepada pelanggan kami. Mari kita patuhi hak dan persyaratan. Ini adalah tugas pertama.
- Dan yang kedua?- Tugas kedua adalah keamanan informasi. Jelas bahwa sebagian besar lisensi berisi penafian yang menyatakan bahwa penulis / pengembang / kontributor tidak bertanggung jawab atas kerugian yang mungkin disebabkan oleh pengoperasian perangkat lunak ini. Ini benar, ini adalah tanggung jawab yang ditransfer ke konsumen dan membutuhkan kedewasaan darinya. Semuanya tidak gratis.
Anda harus membayar untuk tanggung jawab ini dan, tentu saja, bekerja dengan risiko-risiko ini. Tidak semua perusahaan dapat melakukan ini. Kami memiliki departemen keamanan informasi yang sangat kuat - kami beruntung. Oleh karena itu, kami serius tentang adanya kerentanan dan kode berbahaya pada umumnya. Setiap orang yang berencana untuk menggunakan Open Source harus memperhitungkan semua risiko - tidak hanya legal, tetapi juga dalam hal keamanan informasi.
- Lisensi apa yang kamu suka?- Akademik.
- O! Mari kita lebih spesifik. Ada MIT / BSD, dll., Dan ada lisensi virus copyleft seperti Affero GPL. Yang mana dari ini?- Bagus Anda tidak dapat menyukai atau tidak menyukai lisensi. Produk ini dibuat untuk tugas tertentu dan akan digunakan dengan cara tertentu. Saat menggunakan open source, tugas Anda adalah memastikan bahwa Anda menyediakan produk atau layanan Anda tanpa melanggar hak pihak ketiga. Dalam kasus ini, tentu saja, Anda dapat menggunakan copylefts (misalnya, GPL), jika Anda memastikan penggunaannya sehingga tidak melanggar batasan dan hak orang lain. Tentu saja, ada lebih sedikit kesulitan ketika menggunakan lisensi akademik, hanya karena mereka membawa lebih sedikit pembatasan dan karenanya lebih mudah untuk diikuti. Singkatnya, saya sebut MIT "akademik", BSD, Apache, dll.
- Oke, apakah pengembang biasa harus berurusan dengan keamanan informasi? Atau dialokasikan ke departemen terpisah?- Semua pengembang harus memahami dasar-dasar keamanan informasi dan prinsip-prinsip keamanannya untuk sistem mereka. Namun dalam kasus kami, kami bekerja dengan pengembang individual yang berspesialisasi dalam ancaman terhadap keamanan informasi. Selain itu, kami beralih kepada mereka tidak hanya untuk analisis produk-produk sumber terbuka, tetapi juga untuk analisis algoritma dan solusi desain.
"Jelas bahwa penjaga keamanan khusus ini tahu segalanya." Dan apa yang perlu diketahui pengembang dalam hal ini? Apa poin dasarnya?- Model ancaman, perlindungan saluran, perlindungan data. Apa yang rentan terhadap ancaman: mungkin ini adalah antarmuka pengguna atau transmisi data melalui jaringan (semuanya didistribusikan bersama kami, jadi ini adalah masalah yang sangat penting). Alat dasar seperti enkripsi, SSL, TLS, otentikasi, otorisasi, penanganan token dan sebagainya. Anda tidak perlu tahu banyak.
- Rumor mengatakan bahwa Anda ada hubungannya dengan Apache Ignite :-)- Dalam hal berkontribusi, ini adalah proyek utama yang sedang saya kerjakan. Partisipasi dalam Apache Ignite adalah tugas kedua saya - untuk memastikan investasi seimbang dalam proyek-proyek Free dan Open Source. Ini menyiratkan penggunaan kompeten produk (jelas bahwa penggunaan perpustakaan adalah investasi, kami, sebagai pengguna, meningkatkan daya tarik produk), serta pengembangan, dan berkontribusi.
Bagi saya, mungkin, tugas ini bahkan lebih penting. Kami membayar upeti kepada produk-produk yang kami gunakan di perusahaan kami, dan terima kasih kami telah membangun banyak produk dan sistem. Kami mencoba untuk memperbaikinya dan memastikan kemungkinan penggunaan di perusahaan seperti kami: untuk mengoptimalkan, membawa ke keadaan perusahaan.
Apache Ignite bukan satu-satunya proyek, tetapi kami akan secara intensif menyelundupkannya ke dalamnya, karena salah satu platform utama di bank sedang dibangun berdasarkan Apache Ignite. Ignite adalah kisi komputasi terdistribusi yang memungkinkan Anda untuk menyimpan dan memproses data dalam memori, dan sebenarnya itu adalah dasar dari lanskap TI bisnis kami. Oleh karena itu, kami sangat tertarik dengan pengembangannya.
- Banyak orang tahu bahwa Sbertech menggunakan GridGain, dan Anda berbicara tentang Apache Ignite. Apa perbedaan keduanya?- GridGain adalah produk inti terbuka yang dibangun berdasarkan inti terbuka, yaitu Ignite. Dan GridGain adalah seperangkat plug-in untuk inti ini, yang menyederhanakan prosedur perawatan dan operasi, menyediakan sejumlah persyaratan keamanan dan keandalan informasi yang penting. Tetapi, pada intinya, intinya adalah bagian yang paling penting, dan plugin memungkinkan Anda untuk mengeksploitasi semua ini di perusahaan nyata. Dan bank sudah mengoperasikan GridGain.
- Karena Ignite terbuka, Anda dapat sedikit membicarakannya, bukan? Apakah Anda hanya mengeksploitasinya atau melakukan sesuatu untuk menyelesaikannya, berinteraksi dengan pengembang?- Kami secara intensif memodifikasinya. Arah tugas didefinisikan dengan jelas, misalnya, memastikan kinerja dengan mempertimbangkan spesifikasi Sberbank: skala besar, samudra data, aktivitas operasional yang tinggi. Karena itu, harus cepat dan banyak. Maksud saya latensi dan throughput.
Yang kedua adalah untuk memastikan keandalan, mis. ketersediaan dan toleransi kesalahan.
Ketiga adalah efisiensi operasional, manajemen TCO. Mengingat ukuran Sberbank, bahkan sedikit pengurangan dalam penggunaan sumber daya, misalnya, disk dengan persentase tertentu, pada skala kami memberikan penghematan luar biasa.
Dan yang keempat adalah tugas pengembangan fungsional. Bahkan, hal utama adalah pengembangan antarmuka dan integrasi dengan komponen lain dari tumpukan teknologi Sberbank. Ini berguna dan penting dalam hal membangun arsitektur IT yang matang dan terintegrasi.
Secara terpisah, ada tugas menghilangkan utang teknis dan cacat (yang selalu ada). Ini mungkin dapat dikaitkan dengan keandalan.
- Mari kita bahas poin-poin ini untuk klarifikasi. Anda mengatakan bahwa Anda bekerja untuk meningkatkan kinerja, latensi, throughput, itu saja. Pertanyaannya adalah - apakah Ignite memiliki masalah dengan ini? Maksud saya, apakah ada sesuatu untuk dimodifikasi atau itu produk yang ideal?- Tidak, produk tidak dapat dianggap ideal. Dalam setiap rilis, kami menggerakkan benchmark umum dan microbenchmark pada komponen tertentu, kami terus-menerus bekerja pada kinerja - kami tidak boleh berhenti di sini. Tugasnya sulit, karena komponen dan solusi sudah cukup diperketat, kinerjanya hampir di ambang batas besi. Ini menambah kompleksitas, tetapi selalu ada ruang untuk perbaikan. Kami memiliki kasus penggunaan yang berbeda, tugas pengguna baru muncul, di mana ada kemungkinan optimasi. Sebagai contoh, optimalkan tape drive untuk sifat spesifik data. Ada tugas untuk mengoptimalkan lapisan jaringan, yang, sekali lagi, tergantung pada masing-masing kasus. Karena itu, Anda harus selalu menjaga jari Anda pada denyut nadi.
"Kamu bilang akan berkontribusi kembali ke komunitas." Dan semua keputusan tentang berbagai kasus dan optimisasi untuk mereka adalah semacam pertukaran. Ketika kita mengambil tradeoffs kita dan membawanya ke komunitas, mungkin ternyata orang-orang di komunitas memiliki kondisi yang sedikit berbeda, prioritas yang berbeda. Bagaimana mengatur interaksi dan masih menyalin kode yang diperlukan untuk kasus Anda?- Pelanggan lain dengan tugas lain. Benar-benar benar bahwa ini adalah masalah standar. Itu semua tergantung pada arsitektur solusinya. Jika solusinya mencakup, misalnya, kemampuan untuk membuat ekstensi plug-in, plug-in, perpustakaan untuk solusi pengguna yang berbeda - Anda bisa keluar. Misalnya, jika ada pembanding, maka pengguna selalu dapat mengembangkan solusi yang akan meneruskan pembanding ini ke input, dan ini akan menyelesaikan masalah berdasarkan kondisi tertentu. Sekali lagi, kemampuan sangat bergantung pada arsitektur. Adalah keliru untuk secara kasar mengkodekan dan memahat untuk tugas kita tanpa memikirkan klien lain - permintaan tarikan seperti itu tidak melalui peninjauan.
Semua orang mengerti apa itu proyek Open Source, dan secara umum, Anda bisa mempengaruhinya. Tentu saja, ada komunitas di mana perusahaan jelas hadir yang memengaruhi pembangunan untuk kepentingan mereka sendiri, tetapi jika kita memainkan Open Source murni, maka itu akan benar dibandingkan dengan meritokrasi (otoritas yang layak). Buktikan bahwa keputusan Anda baik, dan kemudian akan dibuat. Bertindak, seperti yang sering terjadi dalam pengembangan tertutup, yaitu, dari posisi "Saya bos, saya bilang begitu" tidak akan berhasil.
- Salah satu kasus paling menarik yang Sbertech katakan di depan umum adalah Lapisan Semantik Tunggal. Sejumlah besar data tersebar di kisi dalam memori. Bagaimana hal ini memengaruhi bagian terbuka Ignite dan seberapa menarik perkembangan ini bagi komunitas?- Ya, perkembangan seperti itu sedang berlangsung, dan kami sangat intensif mengerjakan tugas untuk memastikan skalabilitas dan aksesibilitas. Kami menemukan kasus di mana skema manajemen topologi saat ini tidak optimal, karena kompleksitas temporal tumbuh dari jumlah node tidak cukup seperti yang kita inginkan. Ini agak mempersulit pencapaian tujuan.
- Sejauh yang saya ingat, arsitektur cluster adalah sebuah cincin. Yaitu, ketika kita bergabung dengan cincin, maka pada awalnya kita pergi ke koordinator dan kemudian kita pergi sepanjang cincin sampai kita menemukan ekornya. Dan semakin banyak elemen, semakin banyak waktu, kan?"Ya, semacam itu." Pada saat yang sama, dengan peningkatan jumlah node dalam topologi, baik ukuran pesan yang ditransmisikan di sepanjang ring dan jumlah transisi antara peserta meningkat. Ini bukan untuk mengatakan bahwa cincin adalah keputusan yang buruk, tetapi dalam beberapa kasus itu tidak cocok. Oleh karena itu, sejak akhir 2017, kami di komunitas menyelesaikan manajemen topologi sehingga pengguna dapat memilih skema manajemen topologi: cincin (kadang-kadang sangat cocok) atau bintang di Zookeeper.
- Dan dari mana cincin itu berasal? Kenapa begitu? Di mana itu sempurna?- Ini adalah solusi luar biasa pada topologi 100-200 node dalam satu pusat data. Memungkinkan Anda untuk menyinkronkan semua node dengan mudah dan andal, semuanya berjalan berurutan. Jika kita pergi ke bintang, maka mereka mulai bekerja secara paralel, lebih cepat, tetapi pada saat yang sama menyinkronkannya menjadi jauh lebih sulit. Artinya, cincin itu bisa lebih stabil dan dapat diandalkan, setuju?
"Ya, tentu saja." Tetapi dapatkah itu dilakukan agar topologi ini dapat diubah oleh beberapa parameter dalam konfigurasi, bagaimana pengaturannya?- Ya, kami sedang melakukannya sekarang, kami memasukkan kedua topologi dalam rilis. Mungkin, implementasi yang sudah diusulkan tidak mencakup semua kasus pengguna, dan segera setelah yang baru muncul, kami akan mencoba memastikan pemrosesan yang efektif.
- Sejauh yang saya mengerti, ini adalah revisi yang agak rumit. Dan revisi ini dilakukan oleh orang-orang di Sbertekh, selama jam kerja, atau di malam hari untuk kesenangan?- Ini dilakukan oleh masyarakat, termasuk karyawan PBT, yang tugas utamanya selama jam kerja adalah berkontribusi pada proyek ini. Masalah topologi memengaruhi salah satu solusi utama dalam inti produk, sehingga beban utama jatuh pada pengelola DiscoverySPI, tetapi saya berharap bahwa partisipasi pengembang kami juga memengaruhi hasilnya secara positif.
- Ya, ini adalah orang-orang yang memecahkan masalah selama jam kerja, tetapi pada saat yang sama adalah anggota komunitas.- Ya, bagian terpenting dari pekerjaan pengembang kami terjadi di komunitas. Tapi saya juga melihat dari orang-orang kita melakukan hal yang muncul dalam satu jam, dua, tiga malam.
- Dan karyawan ini tidak akan memiliki masalah dari kenyataan bahwa mereka bekerja di bank, pada sistem tertutup, dan pada saat yang sama berkomitmen pada sumber terbuka?- Tidak, tidak akan. Semua peserta adalah kontributor resmi perusahaan. Penciptaan arahan dan keputusan tentang investasi dibuat pada tingkat manajemen perusahaan, dan ya, kelompok kontributor korporat khusus ini, yang sesuai dengan semua standar perusahaan dan TC, mengembangkan produk-produk Open Source untuk kepentingan perusahaan. Ya - ini adalah pengembangan dan Open Source, ya - ini selama jam kerja, dan juga pada jam non-kerja, tapi ini sudah jika masyarakat memintanya.
- Kami baru saja membicarakan beberapa urusan eksternal yang diputuskan oleh komunitas. Tetapi kemungkinan besar, perusahaan perlu membuat integrasi sendiri, meningkatkan untuk beberapa kasus ... Apakah Anda banyak menulis sendiri? Atau hanya dopilka kecil?- Berbicara tentang proyek Apache Ignite, selama kuartal terakhir, kontribusi kami terhadap proyek berjumlah 8-10 persen dari semua perubahan, dan kami berusaha untuk meningkatkan persentase ini. Kami banyak menulis, dan ini bukan hanya pengembangan dan optimalisasi fungsi yang ada, kami juga mengerjakan fungsionalitas baru untuk proyek ini. Ini adalah tantangan bagi masyarakat, dan tanggung jawab bagi kita, karena setelah dimasukkan, masyarakat sampai batas tertentu memiliki tugas untuk mendukungnya.
Tugas dapat muncul tidak hanya dari komunitas, tetapi juga dari pengguna dalam perusahaan: arsitek, tim pengembangan dan pemeliharaan. Pengembangan proyek pada tugas-tugas ini juga secara signifikan mempengaruhi produk.
- Tapi, katakanlah, ada beberapa laporan dari program Sbertekh dari PRPRB mengenai "feng shui khusus" nya. Apakah saya perlu menulis alat tambahan dan halaman admin untuk mendukung ini?- Antarmuka untuk operasi terus berkembang. Konsol manajemen dari Oracle yang sama lebih akrab untuk dijaga dan memiliki lebih banyak fungsi. Apakah perlu direproduksi sepenuhnya adalah pertanyaan lain.
- Dan dalam bentuk terbuka, Anda dapat melihat konsol manajemen?"Ya, tentu saja." Konsol Web diterbitkan, Visor, CLI - semuanya publik.
- Dan jika Anda melihatnya secara lebih global, apa arah dan tujuan umum?- Sekarang kami lebih fokus pada pengembangan Apache Ignite, yang memenuhi prioritas perusahaan. Tetapi tumpukan teknologi kami tidak berakhir di sana. Open Source , , . , , . ( ), , . . , . . .
— , . - ?— — , availability, durability, fault tolerance ..
— , .— , — . , Open Source . . , .
— - , , ? , - , ceph?— , ceph — . , , , .
— - ? ?— OpenStack.
— , OpenStack — , . - , , ?— OpenStack , , , Cloud Foundry, .
— ?— :-) , ( ) . , — , , .
— .— , - Open Source .
, . , , -.
— -?— , , , -: , .. , , , , . . , Open Source, , , .
. , . -, , . . , , , .
, , ( -, , , ) — . , , , .
— .
— , . , «», , « , » «, ». , . , , . , , , . — , .
— , ? , … , , .— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .
— ? ?— , . , , – . — , ROI, .., .
— , - . , : , . , - Spring Hibernate, , , , . , , , . , .- Mungkin itu sebabnya ada lebih banyak pelamar yang baik di pasar daripada pengembang sistem. Saya sangat senang bahwa kami berhasil mengumpulkan tim saat ini, di mana semua orang sangat cerdas. Sungguh menakjubkan bagaimana mereka berpikir dan bekerja, mereka dapat memecahkan hampir semua masalah. Saya harap kami dapat menarik lebih banyak lagi pengembang yang berbakat. Oleh karena itu, orang tidak dapat mengatakan dengan pasti bahwa di Rusia tidak ada yang membutuhkan pengembang sistem.