Cara mengimplementasikan proyek layanan mikro Anda (bagian 3)
Dalam seri yang terdiri dari 6 bagian tentang pengembangan aplikasi layanan mikro ini, kami memberikan konteks untuk menentukan proyek percontohan berbasis cloud yang paling sesuai dengan kebutuhan saat ini dan mempersiapkan keputusan adopsi cloud jangka panjang.
Di sini, di bagian 3: kami memberikan metode untuk mengimplementasikan proyek layanan mikro Anda sendiri.
Mengembangkan aplikasi yang sudah ada
Sekarang kita masuk lebih dalam ke cara memetakan arah perjalanan pengembangan aplikasi layanan mikro khusus dengan skala yang berbeda dan dengan gambaran tentang kemungkinan progres dari transformasi skala yang lebih kecil ke skala yang lebih besar dari aplikasi yang ada.
Meskipun membangun proyek layanan mikro tanpa aplikasi sebelumnya relevan atau penting, kami menyetujui pendekatan “utamakan monolit” saat membangun layanan mikro. Singkatnya, ini berarti Anda membangun aplikasi Anda dengan cara apa pun bisa Anda lakukan untuk memvalidasi ide terlebih dahulu. Kemudian, Anda menerapkan prinsip-prinsip dalam seri blog ini untuk menskalakan dan mengembangkan monolit awal Anda menjadi proyek layanan mikro. Tidak ada gunanya menciptakan layanan mikro dengan implementasi kaku yang tidak menawarkan nilai kembali pada bisnis.
Ada tiga bidang yang perlu Anda pahami untuk menerapkan proyek layanan mikro yang sukses — bisnis, budaya dan keahlian, serta teknologi Anda.
Memahami dan menentukan kebutuhan bisnis Anda
Mengapa Anda berpikir untuk beralih ke layanan mikro? Bagi banyak bisnis, pengembangan perangkat lunak dan praktik operasi yang lebih efisien diperlukan untuk memberikan nilai kepada bisnis lebih cepat dan memberikan pengalaman pengguna yang lebih baik.
Sebelum Anda dapat memahami dampak proyek layanan mikro pada aplikasi dan infrastruktur yang ada, Anda harus memahami bagian mana dari bisnis Anda yang bergerak terlalu lambat untuk menghasilkan hasil yang memuaskan. Dalam banyak kasus, sistem keterlibatan organisasi (SOE) menyebabkan perlambatan. Sistem ini tersedia melalui banyak saluran — web, mobile, API, dan sejenisnya. Kurangnya kecepatan adalah alasan utama untuk pindah ke arsitektur berbasis layanan mikro.
Sebelum Anda dapat mengadopsi pendekatan yang berorientasi pada layanan mikro, Anda dan pemegang kepentingan bisnis Anda harus tahu apa yang menghambat Anda untuk memasuki pasar dengan cukup cepat. Bagian aplikasi mana yang membutuhkan perbaikan dan modifikasi untuk membuatnya lebih cepat? Menjawab pertanyaan itu melibatkan bagian mana dari monolit yang ada yang harus ditargetkan untuk perkembangan layanan mikro.
Gunakan alur pengalaman atau diagram arsitektur untuk membantu tim membuat bagian monolit yang ada dengan cepat melalui anotasi gaya heat-map. Misalnya, menggunakan skala Merah-Kuning-Hijau untuk prioritas titik masalah, berikut adalah arsip aplikasi web untuk bagian etalase:
Pada titik ini, tanpa menyelesaikan semuanya dan sikap terbuka terhadap iterasi, tujuan utama penilaian adalah untuk:
Mengidentifikasi fungsi bisnis terpisah yang disediakan monolit Anda
Memahami kecepatan dan kompleksitas relatif yang diperlukan untuk mengubah fungsi bisnis tersebut
Memahami keinginan pemilik bisnis untuk melihat siklus masukan yang lebih cepat untuk fungsi bisnis tertentu tersebut
Memahami budaya dan keahlian Anda
Meskipun tidak spesifik untuk arsitektur berbasis layanan mikro, pemahaman menyeluruh tentang tim, budaya, dan keahlian organisasi sangat penting untuk transformasi digital yang sukses.
Biasanya, dalam monolit teknik, sebagian besar organisasi dibangun ke dalam silo, dengan tim berpartisipasi sesuai kebutuhan sepanjang siklus pengembangan perangkat lunak. Ini sering menciptakan batas yang ditetapkan dengan baik, dengan peran dan tanggung jawab yang membatasi di sepanjang batas tersebut.
Arsitektur layanan mikro hanya dapat berhasil ketika tim memiliki kekuatan untuk memiliki pengembangan perangkat lunak yang lengkap dan siklus hidup operasi. Membangun tim lintas fungsi yang mewakili semua peran dan tanggung jawab sangat penting dalam menerapkan arsitektur berbasis layanan mikro. Semua orang — mulai dari desain hingga pengembangan hingga operasi hingga pemilik bisnis — bekerja sama erat dan sering berada di lokasi yang sama.
Karena setiap pemangku kepentingan diwakili dalam tim melalui desain, pengembangan, dan operasi, pekerjaan dapat bergerak lebih cepat, efisien, dan dengan fokus yang jelas pada peningkatan pengalaman pengguna untuk mencapai tujuan bisnis.
Tim lintas fungsi juga mendukung pertumbuhan cepat keterampilan individu di seluruh tim. Ketika sebuah tim memiliki semua yang menjadi tanggung jawab layanan mikro, mulai dari desain hingga operasi hingga data waktu proses, tidak ada satu anggota tim yang melakukan satu tugas. Sering kali, insinyur front-end mengembangkan keterampilan administrasi basis data, sementara anggota tim yang berorientasi pada operasi mempelajari lebih lanjut tentang perbedaan dalam kerangka kerja antarmuka pengguna. Memperluas keahlian dengan cara ini membantu seluruh organisasi TI berhasil dengan layanan mikro, karena jauh lebih mudah untuk membangun tim baru dari anggota tim yang berpengetahuan luas, daripada terus-menerus mencari spesialis untuk mengisi peran yang sangat spesifik.
Memahami teknologi
Kecuali Anda mengatasi masalah bisnis dan budaya dan keahlian tim Anda, Anda tidak akan dapat menerapkan teknologi mikro layanan secara efektif dan Anda akan mempertahankan proses dan struktur yang sama.
Analisis yang tepat dari tumpukan teknologi yang ada sangat bervariasi di antara organisasi, tetapi pendekatan sederhana yang kami jelaskan membantu memastikan keberhasilan awal dan berkelanjutan dari proyek layanan mikro Anda. Memulai dari yang kecil dan mendefinisikan kesuksesan progresif berulang adalah pendekatan yang jauh lebih dapat dicapai dan bermanfaat daripada pendekatan yang mencolok dan mengubah segalanya sekaligus.
Tahap pertama memahami teknologi Anda adalah mengidentifikasi layanan besar dan mencakup banyak operasi yang ada di monolit saat ini. Mengidentifikasi layanan besar ini membantu Anda memahami kompleksitas struktur data, tingkat keterikatan antara komponen saat ini, tim yang bertanggung jawab atas layanan besar yang baru, dan sebagainya. Tinjauan yang sukses memberi Anda pemahaman yang jelas tentang batas, baik di dalam layanan tertentu maupun di seluruh layanan.
Setelah mengidentifikasi layanan besar, Anda harus membuat rencana bagaimana mengembangkan layanan besar ini menjadi layanan mikro yang lebih terperinci. Layanan mikro ini, berdasarkan pekerjaan Anda sebelumnya, semuanya harus bekerja dengan data serupa, memiliki data mereka “sendiri”, dan memahami data apa yang mereka butuhkan untuk membaca dari mana dan menulis ke layanan lain. Dari sini, Anda dapat mengidentifikasi dan menerapkan ketahanan, skalabilitas, dan ketangkasan dari tiap layanan mikro terperinci.
API dan layanan mikro adalah dua bagian dari satu keseluruhan bagian yang lebih besar. Setelah memiliki pemahaman yang lebih baik tentang layanan mikro terperinci, Anda juga akan memiliki pemahaman yang lebih baik tentang antarmuka, antarmuka mana yang berada di jalur penting, antarmuka mana yang opsional, dan antarmuka mana yang tidak lagi Anda butuhkan. Jika Anda tidak dapat memetakan antarmuka atau API yang ada ke salah satu layanan mikro besar atau terperinci, kemungkinan besar Anda dapat menghilangkannya.
Mengukur upaya layanan mikro
Upaya berat untuk memahami bisnis, memahami struktur tim, dan memahami teknologi memastikan tim Anda dan organisasi yang lebih besar siap untuk memahami keseluruhan evolusi layanan mikro dari setiap monolit tertentu - apakah itu dalam lingkup bukti konsep, ruang lingkup percontohan, atau lingkup perkembangan dalam skala besar.
Setelah semua pekerjaan analisis dan perencanaan selesai, langkah selanjutnya adalah menentukan jadwal, kecepatan pengiriman, dan hasil yang diharapkan.
Dalam posting berikutnya, kami akan mempertimbangkan pola pengembangan dan operasi yang dapat Anda terapkan dalam melakukan transformasi layanan mikro.
Apa yang harus dilakukan setelah tahap ini:
Untuk memodernisasi dan melakukan pemfaktoran ulang pada aplikasi monolitik, kunjungi progres arsitektur terperinci.
Roland Barcia (IBM Distinguished Engineer/CTO) dan Rick Osowski (Anggota Staf Teknis Senior) berkolaborasi dengan Kyle dalam posting ini.