DevOps – Pengembangan dan Operasi

Kembangkan dan berikan solusi

Pada hari-hari sebelumnya, solusi dikaitkan dengan mendapatkan teknologi yang tepat. Kuncinya adalah teknologi, solusinya adalah teknologi dan bisnis yang diharapkan dan dibayar untuk teknologi. Waktu telah berubah. Yah, setidaknya bagi kita yang memperhatikannya. Teknologi saat ini bukanlah masalah besar. Secara teknis, kita memiliki dunia yang tidak terlalu kompleks. Selama bertahun-tahun, kami memahami bahwa teknologi pada dasarnya adalah pengaturan pemrosesan, memori, jaringan, dan penyimpanan. Kami telah menguasai penggunaan dengan virtualisasi. Kami memahami bahwa penskalaan horizontal “lebih baik” daripada penskalaan vertikal dan bahwa kami dapat menawarkan PMNS dengan lebih mudah dalam produk konvergen dan konvergen yang juga memiliki solusi perangkat lunak. Kami telah mengotomatiskan beberapa aktivitas utama untuk memungkinkan pengurangan waktu dan biaya.

Model cloud datang dan membuat hidup lebih mudah dengan membantu kami menjadi broker layanan daripada administrator server atau insinyur jaringan. Untuk klien, kami sekarang adalah broker layanan; Yah, kita harus. Kami harus melalui siklus pembelian yang lebih pendek karena aplikasi dan layanan (solusi) dikirimkan dari katalog layanan. Meskipun hal ini berlaku untuk model penerapan cloud publik dan model pengiriman perangkat lunak sebagai layanan (SaaS), dalam hal pengadaan cloud pribadi, kami masih terjebak di masa lalu dan mengalami penundaan yang tidak perlu. Bahkan ketika semakin banyak perusahaan memperoleh layanan cloud publik, bisnis mendapatkan server, aplikasi, dan layanan “di sana” masih menantang. Semua pekerjaan yang diperlukan untuk merancang dan menghadirkan lingkungan yang dihosting cloud publik masih terperosok dalam praktik bisnis lama.

Terlepas dari semua perubahan dan pembelajaran ini, merancang dan mengimplementasikan solusi tetap merupakan pekerjaan yang sulit dan menghasilkan tumpukan dokumentasi (beberapa diperlukan, beberapa tidak berguna), bagan Gantt tanpa akhir, dan pertemuan tanpa akhir yang mencoba mendapatkan solusi di tempat dan disampaikan. mengapa demikian?

Pengembangan dan pengiriman aplikasi

Pengembang aplikasi terbiasa hidup di dunia mereka sendiri. Sampai batas tertentu ini masih benar. Perusahaan pengembangan aplikasi biasanya tidak memiliki insinyur jaringan, insinyur teknis, dan perusahaan penyimpanan kecil dan menengah yang duduk di pagi hari. Aplikasi dikembangkan secara terpisah dan terpisah dari solusi teknis yang harus dibuat untuk menampung dan mendukung aplikasi dan sumber daya.

Dalam kebanyakan kasus, aplikasi dikembangkan karena salah satu dari dua alasan. Untuk memberikan solusi kepada klien eksternal atau menawarkan aplikasi untuk bisnis yang menghasilkan uang. Misalnya, perusahaan perlu membayar gaji. Untuk melakukan ini, diperlukan sebuah aplikasi yang dapat membayar gaji, menghitung pajak dan informasi pensiun, memasukkan data ke dalam database dan kemudian mencetak tanda terima pembayaran semua sesuai dengan kerangka hukum yang ditetapkan dalam Aturan Keterlibatan Layanan Pendapatan. Perusahaan pengembang aplikasi akan memenuhi tantangan ini dan melalui serangkaian iterasi akan memberikan aplikasi yang memenuhi semua persyaratan pelanggan dan legislatif. Untuk bisnis yang ingin menghasilkan uang dari aplikasi, skenarionya sangat mirip dengan pelanggan eksternal. Perbedaannya adalah finansial karena perusahaan harus membenarkan biaya memiliki staf pengembang untuk membuat aplikasi. Biaya ini ditentukan terhadap pendapatan yang diharapkan dari penerapan akhir aplikasi sebagai layanan untuk bisnis.

Dalam kedua contoh ada konstanta yang dapat mempersulit. Dengan cara yang sama seperti solusi teknologi yang dipengaruhi oleh orang, proses, dan politik, pengembangan aplikasi dipengaruhi oleh praktik isolasi. mengapa demikian?

mengapa demikian?

Di semua TI mulai dari infrastruktur pusat data hingga aplikasi hingga cloud, satu masalah yang memengaruhi operasi perusahaan yang lancar dan koheren adalah “silo aktivitas”.

Silo selalu menjadi tanda hitam TI. Kami begitu terbiasa bekerja dalam silo sehingga kami bahkan tidak bertanya-tanya apakah pengaturan ini produktif dan hemat biaya. Faktanya, hingga saat ini, sebagian besar organisasi TI beroperasi menggunakan silo. Solusi dan pengembangan dalam isolasi.

