Cloudlets: Tempat cloud bertemu dengan perangkat cerdas

Awan publik skala besar telah mapan sebagai platform baru untuk sistem pencatatan. Penyedia ERP, rantai pasokan, pemasaran, dan aplikasi penjualan saat ini sebagian besar atau secara eksklusif berbasis di cloud publik hyperscale. Oracle sendiri memiliki ribuan pelanggan untuk SaaS front-office dan back-office. Dan daftar pelanggan tumbuh dengan kecepatan yang jauh melebihi aplikasi front-office dan back-office tradisional.

Cloud publik hyperscale juga, tentu saja, merupakan tempat yang tepat untuk menjalankan aplikasi cloud-native baru yang meningkatkan atau memperluas aplikasi system-of-record tersebut. Aplikasi baru ini dirancang secara berbeda. Meskipun sistem rekaman biasanya berukuran besar, aplikasi monolitik yang berjalan di mesin virtual di cloud, aplikasi cloud-native biasanya ditulis sebagai layanan mikro, dikemas dalam container, dan diatur untuk memberikan aplikasi lengkap kepada pengguna. Di antara manfaat pendekatan ini:

  • Inovasi lebih cepat
  • Kemampuan untuk memberikan penyesuaian khusus untuk setiap penggunaan aplikasi
  • Penggunaan kembali kode yang lebih baik
  • Penghematan biaya dibandingkan virtualisasi konvensional karena kepadatan penerapan kontainer yang lebih besar dan konsumsi sumber daya yang lebih efisien

Semua ini sudah menjadi rahasia umum, tak henti-hentinya disebut-sebut, tidak lagi diperdebatkan.

Yang kurang dibahas, bagaimanapun, adalah galaksi aplikasi yang belum tentu cocok untuk penyebaran cloud hyperscale terpusat. Sebaliknya, aplikasi ini berkembang pesat dalam lingkungan komputasi terdistribusi, berpotensi berdasarkan layanan cloud, di atau dekat tepi jaringan. Aplikasi ini adalah sistem keterlibatan dan sistem kontrol.

Sistem di ujung tombak

Sistem keterlibatan telah didefinisikan, oleh firma analis industri terkemuka sebagai “berbeda dari sistem pencatatan tradisional yang mencatat transaksi dan menjaga akuntansi keuangan tetap teratur: Mereka fokus pada orang, bukan proses ... untuk mengirimkan aplikasi dan produk pintar secara langsung dalam konteks kehidupan sehari-hari dan alur kerja waktu nyata pelanggan, mitra, dan karyawan. " Sistem keterlibatan, yang dirancang untuk memfasilitasi interaksi manusia, secara inheren lebih terdesentralisasi daripada sistem catatan.

Jenis aplikasi ketiga untuk membedakan adalah apa yang saya sebut sistem kendali. Aplikasi ini menyediakan kontrol waktu nyata antara perangkat cerdas. Mungkin contoh klasiknya adalah kendaraan yang bisa mengemudi sendiri. Jika dua mobil melaju di jalan raya dengan kecepatan 65 mil per jam, mereka tidak akan secara otomatis mengoordinasikan jaraknya dengan mengirimkan data tentang kecepatan dan posisi ke pusat data jarak jauh untuk diproses. Mereka akan berkomunikasi secara langsung satu sama lain, merespons dalam mikrodetik. Baik untuk mempercepat mobil, jalur perakitan manufaktur, atau operasi robotik, meminimalkan latensi jaringan adalah masalah utama untuk internet of things.

Pengembang yang membangun sistem keterlibatan dan sistem kontrol juga menggunakan model pengembang berdasarkan layanan mikro dan kontainer. Untuk jenis aplikasi ini, kontainer menawarkan:

  • Biaya penerapan hampir nol di sejumlah besar sistem (pikirkan ratusan ribu kendaraan)
  • Waktu startup cepat, dengan pemutaran ulang dan reset instan
  • Portabilitas yang lebih besar karena berkurangnya masalah kompatibilitas platform di berbagai jenis komputer yang mungkin ada di jaringan

