Get best of the week

Bagaimana kami memecahkan masalah tiga monolit

Dalam strategi sebagian besar perusahaan, digitalisasi semakin disebutkan: beberapa perusahaan mencoba memperkenalkan teknologi modern (misalnya, Big Data, IoT, AI, blockchain), sementara yang lain di mana-mana mengotomatiskan proses internal mereka. Meskipun ada upaya dan investasi yang berkembang dalam implementasi sistem, banyak yang melihat hasilnya sebagai biasa-biasa saja. Idealnya, organisasi modern harus dapat dengan cepat menciptakan produk digital baru atau berintegrasi dengan layanan pihak ketiga yang populer; ambil proses di luar organisasi mereka; dapat berinteraksi secara efektif dengan mitra, sambil menjaga isolasi proses mereka. Anda juga harus dapat tidak hanya mengumpulkan data, tetapi juga dengan cepat mengakses dan mengelolanya. Namun, perusahaan yang matang sekalipun menghadapi tantangan mentransformasi dan mengelola data,dengan persaingan konstan dari prioritas bisnis. Apa yang mencegah mereka mencapai kesempurnaan? 

Pengalaman tim DTG kami dalam menciptakan produk dan layanan digital memungkinkan kami untuk menyatakan bahwa solusi untuk masalah ini terhambat oleh masalah tiga monolit: monolit aplikasi, monolit integrasi, dan monolit data . Mereka adalah hasil dari paradigma warisan arsitektur tradisional, budaya, bergantung pada data yang ada dan bekerja dalam sistem "berlapis", di mana isolasi departemen TI dan bisnis menyebabkan hilangnya data dan pengetahuan tentang mereka. Sebagai solusi untuk masalah ini, kami melihat transisi dari pengembangan tradisional dan pendekatan manajemen ke pendekatan terdistribusi, yang menyiratkan perubahan teknis dan budaya yang serius dalam organisasi.

Tetapi hal pertama yang pertama. Mari kita jelaskan secara singkat apa itu monolit yang terkenal itu, dan kemudian kita akan beralih ke solusi yang kami usulkan untuk mengatasi kesulitan yang ditimbulkan oleh monolit.


Aplikasi Monolith


Salah satu dari tiga masalah arsitektur ketika membuat solusi perusahaan adalah monolit aplikasi , yang muncul karena semakin banyak fungsi ditambahkan ke aplikasi yang ada. Selama bertahun-tahun, aplikasi berubah menjadi "monster" dengan banyak fungsi yang terjalin dan komponen yang saling tergantung, melibatkan poin negatif berikut:

  • adanya satu titik kegagalan (jika terjadi kegagalan pada salah satu modul aplikasi, seluruh aplikasi gagal dan semua karyawan yang bekerja dengan aplikasi ini berhenti bekerja);
  • kesulitan dalam memastikan kualitas yang dibutuhkan dari produk yang dikembangkan, kebutuhan untuk pengujian regresi volumetrik;
  • satu tim monolitik, yang tidak praktis untuk berkembang, karena ini tidak akan mempercepat dan memfasilitasi proses pengembangan;
  • , ; , ; 
  • ( -). , , « ». ;
  • .

Layanan Microsoft membantu mengatasi masalah yang dijelaskan. Arti dari pendekatan ini adalah aplikasi monolitik dibagi menjadi beberapa aplikasi kecil yang terdiri dari sekelompok layanan. 


Tidak seperti aplikasi monolitik, ini memberikan skalabilitas yang jauh lebih besar daripada pendekatan monolitik, karena menjadi mungkin untuk skala layanan yang sangat diperlukan, dan bukan seluruh aplikasi. Microservices memungkinkan beberapa tim dalam suatu organisasi untuk bekerja secara independen dan merilis fitur baru yang mereka inginkan.

Meskipun gagasan modularitas telah ada selama bertahun-tahun, arsitektur layanan mikro memberikan fleksibilitas yang jauh lebih besar, memungkinkan organisasi untuk merespon lebih cepat terhadap perubahan kondisi pasar.

