DEV Community: Lana

Dynatrace - Application Performance Monitoring

Lana — Tue, 25 Jun 2024 06:40:24 +0000

Apa itu Application Performance Monitoring?

Sumber: dynatrace.com

Application Performance Monitoring (APM) adalah teknik dan alat untuk mengawasi, mengukur, dan memahami kinerja aplikasi. APM akan memberikan visibilitas yang penting kepada perusahaan terkait dengan cara aplikasi mereka beroperasi. Secara sederhana, APM bekerja dengan melibatkan pengumpulan data kinerja yang mencakup waktu respons, penggunaan sumber daya, dan performa transaksi, yang digunakan untuk mengidentifikasi masalah kinerja, bottleneck, atau anomali dalam aplikasi.

Tentunya dengan pemahaman yang lebih baik tentang kinerja aplikasi, perusahaan dapat merespons masalah dengan lebih cepat, menghindari downtime yang merugikan, dan meningkatkan kepuasan pengguna. Selain itu, APM juga membantu perusahaan dalam pengambilan keputusan berbasis data untuk mengoptimalkan kinerja aplikasi dan mengalokasikan sumber daya secara efisien.

Apa itu Observability?

Sumber: dynatrace.com

Observability adalah pendekatan terintegrasi untuk menyatukan data dari berbagai sumber dalam satu platform. Hal ini memberikan perusahaan visibilitas yang komprehensif dan mendalam untuk mendeteksi, mendiagnosa, dan memecahkan masalah secara efisien pada aplikasi mereka.

Data yang dikumpulkan biasanya terdiri dari beberapa komponen teknologi yang terlibat dalam operasional aplikasi. Misalnya, kinerja aplikasi, jaringan, server, database, dan infrastruktur cloud. Berikut penjelasan lebih lengkap cara observability pada komponen utama aplikasi.

Kinerja Aplikasi
Melacak kinerja aplikasi dan memahami cara pengguna berinteraksi dengan aplikasi, termasuk waktu respons, kesalahan yang terjadi, dan tindakan pengguna.

Infrastruktur
Memantau server fisik dan virtual, cloud machine, serta jaringan yang digunakan untuk mendukung aplikasi. Ini termasuk pemantauan sumber daya seperti CPU, memori, dan storage.

Jaringan
Memahami trafik jaringan, latensi, dan pemecahan masalah yang terkait dengan konektivitas dan jaringan.

Database
Mengawasi kinerja database termasuk trafik, waktu respons, dan pemecahan masalah terkait database.

Log
Mengumpulkan dan menganalisis log dari seluruh tumpukan teknologi untuk melacak aktivitas dan mendeteksi masalah atau ancaman.

Metrik
Menggunakan metrik dan pengukuran kinerja untuk memahami tren dan pola dalam seluruh sistem.

Tracing
Pelacakan transaksi end-to-end melalui seluruh infrastruktur, memungkinkan pemahaman lengkap tentang perjalanan data dan permintaan melalui sistem.

Openshift Kubernetes Distribution (OKD)

Lana — Tue, 25 Jun 2024 06:31:45 +0000

OKD adalah pendistribusian Kubernetes yang dioptimisasi untuk pengembangan aplikasi secara terus menerus dan multi-tenant deployment. OKD menambahkan tools DevOps agar pengembangan aplikasi cepat terjadi, mempermudah penggunaan dan skalabiltas serta maintenance lifecycle jangka panjang bagi tim segala ukuran. Selain itu OKD juga di-embed di Red Hat OpenShift.

Kubernetes merupakan platform open-source yang digunakan untuk melakukan manajemen workloads aplikasi yang dikontainerisasi, serta menyediakan konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem yang besar dan berkembang cepat. Service, support, dan perkakas Kubernetes tersedia secara meluas.

Kubernetes memiliki sejumlah fitur yang dapat dijabarkan sebagai berikut:

platform kontainer
platform microservices

Beberapa jenis openshift

