- Arsitektur microservices memerlukan desain layanan, data, ketahanan, dan kontrak yang cermat agar dapat berjalan dengan baik di lingkungan produksi.
- Kubernetes/OpenShift, CI/CD, dan GitOps memungkinkan otomatisasi penyebaran, penskalaan, dan operasi skala besar.
- Keamanan Zero Trust, manajemen konfigurasi yang tangguh, dan kemampuan observasi dengan OpenTelemetry adalah pilar dari platform ini.
- Pengorganisasian tim produk dan tata kelola terdistribusi sama pentingnya dengan teknologi yang dipilih.
Mengadopsi arsitektur microservices di lingkungan dunia nyata bukan hanya tentang memecah monolit menjadi bagian-bagian yang lebih kecil; ini melibatkan peninjauan ulang infrastruktur, tim, proses, data, keamanan, dan operasi . Ketika sistem berpindah dari teori ke klaster produksi, masalah muncul terkait penemuan layanan, kontrak antar tim, CI/CD, observabilitas, ketahanan, dan skalabilitas. Jika masalah-masalah ini tidak ditangani dengan benar, microservices dapat berubah menjadi kekacauan terdistribusi.
Kabar baiknya adalah saat ini kita memiliki banyak pengalaman yang terkumpul dari organisasi seperti Netflix, Amazon, Google, dan perusahaan besar lainnya yang menjalankan ratusan microservice di lingkungan produksi . Dengan memanfaatkan pelajaran-pelajaran ini, bersama dengan praktik terbaik di lingkungan perusahaan yang menggunakan Kubernetes dan OpenShift, kita dapat mengembangkan pendekatan yang sangat kuat untuk merancang, menerapkan, dan mengoperasikan microservice dalam skala besar tanpa kehilangan kendali.
Mengapa menerapkan microservices ke lingkungan produksi (dan kapan hal itu tidak bermanfaat)?
Arsitektur microservices yang dirancang dengan baik memungkinkan Anda untuk bekerja dengan tim kecil, otonom, dan lintas fungsi yang memiliki kepemilikan atas layanan ujung-ke-ujung. Setiap tim beroperasi dalam konteks yang terdefinisi dengan baik, dapat melakukan deployment secara sering, dan memikul tanggung jawab penuh atas layanannya, sehingga mengurangi waktu siklus pengembangan dan mempercepat pengiriman fitur baru.
Manfaat utama lainnya adalah penskalaan independen per layanan . Anda tidak perlu memperbesar seluruh aplikasi jika hanya katalog, proses pembayaran, atau API publik yang mengalami lonjakan lalu lintas. Anda dapat menyesuaikan setiap layanan mikro secara horizontal atau vertikal sesuai dengan pola bebannya, mengukur biaya setiap fitur secara akurat, dan mempertahankan ketersediaan bahkan jika area tertentu mengalami lonjakan konsumsi.
Cara layanan-layanan ini dikemas dan diterapkan memfasilitasi implementasi berkelanjutan dan berisiko rendah . Merilis setiap layanan mikro secara independen membuat pengujian ide-ide baru dan pengembalian versi yang bermasalah jauh lebih sederhana: penerapan canary, rollback blue/green, dan rollback otomatis mengurangi biaya kegagalan dan memberikan ruang untuk eksperimen.
Dari sudut pandang teknologi, microservices mendorong kebebasan untuk memilih bahasa, framework, dan database untuk setiap layanan. Tidak semua kebutuhan cocok dengan tumpukan teknologi yang sama: Anda mungkin memiliki layanan bisnis di .NET atau Java, pemrosesan data di Scala/Spark, layanan khusus di Python atau F#, atau microservices AI di R. Keragaman yang terkontrol ini memungkinkan Anda untuk menggunakan alat yang tepat untuk setiap kasus, tanpa memaksa seluruh aplikasi untuk mengalami pergeseran teknologi secara global.
Selain itu, memecah sistem menjadi bagian-bagian kecil yang terdefinisi dengan baik mempermudah penggunaan kembali fungsionalitas sebagai blok bangunan . Sebuah microservice yang awalnya dibuat sebagai bagian dari fungsionalitas yang lebih besar dapat digunakan kembali sebagai dependensi dari bagian lain sistem tanpa perlu menulis ulang logikanya. Dan karena layanan-layanan tersebut terisolasi, kegagalan pada salah satunya biasanya hanya mengakibatkan penurunan kinerja sistem sebagian, bukan pemadaman sistem total, asalkan ketahanan telah dirancang sejak awal.
Desain arsitektur dan layanan
Agar microservices dapat berfungsi dengan baik di lingkungan produksi, sangat penting untuk memulai dengan desain batasan dan tanggung jawab layanan yang cermat . Secara praktis, ini biasanya dimulai dengan mengidentifikasi layanan-layanan berukuran besar di dalam monolit yang ada: area fungsional besar atau domain bisnis (misalnya, pesanan, katalog, pengguna, penagihan) yang sudah memiliki pemisahan logis.
Dimulai dengan blok bangunan besar ini, prosesnya melibatkan penyempurnaan desain untuk mendapatkan layanan mikro yang sangat terperinci yang beroperasi pada kumpulan data yang koheren , memiliki modelnya sendiri, dan mengetahui persis apa yang perlu mereka baca atau tulis ke layanan lain. Proses ini biasanya bergantung pada konsep desain berbasis domain (DDD) dan konteks terbatas, mencegah layanan mikro menjadi "monolit mini".
API yang mengekspos layanan ini harus memiliki kontrak yang terdefinisi dengan baik dan stabil . Ini menyiratkan dokumentasi yang ketat (REST dengan OpenAPI, gRPC dengan file .proto, dll.), pembuatan versi yang eksplisit, mempertahankan kompatibilitas mundur jika memungkinkan, dan mengotomatiskan validasi kontrak untuk mendeteksi perubahan yang merusak sebelum mencapai produksi.
Dalam lingkungan dengan puluhan atau ratusan layanan, sangat penting untuk memasukkan pola ketahanan sejak tahap desain, sehingga sistem siap menghadapi kegagalan parsial . Pola seperti pemutus sirkuit, percobaan ulang dengan penundaan, batas waktu yang terdefinisi dengan baik, pembatas, dan tekanan balik membantu mencegah kegagalan satu layanan menyebabkan layanan lainnya ikut terhenti. Alat rekayasa kekacauan seperti ChaosMonkey atau Gremlin berguna untuk menguji secara praktis bagaimana platform berperilaku di bawah simulasi pemadaman.
Banyak sistem kompleks menggabungkan layanan CRUD yang relatif sederhana dengan layanan yang lebih canggih yang menangani aturan bisnis yang terus berkembang. Tidak semua microservice memerlukan arsitektur internal yang kompleks : beberapa dapat berupa controller HTTP sederhana dengan akses data dasar, sementara yang lain, seperti layanan pemesanan atau penagihan, dapat memanfaatkan pola yang lebih canggih (DDD, CQRS, domain event, dll.).
Infrastruktur produksi: cloud, kontainer, dan Kubernetes/OpenShift
Pengalaman di dunia nyata menunjukkan bahwa microservices berkinerja jauh lebih baik ketika diimplementasikan pada infrastruktur cloud dengan container dan orkestrasi daripada pada mesin virtual yang terisolasi. Platform seperti Kubernetes dan OpenShift menyediakan primitif yang diperlukan untuk mengemas layanan sebagai container, melakukan penskalaan, pembaruan, penyeimbangan beban, dan mengelola ketersediaan tinggi.
Biasanya, setiap microservice dikemas dalam image container berdasarkan image dasar perusahaan (misalnya, OpenJDK 21 untuk layanan Java) yang dikelola oleh tim infrastruktur. Image dasar ini selalu diperbarui dengan patch keamanan, dan ketika versi baru dirilis, tim pengembang bertanggung jawab untuk membangun kembali dan menyebarkan ulang layanan mereka di lingkungan yang sesuai.
Di Kubernetes/OpenShift, unit penyebaran dasar adalah pod, yang membungkus satu atau lebih kontainer . Biasanya, sebuah microservice sesuai dengan tipe pod dan disebarkan menggunakan sumber daya seperti Deployment (untuk layanan stateless) atau StatefulSet (ketika ada state yang terkait). Sejak awal, jumlah replika minimum per lingkungan ditentukan sehingga lingkungan pengujian, pra-produksi, dan produksi memiliki tingkat ketersediaan yang sesuai dengan tingkat kepentingannya.
Penskalaan otomatis diimplementasikan menggunakan HorizontalPodAutoscaler (HPA) , yang menyesuaikan jumlah replika berdasarkan metrik seperti CPU, memori, atau metrik khusus lainnya. Platform juga harus mengkonfigurasi aturan anti-afinitas pod untuk mendistribusikan replika layanan yang sama ke berbagai node, mencegah kegagalan satu node menyebabkan semua instance mati.
Terkait penentuan ukuran vertikal, resources.requests dan resources.limits digunakan untuk mendefinisikan rentang CPU dan memori yang dapat dikonsumsi oleh sebuah pod. Misalnya, memesan minimal 100MB CPU dan 256MB memori, dan mengizinkan hingga 500MB dan 2GB masing-masing untuk layanan Java, menyesuaikan JVM (Xms, Xmx, Xss) untuk memanfaatkan sumber daya kontainer dengan baik.
Manajemen status: layanan mikro tanpa status dan dengan status
Sebagian besar layanan mikro bisnis dirancang sebagai layanan tanpa status (stateless) . Ini berarti bahwa pod tidak menyimpan informasi yang perlu bertahan setelah reboot; status disimpan dalam basis data eksternal, antrian pesan, atau penyimpanan lainnya. Pendekatan ini memfasilitasi penskalaan horizontal dinamis dan penerapan tanpa hambatan, karena setiap replika dapat menangani setiap permintaan.
Namun, ada skenario di mana tidak ada alternatif lain selain memiliki layanan mikro stateful yang didukung oleh volume persisten . Ini terjadi pada beberapa basis data, sistem file terdistribusi, atau komponen yang memerlukan pemeliharaan data lokal. Pod ini biasanya di-deploy dengan StatefulSets, dihubungkan ke PersistentVolumes menggunakan PersistentVolumeClaims, dan diskalakan secara vertikal daripada horizontal.
Ketika sebuah microservice membutuhkan penyimpanan persisten, PersistentVolumeClaim (PVC) diminta dengan ukuran, mode akses, dan tujuan penggunaannya , dan tim operasional menyediakannya sesuai dengan kebijakan platform. PVC ini dirujuk dalam manifest deployment dan dipasang pada pod sehingga layanan dapat membaca dan menulis data secara persisten.
Meskipun model stateful mungkin diperlukan dalam kasus-kasus tertentu, rekomendasi umumnya adalah untuk menjaga agar sebanyak mungkin layanan bersifat stateless . Hal ini menyederhanakan penyebaran, penskalaan, ketahanan, dan pemulihan bencana, serta mengurangi kompleksitas operasional di lingkungan dengan banyak layanan mikro.
Desentralisasi data dan kedaulatan layanan
Dalam infrastruktur tradisional, sentralisasi basis data dan penyimpanan adalah hal yang umum untuk memaksimalkan efisiensi. Dengan arsitektur microservices, pendekatan ini bertentangan dengan otonomi tim dan dekoppeling . Jika banyak layanan berbagi skema relasional yang sama, setiap perubahan struktural dapat menghambat banyak tim dan secara tidak sengaja merusak kompatibilitas.
Oleh karena itu, praktik yang direkomendasikan adalah setiap microservice memiliki model data dan basis datanya sendiri , meskipun dalam lingkungan pengembangan basis data tersebut berjalan sebagai kontainer di dalam klaster untuk menyederhanakan penyebaran. Dalam lingkungan produksi, biasanya digunakan instance yang dikelola cloud atau server basis data dengan ketersediaan tinggi lainnya, dengan selalu menjaga batasan kepemilikan yang jelas.
Ini bukan berarti tidak ada integrasi data; ini berarti konsistensi antar layanan dikelola dengan event dan pesan asinkron , menerima konsistensi bertahap bila memungkinkan. Umumnya digunakan event bus (RabbitMQ, Azure Service Bus, Kafka, dll.) untuk menyebarkan perubahan status antar microservice, mengurangi ketergantungan yang kuat pada satu basis data.
Platform cloud memudahkan tim untuk memilih tipe basis data optimal untuk setiap layanan (relasional, dokumen, key-value, time-series, dll.), tanpa memaksakan satu teknologi tunggal. Kuncinya adalah desain mempertimbangkan kemungkinan migrasi skema dan struktur tanpa melanggar kontrak dengan layanan lain, dan keputusan data dibuat selaras dengan batasan domain dari setiap microservice.
Tata kelola terdistribusi, tim, dan organisasi
Beralih ke arsitektur microservices tanpa mengubah struktur organisasi sama saja dengan mencari masalah. Alih-alih struktur fungsional klasik yang terdiri dari jaringan, sistem, basis data, pengembangan, dan operasional , struktur berbasis tim produk lebih dianjurkan, yang menyatukan profil dari pengembangan, QA, DevOps, dan, jika diperlukan, analis bisnis atau data.
Setiap tim bertanggung jawab atas satu atau lebih layanan mikro dalam domain fungsional yang sama, menangani pengembangan dan operasi (Anda membangunnya, Anda menjalankannya) . Ini berarti tim mengelola pipeline CI/CD-nya, berkolaborasi dengan infrastruktur untuk kebutuhan spesifik, dan berpartisipasi dalam pemantauan dan respons insiden. Infrastruktur dan platform cloud berfokus pada penyediaan layanan umum dan terstandarisasi.
Untuk mencegah tata kelola terdistribusi ini berubah menjadi anarki, sangat penting untuk mendefinisikan standar yang ringan dan katalog bersama : citra dasar yang disetujui, pola penyebaran, konvensi penamaan untuk namespace dan layanan, pedoman API, templat Dockerfile dan Kustomize, dll. Pedoman ini berfungsi sebagai "pembatas" yang mengarahkan tim tanpa menghalangi kemampuan mereka untuk membuat keputusan.
Di banyak lingkungan perusahaan, namespace terpisah digunakan untuk setiap proyek atau domain , dengan setidaknya satu per lingkungan (pengembangan, pra-produksi, produksi). Sebuah proyek besar dapat mendistribusikan microservice-nya ke beberapa namespace, asalkan komunikasi internal dikonfigurasi dengan benar dan aturan keamanan dipatuhi.
CI/CD, otomatisasi, dan model GitOps
Ketika sebuah arsitektur terdiri dari puluhan atau ratusan microservice, satu-satunya cara untuk menjaga agar tetap beroperasi adalah dengan berinvestasi besar-besaran dalam otomatisasi ujung-ke-ujung . Ini termasuk pipeline CI/CD yang konsisten, definisi deployment deklaratif, pengujian otomatis, dan mekanisme rollback otomatis.
Pipeline integrasi dan pengiriman berkelanjutan (CI/D) yang umum menangani kompilasi kode, menjalankan pengujian, menganalisis kualitas dengan alat seperti SonarQube , membangun citra kontainer dari Dockerfile perusahaan, dan memperbarui manifes penyebaran. Dari sana, sistem seperti ArgoCD atau yang serupa menerapkan perubahan ke klaster menggunakan pendekatan GitOps.
Setiap repositori microservice biasanya mencakup Dockerfile standar, file konfigurasi pipeline (misalnya, ci.json) , properti untuk analisis kualitas, dan direktori deployment dengan definisi Kubernetes (Kustomize atau Helm) yang dipisahkan berdasarkan lingkungan. Webhook repositori memicu pipeline ketika terjadi peristiwa seperti penambahan tag atau permintaan penggabungan.
Pola GitOps menetapkan repositori Git sebagai sumber kebenaran untuk infrastruktur dan penyebaran . Manifest untuk Penyebaran, Layanan, ConfigMap, PVC, SealedSecret, dan sumber daya lainnya diatur versinya di sana, dan alat khusus menangani sinkronisasi status klaster dengan apa yang didefinisikan di Git. Ini memberikan kemampuan penelusuran, peninjauan permintaan tarik (pull request), dan kemampuan pengembalian (rollback) yang mudah.
Pengaturan, rahasia, dan keamanan
Dalam platform microservices yang matang, manajemen konfigurasi bergantung pada ConfigMap untuk parameter yang tidak sensitif dan Secret untuk informasi rahasia . Setiap microservice biasanya memiliki ConfigMap khusus lingkungannya sendiri, yang menyimpan properti seperti URL layanan yang bergantung, flag fungsionalitas, dan parameter penyetelan.
Rahasia (kredensial, kunci, token, sertifikat) ditangani dengan kebijakan keamanan yang ketat . Di lingkungan yang kurang kritis, mungkin dapat diterima untuk menyimpannya dalam bentuk teks biasa yang dikelola oleh tim pengembangan, tetapi di lingkungan pra-produksi dan produksi, disarankan untuk mengenkripsinya menggunakan alat seperti Sealed Secrets atau pengelola eksternal berbasis cloud tertentu.
Ketika sebuah rahasia perlu dibagikan di antara beberapa layanan (misalnya, kredensial OTEL Collector atau keystore bersama ), rahasia tersebut dapat dipusatkan dalam repositori konfigurasi per namespace. Proyek-proyek yang berbagi namespace tersebut berkoordinasi untuk memperbaruinya sesuai kebutuhan, mempertahankan kendali atas siapa yang dapat membaca atau memodifikasi sumber daya ini.
Dalam hal keamanan komunikasi, pola yang dominan adalah Zero Trust : tidak ada yang dianggap enteng hanya karena lalu lintasnya "internal." Semua panggilan antar layanan, baik internal maupun eksternal, harus diautentikasi dan diotorisasi, idealnya dengan mTLS, token JWT, atau mekanisme setara lainnya. Microservices tidak secara membabi buta mendelegasikan keamanan ke API Manager atau jaringan; mereka juga melakukan pemeriksaan sendiri.
Komunikasi antar layanan mikro, API, dan perpesanan
Dalam arsitektur microservices yang matang, lapisan komunikasi dibagi menjadi beberapa kasus. Untuk lalu lintas dari klien (browser, aplikasi seluler, pihak ketiga) ke backend, digunakan API yang dipublikasikan dan diatur oleh API Manager . API ini biasanya RESTful (sering menggunakan OpenAPI) atau, dalam beberapa kasus, gRPC yang diekspos melalui gateway.
Panggilan antar microservice yang berada di namespace yang sama, atau bahkan di beberapa namespace dalam proyek yang sama, biasanya ditangani oleh layanan Kubernetes internal dengan DNS internal . Panggilan ini melewati API Manager publik tetapi tetap mematuhi kebijakan keamanan, otentikasi, dan otorisasi. Untuk skenario ini, service mesh atau gateway internal yang menerapkan kebijakan umum dapat digunakan.
Ketika layanan mikro termasuk dalam domain fungsional atau proyek yang berbeda , komunikasi dianggap "publik" di tingkat organisasi. Dalam kasus ini, praktik umum adalah menggunakan API Manager atau bus interoperabilitas, di mana kontrak, kuota, keamanan, pembuatan versi, dan audit dikelola, mencegah keterkaitan langsung antara klaster atau namespace independen.
Terkait integrasi dengan sistem lama atau eksternal, yang mungkin tidak selalu mengekspos API modern, biasanya digunakan konektor khusus melalui bus interoperabilitas . Dengan cara ini, layanan mikro berbicara dalam bahasa yang sama (misalnya, peristiwa atau API REST internal), dan konektor menangani penerjemahan ke dan dari sistem lama, selalu dengan keamanan yang ditingkatkan.
Selain komunikasi sinkron, pengiriman pesan asinkron memainkan peran kunci . Ini digunakan untuk memisahkan proses, menyerap lonjakan beban, menyebarkan peristiwa bisnis antar layanan, dan meningkatkan ketahanan. Setiap peristiwa biasanya memiliki skema yang terdefinisi dengan baik dan terversi, dengan mekanisme pelacakan untuk mencegah kerusakan antara produsen dan konsumen seiring perkembangannya.
Observabilitas, Kolektor OTEL, dan pengoperasian
Dalam sistem yang terdiri dari banyak layanan mikro, mendiagnosis masalah tanpa kemampuan observasi yang baik hampir tidak mungkin. Itulah mengapa metrik, pencatatan terpusat, dan pelacakan terdistribusi diintegrasikan sejak tahap desain , memungkinkan pemahaman tentang apa yang terjadi baik di tingkat layanan maupun platform.
Komponen utama dari skema ini adalah OpenTelemetry Collector (OTEL Collector) , yang diimplementasikan di namespace atau secara terpusat untuk mengumpulkan metrik, log, dan jejak dari semua komponen. Microservice hanya perlu mengetahui bahwa mereka harus mengirimkan telemetri mereka ke Collector; Collector kemudian meneruskannya ke sistem observabilitas (Prometheus, Grafana, Jaeger, Elastic, dll.) tanpa layanan tersebut perlu mengetahui detailnya.
Untuk lapisan infrastruktur, kolektor dan eksportir tingkat node digunakan untuk mengumpulkan metrik CPU, memori, disk, jaringan, dan log dari pod, kemudian mengirimkannya ke Prometheus dan Elasticsearch. Alat seperti Grafana dan Kibana digunakan untuk memvisualisasikan informasi ini, membangun dasbor, dan menentukan peringatan dengan ambang batas cerdas dan runbook terkait.
Ketika suatu proyek membutuhkan pemrosesan metrik atau jejak yang sangat spesifik, proyek tersebut dapat menerapkan instance OTEL Collector sendiri di namespace-nya, asalkan memiliki persetujuan operasional dan model pemeliharaan produksi sudah jelas.
Strategi pengujian, kontrak, dan pengalaman pengembangan lokal.
Pengujian arsitektur microservices terdistribusi membutuhkan strategi pengujian yang lebih canggih daripada pengujian monolit. Pengujian unit tetap penting, tetapi pengujian kontrak (untuk API dan event), pengujian integrasi antar layanan, dan pengujian end-to-end yang mencakup alur lengkap menjadi semakin penting.
Untuk mencegah masalah kompatibilitas, teknik seperti pengujian kontrak berorientasi konsumen digunakan , di mana klien mendefinisikan ekspektasi API dan penyedia layanan memenuhinya. Setiap perubahan kontrak menjalani pengujian otomatis dalam pipeline CI, mencegah penerapan yang merusak konsumen yang diketahui.
Ketika jumlah layanan bertambah melebihi seratus, mereplikasi seluruh sistem secara lokal menjadi tidak praktis. Oleh karena itu, pengembangan bergantung pada simulasi layanan yang bergantung atau melakukan tunneling ke lingkungan jarak jauh . Pengembang biasanya hanya meluncurkan sebagian kecil layanan mikro dan mengganti sisanya dengan mock, fake, atau simulator, atau mengarahkan panggilan tertentu ke lingkungan integrasi bersama.
Pengujian ujung-ke-ujung semakin bergantung pada lingkungan sementara atau "pratinjau" yang dibuat dari cabang fitur , yang membangun lingkungan terisolasi dengan layanan yang relevan dengan fungsionalitas tersebut. Hal ini meminimalkan gesekan antar tim, mengurangi efek "berjalan di mesin saya", dan mendeteksi masalah integrasi sebelum mencapai lingkungan yang lebih mahal seperti pra-produksi.
Pola penerapan microservices di lingkungan produksi
Selain Kubernetes, terdapat beberapa pola penerapan microservices di lingkungan produksi yang patut diketahui karena pola-pola tersebut menangani berbagai skenario isolasi, biaya, dan kematangan . Salah satu pola tertua adalah beberapa instance layanan per host, di mana satu host fisik atau virtual menjalankan beberapa instance layanan yang berbeda, biasanya pada server aplikasi bersama.
Dalam pola instance layanan per-VM , setiap layanan dikemas sebagai citra VM (misalnya, AMI EC2) dan berjalan pada instance-nya sendiri. Ini menawarkan isolasi yang kuat dengan biaya konsumsi sumber daya yang lebih tinggi dan waktu startup yang lebih lambat. Alat seperti Packer atau solusi khusus penyedia cloud memudahkan pembuatan citra VM yang siap produksi.
Pola yang paling umum saat ini adalah instance layanan per kontainer , di mana setiap layanan mikro dibangun sebagai citra kontainer dan diimplementasikan pada orchestrator (Kubernetes, OpenShift, dll.). Kontainer lebih ringan daripada VM, memulai dengan sangat cepat, dan memungkinkan Anda untuk mengemas semua yang dibutuhkan untuk layanan tersebut, menyederhanakan implementasi dan memungkinkan penskalaan otomatis.
Terakhir, pendekatan serverless, seperti AWS Lambda , telah mendapatkan popularitas. Pendekatan ini mengemas fungsi-fungsi yang merespons permintaan HTTP atau peristiwa dari layanan lain (S3, DynamoDB, antrean, dll.), dengan pengguna hanya membayar sesuai dengan apa yang mereka gunakan. Pola ini sangat cocok untuk layanan mikro yang sangat kecil atau tugas berbasis peristiwa yang berumur pendek, meskipun memperkenalkan pertimbangan tambahan terkait observabilitas, cold start, dan batasan eksekusi.
Dalam praktiknya, banyak organisasi akhirnya memiliki ekosistem hibrida: bagian inti sistem berjalan di atas kontainer dan orchestrator, sementara komponen tambahan tertentu diimplementasikan sebagai fungsi serverless atau sebagai VM khusus, selalu dengan antarmuka yang jelas dan protokol yang terdefinisi dengan baik untuk mengintegrasikannya ke dalam keseluruhan sistem.
Dalam hal membawa semua ini ke tahap produksi, yang membuat perbedaan bukanlah hanya teknologi yang dipilih, tetapi juga arsitektur yang mampu mentolerir kesalahan, dapat diskalakan jika diperlukan, dapat diimplementasikan secara otomatis, dan dapat diamati . Dengan tim yang selaras dengan produk, kontrak yang dikelola dengan baik, data yang terdesentralisasi, dan platform cloud yang tangguh, microservices berubah dari sekadar janji menjadi cara yang efektif dan berkelanjutan untuk mengembangkan aplikasi kompleks selama bertahun-tahun.