7 Software untuk Mengurangi Ketergantungan pada Vendor Cloud dalam Project Modern

Ketergantungan pada layanan cloud memang membuat proses pengembangan aplikasi modern menjadi jauh lebih praktis. Developer tidak perlu membeli server fisik, menyiapkan jaringan dari awal, atau mengelola seluruh perangkat keras sendiri. Cukup memilih layanan dari AWS, Google Cloud, Azure, atau penyedia lainnya, lalu infrastruktur bisa langsung digunakan.

Namun, kemudahan tersebut juga membawa tantangan yang sering disebut sebagai cloud vendor lock-in. Kondisi ini terjadi ketika sebuah aplikasi terlalu bergantung pada layanan, API, format data, atau teknologi proprietary milik satu penyedia cloud sehingga proses memindahkan aplikasi ke penyedia lain menjadi mahal, rumit, dan membutuhkan banyak perubahan.

Masalahnya bukan berarti menggunakan AWS, Google Cloud, Azure, atau cloud provider lain merupakan sesuatu yang salah. Justru layanan managed cloud dapat memberikan banyak keuntungan. Persoalannya adalah ketika arsitektur aplikasi dibangun sedemikian rupa sehingga tim kehilangan fleksibilitas untuk berpindah platform apabila harga berubah, kebutuhan infrastruktur meningkat, terjadi gangguan layanan, atau strategi perusahaan berubah.

Karena itu, project modern dapat memanfaatkan sejumlah software open-source dan self-hosted untuk menjaga komponen penting aplikasi tetap portabel. Beberapa contohnya adalah Kubernetes untuk orkestrasi container, Terraform atau OpenTofu untuk Infrastructure as Code, Dapr untuk abstraksi layanan aplikasi, MinIO untuk object storage, PostgreSQL untuk database, Apache Kafka untuk event streaming, serta Prometheus dan Grafana untuk observability.

Perlu dipahami bahwa software-software tersebut tidak otomatis menghilangkan vendor lock-in. Portabilitas tetap bergantung pada bagaimana aplikasi dirancang, layanan cloud yang digunakan, format data, konfigurasi jaringan, hingga kemampuan tim mengoperasikan infrastrukturnya sendiri.

Mengapa Vendor Cloud Lock-in Menjadi Masalah?

Vendor lock-in tidak hanya terjadi ketika aplikasi menggunakan satu produk cloud. Lock-in dapat muncul pada beberapa lapisan sekaligus.

Contohnya, sebuah aplikasi mungkin berjalan di container sehingga relatif mudah dipindahkan. Namun database-nya menggunakan layanan proprietary yang hanya tersedia pada satu cloud. Object storage mungkin menggunakan API khusus. Sistem messaging juga memakai layanan proprietary. Monitoring kemudian terhubung sangat dalam dengan layanan observability vendor.

Akibatnya, meskipun container aplikasinya portable, keseluruhan sistem belum tentu portable.

Apa yang Dimaksud Cloud Vendor Lock-in?

Cloud vendor lock-in adalah kondisi ketika perpindahan dari satu penyedia cloud ke penyedia lain membutuhkan biaya, waktu, perubahan kode, migrasi data, atau perubahan arsitektur yang signifikan.

Beberapa penyebab umumnya adalah:

• Menggunakan API proprietary.
• Menggunakan database dengan format atau fitur khusus vendor.
• Menggunakan layanan messaging yang hanya tersedia pada provider tertentu.
• Menyimpan terlalu banyak konfigurasi pada layanan cloud tertentu.
• Menggunakan sistem monitoring yang terintegrasi sangat dalam dengan cloud provider.
• Tidak memiliki salinan data dalam format yang mudah dipindahkan.
• Infrastruktur hanya dapat direproduksi menggunakan tool milik satu vendor.

Karena itu, pendekatan yang lebih realistis bukan menghilangkan seluruh layanan cloud, melainkan mengurangi bagian-bagian arsitektur yang terlalu bergantung pada vendor tertentu.