OpenShift Dedicated
Red Hat OpenShift Dedicated adalah platform aplikasi container yang di-hosting oleh Amazon Web Services (AWS) ataupun Google Cloud Platform dan dikelola oleh Red Hat. Produk ini mempercepat pengembangan aplikasi tradisional maupun aplikasi cloud native bagi para tim developer. Dibangun di Red Hat Enterprise Linux, teknologi Docker dan Google Kubernetes, OpenShift Dedicated terkoneksi ke data center secara aman agar bisnis dapat mengimplementasikan strategi TI hybrid cloud dengan infrastruktur dan biaya yang minim.

OpenShift Online
OpenShift Online adalah sebuah Platform as a Service (PaaS) yang diperuntukkan untuk developer dan organisasi TI agar mereka dapat membangun aplikasi cloud baru secara skalabel dan aman dengan konfigurasi dan manajemen overhead yang minimal. Terlebih lagi, OpenShift Online mendukung banyak bahasa programming dan framework seperti Java, Ruby, dan PHP.

OpenShift.io
OpenShift.io adalah layanan Software as a Service (SaaS) yang menawarkan pengembangan toolchain yang telah dikonfigurasi. Dengan demikian, para pengembang dapat langsung membangun aplikasi yang dikontainerisasi tanpa perlu lagi menginstal dan mengkonfigurasi software.

GIT Workflow

Lana — Wed, 03 Jan 2024 10:23:19 +0000

Terdapat empat metode yang saya ketahui dalam penggunaan Git, beberapa diantaranya adalah sebagai berikut:

Centralized Workflow
Feature Branch Workflow
Gitflow Workflow
Forking Workflow

Ketika saya baru bergabung di perusahaan, alur kerja Git yang digunakan adalah Centralized Workflow. Selang beberapa bulan seiring bertambahnya anggota tim code conflict makin sering terjadi lalu kami mencoba Gitflow Workflow. Singkat cerita Gitflow Workflow sangat membantu mengoptimalkan alur kerja pengguna Git. Code conflict berkurang, tidak ada lagi fitur yang belum selesai terbawa ke production, dan lain sebagainya.

Sampai suatu hari terjadi lagi, mulai sering code conflict dan pekerjaan yang belum selesai malah terbawa ke production. Jelas tidak ada yang salah dengan Gitflow Workflow sekalipun ada yang mengomentari bahwa Gitflow Workflow tidak bagus, ribet dan lain-lain.

Memang perkakas Gitflow ini membungkus perintah-perintah Git dengan tujuan memudahkan pengguna untuk praktek Gitflow Workflow, sekalipun tetap saja ada yang kebingungan dengan alur penggunaanya. Memang sudah cukup banyak artikel yang membahas Gitflow Workflow sayangnya saya masih melihat beberapa tim member kesulitan mengikuti konsepnya. 😓

Singkat cerita, daripada semakin tidak produktif akhirnya saya mencoba merancang ulang alur kerja pengguna Git. Alur kerja yang saya buat mirip dengan Feature Branch Workflow. Hanya saja saya coba terangkan menggunakan bahasa saya sendiri dan memvisualisasikannya supaya lebih mudah dicerna, dicetak dan ditempel di dinding biar tidak lupa. 😎

Yang Boleh Dilakukan 👍

Motivasi dari alur kerja ini adalah:

Branch master haruslah siap dan aman di deploy kapanpun
Mengurangi gap perbedaan source code diantara branch

Penjelasan gambar diatas adalah sebagai berikut:

Ketika memulai pekerjaan, buatlah branch baru dari master branch. Tentu saja ada tata cara penamaan branch yang saya rancang juga, mungkin akan dibahas di artikel yang lain
Disebut working branch karena pekerjaan aktif ada di branch ini, dan branch ini menjadi tanggung jawab pembuatnya tidak boleh di share ke orang lain jika tidak ada kolaborasi kode bersama
Jika pekerjaan sudah selesai, maka merge working branch dengan development branch. Selanjutnya biasanya sudah di ambil alih oleh CI/CD untuk menarik kode di server development
Dan jika testing atau UAT di development environment sudah OK, selanjutnya adalah melakukan merge working branch dengan staging branch. Staging environment biasanya digunakan untuk UAT dengan stakeholder atau pengguna utama, sebelum di rilis ke production environment
Setelah UAT dengan stakholder dianggap PASS atau lolos atau telah diterima. Selanjutnya lakukan merge working branch dengan master branch. Melalui proses CI/CD kode yang kita kerjakan akan bisa digunakan oleh orang banyak