Tetapi jangan naif percaya bahwa layanan microser akan sepenuhnya menyelamatkan lingkungan TI Anda dari kerumitan. Dengan munculnya layanan-layanan mikro, terdapat kompromi untuk meningkatkan fleksibilitas pembangunan sambil meningkatkan kompleksitas manajemen, pengembangan, dan dukungan karena desentralisasi mereka. Selain itu, tidak setiap aplikasi dalam lingkungan perusahaan cocok untuk arsitektur layanan mikro.

Integrasi Monolith


Masalah arsitektur kedua, monolith integrasi, dihubungkan dengan penggunaan bus korporat integrasi ( Enterprise Service Bus , ESB). Ini adalah pola arsitektur dengan lapisan interaksi tunggal perusahaan-lebar yang menyediakan pesan yang berorientasi pada acara yang terpusat dan terpadu. 


Dalam pendekatan tradisional ini, integrasi dipandang sebagai lapisan perantara antara lapisan sumber data dan konsumen mereka. ESB menyediakan layanan yang digunakan oleh banyak sistem di berbagai proyek. ESB dikelola oleh hanya satu tim integrasi, yang harus sangat berkualitas. Apalagi sulit untuk diukur. Karena fakta bahwa tim ESB adalah "penghambat" proyek, sulit untuk mengeluarkan perubahan dan garis peningkatan yang terus meningkat:

  • Integrasi hanya dimungkinkan melalui bus sebagai bagian dari rilis berikutnya, yang lebih baik untuk mengajukan aplikasi karena aliran besar dalam beberapa bulan;
  • setiap perubahan hanya dapat dilakukan jika disetujui dengan konsumen lain, karena tidak semuanya terurai dan terisolasi. Utang teknis terakumulasi, yang hanya meningkat seiring waktu. 

Dalam arsitektur monolitik, data "beristirahat". Tetapi seluruh bisnis dibangun di atas streaming peristiwa dan membutuhkan perubahan cepat. Dan di mana semuanya berubah dengan sangat cepat, penggunaan ESB tidak tepat. 

Untuk mengatasi masalah ini, pendekatan Agile Integration membantu, yang tidak menyiratkan solusi integrasi terpusat tunggal untuk seluruh perusahaan atau tim integrasi tunggal. Menggunakannya, beberapa tim pengembangan lintas fungsi muncul yang tahu data apa yang mereka butuhkan dan kualitas apa yang seharusnya. Ya, dengan pendekatan ini, pekerjaan yang dilakukan dapat digandakan, tetapi ini memungkinkan Anda untuk mengurangi ketergantungan antara tim yang berbeda dan membantu memimpin pengembangan paralel dari berbagai layanan.

Data monolit


Ketiga, tetapi masalah arsitektur yang tidak kalah penting adalah masalah monolit data, terkait dengan penggunaan gudang data perusahaan yang terpusat ( Enterprise Data Warehouse, EDW). Solusi EDW mahal, mereka berisi data dalam format kanonik, yang, karena pengetahuan khusus, didukung dan dipahami oleh hanya satu tim spesialis, yang melayani semua orang. Data dalam EDW berasal dari berbagai sumber. Tim EDW memverifikasi mereka dan mengubahnya menjadi format kanonik yang harus memenuhi kebutuhan berbagai kelompok konsumen dalam organisasi, dan tim dimuat. Selain itu, data yang dikonversi ke format kanonik tertentu tidak nyaman untuk semua orang dan selalu. Intinya - butuh terlalu banyak waktu untuk bekerja dengan data. Karena itu, tidak mungkin meluncurkan produk digital baru dengan cepat di pasar.


Orientasi seperti itu ke komponen pusat, ketergantungannya pada perubahan dalam sistem sekitarnya adalah masalah nyata dalam pengembangan proses digital baru dan perencanaan perbaikannya. Perubahan bisa saling bertentangan, dan koordinasi mereka dengan tim lain semakin memperlambat pekerjaan. 