1. Kubernetes: Membuat Workload Container Lebih Portabel

Kategori: Kontainerisasi dan Orkestrasi

Kubernetes merupakan salah satu fondasi penting dalam arsitektur cloud-native modern. Kubernetes digunakan untuk mengelola workload berbasis container, termasuk deployment, scaling, networking, service discovery, dan berbagai kebutuhan operasional lainnya.

Container sendiri membantu mengurangi ketergantungan terhadap lingkungan tempat aplikasi dijalankan. Dokumentasi resmi Kubernetes menjelaskan bahwa container mengemas aplikasi bersama dependency yang dibutuhkan dan memisahkannya dari infrastruktur host. Hal ini membuat workload lebih konsisten ketika dijalankan pada lingkungan berbeda.

Bagaimana Kubernetes Mengurangi Lock-in?

Misalnya sebuah aplikasi dikemas menjadi container image. Container tersebut kemudian dijalankan pada Kubernetes.

Cluster Kubernetes dapat berada di:

• AWS.
• Google Cloud.
• Microsoft Azure.
• Data center perusahaan.
• Bare metal.
• Private cloud.
• Infrastruktur hybrid.

Dengan pendekatan ini, developer tidak perlu menulis ulang aplikasi hanya karena server berpindah lokasi.

Contohnya, aplikasi yang awalnya berjalan pada Kubernetes di AWS dapat dipindahkan ke cluster Kubernetes di Azure. Manifest Kubernetes seperti Deployment, Service, ConfigMap, dan Secret pada dasarnya tetap menggunakan model yang sama.

Namun, Kubernetes bukan jaminan bebas lock-in. Jika aplikasi menggunakan AWS-specific service seperti layanan database, load balancer, IAM, atau storage tertentu secara langsung, sebagian ketergantungan tersebut tetap ada.

Kapan Kubernetes Cocok Digunakan?

Kubernetes cocok untuk organisasi yang:

• Memiliki banyak microservices.
• Membutuhkan scaling otomatis.
• Menjalankan aplikasi dalam container.
• Memerlukan deployment konsisten.
• Menggunakan hybrid cloud atau multi-cloud.
• Ingin memiliki opsi menjalankan workload di cloud maupun on-premises.

Untuk aplikasi kecil, Kubernetes terkadang justru terlalu kompleks. Menjalankan dan mengamankan cluster membutuhkan kemampuan operasional yang cukup tinggi.

2. Terraform atau OpenTofu: Infrastruktur yang Bisa Direproduksi

Kategori: Infrastructure as Code atau IaC

Terraform dan OpenTofu berada pada kategori Infrastructure as Code.

Infrastructure as Code berarti infrastruktur tidak lagi dibuat hanya melalui klik pada dashboard cloud. Infrastruktur didefinisikan melalui file konfigurasi yang dapat disimpan di Git, direview, diuji, dan digunakan kembali.

Terraform secara resmi dijelaskan sebagai tool Infrastructure as Code yang memungkinkan resource infrastruktur didefinisikan menggunakan konfigurasi yang mudah dibaca manusia. Terraform juga mendukung pengelolaan infrastruktur pada beberapa cloud provider.

OpenTofu memiliki konsep serupa dan berada di bawah stewardship Linux Foundation. Dokumentasi OpenTofu menjelaskan bahwa tool ini dapat mengelola resource cloud maupun on-premises menggunakan konfigurasi yang dapat digunakan ulang dan dibagikan.

Mengapa IaC Mengurangi Vendor Lock-in?

Bayangkan sebuah tim membuat 50 server, network, firewall, database, dan resource lainnya secara manual melalui dashboard.

Ketika ingin pindah cloud, seluruh infrastruktur harus dibuat ulang.

Dengan IaC, definisi infrastrukturnya tersimpan sebagai kode.

OpenTofu maupun Terraform menggunakan konsep provider untuk berinteraksi dengan cloud provider, SaaS, dan API lainnya.

