Bersiaplah untuk tumpukan baru

Virtualisasi mungkin merupakan teknologi paling sukses yang pernah melewati ambang batas pusat data perusahaan. Pemanfaatan perangkat keras yang jauh lebih baik dan kemampuan untuk menjalankan VM dengan biaya sepeser pun telah membuat virtualisasi menjadi penjualan yang mudah selama dekade terakhir, ke titik di mana Gartner baru-baru ini memperkirakan bahwa 70 persen beban kerja x86 divirtualisasi.

Namun hal-hal cloud pribadi yang mewah di atas lapisan virtualisasi itu lambat datangnya. Ya, alat manajemen virtualisasi dari VMware dan Microsoft telah mengaktifkan perilaku seperti cloud untuk server dan penyimpanan, dan bahkan OpenStack akhirnya mendapatkan sedikit daya tarik perusahaan - tetapi cloud publik canggih yang ditawarkan oleh Amazon, Google, IBM, Microsoft, dan Rackspace memberikan lebih banyak lagi penskalaan otomatis lanjutan, pengukuran, dan layanan mandiri (belum lagi ratusan layanan lainnya). Plus, lapisan cloud PaaS untuk mengembangkan, menguji, dan menerapkan aplikasi - sekarang ditawarkan oleh semua cloud publik utama - telah menemukan jalannya ke dalam pusat data perusahaan yang relatif sedikit.

Kemudian Docker mulai populer tahun lalu, menawarkan cloud stack baru berdasarkan container, bukan VM. Container jauh lebih ringan daripada VM dan memungkinkan aplikasi untuk dikemas dan dipindahkan dengan mudah, tanpa kerumitan instalasi konvensional. Jika cloud berbasis VM telah terhenti, dan tumpukan berbasis kontainer baru menawarkan keuntungan yang jelas, apakah tumpukan baru akan melompati jalannya ke dalam perusahaan untuk mengirimkan awan pribadi baru?

Zorawar Biri Singh, mantan kepala HP Cloud Services dan sekarang menjadi mitra ventura di Khosla Ventures, berpendapat bahwa keberhasilan tumpukan baru tidak dapat dihindari - tetapi kita masih jauh dari adopsi perusahaan. Di sinilah dia melihat kemacetan:

Pertama, untuk perusahaan tradisional dan beban kerja produksi tradisional, pengeluaran TI saat ini difokuskan pada penyederhanaan dan pengelolaan perluasan VM melalui solusi terkonvergensi di pusat data. Kedua, stack baru masih rapuh dan lebih awal. Utilitas nyata di sekitar kontainer, seperti keamanan yang diperkuat, masih jauh dari memadai. Saat ini tumpukan baru adalah tempat persemaian yang sangat baik untuk pengembangan dan pengujian beban kerja. Tetapi titik gesekan sebenarnya adalah bahwa tim TI beban kerja produksi perusahaan tidak memiliki orientasi pengembang atau latar belakang TI yang gesit untuk dapat menerapkan dan mendukung aplikasi yang didistribusikan atau tanpa kewarganegaraan. Salah satu masalah terbesar adalah bahwa hanya ada kesenjangan keterampilan yang besar pada pengembang di organisasi perusahaan tradisional.

Di sisi lain, kata Singh, "tim pengembang tertentu dan lini bisnis hijau sudah memanfaatkan infrastruktur ini." Dalam kasus seperti itu, metode devops sudah ada, atau developer perintis menangani sendiri sisi operasi stack berbasis container.

Sama seperti pengembang yang telah mendorong adopsi database NoSQL, mereka berada di garis depan tumpukan baru, mengunduh perangkat lunak sumber terbuka dan bereksperimen - atau beralih ke cloud publik seperti EC2 atau Azure yang sudah mendukung kontainer.

Layanan mikro sangat penting

Mengapa pengembang sangat menyukai tumpukan baru? Sebagian besar karena container kondusif untuk arsitektur layanan mikro, tempat kumpulan layanan tujuan tunggal yang dapat diakses API menggantikan aplikasi monolitik. Arsitektur layanan mikro memungkinkan pengembang untuk membangun aplikasi yang lebih mudah beradaptasi dengan persyaratan baru - dan untuk membuat aplikasi yang sepenuhnya baru dengan cepat menggunakan layanan yang ada.

John Sheehan, salah satu pendiri dan CEO layanan pemantauan dan pengujian API Runscope, melihat layanan mikro sebagai "modernisasi" SOA (arsitektur berorientasi layanan). "Tanggung jawab intinya sebagian besar sama," kata Sheehan. "Kami ingin mendistribusikan bagian yang berbeda dari arsitektur perangkat lunak kami ke seluruh sistem yang berbeda dan memecahnya tidak hanya dengan batasan kode tetapi juga dengan batasan layanan. Pembelajaran itu telah dibawa ke layanan mikro."

Arsitektur layanan mikro bergantung pada protokol yang lebih sederhana dan lebih ramah pengembang daripada SOA - REST sebagai lawan SOAP; JSON sebagai lawan XML. Sheehan mencatat perbedaan utama lainnya:

Jenis layanan mikro yang kami lihat dan yang cenderung digunakan pelanggan kami sangat didorong oleh pengembang. Secara internal, kami menerapkan sekitar 31 kali sehari di perusahaan kami di semua layanan kami yang berbeda. Kami 14 orang dan kami memiliki sekitar 40 layanan berbeda yang berjalan secara internal. Sebagian besar darinya adalah menempatkan infrastruktur yang diperlukan sehingga setiap tim dapat menyebarkan, menskalakan, memantau, dan mengukur setiap layanan secara mandiri.

