Platform kode rendah (Platform aplikasi kode rendah, LCAP) muncul sebagai reaksi terhadap kompleksitas dan beragam alat pengembangan perangkat lunak modern.
Menurut Gartner, salah satu pemain paling terkenal di daerah ini adalah Mendix . Penjualan Siemens untuk ruang $ 700 juta menegaskan hal ini. Jadi saya akan menggunakan platform ini sebagai contoh, meskipun kesimpulan yang sama akan berlaku untuk Outsystems, Appian, Kony, Betty Blocks dan lainnya.
Jadi, dengan menargetkan penjualan ke manajer puncak, vendor platform kode rendah menjanjikan bahwa bahkan pengguna biasa akan dapat membuat aplikasi bisnis sendiri.
Artinya, pengembang tidak lagi diperlukan ?!
Nah ... setelah beberapa tahun, Mendix terpaksa mengakui:
"Sekarang pengembang membutuhkan lebih dari sebelumnya."
Ini adalah twist!
Tampaknya Mendix mengakui bahwa untuk sesuatu yang lebih sulit daripada pekerjaan dasar dengan data, pengembang profesional masih diperlukan, seperti halnya mekanik profesional diperlukan untuk memperbaiki mobil.
Sayangnya, platform kode rendah modern sama sekali tidak dirancang untuk pengembang, dan bergantung pada mereka dalam jangka panjang berisiko untuk bisnis. Jika perusahaan Anda serius mempertimbangkan penggunaan platform kode rendah dalam operasi industri, ada baiknya menimbang solusi ini lagi. Di bawah ini saya akan mencoba memperdebatkan ini.
Alat prototyping yang bagus
Mendix adalah pilihan yang sangat bagus untuk mengotomatisasi proses sederhana atau membuat prototipe, tersedia untuk analis atau pengguna tingkat lanjut.
Editor visual memungkinkan Anda untuk menggambarkan model data, membuat layar dengan cepat menggunakan serangkaian widget dan template, dan bahkan menggambarkan logika menggunakan apa yang disebut mikroflow :
Setelah selesai, Anda dapat menggunakan aplikasi Anda di cloud Mendix dengan satu klik dan mulai bekerja dengannya. Begitu sederhana sehingga terdengar seperti sihir! Dan sepertinya itu laris manis.
Namun, setelah melewati tahap prototipe, interaksi sistem dengan pengguna dan logika bisnis hampir pasti rumit. Untuk mengembangkan proyek lebih lanjut, seorang profesional diperlukan. Jadi, mari kita lihat Mendix melalui mata pengembang.
Perkembangan lambat
Logika apa pun - baik itu komputasi atau interaksi pengguna - harus dijelaskan dalam diagram alur mikroflow, seperti yang ditunjukkan di atas.
Ada beberapa masalah di sini.
Pertama, ini waktu yang lama . Jelas, lebih cepat menulis 10 baris kode dalam IDE yang bagus daripada menyeret dan melepaskan, menyesuaikan, dan bergabung dengan puluhan blok.
Kedua, keterbacaan . Blok tampak cantik, tetapi apa artinya Sub_RegistrationValidation ini? Tidak mungkin untuk memahami ini tanpa jatuh ke blok. Begitu jumlah blok bertambah menjadi beberapa puluh, akan menjadi sangat sulit untuk memahami logikanya.
Sebagai alternatif untuk kasus kompleks, Mendix mendukung panggilan kode Java dari mikroflow. Anda dapat menulis kode dalam Eclipse, yang umumnya bagus, meskipun banyak yang lebih suka IDE yang lebih populer. Kelemahannya adalah kurangnya transparansi: semua titik masuk berada dalam arus mikro, sehingga logika tersebar di antara dua lingkungan yang digabungkan secara longgar. Akibatnya, dependensi debugging dan pelacakan sulit.
Hal terakhir yang ingin saya sebutkan adalah kontrol versi.
Berita baiknya adalah dia. Yang buruk adalah bahwa itu adalah versi Subversion yang dilucuti. Lupakan aliran git.
Kurangnya kontrol
Siapa pun yang akrab dengan ekosistem Jawa tidak dapat meremehkan kekuatan sumber terbuka. Ketika kesalahan muncul di suatu tempat di tumpukan, Anda melihat di bagian mana dari kode ini terjadi. Kode dapat di-debug untuk memahami apa yang sedang terjadi. Anda dapat mencari solusinya. Anda dapat mengirim permintaan tarik. Dalam kasus-kasus ekstrem, Anda dapat melakukan fork perpustakaan. Anda memegang kendali penuh atas proyek ini.
Dengan Mendix, Anda bisa melupakannya. Ini adalah kerangka kerja komersial tertutup, dan apa yang terjadi di dalamnya adalah kotak hitam asli. Yang tersisa untuk Anda adalah membeli dukungan berbayar atau menunggu seseorang untuk membantu di forum dengan ~ 200 pertanyaan per bulan (bandingkan dengan tag #spring pada stackoverflow !).
Ketergantungan vendor
Mendix mungkin cukup sering mencela ini. Mereka bahkan menerbitkan sebuah artikel yang mengatakan bahwa benar-benar tidak ada kecanduan. Jika Anda membaca di antara istilah tersebut, terbaca:
Anda bisa mendapatkan data, DDL, sumber daya dan kode UI (mikroflow dikonversi secara ajaib ke kode Java).
Apakah akan dieksekusi atau dikompilasi tanpa runtime dan API Mendix? Bisakah ini dipertahankan dan dikembangkan? Pertanyaan bersifat retoris. Bahkan, Anda harus menulis ulang semuanya. Anda bergantung pada platform berpemilik. Anda tidak memiliki sistem yang Anda buat.
Skalabilitas terbatas
Pemasaran Mendix difokuskan pada perusahaan terbesar, sehingga istilah "skalabilitas" terus-menerus muncul dalam materi pemasaran.
Pada tahun 2017, Mendix memperkenalkan runtime stateless - yaitu, semua informasi sesi disimpan di sisi klien atau dalam penyimpanan persisten.
Secara teoritis, ini berarti skalabilitas horizontal tanpa batas. Kedengarannya hebat, tetapi seperti biasa ada nuansa - database.
Database hampir selalu berubah menjadi hambatan dalam aplikasi perusahaan. Jadi, apa yang disimpan data di balik banyak server stateless Mendix? Tidak ada kejutan - ini adalah database relasional lama yang baik. Di cloud Mendix - PostgreSQL. Selain itu, Mendix DDL yang dihasilkan, secara halus, tidak sepenuhnya optimal. Sebagai contoh, saya melihat tabel perantara yang biasanya digunakan untuk memodelkan hubungan N: M, dibuat untuk hubungan 1: N.
Masalah skalabilitas dapat diselesaikan dengan metode standar: mengoptimalkan struktur database, caching, atau bahkan menggunakan solusi seperti Citus. Namun tentu saja tidak ada kemungkinan seperti itu.
Satu-satunya cara untuk skala database adalah untuk skala menggunakan replika baca (misalnya, Amazon RDS). Tetapi sebagai catatan, ini tidak akan berhasil.
Meringkas sebelumnya, Mendix memiliki batasan mendasar pada skalabilitas dan tidak ada cara untuk mengoptimalkan kinerja.
Masalah SDM
Mencari personil yang berkualitas selalu merupakan tugas yang sulit. Tampaknya dalam Mendix ini adalah impian setiap manajer, karena persyaratan kualifikasi berkurang tajam.
Faktanya, kami telah mengetahui bahwa sebagian besar proyek membutuhkan tim profesional, apa pun alatnya. Tetapi tidak mungkin bahwa pengembang yang menghargai diri sendiri akan setuju untuk bekerja dengan Mendix, karena ini jelas merupakan jalan buntu dalam karirnya.
Harga
Terakhir tapi tidak kalah pentingnya. Biaya lisensi untuk satu aplikasi mulai dari $ 1875 per bulan, tergantung berlangganan selama tiga tahun, lisensi terbatas untuk 50 pengguna internal.
Harga lisensi perusahaan dengan kemungkinan penyebaran lokal mulai dari $ 7.825, yang hampir $ 100.000 setahun.
Perusahaan menengah dengan beberapa ratus pengguna setiap tahun akan membayar tagihan puluhan juta rubel.
Jangan lupa bahwa kita berbicara tentang aplikasi yang relatif sederhana, seperti yang dapat Anda pahami dari atas. Bagi saya, ini gila. Model penetapan harga ini juga hampir tidak memungkinkan untuk mereplikasi aplikasi yang Anda buat.
Lalu mengapa LCAP masih populer?
Menurut pendapat saya, alasannya terletak pada kekecewaan dalam proses yang ada. Mengelola tim pengembangan di organisasi besar - apakah itu tim internal atau outsourcing - terlalu rumit.
Perencanaan anggaran, persetujuan tanpa akhir, kurangnya orang yang mau bertanggung jawab - saya pikir ini sudah biasa bagi banyak orang.
Yang lucu adalah bahwa hal pertama yang terlintas dalam pikiran ketika proyek-proyek TI bergerak terlalu lambat adalah mempekerjakan lebih banyak pengembang dan, tentu saja, manajer. Tak perlu dikatakan, ini hanya memperburuk situasi. Saya tahu beberapa bank dengan lebih dari 10.000 (!!!) pengembang, dan setidaknya setengah dari mereka melakukan pekerjaan yang tidak berguna.
Dalam keputusasaan, para pemimpin bisnis mencari solusi dalam "tongkat ajaib" seperti LCAP, yang konon mampu menyelesaikan semua masalah.
Cara keluar dari lingkaran setan ini adalah topik untuk artikel terpisah. Tapi ini masalah manajemen, bukan teknologi.
Tanpa merinci, jika Anda berhasil membuat tim kecil yang memenuhi syarat 3-10 orang yang sepenuhnya terlibat dalam proyek, dengan kontak langsung dengan pembuat keputusan, Anda akan mendapatkan hasil yang sangat baik lebih cepat dan lebih murah daripada yang Anda harapkan.
Apa alternatifnya?
Sekarang ada banyak pilihan alat dan kerangka kerja untuk pengembang.
Misalnya, Kerangka Kerja Spring adalah teknologi open-source paling populer untuk membuat perangkat lunak perusahaan yang berfungsi baik dengan kerangka kerja web seperti React atau Angular. Dan alat-alat seperti Spring Initializr dan JHipster telah sangat menyederhanakan pembuatan proyek selama beberapa tahun terakhir.
Jika Anda ingin mendapatkan hasil lebih cepat, Anda harus mempertimbangkan alat RAD seperti CUBA Platform .
Ini didasarkan pada Kerangka Pegas yang sama, melengkapinya dengan alat pengembangan visual dan sejumlah besar komponen yang tersedia. Mungkin ini adalah alternatif terdekat dari LCAP, memberikan fleksibilitas dan proses pengembangan yang nyaman.
Pilihan akhir harus tergantung pada tugas, serta keterampilan tim dan preferensi Anda.
Kesimpulan
Platform kode-rendah sangat bagus untuk membuat prototipe. Mereka mempersempit kesenjangan antara pengguna bisnis dan TI, yang memungkinkan Anda untuk dengan cepat mendapatkan prototipe yang berfungsi dan membentuk visi sistem masa depan.
Karena ada sangat sedikit pengguna prototipe, biaya pada tahap ini juga kecil. Dan pada saat ini layak untuk dihentikan!
Saat menggunakan LCAP untuk mengembangkan sistem yang lengkap, kecepatan pekerjaan pasti akan turun, dan Anda akan bergantung pada platform eksklusif yang mahal yang membatasi Anda.