Untuk mengatasi masalah monolit data, repositori data yang tidak terstruktur, Data Lake , diciptakan. Perbedaan utamanya adalah bahwa data "Raw" dimuat ke dalam Data Lake, tidak ada tim tunggal untuk bekerja dengan mereka. Jika sebuah bisnis perlu mendapatkan beberapa data untuk menyelesaikan masalahnya, sebuah tim dibentuk yang mengekstraksi data yang diperlukan untuk tugas tertentu. Di dekatnya, tim lain dapat melakukan hal yang sama untuk tugas lain. Dengan demikian, Data Lake diperkenalkan sehingga beberapa tim dapat secara bersamaan mengerjakan produk mereka. Pendekatan ini menyiratkan bahwa data dapat diduplikasi dalam domain yang berbeda, karena tim mengubahnya menjadi bentuk yang cocok untuk mengembangkan produk mereka. Di sini muncul masalah - tim perlu memiliki kompetensi untuk bekerja dengan berbagai format data. Namun, pendekatan ini, meskipun membawa risiko biaya tambahan,memberi bisnis kualitas baru dan secara positif memengaruhi kecepatan menciptakan produk digital baru.

Dan hanya beberapa di antara organisasi maju yang menggunakan pendekatan yang bahkan lebih "matang" dalam bekerja dengan data - Data Mesh , yang mewarisi prinsip-prinsip dari dua yang sebelumnya, tetapi menghilangkan kekurangan mereka. Manfaat Data Mesh adalah Analisis Data Real-Timedan biaya yang lebih rendah untuk mengelola infrastruktur big data. Pendekatan ini mendukung pemrosesan aliran dan menyiratkan bahwa sistem eksternal menyediakan aliran data yang menjadi bagian dari API solusi sumber. Kualitas data adalah tanggung jawab pemilik tim dari sistem yang menghasilkan data ini. Untuk memaksimalkan pendekatan ini, kontrol yang lebih ketat atas bagaimana data diproses dan diterapkan diperlukan untuk menghindari "membuat orang menjadi banyak informasi yang tidak berarti". Dan ini membutuhkan perubahan dalam pemikiran manajemen dan tim tentang bagaimana interaksi TI dengan bisnis dibangun. Pendekatan ini berfungsi baik dalam model yang berorientasi produk, dan tidak dalam model yang berorientasi proyek.

Infrastruktur data seperti itu membuka perspektif yang sama sekali berbeda dan berkontribusi pada transisi dari keadaan "menyimpan data" ke keadaan "responsif terhadap data." Pemrosesan streaming memungkinkan bisnis digital untuk segera merespons peristiwa ketika menghasilkan data, menyediakan cara intuitif untuk memperoleh data analitis dan menyiapkan produk atau layanan secara real time, yang akan membantu organisasi melangkah selangkah lebih maju dari para pesaingnya.

Pendekatan terdistribusi


Untuk meringkas, solusi untuk masalah semua monolith yang terdaftar adalah:

  • membagi sistem menjadi beberapa blok terpisah yang berfokus pada fungsi bisnis;
  • alokasi tim independen, yang masing-masing dapat membuat dan mengoperasikan fungsi bisnis;
  • paralelisasi kerja antara tim-tim ini untuk meningkatkan skalabilitas, kecepatan.

Tidak ada solusi sederhana dalam membangun infrastruktur TI organisasi modern. Dan transisi dari arsitektur tradisional ke arsitektur terdistribusi tidak hanya transformasi teknis, tetapi juga transformasi budaya. Untuk itu diperlukan perubahan pemikiran terkait interaksi bisnis dan sistem informasi. Dan jika aplikasi monolitik ada di organisasi sebelumnya, sekarang ribuan layanan bekerja yang perlu dikelola, dipelihara, dan dibandingkan dalam hal antarmuka dan data. Ini meningkatkan biaya, meningkatkan persyaratan untuk keterampilan orang dan manajemen proyek. Departemen TI dan bisnis harus mengambil tanggung jawab tambahan, dan jika mereka belajar mengelola kompleksitas ini, maka infrastruktur ini akan memungkinkan bisnis untuk merespons tantangan pasar dengan kualitas baru yang lebih tinggi.

