Budaya Antara Developer dan Operations

Budaya merupakan karakter yang berlangsung lama. Budaya yang cukup krusial dalam bidang teknologi informasi adalah penggunaan waterfall dan arsitektur monolitik. Metodologi waterfall mengakibatkan setiap proses saling tunggu menunggu sehingga terjadi inefisiensi dalam hal waktu, sedangkan arsitektur monolitik merupakan arsitektur yang membuat setiap komponen terkait satu sama lain sehingga ketika satu komponen mengalami kerusakan maka komponen lain tidak akan berjalan dengan baik. Kedua budaya tersebut biasa terjadi antara developer dan operations.

Developer adalah seorang atau sekumpulan orang yang melakukan perancangan (plan), penulisan kode (code), membangun kode (build) serta menguji kode dari perangkat lunak (test), sedangkan operations adalah seorang atau sekumpulan orang yang melakukan rilis (release), menyebarkan (deploy), melakukan operasi (operate) serta memantau infrastruktur (monitor) yang digunakan oleh perangkat lunak yang telah dibuat oleh Developer sebelumnya. Bayangkan sebuah shoes manufaktur yang memiliki developer sepatu kemudian diterapkan di plant production. Nah, orang yang menjembatani antara developer dan operation itu yang disebut DevOps.

sumber: https://www.istockphoto.com/id/foto/konsep-devops-gm1303169214-394701723

Seorang DevOps secara umum akan bergelut dengan Docker, Jenkins, dan Kubernetes. Dia bertugas untuk mengkombinasikan budaya, praktek, dan alat yang dapat meningkatkan kemampuan perusahaan untuk menyajikan perangkat lunak secara cepat. Dengan demikian ekslusifitas dari developer dan operations menjadi lebih terbuka untuk saling berkolaborasi. Ada 3 prinsip utama yang perlu dipahami oleh seorang DevOps, yaitu prinsip alur kerja, umpan balik, dan proses belajar-percobaan yang berkelanjutan.

Alur kerja yang cepat dan lancar sangat dibutuhkan dalam proses pengembangan aplikasi. Pertama perlu dilakukan penampakkan dari pekerjaan seorang Developer dan Operations. Kalau di manufaktur pekerjaan mereka tampak sedangkan seorang ahli teknologi informasi tidak terlalu tampak pekerjaannya. Caranya adalah membuat kanban board atau scrum board, yaitu semacam papan visualisasi. Kemudian dilakukan pembatasan WIP atau work in process. Proses dalam manufaktur sebaiknya dikerjakan dalam skala batch yang diperkecil atau dengan kata lain mengubah mass production menjadi single piece flow. Ilustrasinya seperti pembuatan 10 sepatu. Dalam mass production artinya 10 bahan dipotong, kemudian 10 bahan dijahit, dan 10 bahan di satukan menjadi 10 sepatu, sedangkan dalam single piece flow dibuat sepatu pertama, setelah selesai baru dibuat sepatu kedua, seterusnya hingga sepatu kesepuluh. Penerapan skala batch yang diperkecil atau single piece flow akan menghasilkan WIP lebih sedikit, lead time lebih cepat, deteksi kesalahan lebih awal, dan pengerjaan ulang lebih sedikit. Sebelum proses dijalankan akan ada handoff atau penyerahan informasi, tanggung jawab, atau pekerjaan dari satu pihak ke pihak lain. Terlalu banyak handoff juga membuat alur kerja menjadi tidak cepat dan tidak lancar, oleh sebab itu handoff juga perlu dilakukan pemangkasan.

