Pandangan lain ke awan. Apa itu awan pribadi?

Pertumbuhan daya komputasi dan perkembangan teknologi virtualisasi platform x86 di satu sisi, dan penyebaran outsourcing TI di sisi lain, telah mengarah pada konsep komputasi utilitas. Mengapa tidak membayar TI dengan cara yang sama seperti air atau listrik - persis sebanyak dan tepat saat Anda membutuhkannya, dan tidak lebih.



Pada saat ini, konsep komputasi awan muncul - konsumsi layanan TI dari "awan", yaitu dari beberapa kumpulan sumber daya eksternal, tanpa peduli tentang bagaimana dan dari mana sumber daya ini berasal. Sama seperti kita tidak peduli dengan infrastruktur stasiun pompa air. Pada saat ini, sisi lain dari konsep tersebut juga dikerjakan - yaitu, konsep layanan TI dan bagaimana mengelolanya di dalam ITIL / ITSM.



Sejumlah definisi awan (komputasi awan) telah dikembangkan, tetapi mereka tidak boleh diperlakukan sebagai kebenaran tertinggi - ini hanyalah cara untuk memformalkan cara komputasi utilitas disediakan.



  • "Komputasi awan adalah teknologi pemrosesan data terdistribusi di mana sumber daya dan daya komputer disediakan untuk pengguna sebagai layanan Internet" Wikipedia
  • โ€œKomputasi awan adalah model untuk menyediakan akses jaringan yang nyaman ke kumpulan sumber daya komputasi yang dapat dikonfigurasi bersama (seperti jaringan, server, penyimpanan, aplikasi, dan layanan) sesuai permintaan, yang dapat dengan cepat disediakan dan disampaikan dengan upaya manajemen minimal atau intervensi minimal. penyedia layanan ยปNIST
  • โ€œKomputasi awan adalah paradigma untuk menyediakan akses jaringan ke kumpulan sumber daya fisik atau virtual terdistribusi yang dapat diskalakan dan fleksibel, yang disampaikan dalam mode layanan mandiri dan dikelola sesuai permintaanโ€ ISO / IEC 17788: 2014. Teknologi informasi - Komputasi awan - Gambaran umum dan kosakata.


Ada tiga jenis awan utama menurut NIST:



  1. IaaS - Infrastruktur sebagai Layanan - Infrastruktur sebagai Layanan
  2. PaaS - Platform sebagai Layanan - Platform sebagai Layanan
  3. SaaS - Perangkat Lunak sebagai Layanan Perangkat Lunak sebagai Layanan






Untuk pemahaman yang sangat sederhana tentang perbedaannya, mari kita lihat model Pizza-as-a-Service:







NIST mendefinisikan fitur yang diperlukan berikut dari layanan TI untuk dianggap berbasis cloud.



  • (broad network access) โ€“ , . โ€“ 220 (), , , .
  • (measured service) โ€“ . โ€“ , , , .
  • (on demand self service) โ€“ , . , . ( ) .
  • (rapid elasticity) โ€“ / ( ). โ€“ 3 , โ€“ .
  • (resource pooling) โ€“ () . , . .


Penting untuk dipahami bahwa karakteristik awan yang dijelaskan di atas tidak diambil dari langit-langit, tetapi merupakan kesimpulan logis dari konsep komputasi utilitas. Dan layanan publik harus memiliki karakteristik ini dalam konsepnya. Jika karakteristik ini atau itu tidak cocok, layanan tidak menjadi lebih buruk dan tidak menjadi "beracun", itu hanya berhenti menjadi keruh. Nah, siapa bilang semua layanan itu dibutuhkan?



Mengapa saya membicarakan hal ini secara terpisah? Dalam 10 tahun sejak definisi NIST diperkenalkan, ada banyak kontroversi tentang "kekeruhan yang sebenarnya" seperti yang didefinisikan. Di Amerika Serikat, frasa "sesuai dengan hukum, tetapi tidak dengan semangat" kadang-kadang masih digunakan di lingkungan peradilan - dan dalam kasus komputasi awan, yang utama adalah semangat, sumber daya untuk disewa dalam dua klik.



Perlu dicatat bahwa 5 karakteristik di atas berlaku untuk cloud publik, tetapi ketika pindah ke cloud pribadi, sebagian besar menjadi opsional.



  • Akses jaringan yang luas - Dalam cloud pribadi, organisasi memiliki kendali penuh atas kapasitas pembangkit dan pelanggan konsumen. Dengan demikian, karakteristik ini dapat dianggap terpenuhi secara otomatis.
  • (measured service) โ€“ utility computing, . ? , , - . . : chargeback ( ) showback ( , ).
  • (on demand self service) โ€“ , . - - . โ€“ .
  • (rapid elasticity) โ€“ . . โ€“ .
  • (resource pooling) โ€“ , . .


Pertanyaan: Jadi, apa sebenarnya cloud pribadi Anda? Apa yang perlu dibeli dan diterapkan perusahaan untuk membangunnya?



Jawaban: awan pribadi adalah transisi ke model administratif baru interaksi Bisnis-TI, yang merupakan 80% tindakan administratif dan hanya 20 teknologi.