Desain solusi dan pengembangan aplikasi melihat kedatangan Lean dan Agile sebagai cara yang sangat efisien untuk bekerja, namun silo tetap ada. Perusahaan-perusahaan itu menjalankan Agile tetapi tetap menggunakan cara silo dalam melakukan sesuatu. Aneh ketika Anda memikirkannya. Agile berarti fleksibilitas dan kemampuan untuk berubah tanpa kejutan. Silo adalah “lubang” dengan sisi tinggi yang membuat perubahan sangat sulit. Jadi, pada dasarnya, Agile dan silo bekerja sama dan membuat perubahan menjadi sulit. masih.

silo

Di bawah ini adalah contoh nyata dari lingkungan TI tradisional berbasis silo di mana aplikasi dikembangkan dan disebarkan. Prosesnya mungkin sedikit berbeda di beberapa perusahaan dan jabatan mungkin tidak sama, tetapi ini adalah pengalaman saya bekerja dengan banyak perusahaan IT besar dan dapat dikenali sebagai prosedur yang cukup umum.

Pengembang aplikasi membuat aplikasi dari sebuah konsep atau dari permintaan. Teknisi Layanan Teknis (TS) diharuskan membuat Desain Tingkat Tinggi (HLD) untuk infrastruktur aplikasi. Insinyur TS menyerahkan HLD ke insinyur proyek untuk tinjauan desain. Arsitek proyek menyerahkan HLD terakhir kembali ke TS Architect. Arsitek TS menjelaskan desain kepada pengembang aplikasi dan mencakup elemen apa pun yang berpotensi membahayakan aplikasi. Ini biasanya dilakukan secara terpisah dari ahli lain. HLD ditandatangani untuk pengadaan satu orang atau orang lain dan insinyur proyek mulai melakukan aktivitas uji tuntas sebelum membuat Desain Tingkat Rendah (LLD atau Dokumen Pembuatan) untuk infrastruktur aplikasi. Insinyur proyek harus mengunjungi beberapa ahli materi pelajaran (UKM) untuk komputasi, jaringan, penyimpanan, dan pemulihan bencana (DR) untuk mengetahui teknologi dan persyaratan apa yang harus ada dalam LLD. Detail tentang protokol, perutean, keamanan, dan aturan firewall bisa rumit dan dapat berdampak negatif pada aplikasi jika tidak direncanakan dengan hati-hati. Untuk mendapatkan hak ini, pakar analisis dampak bisnis harus dikonsultasikan untuk memastikan bahwa masalah keamanan dan kepatuhan, jika ada, dapat diatasi atau dikurangi. Sebagian besar aplikasi dikerahkan dalam infrastruktur virtual yang memerlukan partisipasi pakar virtualisasi untuk membantu penyediaan dan teknologi otomatisasi. Umumnya, seorang insinyur proyek harus berkonsultasi dengan beberapa silo/ahli teknologi. Dalam kegiatan ini, insinyur harus terus-menerus kembali ke pengembang aplikasi untuk memverifikasi bahwa apa yang direncanakan untuk infrastruktur tidak akan “merusak” desain aplikasi dan membuat aplikasi tidak efektif saat digunakan. Akhirnya, pembungkus layanan harus ditempatkan untuk mendukung aplikasi dan memenuhi persyaratan non-fungsional dalam Perjanjian Tingkat Layanan (SLA). Mungkin ada dua puluh orang yang terlibat dalam proses ini dengan mudah. Saya tidak menyertakan pengujian dan pengembangan karena ini biasanya menunggu hingga akhir proses utama bersama dengan Pengujian Penerimaan Pengguna (UAT). Terkadang ada tim terpisah yang menangani bagian ini, dan terkadang dilakukan oleh operasi. Desain aplikasi juga mencakup lapisan ketergantungan yang menyediakan lapisan middleware dan database. Lebih banyak orang mungkin perlu dilibatkan ketika layanan ini disertakan. Yang benar adalah bahwa setiap perusahaan kecil dan menengah adalah bagian dari silo. Proyek harus berkonsultasi dengan semua silo ini. Beberapa berguna, beberapa tidak dan ada banyak alasan mengapa Anda tidak harus melakukannya! Semua pertanyaan dan solusi yang diusulkan dapat dijawab.

Semua silo dan semua orang yang terlibat membuat keseluruhan proyek menjadi lambat dan mahal. Analoginya adalah permainan ular tangga.

DevOps

Meskipun contoh di atas cukup sederhana, ini adalah penilaian yang adil tentang seperti apa pengembangan aplikasi dari awal hingga akhir. Semua orang di industri tahu bahwa ini adalah situasi “normal” dan menerima bahwa itu kurang sempurna. DevOps muncul sebagai jawaban atas pendekatan silo tradisional. DevOps mencoba menghapus silo dan menggantinya dengan aktivitas kolaboratif dan inklusif perusahaan. Pengembangan aplikasi dan desain solusi memanfaatkan prinsip-prinsip DevOps.

Apa yang harus dilakukan untuk menghapus silo:

  • Ubah budaya kerja

  • Hapus dinding di antara tim (dan hapus silo)