Artinya, satu workflow dapat digunakan untuk mengelola berbagai jenis platform.

OpenTofu juga memiliki registry provider yang mencakup berbagai platform dan service.

Terraform atau OpenTofu?

Keduanya memiliki konsep yang sangat mirip, tetapi ada perbedaan ekosistem dan arah pengembangan.

Terraform merupakan produk HashiCorp, sedangkan OpenTofu merupakan proyek open-source yang berada di bawah Linux Foundation. Untuk organisasi yang memprioritaskan ekosistem Terraform, Terraform masih menjadi pilihan yang relevan. Sementara itu, OpenTofu dapat menjadi alternatif bagi tim yang menginginkan proyek IaC open-source dengan governance komunitas.

Yang paling penting adalah jangan menganggap konfigurasi multi-cloud otomatis berarti bebas lock-in. Resource-specific seperti AWS Lambda, Google Cloud-specific services, atau Azure-specific networking tetap dapat membuat konfigurasi bergantung pada provider tertentu.

3. Dapr: Mengabstraksikan Komponen Aplikasi Terdistribusi

Kategori: Cloud-Native Application Architecture

Dapr atau Distributed Application Runtime dirancang untuk membantu developer membangun aplikasi terdistribusi dan microservices.

Dapr menyediakan berbagai building block seperti state management, pub/sub, secret store, service invocation, bindings, dan komponen lainnya. Dokumentasi resminya menunjukkan bahwa komponen Dapr dapat dikonfigurasi menggunakan component definition dan memiliki implementasi backend yang dapat diganti.

Bagaimana Dapr Mengurangi Ketergantungan Cloud?

Misalnya aplikasi membutuhkan state store.

Tanpa abstraksi, developer mungkin langsung menggunakan SDK tertentu:

Aplikasi -> AWS SDK -> DynamoDB

Jika suatu hari backend diganti, kode aplikasi mungkin harus diubah.

Dengan Dapr, arsitekturnya dapat dibuat lebih abstrak:

Aplikasi -> Dapr API -> State Store

Backend state store kemudian ditentukan melalui konfigurasi.

Dokumentasi Dapr menjelaskan bahwa state store dapat menggunakan berbagai database dan dikonfigurasi sebagai component.

Hal serupa berlaku untuk secret management. Dapr menyediakan abstraction layer untuk secret store dan mendukung berbagai backend melalui component.

Contoh Penggunaan

Aplikasi dapat menggunakan Dapr untuk mengakses:

• Redis.
• Database tertentu.
• Message broker.
• Secret store.
• Pub/sub system.
• Service-to-service communication.

Pendekatan ini membuat kode aplikasi tidak perlu mengetahui seluruh detail backend.

Namun ada catatan penting: Dapr tidak membuat semua backend identik. Setiap database atau message broker tetap mempunyai kemampuan dan batasan yang berbeda. Abstraksi paling efektif jika aplikasi hanya menggunakan fitur yang memang tersedia secara portable.

4. MinIO: Alternatif Object Storage Berbasis S3 API

Kategori: Object Storage

MinIO digunakan untuk menyediakan object storage yang kompatibel dengan API Amazon S3.

Object storage biasanya digunakan untuk menyimpan:

• Gambar.
• Video.
• Backup.
• Dokumen.
• File hasil upload.
• Dataset.
• Artifact aplikasi.

Masalah muncul ketika aplikasi terlalu bergantung pada implementasi storage proprietary.

Mengapa Kompatibilitas S3 Penting?

S3 API telah menjadi salah satu interface yang sangat umum digunakan dalam aplikasi cloud-native.

MinIO secara resmi menyatakan bahwa kompatibilitas S3 merupakan bagian utama dari desainnya dan memungkinkan aplikasi menggunakan storage pada berbagai hardware, lokasi, dan cloud.

Dengan begitu, aplikasi dapat menggunakan pola:

Application
     |
     v
S3-compatible API
     |
     +---- MinIO
     +---- Amazon S3
     +---- S3-compatible storage lainnya

Dari sisi aplikasi, penggunaan API yang kompatibel dapat mengurangi perubahan kode ketika backend storage diganti.

MinIO Cocok untuk Siapa?

MinIO menarik untuk organisasi yang membutuhkan:

• Object storage on-premises.
• Private cloud.
• Storage pada Kubernetes.
• Hybrid cloud.
• Backup dan archive.
• Storage untuk workload AI dan data engineering.

Tetapi kompatibilitas API bukan berarti seluruh fitur identik. Perbedaan IAM, lifecycle, replication, encryption, networking, dan fitur proprietary tetap perlu diperiksa sebelum migrasi.

5. PostgreSQL atau CockroachDB: Menghindari Database Proprietary

Kategori: Database Relasional

Database merupakan salah satu bagian paling sensitif ketika membicarakan cloud lock-in.

Memindahkan compute relatif mudah. Memindahkan data dalam jumlah besar dengan skema kompleks jauh lebih sulit.

Karena itu, pemilihan database sejak awal sangat berpengaruh terhadap portabilitas aplikasi.

PostgreSQL sebagai Database Universal

PostgreSQL merupakan database relational open-source yang menggunakan dan memperluas SQL.

Dokumentasi resmi PostgreSQL menyebutkan bahwa PostgreSQL merupakan object-relational database system open-source yang dirancang untuk menyimpan dan menskalakan workload data yang kompleks. PostgreSQL juga berjalan pada berbagai sistem operasi dan memiliki banyak fitur untuk data integrity, concurrency, indexing, JSON, replication, backup, dan sebagainya.

Inilah alasan PostgreSQL sering menjadi pilihan menarik untuk aplikasi yang ingin menjaga fleksibilitas deployment.

PostgreSQL dapat dijalankan:

• On-premises.
• Virtual machine.
• Kubernetes.
• AWS.
• Azure.
• Google Cloud.
• Private cloud.
• Dedicated server.

Bagaimana PostgreSQL Mengurangi Lock-in?

Daripada membangun aplikasi secara langsung menggunakan API database proprietary, aplikasi dapat menggunakan SQL dan PostgreSQL sebagai database utama.

Misalnya:

Application
     |
     v
PostgreSQL
     |
     +---- AWS
     +---- Azure
     +---- Google Cloud
     +---- On-premises

Perpindahan database tetap membutuhkan proses backup, restore, testing, dan kemungkinan penyesuaian konfigurasi. Namun pilihan database yang portable membuat jalurnya jauh lebih terbuka.

Bagaimana dengan CockroachDB?

CockroachDB dapat menjadi pilihan ketika kebutuhan aplikasi sudah mengarah pada distributed SQL dan deployment lintas region.

Namun CockroachDB bukan sekadar “PostgreSQL yang lebih scalable”. Ada perbedaan perilaku, kompatibilitas, arsitektur, dan fitur yang perlu dipahami sebelum digunakan.

Karena itu, PostgreSQL lebih cocok ketika prioritasnya adalah ekosistem SQL yang matang dan deployment luas, sedangkan distributed SQL seperti CockroachDB dapat dipertimbangkan ketika kebutuhan aplikasi memang membutuhkan karakteristik distributed database.

6. Apache Kafka: Event Streaming yang Tidak Terikat Satu Cloud

Kategori: Event Streaming dan Message Broker

Apache Kafka merupakan platform event streaming terdistribusi yang banyak digunakan untuk komunikasi asynchronous dan pemrosesan data stream.

Dokumentasi Apache Kafka menjelaskan bahwa Kafka dapat digunakan untuk publish dan subscribe event, menyimpan event secara durable, serta memproses stream ketika event terjadi maupun secara retrospektif. Kafka juga dapat berjalan pada bare metal, virtual machine, container, on-premises, maupun cloud.