Umpan balik secara cepat dan banyak juga dibutuhkan dari operations ke developer. Sebelumnya dalam mengelola masalah dikenal three-tier support hierarchy yaitu suatu masalah akan melewati 3 tingkatan. Dengan adanya tingkatan maka memunculkan potensi antrean, hal ini yang membuat proses menjadi inefisien. Sebagai solusinya digunakan swarming yaitu mekanisme berfokus untuk mengurangi waktu yang dibutuhkan untuk menyelesaikan masalah sekaligus berbagi pengetahuan pada tim terkait. Biasanya tim swarm terdiri atas beberapa orang dengan bidang keahlian tertentu, yaitu severity 1 swarm (3 orang ahli yang dirotasi), local dispatch swarm (bertemu 60-90 menit per hari untuk menyelesaikan masalah secara cepat), dan backlog swarm (menyelesaikan masalah yang tidak bisa diselesaikan product line support team).

Belajar dan eksperimen yang berkelanjutan menggantikan pemahaman bahwa cara untuk menguasai sesuatu adalah melalui pengulangan dan berlatih terus-menerus. Kesalahan yang terjadi dalam sebuah tim biasanya akan dianggap sebagai hal yang memalukan dan sebagai hal yang dihukum. Berbeda dengan proses yang lebih maju akan mendorong orang yang berbuat kesalahan untuk proses belajar. Dengan adanya alur kerja yang cepat dan lancar serta adanya umpan balik maka akan tercipta keberanian mengambil risiko. Menurut Dr. Ron Westrum ada 3 tipe kultur perusahaan, yaitu perusahaan patologis (rasa takut menjalar di antara pegawai seperti menahan informasi baik atau informasi buruk), perusahaan birokrasi (penuh dengan aturan dan proses berbelit), dan perusahaan generatif (mencari dan berbagi informasi). Daripada menyalahkan manusianya lebih baik fokus ke akar permasalahannya dan memikirkan bagaimana agar sistem dapat didesain ulang untuk mencegah hal yang sama terjadi lagi.

sumber: https://en.wikipedia.org/wiki/Naval_Reactors

Pada dasarnya seorang DevOps bertujuan menyatukan orang-orang untuk bekerja sama dan menghilangkan hambatan sehingga mereka dapat mencapai tujuan secara optimal. Ketika tujuan telah diketahui maka akan lebih mudah untuk menentukan cara untuk mencapai tujuan tersebut. Sejauh ini ada yang dikenal dengan kerangka kerja atau framework CALMS yaitu culture, automation, lean, measurement, dan sharing. Framework CALMS pertama kali di kemukakan oleh Jez Humble.

Pola pikir atau mindset yang baik nan tepat diperlukan untuk memelihara kultur DevOps, yaitu yang mengutamakan orang ketimbang praktek dan alat. Bahwa sebaik apapun praktek dan alat yang dimiliki tanpa ada orang yang bersatu untuk mengerjakannya maka akan sulit. Developer dan operations memiliki alat dan tujuannya sendiri-sendiri, nah menjadi penting untuk menciptakan lingkungan yang kolaboratif antara keduanya. Indikasi adanya kolaboratif adalah sikap saling percaya dan menghargai satu sama lain, serta mentransfer pengetahuan dan praktek terbaik ke seluruh tim. Tujuannya keduanya juga harus satu yaitu fokus pada kebutuhan pelanggan. Jadi permasahalan apapun yang muncul hendaknya diarahkan apakah merupakan kebutuhan pelanggan atau tidak. Pada sisi lain perlu juga diperhatikan keamanan di setiap fase dalam penerapan kultur tersebut. Kembali lagi bahwa kolaborasi dengan tujuan fokus pada kebutuhan pelanggan perlu juga memperhatikan keamanan dari developer dan operations.

Dalam pengerjaan tugas baik developer maupun operations mungkin akan menemui tugas yang sifatnya repetitif atau berulang. Padahal pekerjaan berulang tersebut bisa didelegasikan oleh sekumpulan kode yang dibuat dengan bahasa pemrograman tertentu. Dengan adanya automation maka dapat menghilangkan waktu yang digunakan untuk tugas berulang. Dengan adanya cloud computing maka dimungkinkan infrastruktur dibuat dalam bentuk kode atau biasa dikenal Infrastructure as a Code (IaaC). Intinya dalam kerangka automation adalah menghilangkan tugas yang bersifat repetitif atau berulang dengan memanfaatkan bahasa pemrograman tertentu seperti Python atau JavaScript.

