Alih-alih memperkenalkan
Beberapa bulan telah berlalu sejak peluncuran layanan mikro pertama. Dan sekarang, menurut kami, adalah waktu yang tepat untuk menceritakan pengalaman yang didapat.
Perlu segera membuat reservasi tentang apa yang akan ada di artikel ini dan apa yang tidak ada di artikel. Artikel ini tidak akan menjelaskan solusi dan deskripsi arsitektural dengan alasan pengambilan keputusan ini. Kami tidak akan fokus pada tumpukan teknologi tempat kami membuat layanan mikro.
Fokus utama artikel ini adalah pada masalah global yang dihadapi tim kami selama proyek berlangsung.
Artikel ini akan menjadi yang pertama dari sekian banyak artikel. Dan tujuannya, pertama-tama, adalah untuk memperkenalkan masalah kita dalam konteks transisi ke arsitektur layanan mikro dan dengan mulus mengarah ke topik berikut, yang mengungkapkan secara rinci aspek tertentu dari transisi tersebut.
Bagaimana semua ini dimulai
Keputusan untuk beralih ke arsitektur layanan mikro dibuat sekitar satu setengah tahun yang lalu. Tantangan kami adalah mempersiapkan pertumbuhan pesat perusahaan kami. Kami harus menjadi lebih fleksibel dalam hal solusi teknis, meningkatkan kecepatan membuat perubahan dan, tentu saja, meningkatkan ketahanan sistem kami.
Setelah keputusan dibuat untuk beralih ke arsitektur layanan mikro, unit terpisah dibuat dari orang-orang yang berpengalaman dan proaktif. Faktor penentu untuk mempertimbangkan calon untuk dipindahkan ke departemen baru adalah keahlian tinggi dalam satu atau beberapa sistem informasi yang ada.
Karena tidak ada pemahaman yang jelas tentang front kerja saat itu, tim dibentuk secara spontan. Tetapi pada saat yang sama, prinsip kemandirian sudah diletakkan saat itu - pengembang, analis, dan penguji dalam tim harus memiliki prinsip mereka sendiri.
Dua jalur dipilih sekaligus sebagai strategi untuk beralih ke layanan mikro:
- kami mengeluarkan ke layanan mikro apa (seperti yang kami duga) paling mudah dilakukan;
- Kami menghadirkan layanan mikro, yang transfer ke layanan mikro memecahkan sebagian besar masalah untuk bisnis dan TI.
Cara pertama bagus karena dalam prosesnya tim akan memperoleh keahlian yang diperlukan dan mengisi tangan mereka, sehingga meningkatkan efisiensi mereka untuk pekerjaan selanjutnya. Jalur kedua adalah memberikan semacam kemenangan cepat bagi tim, menunjukkan kebenaran keputusan yang dipilih untuk beralih ke layanan mikro untuk perusahaan dan memotivasi tim untuk prestasi baru.
Tim berada di awal perjalanan. Itu adalah saat yang membahagiakan: masa depan tampak cerah dan tidak berawan, dan bagi kami sepertinya kami punya rencana.
Kesulitan pertama
Dan, tentu saja, karena kita berbicara tentang layanan mikro, kita tidak bisa tidak berbicara tentang monolit. Ini adalah sistem informasi utama kami.
Arsitektur sistem individual kami paling baik diilustrasikan oleh gambar yang diambil dari artikel oleh Stefan Tilkov "Jangan mulai dengan monolit". Seperti yang bisa kita lihat, blok fungsional dalam monolit sangat erat kaitannya satu sama lain. Ini merupakan kendala serius bagi proses pemindahan fungsionalitas terpisah ke layanan mikro.
Sebagai referensi, monolit kita berumur sekitar 13 tahun, dan basis kode monolit rata-rata adalah sekitar 1,2 juta baris.
Dengan kata lain, tim menghadapi masalah berikut berulang kali:
- proses yang sangat memakan waktu dalam menganalisis fungsionalitas yang ada;
- sering kali kurangnya pemahaman tentang apa sebenarnya yang kami hadirkan ke layanan mikro;
- kompleksitas dalam mengintegrasikan monolit dengan layanan mikro baru.
Menimbang bahwa, selain menyelesaikan masalah tersebut, tim juga perlu meningkatkan keahlian dalam stack baru dan pendekatan desain baru, pengerjaannya tidak berjalan sangat cepat.
Namun demikian, setelah beberapa bulan, tim mulai menunjukkan hasil pertama - layanan mikro pertama dengan ramah menyediakan API mereka untuk semua orang. Tim percaya pada diri mereka sendiri dan tahu pasti bahwa mereka melakukan segalanya dengan benar. Nah, banyak hal dalam hidup kita yang cukup ilusi.
Keberhasilan pertama dan kesulitan baru
Terlepas dari kesulitan pertama, tim menerima pengalaman baru dan hasil pertama. Tetapi beberapa risiko yang tidak diketahui telah muncul mencegah peluncuran layanan mikro.
- Ternyata monolit belum siap untuk bekerja dengan tumpukan baru, dan integrasi ditunda.
- - .
- , , , , .
Dua masalah pertama diselesaikan dengan cukup sederhana - dengan menulis klien terpisah untuk mengintegrasikan monolit dan layanan mikro dan menyesuaikan fungsionalitas monolit yang sesuai. Namun masalah ketiga belum sepenuhnya terselesaikan hingga saat ini.
Ketidakkonsistenan sumber daya sebagian diselesaikan melalui penjadwalan sumber daya kolaboratif. Tampaknya tim memperhitungkan semua kesalahan mereka, ada pemahaman tentang apa dan bagaimana melakukannya dengan benar, dan pada awal tahun 2020, sekitar selusin layanan mikro ditulis (beberapa ternyata bukan layanan mikro sama sekali) menunggu integrasi dan rilis ke produksi. Mereka menutupi fungsinya sebagian besar proses bisnis penting, seperti menghitung biaya dan waktu pengiriman, membawa kawasan dan kantor baru ke lokasi penjualan, mencari dan memilih barang, dll.
Kami dengan percaya diri bergerak maju, memiliki pengalaman yang solid dan telah mengisi banyak rintangan. Tampaknya kami dihadapkan pada semua jebakan, dan sekarang tinggal dengan sengaja, langkah demi langkah, untuk mengimplementasikan rencana kami.
Baik…
Karantina, eksploitasi tenaga kerja dan akhirnya sukses
Awal tahun membuat penyesuaian yang signifikan terhadap rencana kami, dan ini karena konsekuensi dari virus corona baru yang menyebar saat itu. Jelas, tidak perlu menjelaskan apa yang dipertaruhkan: semua orang sudah tahu banyak tentang topik ini.
Pecahnya pandemi dan krisis ekonomi yang menyertainya memaksa perusahaan kami untuk sedikit mempertimbangkan kembali prioritas pengembangannya. Dan sebagai hasilnya, prioritas TI berubah - tugas baru ditetapkan, dirancang untuk membuat ulang proses bisnis dalam waktu sesingkat mungkin ke realitas baru.
Perubahan tersebut juga memengaruhi rencana untuk layanan mikro. Karena realokasi sumber daya, integrasi layanan mikro dengan monolit, dan akibatnya, rilis layanan mikro itu sendiri kembali ditunda.
Di sini, akhirnya, penting untuk membahas lebih detail tentang apa yang terjadi di tim dan bagaimana perasaan tim.
Pertama, demotivasi. Karena kurangnya hasil yang solid untuk waktu yang lama, dan tidak ada layanan mikro yang sepenuhnya siap pakai dan terintegrasi dalam produksi selama hampir satu tahun, tim ini kelelahan secara moral (terhadap istilah ini, namun demikian). Efisiensi telah menurun drastis. Bukan tanpa jarang, tapi gangguan emosional yang jelas.
Kedua, karantina dan transisi lengkap ke remote control. Tentu saja, kami memiliki banyak pengalaman dalam bekerja secara jarak jauh: hampir ⅔ pengembangnya adalah pekerja jarak jauh. Tetapi setiap orang yang bekerja pada layanan mikro bekerja bersama di kantor yang sama, dan transisi ke pekerjaan jarak jauh tidak memengaruhi efektivitas tim dengan cara terbaik. Di satu sisi, fakta bahwa butuh waktu untuk restrukturisasi dan transisi ke format kerja yang baru. Di sisi lain, selama periode penurunan motivasi tim diperlukan komunikasi yang lebih personal dan saling mendukung dalam tim.
Ketiga, tim harus menunjukkan hasil. Memang, seluruh tim, terlepas dari masalah internal dan eksternal, dipahami dengan jelas: nasib selanjutnya dari seluruh perusahaan bergantung pada seberapa cepat kita dapat menekan tujuan kita ke hasil yang solid. Banyak orang di perusahaan kami siap untuk mengakui eksperimen beralih ke layanan mikro sebagai tidak tepat waktu, tidak berhasil dan membubarkan departemen.
Selama hampir dua bulan, tim bekerja 12-15 jam, seringkali tujuh hari seminggu. Dan dia mampu mencapai tujuan yang diinginkan - empat layanan mikro, bekerja penuh dan terintegrasi penuh dengan sistem monolitik, langsung berproduksi penuh.
Penting untuk dicatat bahwa kami tidak menggunakan teknik rumit apa pun untuk memotivasi tim, tidak ada cara untuk berbagi. Hanya saja, hari demi hari tim melakukan hal berikut:
- sering melakukan panggilan Skype dengan memperbarui status pekerjaan saat ini dan resolusi cepat dari masalah yang muncul;
- mempertahankan sikap positif dalam tim dengan terus menerus memeriksa status sumber daya masing-masing.
Hasil dari
Alih-alih sebuah kesimpulan, saya ingin memikirkan kesimpulan yang kami buat untuk diri kami sendiri ...
- Lintas Tim. Agar berhasil melaksanakan proyek ambisius seperti itu, harus ada tim yang berdedikasi penuh dan otonom dengan sumber daya yang cukup untuk menyelesaikan masalah apa pun. Dalam kasus kami, ini berarti bahwa tim yang membuat layanan mikro di tumpukan baru harus memiliki orang-orang dari tim pengembangan monolit. Jika kita telah memahami ini sebelumnya dan mampu mendorong ide ini sampai akhir, ini akan memungkinkan kita untuk menghindari kesalahan yang terkait dengan keahlian yang tidak mencukupi dalam proses bisnis dan ketidakkonsistenan sumber daya untuk integrasi layanan mikro dan monolit.
- . , , . . , , , , . .
- . , . .
Sekarang, setelah menyelesaikan kesalahan, kami dapat mengatakan dengan percaya diri: eksperimen, yang dimulai hampir satu setengah tahun yang lalu, dapat dianggap berhasil. Dan sekarang, dari kategori sekedar eksperimen, proyek transisi ke arsitektur layanan mikro menjadi salah satu strategi TI utama di perusahaan kami.
Di masa mendatang, kami akan kembali ke topik ini dan membahas lebih detail tentang tumpukan teknologi, solusi individual, dan banyak lagi. Kami telah mengumpulkan cukup materi dan pengalaman.