Tidak ada pull request ya 😲? lalu kapan dan bagaimana code review dilakukan? ini juga akan dibahas di artikel yang lain 😁 termasuk CI/CD yang membuat Git tagging.

Singkat cerita itulah hal yang dibolehkan. Tidak berhenti sampai disitu, untuk lebih memperjelas alur kerja pengguna Git, saya juga membuat aturan “TIDAK BOLEH”. Melalui diagram dibawah ini saya terangkan apa yang tidak boleh dilakukan.

Yang Tidak Boleh Dilakukan dan Pengecualian 👎

Inti dari diagram diatas adalah untuk menjaga agar tiap-tiap branch aman dari perubahan-perubahan yang terjadi di working branch dan development branch.

Coba teman-teman bayangkan jika development branch di merge dengan staging branch. Development branch berisi kode-kode yang belum teruji atau bahkan setengah jadi. Lalu di merge ke branch staging dimana branch staging ini digunakan untuk UAT atau 3rd party integration. Amburadul tentunya ya, apalagi klo langsung di merge ke master branch 😲

Selain itu jika diperhatikan ada Friends Working Branch, maksudnya adalah ketika kita mendapatkan tugas mengerjakan suatu fitur dan dikerjakan lebih dari satu orang maka bisa terjadi kolaborasi di working branch. Dan ini harus dengan supervisi agar gap kode antar branch tidak semakin jauh.

Sudah hampir 1.5 tahun dan alur kerja pengguna Git ini berhasil menjadi salah satu faktor stabilitas produktivitas teman-teman. 😎

Time-Series Database

Lana — Wed, 03 Jan 2024 10:17:50 +0000

Mungkin kalian yang membaca sekarang sangat akrab dengan apa yang dinamakan “ database “. tempat dimana data yang kita olah disimpan. mungkin pada zaman dulu jenis database tidak sebanyak sekarang. tentunya dampak tersebut terjadi karena sebuah kebutuhan dan inovasi terhadap teknologi database itu sendiri.

Dari pengalaman saya, database memiliki beberapa jenis seperti :

LocalStorage/indexedDB(localForage)
WebSql(watermelonDB,pouchdb,alaSql)
NoSql(redis,flux,couch,mongo)
Sql(mysql,mariadb,postgres)
LocalDB(sqlite,room,realm)
Object Storage (MinIO)

namun pada tiap jenis database memiliki ekosistemnya sendiri dan fungsi penggunaan berbeda tergantung kebutuhan kita juga. contoh ekosistem web ada namanya indexedDB, WebSQL dan LocalStorage yang dapat kita manfaatkan untuk menyimpan data di browser atau NoSql sebagai database Transcational dan Sql sebagai database Master.

pada waktu dekat ini kebetulan saya belajar mengelola data bertipe deret waktu dan cukup kesusahan dalam mengelola data tersebut. rencana memakai SQL tentu pilihan itu tidak tepat. lalu pilihan saya tertuju pada database NoSql. menurut pengalaman saya sepertinya sangat cocok karna sudah terbiasa digunakan untuk pencatatan/log system/ dan tidak memiliki stuktur tabel seperti SQL. namun dalam pencarian platform yang cocok, saya menemukan hal baru yaitu TSDB (Time-Series Database). whatttt .…??

TSDB (Time-Series Database) merupakan sebuah sistem database yang dapat mengoptimasi penyimpanan dan penyediaan data bertipe Time-Series (deret waktu) berdasarkan rangkaian waktu dan nilai terkait.

biasanya Time-Series dikaitkan dengan grafik,stastistik,log,history atau trend. Beberapa database Time-Series awalnya hanya digunakan pada aplikasi untuk optimasi secara efisien menyimpan nilai yang diukur dari peralatan sensorik (juga disebut sebagai history data), tetapi sekarang digunakan untuk mendukung berbagai aplikasi yang jauh lebih luas.