Dan sekarang tentang apa sebenarnya kitaApakah kita menggunakan DTG sebagai solusi untuk "masalah monolit" ketika mengoptimalkan proses digital pelanggan kami dan integrasi mereka ke dalam ekosistem mitra? Jawaban kami adalah kelas Platform Teknologi Bisnis Digital (lihat klasifikasi analitik Gartner). Kami memanggilnya GRANUMdan, berdasarkan tradisi, dibangun di atas kombinasi teknologi open source, yang memungkinkan kami untuk dengan cepat dan mudah menciptakan sistem terdistribusi yang kompleks di lingkungan perusahaan. Kami akan menyentuh teknologi secara lebih rinci di bawah ini. Apa yang menjadi lebih mudah dan lebih cepat? Menggunakan platform, kami secara signifikan mempercepat integrasi platform TI pelanggan yang ada, sistem interaksi pelanggan, manajemen data, IoT, dan analitik, mampu dengan cepat mengintegrasikan sistem pelanggan dengan mitra ekosistem untuk menangani acara bisnis dan membuat keputusan bersama untuk menciptakan nilai bersama. Selain itu, penggunaan teknologi open source membantu kami menanggapi permintaan pelanggan terkait dengan menghindari perangkat lunak berlisensi. 

Dari sudut pandang teknis, selama digitalisasi proses melalui penggunaan arsitektur terdistribusi (layanan microser dan pendekatan DataMesh), kami berhasil mengurangi saling ketergantungan komponen dan memecahkan masalah pengembangan yang kompleks dan panjang. Selain itu, kami dapat memproses acara streaming secara langsung, menjaga kualitas data, dan juga menciptakan lingkungan tepercaya untuk berinteraksi dengan mitra.


Platform ini dapat dibagi menjadi tiga lapisan logis. 

  1. Lapisan bawah adalah infrastruktur. Dirancang untuk menyediakan layanan dasar. Ini termasuk keamanan, pemantauan dan analisis log, manajemen kontainer, perutean jaringan (load balancing), devops. 
  2. Lapisan integrasi - mendukung arsitektur terdistribusi (pendekatan DataMesh, layanan microser dan streaming data).
  3. — . (track&trace), , . . 

Mari kita bicara lebih spesifik tentang teknologi sumber terbuka yang telah kita pilih. Yang mana dari mereka yang digunakan dalam praktik terbaik mereka oleh perusahaan-perusahaan Internet terkemuka seperti Netflix, LinkedIn, Spotify. Teknologi Kubernetes, Jenkins, Keycloak, Spring Boot, Fluentd, Grafana, Prometheus dipilih untuk memerangi monolit aplikasi dan untuk membangun dan bekerja dengan arsitektur layanan-mikro, serta dalam mengejar fleksibilitas dan kecepatan perubahan. Untuk menjauh dari arsitektur monolitik, pendekatan Agile Integration biasanya menggunakan Apache Camel, NiFi, WSO2 API Manager. Dan akhirnya, Kafka, Flink, Salase Event Portal berguna untuk menyelesaikan masalah monolit data, partisi dan transisi ke analisis data waktu nyata menggunakan pendekatan Data Mesh.

Ilustrasi di bawah ini mewakili seperangkat teknologi yang, sebagai hasil eksperimen, kami di DTG dianggap optimal untuk menyelesaikan masalah tiga monolit.


Kami memulai aplikasi praktis dari platform yang dijelaskan sekitar setahun yang lalu dan hari ini kami sudah dapat menyimpulkan bahwa, terlepas dari industri, solusi semacam itu menarik bagi organisasi yang berpikir untuk mengurangi biaya dalam menjalankan proses bisnis mereka, meningkatkan efisiensi interaksi dengan mitra, menciptakan rantai nilai baru. Perusahaan tersebut ditujukan untuk eksperimen aliran digital cepat (pengujian hipotesis, integrasi, peluncuran pasar cepat dan, jika keberhasilan lokal, implementasi global), dan juga akan membuka saluran komunikasi baru dengan pelanggan dan membangun komunikasi digital yang lebih intens dengan mereka Dunia. Lowongan menarik

selalu terbuka di grup perusahaan kami . Menunggumu!

More articles:


All Articles