Mengapa Kafka Membantu Mengurangi Lock-in?

Dalam arsitektur cloud, komunikasi antarlayanan dapat menggunakan layanan messaging proprietary.

Contohnya:

Service A -> Cloud Messaging -> Service B

Masalah muncul ketika sistem sangat bergantung pada API dan karakteristik layanan tersebut.

Kafka memberikan alternatif dengan platform event streaming yang dapat dijalankan sendiri atau menggunakan layanan managed dari berbagai provider.

Arsitekturnya dapat menjadi:

Service A
   |
   v
 Kafka
   |
   +---- Service B
   +---- Service C
   +---- Data Pipeline

Kafka bahkan dapat menjalankan cluster yang mencakup beberapa data center atau cloud region.

Apa Keuntungannya?

Dengan Kafka, organisasi dapat mempertahankan konsep event seperti:

• OrderCreated.
• PaymentCompleted.
• UserRegistered.
• ProductUpdated.
• ShipmentCreated.

Producer dan consumer berkomunikasi melalui event stream sehingga aplikasi tidak harus mengetahui implementasi backend cloud tertentu.

Namun Kafka membutuhkan kemampuan operasional yang tidak sedikit. Storage, replication, partitioning, broker management, security, monitoring, dan capacity planning harus diperhatikan.

Jadi, Kafka bukan pilihan otomatis untuk semua aplikasi. Untuk sistem sederhana, message queue managed cloud mungkin justru lebih praktis.

7. Prometheus dan Grafana: Observability yang Bisa Dibawa ke Mana Saja

Kategori: Observability dan Monitoring

Prometheus dan Grafana sering digunakan bersama sebagai bagian dari observability stack.

Prometheus berfungsi mengumpulkan dan menyimpan metrics time-series yang digunakan untuk monitoring dan alerting. Dokumentasi Grafana menyebutkan Prometheus sebagai open-source monitoring system dan time-series database.

Sementara itu, Grafana digunakan untuk query, visualisasi, dashboard, dan alerting dari berbagai data source. Grafana mendukung banyak sumber data, termasuk Prometheus, PostgreSQL, CloudWatch, Azure Monitor, Google Cloud Monitoring, Loki, dan lainnya.

Mengapa Ini Mengurangi Lock-in?

Bayangkan sebuah perusahaan menggunakan dashboard monitoring proprietary dari cloud provider.

Semua:

• Dashboard.
• Alert.
• Query.
• Metric.
• Notification.
• Monitoring workflow.

dibangun khusus untuk platform tersebut.

Jika pindah cloud, observability stack juga harus dibangun ulang.

Dengan Prometheus dan Grafana, perusahaan dapat mempertahankan format monitoring dan dashboard yang relatif konsisten di berbagai lingkungan.

Misalnya:

Application
     |
     v
 Prometheus
     |
     v
 Grafana
     |
     +---- AWS
     +---- Azure
     +---- Google Cloud
     +---- On-premises

Grafana juga tidak terbatas pada Prometheus. Dokumentasinya menunjukkan bahwa Grafana dapat menghubungkan berbagai data source dan menggabungkan beberapa sumber dalam dashboard.

Metrics, Logs, dan Traces Jangan Disamakan

Ada satu hal yang perlu diluruskan dari konsep observability.

Prometheus terutama berfokus pada metrics, bukan sistem penyimpanan log utama.

Untuk log, ekosistem Grafana dapat menggunakan Loki atau sumber log lainnya. Untuk traces, tersedia berbagai data source seperti Tempo dan Jaeger.

Jadi kombinasi Prometheus dan Grafana merupakan fondasi observability, tetapi belum tentu seluruh kebutuhan observability selesai hanya dengan dua software tersebut.

Bagaimana Menggabungkan 7 Software Ini dalam Satu Arsitektur?

Ketujuh software tersebut justru menjadi lebih menarik ketika digunakan sebagai bagian dari satu arsitektur.