Kerampingan dari proses produksi kode merupakan kegiatan untuk mencapai tujuan kebutuhan pelanggan dengan menghilangkan hal-hal yang inefisien. Maksud dari hal-hal yang inefisien adalah pemborosan. Di manufaktur dikenal dengan seven waste atau 7 pemborosan yang diakronimkan TIMWOOD, yaitu transportation, inventory, motion, waiting, over-processing, over-production, dan defect. Indikator pekerjaan yang dilakukan secara lean atau ramping adalah minimalnya WIP, pekerjaan yang transparan, eliminasi kerumitan saat transaksi kode, dan berkurangnya waktu tunggu saat berpindah dari satu fase ke fase lainnya. Aplikasi yang lean akan memindahkan arsitektur monolitic menjadi arsitektur microservice. Dengan arsitektur microservice maka aplikasi akan terpecah menjadi komponen-komponen kecil yang tidak saling berketergantungan. Ada 2 keuntungan dari arsitektur microservice, yaitu mudah untuk di maintenance atau diubah dan jika terjadi kegagalan dari satu komponen maka tidak berpengaruh pada komponen lainnya.

Dengan adanya pengukuran maka dimungkinkan perbaikan yang efektif. Namun, tidak setiap hal diukur tetapi ada hal-hal tertentu yang perlu diukur seperti waktu penulisan kode, seberapa sering bug terjadi, waktu untuk recover kegagalan sistem, banyak orang yang mengujungi aplikasi, banyak orang yang melakukan transaksi, hingga banyak orang yang tidak lagi menggunakan aplikasi. Pada prinsipnya data yang komprehensif akan memberikan keputusan yang tepat. Ingat data yang komprehensif bukan data yang banyak. Makna dari data yang komprehensif adalah setiap data yang memberikan impak signifikan dari terjadinya transaksi pengguna aplikasi. Maksud signifikan sendiri adalah ketika data tersebut memiliki pengaruh minimal 1% atau 5%. Biasanya untuk hal yang sifatnya science maka digunakan standar signifikan minimal 1% sedangkan hal yang sifatnya engineering maka digunakan standar signifikan minimal 5%.

Setelah bekerja dengan budaya, otomasi, ramping, dan terukur maka perlu dilakukan menciptakan budaya keterbukaan di dalam dan di antara tim. Sharing akan adanya masalah atau adanya penyelesain terbaru akan menciptakan kebersamaan. Dengan adanya rasa kebersamaan maka dimungkinkan berbagi tanggung jawab untuk meraih keberhasilan bersama. Pada bagian sharing ini tidak ada lagi saling menyalahkan antara satu orang dengan orang lain yang harus dikedepankan adalah compromise atau berkompromi demi aplikasi dapat berjalan. Artinya jika aplikasi tidak berjalan bukanlah salah satu orang melainkan salah dalam satu tim tersebut, sehingga satu tim tersebut harus saling bahu membahu untuk dapat menjalankan aplikasi tersebut secara cepat dan lancar. Indikator berhasilnya sharing adalah setiap orang merasa memiliki aplikasi tersebut.

sumber: https://pixabay.com/id/vectors/inovasi-kolaboratif-sains-2889557/