Di mana kontainer ini akan dijalankan? Untuk sistem kontrol, kontainer biasanya akan berjalan di perangkat cerdas itu sendiri - misalnya, di dalam mobil tanpa pengemudi.

Untuk menjalankan sistem keterlibatan, perusahaan perlu mengintai real estat digital di tepi jaringan yang dekat dengan pelanggan, karyawan, dan mitra mereka - bukan di cloud hyperscale, melainkan di cloud yang jauh lebih kecil yang cocok untuk aplikasi berbasis kontainer ringan . Sebut mereka cloudlets.

Masukkan cloudlets

Cloudlets adalah cara untuk memindahkan kapasitas komputasi awan lebih dekat ke perangkat cerdas di edge jaringan. Saat peneliti Carnegie Mellon mendefinisikan cloudlets, cloudlet adalah level menengah dari hierarki tiga level: perangkat cerdas, cloudlet, dan cloud. Cloudlets dapat dilihat sebagai pusat data dalam sebuah kotak, dengan tujuan untuk mendekatkan cloud ke perangkat. Berdasarkan ide peneliti CMU, saya percaya bahwa cloudlet harus memiliki empat atribut utama:

  • Desain alat kecil, berbiaya rendah, dan bebas perawatan, berdasarkan teknologi cloud standar
  • Kuat, terhubung dengan baik, dan aman
  • Mempertahankan hanya keadaan lunak (dibuat untuk layanan mikro dan kontainer)
  • Terletak di tepi jaringan, dekat dengan perangkat cerdas yang akan berkomunikasi dengannya

Implikasinya signifikan. Misalnya, sementara banyak orang memiliki visi tentang perusahaan virtual yang menjalankan aplikasi secara terpusat di satu pusat data skala besar di cloud, kenyataannya adalah bahwa perusahaan inovatif akan menerapkan keterlibatan dan mengontrol aplikasi di ratusan atau kemungkinan ribuan cloud secara global.

Untuk pengecer, mungkin jelas di mana menempatkan infrastruktur cloudlet dan kontainer yang mereka jalankan: di gerai pengecer. Untuk bisnis lain yang tidak memiliki kehadiran fisik lokal, penyedia telekomunikasi menawarkan layanan cloud di pusat data metropolitan atau bahkan secara geolokal seperti menara ponsel terdekat.

Akibatnya, daripada memiliki ratusan pusat data di mana pun keberadaannya diinginkan, bisnis dapat menyewa sepotong awan untuk jangka waktu tertentu - secara efektif kamar hotel untuk aplikasi mereka di pusat data lokal. Aplikasi memeriksa masuk dan keluar sesuai kebutuhan oleh orang, perangkat, atau sensor di tepi jaringan.

Wadah menggiring

Implikasi penting lainnya: Pendekatan manual tradisional untuk memperbaiki masalah memberi jalan bagi otomatisasi. Dengan ratusan atau ribuan kontainer didorong ke cloudlet dalam jumlah besar, hari-hari pemecahan masalah dalam produksi telah berakhir.

Apakah perangkat keras rusak? Penampung penskalaan otomatis dapat secara otomatis meluncurkan penampung baru pada perangkat keras cloud redundan sesuai kebutuhan. Kegagalan perangkat lunak sistem? Wadah yang rusak dapat disingkirkan dan wadah baru dimuat. Kegagalan perangkat lunak aplikasi? Perbaiki sumber satu kali dan keluarkan gelombang baru penampung secara global. Jangan pernah menambal atau mengupgrade kontainer di lapangan.

Ini disebut model penerapan dan pengelolaan aplikasi “ternak versus hewan peliharaan” seperti yang dijelaskan oleh Gavin McCance dari CERN. Hewan peliharaan itu unik. Mereka dibesarkan dan dirawat dengan penuh kasih. Ketika mereka sakit, Anda merawat mereka kembali sehat. Hal yang sama dapat dikatakan untuk OLTP tradisional dan sistem pendukung keputusan yang dibangun dengan aplikasi monolitik yang sangat besar dan kompleks.