Contohnya:

                     Internet
                         |
                    Load Balancer
                         |
                    Kubernetes
                         |
          +--------------+--------------+
          |              |              |
       Service A      Service B      Service C
          |              |              |
          +--------------+--------------+
                         |
                       Dapr
          +--------------+--------------+
          |              |              |
       PostgreSQL      Kafka          Storage
                                      |
                                    MinIO

                         |
                    Prometheus
                         |
                      Grafana

Sementara infrastrukturnya didefinisikan menggunakan Terraform atau OpenTofu.

Terraform / OpenTofu
          |
          +---- Kubernetes
          +---- Network
          +---- VM
          +---- Storage
          +---- Database
          +---- Monitoring

Arsitektur tersebut tidak berarti perusahaan sepenuhnya bebas dari cloud provider. Kubernetes tetap membutuhkan compute, network, storage, dan berbagai resource lain.

Namun lapisan aplikasi menjadi lebih terpisah dari layanan proprietary provider.

Apa yang Sebenarnya Dimaksud dengan Portabilitas?

Portabilitas sering disalahartikan sebagai kemampuan menjalankan software di mana saja tanpa perubahan.

Dalam praktiknya, portabilitas memiliki beberapa lapisan.

Portabilitas Aplikasi

Apakah kode aplikasi dapat dijalankan di lingkungan lain?

Container dan Kubernetes sangat membantu di sini.

Portabilitas Infrastruktur

Apakah infrastruktur dapat dibuat ulang di lingkungan berbeda?

Terraform atau OpenTofu membantu dengan pendekatan IaC dan provider.

Portabilitas Data

Apakah database dan object storage dapat dipindahkan?

PostgreSQL dan object storage berbasis S3 dapat membantu, tetapi migrasi data tetap membutuhkan proses teknis.

Portabilitas Integrasi

Apakah aplikasi masih menggunakan API proprietary?

Dapr dan event-driven architecture dapat membantu mengurangi ketergantungan tersebut.

Portabilitas Observability

Apakah monitoring masih dapat digunakan setelah aplikasi berpindah cloud?

Prometheus dan Grafana dapat memberikan fondasi observability yang lebih independen dari cloud provider.

Apakah Harus Menggunakan Semua Software?

Tidak.

Justru salah satu kesalahan dalam merancang sistem modern adalah menggunakan terlalu banyak teknologi hanya karena semuanya populer.

Project kecil mungkin cukup menggunakan:

Docker
+
PostgreSQL
+
Object Storage
+
Monitoring sederhana

Project yang lebih kompleks mungkin membutuhkan:

Kubernetes
+
OpenTofu
+
Dapr
+
PostgreSQL
+
Kafka
+
MinIO
+
Prometheus/Grafana

Pilihan harus berdasarkan kebutuhan.

Tujuan utama mengurangi vendor lock-in bukan mengganti semua managed service dengan self-hosted software. Tujuannya adalah menentukan bagian mana yang perlu portable dan bagian mana yang memang lebih efisien jika menggunakan layanan managed.

Strategi Mengurangi Vendor Lock-in Tanpa Membuat Infrastruktur Terlalu Rumit

Pendekatan paling realistis adalah menggunakan strategi bertahap.

1. Identifikasi Ketergantungan yang Paling Sulit Dipindahkan

Buat daftar seluruh layanan cloud yang digunakan.

Kemudian kelompokkan menjadi:

• Compute.
• Database.
• Storage.
• Networking.
• Messaging.
• Authentication.
• Monitoring.
• DNS.
• Secrets.
• CI/CD.

Tidak semuanya harus dibuat portable.

2. Prioritaskan Data

Data biasanya merupakan bagian paling mahal untuk dipindahkan.

Pastikan database memiliki:

• Backup reguler.
• Export yang dapat dipulihkan.
• Dokumentasi schema.
• Prosedur restore.
• Disaster recovery plan.

3. Gunakan API Standar Jika Memungkinkan