Tidak mudah untuk menerapkan DevOps tetapi juga tidak sulit asal ada kemauan. Seorang DevOps akan bekerja secara praktis dengan pipeline dan tools. DevOps pipeline atau biasa disebut CI/CD pipeline merupakan rangkaian proses dan tools terotomasi yang memungkinkan Developer dan Operations bekerja secara padu untuk men-deploy kode ke production environment. DevOps pipeline diterapkan dalam kerangka kerja CALMS, yaitu culture (menuntut Developer dan Operations untuk terus bekerja sama dan berkolaborasi), automation (proses handoff dibuat otomatis), lean (proses yang rumit diubah menjadi lebih ringkas), measurement (memonitor metrik infrastruktur), dan sharing (menggunakan sebuah tools dan menyelesaikan masalah secara bersama). Tahap dari DepOps pipeline adalah code, build, test, release, deploy, dan monitor.

1. Code : developer menulis kode misalnya dengan JavaScript dan setelah selesai kode tersebut di-push ke sebuah lokasi terpusat misalnya Git repository
2. Build : melakukan compile kode, periksa gaya standar kode, analisis tingkat kompleksitas pemeliharaan kode, validasi dependencies, membuat artifact seperti container image atau installer, dan menjalankan unit test
3. Test : setelah artifact terbuat maka diuji
• Functional testing : sesuai kebutuhan fungsional dari aplikasi
• Integration testing : setiap unit atau komponen aplikasi digabungkan dan diuji
• Regression testing : jika terjadi perubahan kode maka aplikasi tetap bisa berjalan
• Acceptance testing : pengujian dilakukan oleh client atau pihak luar
• Load testing : pengujian beban kerja atau traffic pada kondisi production
• Security testing : identifikasi kerentanan, kelemahan, ancaman, dan risiko keamanan
4. Release : artifact yang telah diuji kemudian dikemas dengan nomor versi
5. Deploy : artifact dengan versi kemudian di deploy dengan infrastruktur yang dibutuhkan seperti server
6. Monitor : aplikasi yang berhasil di deploy kemudian dipantau selama berjalannya

DevOps erat kaitannya dengan CI/CD yaitu continuous integration, continuous delivery (persetujuan manua), dan continuous deployment. Secara sederhana hal-hal tersebut yang dimaksud DevOps pipeline, sedangkan DevOps tools adalah penggunaan alat untuk mencapai kemudahan, konsistensi, dan prediksi. Perhatikan alat dibawah:

• Komunikasi dan kolaborasi : microsoft teams, slack, workplace, cisco webex teams, amazon chime
• Cloud computing : GCP, alibaba Cloud, AWS, Azure
• Integrated development environment : visual studio, intellij IDEA, AWS Cloud9
• Pipeline
• Code : GitHub, GitLab, BitBucket, AWS CodeCommit
• Build : Jenkins, Travis CI, CircleCI, AWS CodeBuild
• Test : AWS CodeDeploy, Gremlin, Testable, LoadRunner, UFT One
• Release : Docker Hub, JFrog Artifactory, Amazon ECR, AWS CodeArtifact
• Deploy : Heroku, Netlify, GitHub Pages, AWS CodeDeploy, AWS Elastic Beanstalk
• Monitor : Prometheus, Elastic Stack, Dynatrace, AWS X-Ray, Amazon CloudWatch
• Infrastructur as Code
• Infrastructure automation : Terraform, AWS CloudFormation
• Configuration management : Chef, Puppet, Ansible, AWS OpsWorks
• Arsitektur Microservices
• Container : Kubernetes, OpenShift, Nomad, Amazon EKS, Amazon ECS
• Serverless : Serverless, OpenFaaS, OpenWhisk, AWS Lambda
• Monitoring dan logging : promoteus, Elastic Stack, Dynatrace, AWS X-Ray, Amazon CloudWatch

Perusahaan sekelas Amazon pun pada awalnya merupakan perusahaan tradisional yang belum menerapkan DevOps, namun seiring perkembangan teknologi Amazon mulai menerapkan DevOps agar perusahaan lebih fleksibel dan mudah berkembang. Salah satu cara yang digunakan Amazon adalah membentuk two-pizza teams.

ref:

aws.amazon.com

other