Membayar hanya untuk sumber daya yang dikonsumsi dan kemudahan masuk, tanpa harus mengubur ratusan juta minyak dalam belanja modal, telah menciptakan lanskap teknologi baru dan munculnya perusahaan-perusahaan miliarder. Misalnya, raksasa modern Dropbox dan Instagram muncul sebagai perusahaan rintisan di AWS tanpa infrastruktur milik mereka sendiri.



Perlu ditekankan bahwa alat manajemen layanan cloud menjadi lebih banyak proxy, dengan sumber dan kontrol kualitas menjadi tanggung jawab CIO utama. Mari kita lihat tantangan dari dua tanggung jawab baru ini.



Muncul sebagai alternatif dari infrastruktur berat klasik dengan pusat data dan perangkat kerasnya sendiri, awan tampak ringan. Sangat mudah untuk masuk ke cloud, tetapi masalah keluar biasanya dilewati. Seperti halnya industri apa pun, penyedia cloud berkomitmen untuk melindungi bisnis dan mempersulit persaingan. Satu-satunya momen kompetitif yang serius muncul hanya selama pilihan awal penyedia layanan cloud, dan kemudian pemasok akan melakukan segala upaya agar pelanggan tidak meninggalkannya. Selain itu, tidak semua upaya diarahkan pada kualitas layanan atau jangkauannya. Pertama-tama, ini adalah pengiriman layanan unik dan penggunaan perangkat lunak sistem non-standar, yang membuatnya sulit untuk beralih ke penyedia lain. Masing-masing,Saat memilih penyedia layanan, penting untuk secara bersamaan membentuk rencana transisi dari penyedia ini (pada kenyataannya, DRP lengkap - rencana pemulihan bencana) dan memikirkan arsitektur penyimpanan data dan salinan cadangan.



Aspek penting kedua dari tanggung jawab baru CIO adalah mengontrol kualitas layanan dari pemasok. Hampir semua penyedia cloud mematuhi SLA menurut metrik internal mereka sendiri, yang dapat memiliki arti yang sangat tidak langsung bagi proses bisnis pelanggan. Dan karenanya, implementasi sistem pemantauan dan kontrol kami sendiri menjadi salah satu proyek utama saat mentransfer sistem TI yang signifikan ke penyedia cloud. Melanjutkan topik SLA, harus ditekankan bahwa sebagian besar penyedia cloud membatasi kewajiban untuk tidak terpenuhinya SLA dalam biaya langganan bulanan atau sebagian kecil dari pembayaran. Misalnya, AWS dan Azure, setelah melebihi ambang ketersediaan 95% (36 jam per bulan), akan memberikan diskon 100% untuk biaya bulanan, dan Yandex.Cloud - 30%.







https://yandex.ru/legal/cloud_sla_compute/



Dan tentu saja, kita tidak boleh lupa bahwa awan tidak hanya dilakukan oleh mastodon kelas Amazon dan gajah kelas Yandex. Ada juga awan yang lebih kecil - seukuran kucing, atau bahkan tikus. Seperti yang ditunjukkan contoh CloudMouse, terkadang cloud mengambil dan mengakhiri begitu saja. Anda tidak akan menerima kompensasi atau diskon - Anda tidak akan menerima apa pun kecuali kehilangan data total.



Mengingat masalah di atas dengan implementasi sistem TI kelas tinggi dari kekritisan bisnis dalam infrastruktur cloud, fenomena "repatriasi cloud" telah diamati dalam beberapa tahun terakhir.







Pada tahun 2020, komputasi awan telah melewati puncak ekspektasi yang meningkat dan konsepnya sedang menuju ke jurang kekecewaan (menurut siklus hype Gartner). Menurut penelitian IDC dan 451 Research hingga 80% pelanggan korporat kembali dan berencana mengembalikan muatan dari cloud ke pusat data mereka sendiri karena alasan berikut:



  • Meningkatkan ketersediaan / kinerja;
  • Mengurangi biaya;
  • Untuk memenuhi persyaratan IS.


Apa yang harus dilakukan dan bagaimana semuanya "benar-benar"?



Tidak diragukan lagi bahwa awan telah datang dengan sungguh-sungguh dan untuk waktu yang lama. Dan setiap tahun peran mereka akan semakin meningkat. Namun, kami tidak hidup di masa depan yang jauh, tetapi di tahun 2020 dalam situasi yang sangat pasti. Apa yang harus dilakukan dengan cloud jika Anda bukan pemula tetapi pelanggan korporat klasik?



  1. Awan pada dasarnya adalah tempat untuk layanan dengan beban musiman yang tidak dapat diprediksi atau diucapkan.
  2. Dalam kebanyakan kasus, layanan dengan beban stabil yang dapat diprediksi lebih murah untuk dikelola di pusat data Anda sendiri.
  3. Anda perlu mulai bekerja dengan cloud dengan lingkungan pengujian dan layanan dengan prioritas rendah.
  4. Mempertimbangkan penempatan sistem informasi di cloud dimulai dengan pengembangan metode untuk pergi dari cloud ke cloud lain (atau kembali ke pusat data Anda sendiri).
  5. Menempatkan sistem informasi di cloud dimulai dengan mengembangkan skema cadangan untuk infrastruktur yang Anda kontrol.



All Articles