Apa perbedaan antara DevOps dan Automation?

Saya melihat bahwa setiap kali seseorang melakukan DevOps, sebagian besar tentang mengotomatisasi hal-hal seperti penyebaran dll.

Tetapi di mana otomasi berakhir dan DevOps dimulai?

Sebagian besar DevOps memungkinkan rilis sangat sering. Itu datang dengan pembuatan otomatis, pengujian otomatis, dll. Anda dapat mengatakan bahwa untuk mencapai tujuannya, DevOps perlu menggunakan otomatisasi agar menjadi efisien.

Begini cara DevOps dan otomasi saling berhubungan. DevOps bukan hanya otomatisasi, ada lebih dari itu. Sebaliknya, otomasi tidak secara eksklusif digunakan oleh "orang-orang DevOps". Banyak otomatisasi terjadi di TI sebelum DevOps muncul.

Tolong jangan mempertimbangkan diagram di atas untuk mewakili semua yang DevOps, atau semua ini adalah otomatisasi. Ini untuk membantu pembaca menggambarkan bagaimana kedua konsep itu terkait.

Otomasi adalah atribut utama DevOps, tetapi ini bukan cerita lengkapnya. Pertanyaannya adalah seperti "Apa perbedaan antara tinju waktu dan Scrum?".

Anda akan mendengar DevOps disebut 'budaya', 'gerakan', 'metodologi', dan segala macam hal yang tidak akan cukup baik bagi Anda untuk memahaminya, meskipun deskripsi itu akurat. Singkatnya, DevOps adalah tentang pertemuan metodologi Agile, otomatisasi, dan virtualisasi yang memungkinkan loop umpan balik baru dalam manajemen / kontrol / kemudi proyek perangkat lunak.

Dengan otomatisasi yang agresif, hal-hal yang dulu memakan waktu lama dan menjadi subyek kesalahan manusia sekarang terjadi dengan cepat dan tanpa insiden. Akibatnya, kita cenderung melakukannya lebih sering. Contoh utama dari ini adalah 'deploy to production'. Kami dulu menghemat banyak pekerjaan dan menyebarkannya di luar jam kalau-kalau 'ada yang salah'. Tapi sekarang kita bisa menerapkan perubahan beberapa kali sehari, dengan cara peluang 'sesuatu yang salah' berkurang secara dramatis, dan dengan cara itu dampak sesuatu yang salah jauh lebih kecil ketika itu terjadi.

Setelah kami memiliki proses berulang ini, kami mulai melihatnya sebagai 'pipa'. Persyaratan masuk, kode yang digunakan untuk produksi keluar. Kami mengotomatiskan segala sesuatu di sepanjang jalur pipa ini - tes, dokumentasi, penggabungan, penyebaran, dan lebih banyak tes, dan seterusnya ... Karena orang-orang fokus pada otomatisasi, mereka tidak melihat 'mentalitas pipa' yang mendorongnya. Ini adalah metodologi manajemen - perhatian dibayarkan pada pipa - yang membuat DevOps lebih dari Otomasi.

Setelah kami memiliki otomasi itu, loop umpan balik masuk. Kami mulai mengukur hal-hal seperti waktu siklus sehingga kami dapat mengetahui hal-hal yang sebelumnya kami coba tebak dengan perkiraan. Hal-hal tentang arsitektur yang membuat otomatisasi / pengiriman terus-menerus sulit cenderung diganti dengan pola arsitektur alternatif yang membuat otomatisasi / pengiriman terus-menerus lebih mudah (beberapa contoh besar dari ini didokumentasikan dalam buku 'Basis Data Evolusi'. 'Penyebaran Hijau / Biru' adalah hal lain. ).

Perhatikan bahwa saya dapat memberikan deskripsi ini tanpa membicarakan tentang Jenkins, Check, Puppet, Ansible, Vagrant, AWS, atau alat lainnya yang mendukungnya. Inilah yang kami maksud dengan kata kunci tingkat lebih besar seperti 'metodologi'. Pada akhirnya, setiap set alat dapat diganti ... Yang tersisa adalah prinsip manajemen inti yang diaktifkan oleh otomatisasi dan fokus pada pipa.

DevOps benar-benar merupakan perubahan budaya - ini dimaksudkan untuk meruntuhkan penghalang tradisional antara operasi dan pengembangan (dan juga dengan QA dan bisnis lainnya!). Idenya adalah bahwa daripada memiliki 'silo' departemen Anda dapat bekerja secara langsung dengan tim lain untuk menyelesaikan sesuatu lebih cepat dan lebih efisien.

Ini semua tentang menghilangkan kendala dan merampingkan proses. Otomasi menjadi sangat berat karena proses berulang yang membantu menghilangkan kendala. Sebagai contoh: jika seseorang dari ops harus melakukan proses rilis manual untuk mendapatkan kode ke lingkungan, ada beberapa hal yang dapat menghalangi - satu adalah bahwa harus ada seseorang di ops yang bebas untuk melakukan penyebaran, dan kedua, ada kurang percaya diri dalam proses rilis karena pekerjaan manual rawan kesalahan.

DevOps mencakup otomatisasi tetapi itu hanya sebagian saja. DevOps adalah perubahan budaya untuk memecah silo antara berbagai bagian organisasi untuk memberikan aliran nilai yang lengkap. Memberikan budaya di mana bisnis, pengembangan, jaminan kualitas, infrastruktur, keamanan, ops, dll semuanya bekerja sama untuk memberikan nilai kepada siapa yang pernah menjadi pengguna akhir. DevOps bukan alat, Anda tidak bisa membelinya, Anda harus mengubah budaya Anda.