Di sisi lain, sistem berdasarkan layanan mikro dan wadah diperlakukan lebih seperti ternak. Sapi hampir identik satu sama lain. Anda mungkin memiliki ratusan atau ribuan dari mereka. Jika ada yang sakit, gantilah dengan yang lain.

Jadi, pandangan fundamental operasi TI untuk sistem keterlibatan dan kontrol berbasis wadah berbeda. TI akan menghasilkan banyak kontainer dan mendorongnya ke cloudlet yang dekat dengan pengguna dan data untuk penggunaan jangka pendek, biasanya berjam-jam atau berhari-hari. Jika penampung mengalami kegagalan atau menjadi usang, penampung tersebut tidak ditambal atau ditingkatkan: Penampung dihapus, dan penampung baru didorong ke cloudlet.

Agar bisnis berfungsi sebagai keseluruhan yang kohesif, sistem catatan, sistem keterlibatan, dan sistem kontrol perlu diintegrasikan. Infrastruktur umum untuk seluruh siklus proses - mengembangkan, membangun, mendistribusikan, memantau, dan mengelola - dapat digunakan untuk membangun dan menerapkan layanan cloud terdistribusi dalam bentuk container. Aplikasi SaaS monolitik yang besar tidak akan hilang, tetapi mungkin itu pengecualian, bukan aturannya.

Teknologi yang diperlukan untuk mewujudkan konsep ini menjadi fokus. Ada pengakuan yang semakin besar tentang pentingnya memiliki seperangkat alat yang menyederhanakan siklus proses pengembangan, penerapan, dan pengelolaan kontainer.

Pengembangan aplikasi berbasis layanan mikro biasanya mengandalkan alat seperti bahasa skrip, kerangka kerja pengembangan, repositori sumber, alat pelacakan bug, alat integrasi berkelanjutan, dan repositori biner. Alat lain mengemas dan menerapkan layanan mikro sebagai wadah. Alat manajemen untuk penyebaran dan konfigurasi dirancang untuk implementasi layanan identik yang sering di server yang identik. Alat orkestrasi digunakan untuk membuat kumpulan logis dari container yang dimiliki aplikasi untuk manajemen cluster, penjadwalan, penemuan layanan, pemantauan, dan banyak lagi.

Banyak perusahaan mengirimkan alat ini, dan standar industri mulai muncul. Pada akhirnya, alat dan standar ini dapat memungkinkan perusahaan untuk mengoperasikan pusat data virtual yang terdiri dari banyak layanan awan di seluruh lusinan atau ratusan pusat data fisik yang berpotensi.

Bagaimana Anda bisa memulai visi yang lebih besar dari pusat data virtual? Ada dua langkah segera. Pertama, dapatkan sistem catatan Anda ke cloud publik dan kosongkan sumber daya internal Anda untuk fokus pada sistem keterlibatan dan kontrol inovatif baru. Kedua, bangun disiplin pengembang dalam organisasi TI Anda. Kedua langkah tersebut bisa lama dan sulit, tetapi mereka dapat membayar sendiri saat Anda melakukannya. Di akhir perjalanan terdapat pusat data virtual dengan skalabilitas, keandalan, dan daya tanggap yang diperlukan untuk perusahaan real-time sejati.

Robert Shimp adalah wakil presiden grup Linux dan Manajemen Produk Virtualisasi di Oracle.

Forum Teknologi Baru menyediakan tempat untuk mengeksplorasi dan mendiskusikan teknologi perusahaan yang sedang berkembang secara mendalam dan luas. Pemilihannya subjektif, berdasarkan pilihan teknologi yang kami yakini penting dan paling menarik bagi pembaca. tidak menerima jaminan pemasaran untuk publikasi dan berhak untuk mengedit semua konten yang dikontribusikan. Kirim semua pertanyaan ke [email protected]