Dalam banyak kasus data Time-series akan menggunakan algoritma kompresi untuk mengelola data secara efisien. Meskipun dimungkinkan untuk menyimpan data Time-Series dalam berbagai jenis basis data.

Performa SQL vs TSDB INSERT 10,000-row batches ( Time-Series Database )

Perbedaan mencolok, database Time-Series menggunakan waktu sebagai indeksnya (pipeline times chunk). berarti proses yang dilakukan secara paraller dan realtime. tiap waktu memiliki data. bukan data memiliki waktu. dampaknya konsumsi memory akan lebih optimal tentunya.

Perbedaan RDMS vs TSDB

dengan TSDB kita bisa dengan mudah memanipulasi data dengan interval waktu yang tertata rapi

mendiagnosa data dengan berdasarkan urutan waktu jadi semakin mudah tidak perluh library pendukung lagi

database Time-Series biasanya memisahkan set karakteristik tetap, diskrit dari dinamis, nilai kontinu menjadi set poin atau ‘tag.’ Contohnya adalah penyimpanan Utilisasi CPU untuk pemantauan kinerja: karakteristik tetap akan mencakup nama ‘Utilisasi CPU’, satuan ukuran ‘%’ dan kisaran ‘0 hingga 1’; dan nilai dinamis akan menyimpan persentase pemanfaatan dan gap waktu. Pemisahan ini dimaksudkan untuk secara efisien menyimpan dan mengindeks data untuk keperluan aplikasi yang dapat mencari melalui set poin berbeda dari nilai-nilai yang diindeks waktu.

Basis data sangat bervariasi dalam fitur-fiturnya, tetapi sebagian besar akan memungkinkan fitur untuk membuat, membaca, memperbarui, dan menghapus. namun pada database time-series dapat memanipulasi pasangan nilai waktu serta poin yang terkait dengannya. Ada juga fitur tambahan seperti perhitungan, interpolasi, pemfilteran, dan analisis.

Ada beberapa pilihan lagi sebelum menggunakan jenis database ini.

yups.., memilih software yang akan menghandle.

Berikut daftar database Time-Series yang bisa kamu coba :

Cube
DalmatinerDB
Druid
eXtremeDB
InfluxDB
Informix TimeSeries
KairosDB
OpenTSDB
TimescaleDB

akhirnya saya memilih InfluxDB, alasan saya memilih InfluxDB karena pertama populer dan sudah ada komunitasnya. serta memiliki beberapa tools dan fitur yang lengkap seperti

layanan cloud
telegraf ( data kolektor )
flux query ( perintah querynya )
chronograf ( data visual kayak nyediain chart gitu lah )
kapacitor ( data prosessing )
dan influxDB client ❤.

Selain itu InfluxDB merupakan project open source jadi bisa anda coba di sistem local komputermu.

Software Development Engineer in Test / Quality Assurance

Lana — Mon, 03 Jul 2023 08:39:17 +0000

Dalam dunia yang semakin bergantung pada teknologi, aplikasi digital telah menjadi bagian tak terpisahkan dari kehidupan sehari-hari. Mulai dari aplikasi pada smartphone kita untuk tetap eksis di sosial media, sampai ke aplikasi jasa yang kita gunakan sehari-hari.

Dalam proses pengembangan sebuah produk atau aplikasi, QA Engineer bertanggung jawab untuk melakukan pengujian terhadap aplikasi yang dibuat. Hal ini dibutuhkan demi memastikan bahwa sistem yang dikembangkan sesuai dengan kebutuhan yang telah ditentukan sebelumnya sehingga menghasilkan sistem yang terjamin kualitasnya.

Seorang Software Tester Profesional akan mempelajari berbagai teknik pengujian aplikasi digital agar bisa ditemukan kesalahan yang mungkin terjadi, mengidentifikasi masalah, hingga upaya agar masalah bisa dicegah.