S3-compatible storage adalah contoh pendekatan ini.

Database SQL juga merupakan contoh penggunaan interface yang relatif umum.

Untuk messaging, event contract yang jelas juga membantu.

4. Hindari Memasukkan Vendor SDK ke Seluruh Kode

Jika seluruh aplikasi langsung bergantung pada SDK cloud tertentu, migrasi akan menjadi lebih sulit.

Gunakan abstraction layer ketika memang diperlukan.

Dapr dapat digunakan untuk beberapa kebutuhan seperti state, pub/sub, dan secret store. Namun abstraction harus tetap digunakan secara proporsional.

5. Uji Portabilitas Secara Berkala

Portabilitas tidak cukup ditulis di dokumentasi.

Sesekali lakukan pengujian:

Bisakah aplikasi benar-benar dijalankan di lingkungan kedua?

Jika jawabannya tidak, berarti portability tersebut masih bersifat teoritis.

Perbandingan 7 Software untuk Mengurangi Vendor Cloud Lock-in

Software	Kategori	Fungsi Utama	Bagian yang Dibuat Lebih Portable	Tingkat Kompleksitas	Cocok Untuk
Kubernetes	Container & Orchestration	Menjalankan dan mengelola container	Application workload & deployment	Tinggi	Microservices, hybrid cloud, enterprise
Terraform / OpenTofu	Infrastructure as Code	Mendefinisikan dan mengelola infrastruktur	Infrastruktur & provisioning	Menengah-Tinggi	DevOps, multi-cloud, infrastructure automation
Dapr	Application Runtime	Abstraksi state, pub/sub, secrets, service communication	Backend service aplikasi	Menengah	Microservices & distributed application
MinIO	Object Storage	Menyediakan storage berbasis object	File, backup, dataset, object storage	Menengah	Private cloud, Kubernetes, hybrid cloud
PostgreSQL	Relational Database	Menyimpan dan mengelola data SQL	Database dan data layer	Menengah	Hampir semua aplikasi berbasis relational data
Apache Kafka	Event Streaming	Messaging dan pemrosesan event stream	Event-driven communication	Tinggi	Data platform, microservices, streaming
Prometheus + Grafana	Observability	Metrics, dashboard dan monitoring	Monitoring & visualization	Menengah	Cloud, on-premises, Kubernetes

Jika dilihat berdasarkan lapisan arsitektur, masing-masing memiliki peran yang berbeda. Kubernetes menangani workload, Terraform atau OpenTofu mengelola infrastrukturnya, Dapr membantu mengabstraksikan layanan aplikasi, PostgreSQL menangani data relasional, MinIO menangani object storage, Kafka menangani event streaming, sedangkan Prometheus dan Grafana menangani observability.

Tidak ada satu software yang dapat menghilangkan cloud lock-in sendirian. Portabilitas adalah hasil dari desain arsitektur secara keseluruhan.

Untuk project modern, pendekatan yang cukup masuk akal adalah memilih komponen portable pada bagian yang paling kritis, terutama database, storage, event streaming, observability, dan deployment. Sementara itu, layanan managed cloud tetap dapat digunakan untuk bagian yang memberikan nilai operasional tinggi dan tidak terlalu sulit untuk diganti.

Pada akhirnya, tujuan mengurangi vendor lock-in bukan berarti harus meninggalkan cloud. Justru cloud tetap dapat dimanfaatkan secara maksimal, tetapi organisasi memiliki jalan keluar yang lebih jelas jika suatu saat perlu berpindah provider, menjalankan workload secara hybrid, menambah infrastruktur on-premises, atau mengubah strategi teknologi.

Dengan pendekatan seperti Kubernetes, Terraform atau OpenTofu, Dapr, MinIO, PostgreSQL, Apache Kafka, serta Prometheus dan Grafana, perusahaan dapat membangun fondasi yang lebih terbuka tanpa harus mengorbankan seluruh keuntungan dari cloud computing.