Otomasi adalah bagian penting dari DevOps karena memungkinkan kecepatan pengiriman dengan kualitas. Otomasi untuk proses penyebaran adalah salah satu bidang yang banyak orang fokuskan terlebih dahulu karena merupakan salah satu cara terbaik untuk mendapatkan nilai dengan cepat dan memberikan pengembalian investasi yang tinggi melalui tidak hanya mengurangi waktu untuk penempatan tetapi juga menstandarisasi proses dan menghapus kesalahan.

Saya ingin menambahkan 2 sen:
1) Otomasi :
     Sesuatu yang saat ini harus kita hadapi. Ini telah menjadi lebih dari keharusan di mana cara yang lebih disukai adalah mengotomatisasi potongan, jika tidak seluruh proses. Pendekatan ini memberikan pengguna (pengembang) fleksibilitas untuk menggunakan langkah tetap bersama dengan kemampuan untuk menyesuaikan sesuai kebutuhan.
     Keuntungan dalam pendekatan ini adalah kita dapat mengotomatisasi bagian yang kita inginkan sementara proses individu dapat diikat bersama oleh pengembang. Semakin rinci langkah-langkah otomatisasi, semakin baik kontrol yang mereka miliki.
     Juga, ada banyak alat untuk otomatisasi di ruang seperti otomatisasi robot, otomatisasi SOP (untuk industri servis), otomasi laporan (seperti Splunk), dll.
2) DevOps:
     Mengingat kualitas pengiriman dan ketepatan waktu yang diharapkan dari dunia saat ini, ada kebutuhan untuk memperpanjang otomatisasi proses pengiriman perangkat lunak. Untuk mengaktifkan ini dan memberikan nilai kepada pelanggan dengan cara tercepat yang mungkin, DevOps secara ekstensif bergantung pada alat otomatisasi.
     Keuntungan dalam pendekatan ini adalah bahwa, langkah-langkah individual dapat diotomatisasi untuk menghasilkan konsistensi di seluruh perusahaan sementara keseluruhan orkestrasi dapat dimodifikasi agar sesuai dengan proses yang dibutuhkan oleh proyek tersebut.
     Alat otomasi individu (dengan cara) seperti Chef untuk ditempatkan, Docker melalui Dockerfile, Maven untuk build, dll. Dapat diikat bersama mungkin melalui Jenkins untuk memberikan solusi yang diperlukan sementara pada saat yang sama menurunkan waktu yang diperlukan untuk implementasi atau penggunaan .
Semoga ini membantu menambah nilai apa pun pada proses pemikiran yang mungkin sudah Anda miliki.

Sunting: Lupa untuk menambahkan bahwa saya telah berbicara tentang Proses dan Alat - 2 dari 3 aspek di DevOps. Seperti yang disebutkan oleh yang lain, aspek ke-3 dan sama pentingnya adalah People. Salah satu perbedaan utama yang saya asumsikan antara ini dan otomatisasi adalah bahwa orang lebih rentan untuk menyerap otomasi lebih sering daripada menolak DevOps. Saya merasa bahwa ini disebabkan oleh sifat DevOps itu sendiri, karena otomasi biasanya dikaitkan dengan membuat segalanya menjadi lebih mudah bagi mereka, sementara mereka merasa bahwa DevOps mengubah cara mereka merasa nyaman.

Gerakan DevOps terdiri dari empat area utama yang disingkat CAMS :

1. Budaya
2. Otomatisasi
3. Pengukuran
4. Berbagi

Ini adalah postingan pendefinisian awal dari 2010.

Di setiap bidang ada beberapa alat, proses dan praktik yang secara umum diterima, meskipun subjek tidak didefinisikan dengan baik untuk Praktik Terbaik, dalam banyak kasus ada beberapa Praktik Baik untuk diikuti.

Otomasi dengan sendirinya adalah subjek yang sedikit lebih luas, tetapi dalam konteks DevOps itu hanya sebagian dari apa yang dibahas. Catat bahwa kita memimpin dengan budaya, meskipun banyak praktisi DevOps yang baru di lapangan sering mengabaikannya dengan risiko sendiri dan langsung beralih ke otomatisasi.

Otomasi dan DevOps tidak terkait. DevOps lebih seperti rekayasa gabungan di mana Pengembang situs atau layanan adalah semua Operator situs atau layanan itu. Kenapa novel ini? Dalam pengalaman saya, hal pertama yang dilakukan tim Ops ketika sesuatu yang lebih menarik daripada blip jaringan terjadi adalah memanggil tim Dev. Mengapa mereka melakukan itu? Karena semua yang dilakukan tim Ops adalah memantau dan menyimpan daftar nomor telepon pengembang untuk dihubungi.

Perhatikan saya tidak mengatakan apa pun tentang otomatisasi.

Otomasi adalah pengulangan kesuksesan. Jika saya melakukan langkah a, b dan c dan proses X selalu berhasil, maka langkah a, b dan c adalah kandidat yang baik untuk otomatisasi. Kemudian saya dapat menggunakan waktu untuk apa yang dulunya merupakan proses manual untuk melakukan hal-hal yang membuat saya lebih banyak uang. Otomasi berhasil ketika sederhana. Menyebarkan rilis baru, menjalankan tes integrasi, membuat mur pada baut, mencadangkan data, menyeimbangkan kredit vs debet, dll. Semuanya adalah kandidat yang hebat untuk otomatisasi karena langkah-langkahnya diulangi baik oleh orang atau robot.

Catatan : Apa yang baru adalah bahwa Pengembang juga operator. Tidak ada grup lain. Kerja sama dalam kasus saya jarang terjadi. Jika tidak ada dalam Panduan Pemecahan Masalah (alias TSG) maka Anda dijamin akan menerima panggilan telepon. Dalam pengalaman saya, Ops adalah panggilan pertama dalam hal backhoe. Masalah antara layanan keluar dari ruang kemudi mereka.