Meski demikian, peran QA Engineer di dalam sebuah tim seringkali kurang dianggap karena mereka terkesan tidak memiliki keahlian khusus, berbeda dengan developer atau designer. Bahkan beberapa tim justru meniadakan posisi QA Engineer dalam proses pengembangan produk atau aplikasi.
Pun seperti profesi lain seperti penulis dengan editor, akuntan, reviewer, adalah orang yang berbeda dan independen, seorang Software Tester Profesional (atau nama lainnya biasa disebut Quality Assurance, SDET) akan menawarkan perpektif yang berbeda dari pengujian yang dilakukan oleh developer, product manager, ataupun end user.

QA Engineer mempunyai beberapa tanggung jawab, yaitu:

Melakukan end to end test friendly sampai ke user,
Menguji fungsionalitas, dan
Memastikan bahwa aplikasi tahan banting atau tidak gampang eror.

Ketika bug muncul, maka hal yang perlu dilakukan oleh QA Engineer adalah melakukan reject terhadap fungsi tersebut dan mengakibatkan produk atau aplikasi tidak bisa dipindahkan ke production. Dampaknya, apa yang telah dikerjakan oleh developer atau designer seperti sia-sia.

Bagi QA Engineer yang tidak “tegaan” bisa saja bug kecil tidak dianggap dan diluluskan saja. Namun sebaliknya, bagi QA Engineer yang “tegaan”, sekecil apapun bug yang ada, maka produk atau aplikasi tersebut harus dinyatakan tidak layak untuk digunakan.

Tujuan

penguji profesional diantaranya (tidak terbatas pada ini) adalah sebagai berikut.

Menjaga Kualitas Produk yang Prima

Seorang penguji profesional akan melaksanakan berbagai macam pengujian, eksperimen, hingga simulasi untuk dapat mengidentifikasi masalah dan memperbaiki kesalahan aplikasi sebelum peluncuran ke pengguna.

Hal ini akan mengurangi risiko perangkat lunak mengalami masalah atau kegagalan yang bisa berdampak buruk pada pengguna. Tentu perusahaan tidak mau menjadi viral di dunia maya karena dikritik oleh netizen Indonesia.

Efisiensi Biaya dan Waktu Pengembangan

Dengan mengidentifikasi bugs/eror sedini mungkin, developer dapat memperbaiki masalah sebelum bugs tersebut bermutasi menjadi lebih kompleks, dan proses perbaikannya pun relatif lebih cepat karena ingatan developer masih sangat jelas akan kode yang belum lama dia buat.

Meningkatkan Keamanan

Keamanan adalah salah satu aspek kritis dalam pengembangan perangkat lunak. Software testing pun akan menguji sis kerentanan yang dapat dieksploitasi oleh penjahat siber.

Memenuhi Persyaratan dan Kepatuhan Regulasi

Dalam beberapa industri, ada persyaratan dan regulasi ketat yang harus dipenuhi oleh perusahaan. Software testing membantu memastikan bahwa perangkat lunak mematuhi standar dan persyaratan yang ditetapkan oleh badan pengatur dan pelanggan. Kepatuhan ini penting untuk menghindari denda, sanksi, dan kerugian reputasi.

Meraih Kepuasan Pelanggan

Software yang telah diuji secara menyeluruh cenderung lebih andal, efisien, dan mudah digunakan. Hal ini berarti bahwa pengguna akan memiliki pengalaman yang lebih baik saat menggunakan perangkat lunak, yang pada gilirannya akan meningkatkan kepuasan pelanggan.

Redaksional :

Fachrul Choliluddin | QA Engineer ex-Gojek, YC S21 Uni Emirate
Andria Sufy | QA Engineer at CODEX Telkom

Fundamentals of Kafka

Lana — Mon, 03 Jul 2023 07:34:43 +0000

Kafka awalnya dikembangkan di LinkedIn, dan kemudian dijadikan open-source pada awal 2011. Jay Kreps, Neha Narkhede dan Jun Rao membantu menciptakan Kafka yang kemudian meninggalkan LinkedIn untuk membangun Confluent.

Jay Kreps memilih untuk menamai perangkat lunak tersebut dengan nama penulis Franz Kafka karena itu adalah “sistem yang dioptimalkan untuk penulisan”, dan dia menyukai karya Kafka.