Dalam skenario seperti itu, garis antara dev dan ops menjadi kabur. Personel ops menulis kode untuk mengelola infrastruktur, yang pada dasarnya menjadi bagian dari tim pengembangan. "Ada sedikit perbedaan antara tim operasi dan tim aplikasi," kata Sheehan. Dalam operasi, "Anda kebetulan melakukan coding terhadap server, bukan coding terhadap layanan."

Singh yakin pendekatan layanan mikro intensif pengembang mungkin meniadakan kebutuhan akan PaaS "formal". Penawaran PaaS seperti Cloud Foundry atau OpenShift menawarkan koleksi layanan dan proses yang ditentukan sebelumnya untuk membangun, menguji, dan menerapkan aplikasi - sedangkan, dalam tumpukan baru, rangkaian layanan mikro yang dapat diakses API yang kaya dapat disematkan di setiap lapisan. Baik dev dan ops dapat dihubungkan ke layanan mikro naik dan turun tumpukan, tanpa batasan yang diberlakukan oleh PaaS.

Jenis hibrida yang berbeda

Arsitektur layanan mikro mungkin melompati PaaS, tetapi seluruh tumpukan baru tidak akan berakar dalam semalam. Misalnya, Netflix secara luas dianggap memiliki penyebaran layanan mikro paling canggih di mana pun, dan itu membuat banyak layanan prebuilt tersedia untuk komunitas open source sebagai image Docker di Docker Hub - tetapi Netflix tidak menggunakan Docker dalam produksi. Runscope juga tidak, dalam hal ini. Keduanya menggunakan VM konvensional sebagai gantinya.

Terlepas dari minat besar di antara pengembang dalam solusi berbasis kontainer, ini masih awal. Untuk satu hal, alat orkestrasi dan manajemen untuk kontainer, seperti Mesosphere dan Kubernetes, masih terus berkembang. Di sisi lain, tidak jelas standar kontainer mana yang akan menang, dengan CoreOS menjadi tantangan besar bagi Docker Desember lalu. Tumpukan berbasis kontainer mungkin akan menang pada akhirnya, tetapi itu akan memakan waktu cukup lama.

"Kami melihat hasil yang paling mungkin adalah kontainer dan VM akan digunakan dalam kombinasi," kata Kurt Milne dari penyedia manajemen multicloud Cliqr. Itu bisa berarti menjalankan kontainer di dalam VM - atau bisa juga berarti bahwa tumpukan berbasis kontainer baru dan tumpukan berbasis VM akan berjalan berdampingan.

Skenario hybrid ini membuka peluang bagi VMware dan lainnya yang telah membangun manajemen dan orkestrasi untuk virtualisasi. Dalam wawancara dengan minggu lalu, wakil presiden eksekutif VMware Raghu Raghuram menolak untuk melihat kontainer sebagai ancaman. Sebaliknya, dia berkata:

Kami melihat container sebagai cara untuk menghadirkan aplikasi baru ke platform kami. Ketika pengembang atau orang-orang TI bertanya-tanya apa yang mereka butuhkan untuk menjalankan kontainer dengan cara yang kuat, ternyata mereka membutuhkan lapisan infrastruktur di bawahnya - mereka membutuhkan ketekunan, mereka membutuhkan jaringan, mereka membutuhkan firewall, mereka membutuhkan manajemen sumber daya dan segala macam itu sesuatu. Kami sudah membuatnya. Ketika Anda meletakkan mekanisme kontainer di atas ini, maka Anda dapat mulai menggunakan infrastruktur yang sama untuk hal-hal itu juga. Kami melihat pola di mana front end Web stateless adalah semua kontainer, dan persistensi serta database semuanya VM. . Ini campuran keduanya. Jadi sekarang pertanyaannya adalah: Apa yang dimaksud dengan lingkungan infrastruktur yang sama dan lingkungan manajemen yang sama? Kami melihatnya sebagai kesempatan yang luar biasa bagi kami.

Raghuram menolak mengatakan kapan VMware mungkin memperluas alat manajemennya ke lapisan penampung, tetapi implikasinya jelas. Akan menarik untuk melihat bagaimana pendekatan berorientasi operasi VMware akan dipenuhi oleh pengembang yang mendorong eksperimen berbasis kontainer hari ini.

Yang jelas adalah, terlepas dari keseruan saat ini, tumpukan baru tidak akan menggantikan tumpukan yang ada dalam beberapa gelombang rip-and-replace yang dramatis. Seperti adopsi cloud, tumpukan berbasis kontainer hampir secara eksklusif akan digunakan untuk dev dan pengujian terlebih dahulu. Investasi besar yang ada dalam infrastruktur virtualisasi tidak akan dibuang dari jendela pusat data.

Meskipun demikian, tumpukan berbasis kontainer baru adalah lompatan besar dalam kelincahan dan kontrol pengembang. Pengembang menemukan dan mengadopsi alat yang mereka butuhkan untuk membangun arsitektur layanan mikro dan untuk memberikan aplikasi yang lebih banyak dan lebih baik dengan klip yang fantastis. Saat potongan-potongan itu jatuh ke tempatnya, dan keterampilan pengembang menjadi ada di mana-mana, Anda dapat bertaruh tumpukan baru akan berakar tanpa henti seperti virtualisasi.