kunci:

  • Komunikasi, kolaborasi, integrasi, dan pertukaran informasi

Mudah diucapkan dan sulit dilakukan.

Sebagian besar usaha kecil dan menengah suka menyimpan informasi mereka untuk diri mereka sendiri. Ini tidak benar untuk semua orang tetapi bagi banyak orang. Ini adalah bagian dari budaya tradisional yang telah berkembang selama bertahun-tahun. Praktek perburuhan membuat perubahan menjadi sulit. Mengelola perubahan adalah salah satu tugas tersulit yang dapat dilakukan oleh perusahaan mana pun. Perlawanan akan bersifat fleksibel karena penting bagi orang untuk merelakan sesuatu demi memperoleh sesuatu. Mengklarifikasi apa keuntungannya sangat penting. Orang akan mengubah sikap dan perilaku mereka, tetapi Anda harus memberi mereka alasan yang baik untuk melakukannya. Saya telah menemukan bahwa menjalankan lokakarya multidisiplin untuk usaha kecil dan menengah telah terbukti menjadi cara yang efektif untuk mendorong berbagi informasi dan meruntuhkan ‘dinding yang menempel’ itu.

Menjelaskan kepada Tim Apa itu DevOps dan apa yang seharusnya dicapai adalah bagian pertama dari proses pembelajaran. Yang kedua adalah apa yang harus dilakukan.

Tujuan negara yang spesifik dan terukur:

  • Menerapkan struktur organisasi yang “tetap”. Jika kita merangkul penskalaan horizontal, mengapa tidak melakukan organisasi horizontal?

  • Setiap pengembang aplikasi atau pengembang solusi adalah sebuah proyek dan tim adalah ujung ke ujung lintas disiplin ilmu

  • Implementasi pertukaran informasi dan tinjauan berkelanjutan

  • Pastikan semua orang yang mendaftar ke DevOps memahami modelnya

Apa itu DevOps?

Sama seperti model cloud, ini hanyalah cara lain untuk melakukan sesuatu. Seperti Cloud, ia memiliki definisi yang berbeda tergantung pada siapa Anda berbicara saat itu.

Wikipedia menyatakan sebagai berikut: Karena DevOps mewakili pergeseran budaya dan kolaborasi antara pengembangan dan operasi, tidak ada alat DevOps tunggal, melainkan rangkaian atau “rantai alat” yang terdiri dari beberapa alat. Secara umum, alat DevOps termasuk dalam satu atau beberapa kategori, yang mencerminkan proses pengembangan dan pengiriman perangkat lunak.

Saya tidak berpikir itu semua tentang DevOps. Kesimpulannya adalah DevOps hanya peduli dengan pengembangan aplikasi dan proses. Saya tidak percaya itu. Saya pikir DevOps adalah sebuah paradigma dan seperti Standar dan paradigma TI lainnya, DevOps relevan untuk semua TI dan bukan hanya aplikasi. Dengan menghilangkan bagian antara setiap praktik dalam rantai dan melibatkan semua pemain kunci sejak hari pertama, sebagai bagian dari tim yang inklusif dan kolaboratif, siklus pengembangan aplikasi dan desain solusi menjadi proses berkelanjutan yang tidak harus dialihkan untuk berkonsultasi setiap dibutuhkan ahli. Tidak ada yang perlu melempar dokumen ke dinding untuk kru berikutnya. Setiap dokumen ditulis dalam proses kolaborasi dan ini akan membuat dokumen lebih relevan dan kuat. Bayangkan tim proyek selalu berada di ruangan yang sama mulai dari ide hingga penerapan dan setiap pakar selalu tersedia untuk berkomentar dan menambahkan ke setiap langkah proyek ini. Betapa lebih baik daripada metode tradisional yang membutuhkan waktu berhari-hari untuk mendapatkan jawaban atas pertanyaan sederhana, atau bahkan menemukan orang yang tepat untuk menanyakannya.

Mantranya adalah: pengembangan, pengujian, penyebaran, pemantauan, umpan balik, dll. Ini tampaknya berorientasi pada aplikasi. Bahkan, ini dapat diterapkan pada pengembangan solusi TI apa pun. Seperti ITIL, TOGAF, dan model referensi tujuh lapis, model ini dapat diterapkan pada setiap dan semua aktivitas TI mulai dari pengembangan hingga layanan pendukung. DevOps menempatkan kita semua pada halaman yang sama dari awal hingga akhir.

Jangan izinkan perusahaan Anda mengimplementasikan DevOps secara terpisah dan sebagai kerangka kerja untuk pengembangan aplikasi saja. Melakukannya berarti membuat silo lain. Gunakan untuk setiap proyek dan sebagai budaya virtual untuk semua tim Anda apakah mereka pengembang, insinyur, arsitek, operasi atau bukan. Terakhir, jangan dipersulit. DevOps tidak membutuhkan definisi yang dalam dan mendalam atau percakapan yang panjang dan membosankan tentang apa itu dan bagaimana menerapkannya. lakukan.

Leave a Reply

Comment
Name*
Mail*
Website*