Franz Kafka adalah seorang novelis bahasa Jerman yang bepengaruh pada abad 20.

Kafka dilahirkan dalam keluarga kelas menengah Jerman-Yahudi di Praha, ibu kota Kerajaan Bohemia, yang saat itu merupakan bagian dari Kekaisaran Austro-Hongaria, sekarang ibu kota Republik Ceko.

Konsep Dasar Kafka

Conceptual Diagram

Apache Kafka adalah implementasi kerangka software bus menggunakan stream-processing. Apache Kafka juga merupakan proyek open-source yang dikembangkan oleh Apache Software Foundation yang ditulis menggunakan bahasa pemrograman Scala dan Java.

Perhatikan tulisan tebal diatas? yang ini “sistem yang dioptimalkan untuk penulisan”.

Kafka akan menyimpan data secara berkelanjutan dan tidak ada proses hapus data. Data yang disimpan didalam Kafka akan memiliki ID masing-masing dengan timestamp yang incremental.

Tipe data yang bisa disimpan di Kafka itu bisa teks atau binary. Tipe data teks bisa menyimpan berbagai macam format seperti JSON, CSV, dan lain sebagainya.

Kafka adalah suatu platform event streaming terdistribusi yang memungkinkan kita untuk membaca, menulis, menyimpan dan memproses suatu events (records atau messages) dari berbagai mesin.

Menurut dokumentasi resmi Kafka. Kafka bisa digunakan untuk berbagai macam hal sebagai berikut:

Messaging
Website Activity Tracking
Metrics
Log Aggregation
Stream Processing
Event Sourcing
Commit Log

Berikut Konsep dasar dari hirarki Kafka:

Producers adalah aplikasi yang mengirimkan pesan ke server Kafka. Suatu server Kafka dapat menerima pesan dari satu atau lebih producer
Clusters adalah tempat virtual dimana sekumpulan brokers dikelompokan. Server Kafka dapat memiliki satu atau lebih cluster untuk mendukung scalability, high availability dan fault-tolerant
Brokers adalah komponen pada suatu server kafka yang bertugas menerima dan memberikan pesan. Dalam suatu clusters bisa terdapat banyak brokers
Topics adalah tempat dimana pesan-pesan dikelompokan. Dalam satu brokers bisa terdapat banyak topic
Partitions adalah pembagian penyimpanan pesan dalam suatu topics. Partisi digunakan untuk meningkatkan scalability dan peformance. Dimana setiap partisi dapat di tangani oleh suatu consumers tertentu. Satu topics bisa memiliki satu atau lebih partitions
Offset adalah posisi terakhir dari suatu urutan pesan yang masuk ke dalam suatu partisi di dalam topik
Messages, Records adalah pesan atau struktur pesan yang tersimpan dalam suatu topic
Key, Value, Timestamp, biasanya didalam setiap pesan yang tersimpan di topic terdapat informasi key, value dan timestamp. Key bersifat opsional sedangkan value adalah isi dari pesan dan timestamp menunjukan waktu pesan dimasukan kedalam topik/partisi
Consumer Groups adalah sekumpulan consumer yang mengambil pesan dari suatu topik. Consumer di dalam consumer grup dipastikan akan mendapatkan pesan sesuai dengan jumlah partisinya. Misal ada 3 partisi dalam suatu topik, lalu ada 2 consumers dalam suatu consumer groups, maka 1 consumer akan mengambil pesan dari 1 partisi, dan 1 consumer lagi akan mengambil pesan dari 2 partisi. Jika jumlah consumer lebih banyak dari jumlah partisi, maka akan ada consumer yang idle atau tidak pernah mendapatkan pesan. Satu consumer group dapat memiliki satu atau lebih consumer
Consumers adalah aplikasi yang berfungsi untuk menarik data dari server Kafka pada suatu topik tertentu.
Suatu aplikasi bisa berperan sebagai producer sekaligus consumer.

Redaksional :

eBook https://www.confluent.io/resources/kafka-the-definitive-guide-v2/
https://www.confluent.io/resources
https://kafka.apache.org/quickstart
https://kafka.apache.org/documentation/#quickstart