Docker dulunya adalah hal yang keren dan awet muda. Dan kemudian entah bagaimana buruh pelabuhan itu berhenti menjadi menarik: dia hanya ada, dia ada di semua orang dan dalam segala hal. Ia memiliki semua layanan microser, Kubernetes, devops - apapun. Namun, orang menarik wadah ke mulut mereka dari mana saja. Mereka bahkan sering tidak tahu apa yang ada di dalamnya.
Apa yang sekarang menarik bagi para insinyur DevOps? Tim superhero - komite program konferensi DevOops - jatuh ke dalam perangkap jahat di Hangouts dan menjawab pertanyaan selama satu jam. (Siapa semua orang ini - ditulis
secara rinci
di sini ).
Di bawah potongan - wawancara, diwarnai dengan krayon. Setiap pakar memiliki warna sendiri:
Baruch, apa yang menurut Anda telah terjadi di dunia sejak DevOops masa lalu? 
Tampak bagi saya bahwa yang paling menarik, dari yang sudah jelas, adalah lepas landasnya Kubernetes di semua bidang, dan dari yang tidak jelas - konsumerisasi yang kurang terlihat, tetapi tidak kalah penting, dari konsumen buruh pelabuhan. 
Artinya, sebelum buruh pelabuhan itu bukan untuk semua orang?
Tidak. Docker dulunya adalah hal yang keren dan awet muda. Dan entah bagaimana buruh pelabuhan itu berhenti menjadi menarik, yaitu, ada di sana, semua orang dan semuanya memilikinya, ia memiliki semua layanan microser, Kubernetes, devops, segalanya, apa saja. Tapi buruh pelabuhan itu sendiri, sebagai teknologi, tiba-tiba sekali dan sekali lagi tidak menarik minat siapa pun. Jangan jalankan Java yang sama di server, jelas bahwa wadah. Itu benar-benar membuat saya terpesona.
Orang biasanya mendiskusikan masalah atau tugas langsung yang mereka hadapi. Tidak ada masalah di buruh pelabuhan dan apakah mereka ada di sana?
Ada banyak masalah di buruh pelabuhan, dan mereka benar-benar diselesaikan. Selain itu, kami berhenti menggunakan bagian-bagian dari buruh pelabuhan yang menyakitkan. Pekerja pelabuhan memiliki hal-hal yang dapat dilakukannya dengan sangat baik. Dan ada yang buruk.
Berikan contoh.
Misalnya, penjara dalam proses unix - semuanya sangat baik dan cerdas di sana. Ini benar-benar bekerja sangat keren. Tapi misalnya, konektivitas antara layanan microser yang berjalan dalam wadah, cluster, penyebaran, itu semua adalah neraka dan mimpi buruk.
Apakah maksud Anda Gerombolan yang mereka coba samakan dengan Kubernet? 
Ya, maksud saya Susun, itu semua adalah mimpi buruk dan neraka. Dan kami memutuskan untuk tidak menggunakannya, tetapi hanya menggunakan apa yang berfungsi dengan baik, yang dapat dimengerti dan gratis. Dan buruh pelabuhan menjadi sangat keren di satu sisi, dan di sisi lain tidak lagi menarik. Docker dan buruh pelabuhan - baik dan bagus.
Sekarang, ketika Anda melihat perangkat lunak baru, pertama-tama Anda melihat apakah ada wadah yang sudah jadi. Lebih disukai dari produsen perangkat lunak ini. Kemudian Anda menyaksikan bagaimana membuka lipatan dan menusuknya dengan tongkat. Docker mengirimi kami layanan kompleks untuk mencolek mesin yang berfungsi. Sekarang tidak terlalu penting apakah Anda poppy atau Linux. Sentry yang sama terdiri dari 5-6 komponen yang Anda mulai jalankan secara terpisah. Dan jika Anda memiliki tugas hanya untuk melihat bagaimana ini terlihat bagus, kirim sinyal dan perhatikan bagaimana itu terurai di sana. Sekarang akan memakan waktu 15 menit - diluncurkan, diluncurkan, dan karya akan berada di Ruby, karya di Jawa, dilarang Tuhan, beberapa Elasticsearch - yang akan mati dengan buruh pelabuhan yang sama.
Yang terpenting, dia akan mati nanti. 
Ya, ini adalah pesona yang terpisah. Sebelumnya, Anda bisa menipu diri sendiri ke dalam sistem sehingga di / usr / local tidak ada apa-apa. Dan masih bangun - seseorang di / opt, seseorang di / usr / local, orang lain di suatu tempat. Dan sistem Anda membengkak, ditumbuhi segala sesuatu yang tidak perlu. Ini adalah satu, dan yang kedua - semakin Anda tidak perlu, semakin besar vektor serangan pada Anda, karena itu Anda bisa tersinggung. Dan karena kita sekarang meluncurkan semua ini di buruh pelabuhan, keamanan di sini dan kebersihan tidak membawa hal-hal buruk dengan kita.
Dengar, tuan dan nyonya-nyonya, Anda sedang mengadakan konferensi tentang para devosan, dan di sana jika buruh pelabuhan menjadi membosankan dan tidak menarik, bagaimana sekarang, tidak akan ada buruh pelabuhan?
Pertama, buruh pelabuhan akan ada di mana-mana. Hanya karena telah menjadi membosankan dan tidak menarik bukan berarti itu akan berhenti digunakan. Sebaliknya, ini berarti bahwa kita sekarang menggunakannya dan tidak memperhatikan. Artinya, dia ada di mana-mana. Ini bukan topik untuk diskusi terpisah di konferensi.
Apakah dia punya laporan? Jika saya masuk ke program sekarang dan menulis kata buruh pelabuhan, tidak akan ada apa-apa?
Menulis Mari kita lakukan eksperimen yang luar biasa ini.
Menulis dan berbunyi: Langkah-langkah praktis untuk mengamankan penyebaran kontainer Anda
Ini adalah cerminan dari fakta bahwa buruh pelabuhan memungkinkan sistem modern kita menjadi lebih aman secara alami. Selain itu, itu mencerminkan satu hal lagi, yang mungkin juga telah berubah akhir-akhir ini ... Devops telah menjadi lebih. Anggap saja perusahaan-perusahaan besar mulai menembus mereka semakin banyak. Dan bersama mereka, semakin banyak diskusi dimulai pada topik keamanan, yang dapat dibawa oleh para devops, atau, sebaliknya, untuk menghancurkan keamanan ini. Laporan Liz adalah tentang bagaimana mempersiapkan devo ini dengan benar agar penjaga Anda senang. 
Apakah Anda mengenal pembicara secara pribadi? Siapakah Liz Rice?
Liz adalah tokoh penting dalam lanskap devopian. Dia adalah kepala semua KubeCons. Faktanya, Liz, pertama, adalah pembicara yang sangat baik. Kedua, dia bekerja untuk Aqua Security, sebuah perusahaan yang menangani keselamatan kontainer. Kami tidak akan menemukan orang yang lebih baik untuk cerita tentang keamanan kontainer daripada mereka yang secara khusus terlibat dalam hal ini. Apa yang menarik secara khusus tentang laporan Liz, saya melihat banyak laporannya, adalah bahwa dia sedang mencoba menyelesaikan masalah yang agak rumit. Masalahnya adalah bahwa hari ini, keamanan adalah, pertama, kompleks, dan semakin rumit, karena serangan menjadi lebih canggih. Oleh karena itu, menjadi lebih sulit untuk bertahan melawan mereka, kita harus mengenkripsi informasi kita pada REST, kita harus mengenkripsi lalu lintas, semua jenis TLS, https, sertifikat, protokol ... semua ini rumit . Dengan huruf A di akhir. Pertama, ini sulit, dan kedua, tidak ada jalan keluar darinya, karena Anda tidak bisa mengatakan sekarang: "Oh, saya tidak tahu ini, ayolah, saya tidak akan melakukan https. Nah, siapa yang peduli siapa yang saya butuhkan. " Karena Chrome jahat yang sama akan segera berteriak kepada semua pengguna Anda bahwa semuanya tidak diamankan dengan Anda. Dan kombinasi dari kerumitan dan kebutuhan ini, membeku, karena itu bukan urusan kita, kita tidak semua aman. Di sisi lain, itu ada pada kita, karena kita tidak bisa begitu saja mengabaikan aspek-aspek ini. Liz dalam laporannya mencoba untuk secara sederhana dan jelas menyampaikan aspek-aspek utama dari keselamatan kontainer kepada orang-orang yang jauh dari keselamatan, dan ini sangat keren.
Ada masalah lain yang orang tarik wadah ke mulut mereka dari mana saja. Mereka bahkan sering tidak tahu apa yang ada di dalamnya. Satu hal jika Anda ingin menempelkan tongkat Anda di laptop. Dan satu hal lagi adalah menyeretnya ke dalam produksi. Dan, sayangnya, banyak yang menyeret hit apa pun. Artinya, Anda membutuhkan sesuatu yang sulit untuk dirakit, mereka mengambil yang jadi dan baik, jika dari pabrikan, yang merawat dan mengambil wadah pangkalan normal. Dan ini adalah vektor yang sama untuk serangan. Misalnya, dalam waktu dekat kita dapat menyapu gelombang baru wadah dengan nama yang sama, seperti halnya dengan modul pip, dengan modul get. Seperti halnya dengan domain, semuanya sama. Artinya, ini bukan masalah baru, itu masih sama lama. Dan ketika sebuah layanan menjadi komoditas, ketika didistribusikan, orang datang ke sana yang menghukum mereka yang tidak memantau keamanan. Omong-omong, karena ini, kami memiliki banyak laporan tentang keamanan.
Apa lagi yang ada di sana?
Kami masih memiliki tentang mengelola rahasia dari Seth Vargo. Ngomong-ngomong, akan ada meja bundar tentang keamanan bersamanya.
Apakah Seth orang yang sama dari Google yang dulu bekerja di HashiCorp?
Sebelum itu, ia bekerja di Chef Software dan menjadi bintang di sana ketika Chef berada di puncak popularitas. Dia meninggalkan bekas di hampir setiap buku masak. Beberapa bahkan tidak menyukainya untuk kegiatan ini. Kemudian dia banyak mewarisi di HashiCorp. Dan kereta HashiCorp ini masih membentang di belakangnya. Di sini dia akan berbicara tentang produk HashiCorp. Dia tidak akan berbicara tentang Google. Namun dalam judul dia akan memiliki Google, jadi ini menambah bobot.
Ngomong-ngomong, apa yang terjadi pada Chef?
Di beberapa tempat, Chef terbunuh oleh wadah yang sangat.
Aplikasi Chef di mana mereka ditulis dan bekerja - sejauh yang saya mengerti, dapat terus bekerja untuk waktu yang lama, karena manajemen konfigurasi itu sendiri belum mati.
Kawan, saya dapat memberi tahu Anda dengan contoh hidup. Kami memiliki sesuatu yang tidak ada di buruh pelabuhan, kemudian di bawah Chef. Karena server-kepingan salju tidak pergi ke mana pun.
Anda baru saja mengatakan apa yang terjadi pada Chef. Apa yang tidak di bawah buruh pelabuhan ada di bawah Chef. Tetapi di bawah Docker, kita memiliki hampir segalanya.
Semuanya benar, tetapi masih ada server yang tahan lama, server dengan data yang tidak ingin didorong oleh siapa pun. Di sini mereka akan tetap tinggal bersama Chef selama beberapa waktu, karena setiap orang yang telah berada di dunia normal tidak ingin kembali ke arena kontrol manual.
Omong-omong, adakah yang hadir menggunakan Ansible?
Ya, Ansible juga ada di sana.
Kami menggunakan.
Dan bagaimana caranya? Mengapa mungkin
Kemampuan luar biasa untuk berubah menjadi sampah dengan kecepatan liar. Ini adalah kesan Ansible daun. Saya belum pernah bertemu konvergensi ke neraka dalam hidup saya.
Tampaknya kami memiliki laporan tentang ini!
Tepat Dan itu membantu tidak hanya mengubah hasil bekerja dengan Ansible menjadi apa yang saya sebutkan. Dan ini luar biasa, maaf, saya tidak melihatnya ketika kami menulis ini semua baik .
Anda mengatakan bahwa semuanya dimulai di bawah buruh pelabuhan, tetapi server itu sendiri perlu dikonfigurasi entah bagaimana untuk menjalankan hypervisor pada mereka?
Tidak, Anda bawa di Amazon ...
Ah, curang, di Amazon. Saya melihat.
Atau Terraform - di mana saja.
Yang paling maju. Dan soal ini kami juga punya laporan .
Terraform menutup kebutuhan ini, bahwa ada banyak penyedia, mesin virtual mereka mulai berbeda, dan Anda menggunakan Terraform untuk menutup lapisan ketika mesin Anda muncul. Maka Anda memiliki beberapa penyedia di Terraform, Chef yang sama, Ansible yang sama. Beberapa penyedia menyediakan lapisan berikutnya, dan kemudian Docker terbang ke mesin minimal yang sudah jadi ini. Untung
Dan laporan ini dipimpin oleh orang yang melakukan aws-modules untuk Terraform?
Dia telah melakukan banyak hal untuk modul Amazon, tetapi ini adalah bagian komunitas. Dan orang ini juga menarik sebagai berikut: karena dia telah hidup dengan Terraform sejak lama, beberapa praktik terbaik telah terbentuk di komunitas tempat dia bergaul selama bertahun-tahun, dan praktik terbaik ini tidak cukup di sekitar Terraform, karena di tempat-tempat itu sangat sederhana dan tidak memungkinkan Anda membuat gerakan yang tidak perlu, yang terkadang uraiannya terlalu rumit. Anda akan memiliki kain kaki, atau sebaliknya, struktur yang saling berhubungan yang sangat kompleks. Dan kami berharap bahwa Anton Babenko, yang hanya akan membicarakan semua ini, akan membantu memilah cara hidup dengan Terraform dan tidak menderita karenanya. Bagaimana mengembangkan modul Anda untuk kebutuhan pribadi, sehingga modul-modul itu tetap bersih, dapat dibaca dan, omong-omong, di sana, tentu saja, tidak ada yang menguji apa pun juga.
Tidak ada yang mencoba ini Terraform footcloths dari bahasa logam yang lebih nyaman untuk menghasilkan?
Ada ide seperti itu. Dan kami berusaha untuk tidak melakukannya. Di sana, pada kenyataannya, Terraform memiliki struktur data yang masih dapat dilakukan tanpa generasi, tetapi sulit. Bayangkan Anda memiliki beberapa vpc di Amazon di berbagai wilayah, Anda perlu mengintip di antara mereka, dan di sini Anda memulai petualangan. Di setiap wilayah API, titik masuknya berbeda, dan Terraform yang Anda bicarakan. Artinya, Anda perlu menyelesaikan titik entri ini dalam deskripsi, menjelaskan setiap vpc dan juga mengintip, koneksi antara vpc ini di berbagai wilayah. Dan semua ini entah bagaimana harus dijelaskan. Teman-teman kami melakukannya dengan modul mereka, dan dengan ini setidaknya entah bagaimana menjadi mungkin untuk hidup. Secara umum, sulit, sulit. Tetapi jika Terraform memberi lebih banyak kemungkinan, jika ada ... Apa namanya ketika variabel di dalam variabel dipanaskan?
Kotlin DSL. 
<semua orang tertawa terbahak-bahak>
Variabel variabel, atau interpolasi - tergantung pada apa yang Anda maksud.
Secara umum, ini bukan bahasa lengkap, itu sangat terpotong. Dia membuat Anda menulis sesederhana mungkin, tidak seperti Kotlin DSL, di mana Anda memiliki Kotlin penuh di tangan Anda.
Nah, bagaimana, dengan semua keterbatasan DSL Kotlin, yang Anda sendiri mengerti, diselesaikan dengan apa?
Apa?
DSL asyik dipecahkan secara alami!
Banyak yang menggunakan TeamCity dari yang hadir di sini?
Ya tentu saja Groove DSL, Kotlin DSL, kami punya laporan tentang itu!
Dan tentu saja Anda melakukannya?
Bukan aku yang melakukannya, tidak! Kami hanya akan memiliki TeamCity dengan DSL Kotlin dan perbandingannya dengan DSL Groovy di Jenkins.
Seseorang dari JetBrains tiba?
Tidak. Ini adalah pesona yang terpisah.
Kami memiliki pengguna nyata, tidak ada pemasaran.
Semua orang, saya menyerah, siapa lagi yang bisa membuat laporan tentang TeamCity?
Sebuah perusahaan kecil, dikenal luas di Rusia sebagai Tinkoff, menggunakan. Di sini, dia ada di program .
Ya, dan ceritakan sedikit, bandingkan dengan semua Jenkins yang dibenci, tetapi digunakan secara universal dan DSL Groovy-nya.
Kita harus pergi, mendengarkan, dan mencari tahu apa peran karisma Baruch dalam pilihan teknologi.
Tidak ada Saya abstrak sepenuhnya dari ini semua. Semuanya akan jujur, tanpa muhlezh.
Maksud saya Tinkoff mengambil semua teknologi hipster ini karena suatu alasan, TeamCity bukan semacam perusahaan dua puluh tahun yang lalu, seperti yang biasa terjadi di bank.
Tinkoff adalah bank yang telah melakukannya sejak awal. Bank untuk hipsters dari hipsters. Dengan demikian, teknologi di sana segar dan benar.
Guys, saya benar-benar menggunakan TeamCity setiap hari, dan dalam versi terbaru itu menjadi hebat. DSL TeamCity sekarang tersedia. Lihat apa masalahnya hingga versi terbaru. Di versi sebelumnya, jika Anda beralih ke Kotlin DSL, Anda tidak punya opsi untuk terus menggunakan antarmuka. Begitu Anda melewati batas, satu-satunya cara untuk menulis lebih lanjut hanya di Kotlin.
Itu saja, Anda menginjak Sisi Gelap.
Ya, ada minimum dokumentasi, dan itu adok. Jadi kami mencoba dan memutar kembali ke konfigurasi XML. Dalam versi terbaru, ketika Anda beralih ke Kotlin DSL, Anda terus menggunakan antarmuka web, dan itu membentuk tambalan di bawah tenda, tambalan struktur ini langsung di repositori. Maka Anda dapat dengan aman melanjutkan menulis di Kotlin jika Anda sudah menguasai sesuatu di suatu tempat. Mereka yang belum berdedikasi dapat terus melihat-lihat antarmuka. Ini orang-orang hebat!
Ini adalah pengaruh yang menguntungkan dari Anton Arkhipov.
Omong-omong, semua jenis praktik disebutkan di sini. Apakah kita memiliki laporan yang didedikasikan bukan untuk penyetelan, tetapi untuk beberapa proses, budaya, sisi manusia?
Secara alami. Pertama, kita memiliki keynote penutup yang bagus dari Sasha Titov dan Kirill Tolkachev, di mana mereka akan membahas apakah semuanya buruk di devoop atau masih ada harapan. 
Tampaknya penting bagi saya untuk mengatakan bahwa DevOops mungkin saat ini merupakan satu-satunya konferensi profesional yang diselenggarakan oleh Grup JUG.ru, di mana ia diperbolehkan untuk berbicara tentang hal-hal sosial dan proses, dan pada tingkat resmi.
Untuk melakukan ini, kami harus berbicara dengan manajemen Grup JUG.ru, tetapi hasilnya langsung.
Selain keynote yang indah ini, kami juga memiliki laporan dari Dell EMC, yang juga banyak terkait dengan proses. Ini tentang tim di dalam perusahaan yang menulis layanan untuk penggunaan internal. Adalah satu hal untuk menulis layanan ini, dan yang lain untuk mulai menggunakannya, karena semua orang sibuk, mereka tidak punya waktu untuk menguasai teknologi hipster. Karenanya, tulis layanan, dan kemudian jual di dalam perusahaan. Pengguna akan mendatangi Anda, semua jenis kebutuhan non-standar akan mulai muncul, dan di sini Anda memiliki dilema - untuk mengembangkan layanan sehingga banyak yang dapat menggunakannya atau memuaskan tim khusus ini. Kami mengharapkan cahaya di sana juga.
Akan ada deskripsi dari kisah dua tahun yang mengerikan, yang tidak lagi seburuk pada awalnya.
Baruch, apakah Anda juga mengatakan sesuatu yang sangat sosial?
Lenya Igolnik dan saya punya laporan tentang bagaimana mulai mengukur sekarang ini semua ini adalah aib yang terjadi pada para devop kita. Secara alami, kami memiliki semacam metrik yang kami bawa dari dev dan yang tidak kami gunakan dan tidak pernah digunakan. Kami memiliki metrik yang kami bawa dari ops, yang selalu jauh lebih baik. Pertanyaannya adalah, apa sebenarnya metrik devops? Apa artinya ini? Apakah hanya mengambil dan mengambil yang lain, atau itu sesuatu yang baru, beberapa metrik baru? Singkatnya, para pengembang data-driven .
Baruch, kadang-kadang pembaca, pengunjung marah bahwa kawan-kawan dari komite program membaca laporan mereka, mereka menganggap ini sesuatu yang tidak jujur.
Kami benar-benar memperhitungkan semua ini. Setidaknya, kami berusaha sangat keras untuk menghadirkan sebanyak mungkin pembicara yang beragam, yang tidak hanya dari komite program. Tetapi pada saat yang sama, kami masih ingin melihat beberapa peserta PC sebagai pembicara. Sebagai contoh, Alena Prokhorchik, Principal Engineer di Rancher Labs, yang mungkin memiliki pengalaman paling banyak di dunia dengan penyebaran Kubernet multicloud. Saya pikir semua orang ingin mendengarnya, dan dia punya sesuatu untuk diceritakan . Dan kami, sebagai komite program, menikmati keahliannya dalam mengevaluasi laporan. Mungkin, ketika seluruh konferensi terdiri dari pembicara dari komite program, dan masing-masing dari mereka memiliki lima laporan, ini benar-benar tidak baik. Tetapi jika kita memiliki pembicara yang baik yang ingin membantu komite program, sejujurnya saya tidak mengerti mengapa kita harus memilih yang satu atau yang lain.
Baruch, Anda bekerja bekerja, plus Anda terus-menerus bepergian dengan laporan, ditambah Anda bekerja di komite program. Apakah Anda memiliki kehidupan sama sekali? Bagaimana Anda bisa melakukan semuanya?
Menjadi sukarelawan untuk konferensi Grup JUG.ru sangat menyenangkan karena memberi banyak kesenangan - dan selain itu, saya belajar yang baru. Menjalankan laporan orang yang tahu lebih banyak dari saya sangat berguna.
Saya melihat. Adakah yang mau menambahkan sesuatu ke monolog kami dengan Baruch?
Saya sering mengatakan bahwa saya telah mendengar laporan bahwa tidak seorang pun akan mendengar .
Ya, komite program tidak hanya mendengar apa yang sampai ke konferensi. Persaingan adalah satu dari tiga. Kita dapat mengatakan bahwa ini terjadi, karena di antara aplikasi ada banyak yang cukup menarik. Bagian dari apa yang kami filter, kami rekomendasikan di konferensi lain.
Apakah ada topik yang harus Anda filter berdasarkan kuantitas? Kubernetes, misalnya. Apakah ada hal lain?
Pemantauan Kami memiliki pertempuran untuk pemantauan.
Banyak laporan. Semua orang suka memonitor.
Siapa yang memenangkan Raja Bukit ini?
Alexey Kirpichnikov, laporkan "Apa yang telah kita pelajari saat kita membuat sistem pemberitahuan darurat kita sendiri" .
Apakah ada sesuatu yang ingin saya miliki dalam program ini, tetapi tidak ada pakar?
Anda melepas lidah. Ada sisi lain dari koin, serverless kita yang tercinta, yang tampaknya berada di bawah hype, tetapi tidak ada yang berpikir dengan baik dan secara praktis menerapkan semua ini belum muncul. Saya harap kita mendapatkan setidaknya satu. Tetapi secara umum, perusahaan memiliki sedikit pengalaman industri. Baruch, bagaimana dengan para ahli evangelis? Mereka juga tidak ada di sana? Atau tidak ada yang datang kepada kita?
Seluruh kisah visa benar-benar merusak situasi bagi kami dalam banyak hal, termasuk dengan para pengembang yang ingin datang dan berbicara tentang tanpa server, khususnya dari Amazon, tentang lambda. Pada visa, sayangnya, semuanya macet.
Dan ada laporan di mana Anda benar-benar mempelajari sesuatu yang baru untuk diri sendiri, yang tidak Anda miliki sebelumnya? Atau beberapa hal terobosan yang Anda ingat?
Saya, sebagai salah satu orang yang paling non-teknis di komite program, terus-menerus menemukan banyak hal baru yang saya bawa kepada para insinyur saya nanti, dan mereka berkata ya, itu yang Anda bawa kepada saya. Tapi tidak selalu!
Tatyana, Anda tidak mengatakan apa-apa, katakan padaku, apa yang Anda pelajari baru dalam proses PC?
, , . , . - . , Ansible , . Ansible, . , , - . : , , , , . , , , .
, , . , , . .
.
?
. . , , , .
stateful , -, .
, . managed PostgreSQL … , - , — . , , , .
, - , . , ?
. Kubernetes , , . , , - , .
, . - , ? - , - , ?
— . , , , . , ( — , ) — , . JUG.ru Group , , . , , . . , (BOF). , , SRE. security, — , , , , . , , , -, , — , , :-)
- ?
, .
« , , » — , .
?
, , , . .
, , , - Java Virtual Machine, BOF . , , , - .
JVM, , , . , , , .
, — , , . , .
, . DevOops , . . , people + processes, , , .
, , TechTrain, .
, . , , , , . , TechTrain, . , TechTrain . JUG.ru Group, — . , . , . , , , .
, , — « » ( ).
, . -, , , . — , .
DevOops !
, , Joker , Java . , , — .
, , , DevOops - . , every company is a software company, - .
Terima kasih atas wawancara! Kami akan bertemu dengan Anda beberapa kali dalam persiapan artikel, tetapi dengan pembaca kami dari Habr, kami hanya akan bertemu di DevOops. Semua yang terbaik, dan sampai jumpa lagi!
DevOops Conference akan diadakan pada 14 Oktober 2018 di St. Petersburg. Jika Anda tiba-tiba menyukai program yang kami diskusikan di sini, maka pastikan untuk datang. Tiket ada di sini .