🧔 🤸🏻 🙇🏾 Server sendiri atau cloud publik? 👎🏿 🌶️ 📑

Ketika saya sekali lagi menyiapkan catatan analitik untuk manajemen tentang nuansa beralih ke cloud publik, saya perhatikan bahwa sebagian besar artikel tentang cloud (bahkan tentang Habré) ditulis oleh mereka yang menjualnya (walaupun ini, secara umum, logis). Oleh karena itu, saya memutuskan untuk mengubah catatan saya sedikit ke gambar yang lebih umum dan meletakkannya di sini. Dengan demikian, argumen tentang kelayakan penggunaan cloud publik tidak lagi dari perspektif mereka yang menjual cloud, tetapi dari perspektif mereka yang menggunakannya. Saya akan segera memperingatkan Anda bahwa saya tidak akan menarik kesimpulan yang pasti (atau menyebutkan merek).

Situasi cloud berbeda. Misalnya, di perusahaan yang jauh dari TI, beberapa tahun yang lalu, saya dengan susah payah meyakinkan direktur untuk membawa beberapa layanan ke cloud publik, karena pemeliharaan staf administrator server yang berkualifikasi hanya demi mengawal mesin virtual ini tidak akan pernah berhasil, dan eneykeyschiki, melayani komputer pribadi, tidak cukup cocok untuk tugas seperti itu. Kemudian mereka tidak mendengarkan saya, tetapi kemudian hidup tanpa ampun membuktikan saya benar: mereka tidak bisa mendapatkan ahli pada anggaran yang tersedia, mereka tidak membeli besi, dan sebagai hasilnya semuanya meringkuk, setelah itu server pindah ke cloud. Dalam kasus lain, operator telekomunikasi yang sangat besar secara terus-menerus ingin mentransfer 500 mesin virtual perusahaan kami (yang sudah berbeda) ke dirinya sendiri. Dengan harga sewa yang rendah. Dan kemudian saya sudah berpegang pada kebalikannya, anti-cloud,posisi. Bagaimanapun, cloud publik adalah alat yang hebat, tetapi, sayangnya, bukan peluru perak. Mengapa - Saya akan mencoba untuk mengungkapkan sudut pandang saya di bawah potongan.

Cloud sekarang disebut segalanya, jadi mari kita segera memutuskan persyaratannya. Cloud adalah model penyediaan akses sesuai permintaan ke dana umum tertentu dari sumber daya komputasi yang dapat dikonfigurasi (definisi untuk Wikipedia [ 1 ], disingkat menjadi konteks kita ). Menurut model cloud, berbagai layanan dapat disediakan:

VPS / VDS (Virtual Private / Dedicated Server - penyewaan mesin virtual),
VDI (Virtual Desktop Infrastructure - penyewaan desktop virtual),
sudah dangkal dan hosting aplikasi web sedikit sekarat,
SaaS (Perangkat Lunak sebagai Layanan - rental aplikasi),
IaaS (Infrastruktur sebagai Layanan - sewa infrastruktur),
DaaS (Desktop sebagai Layanan - nama pemasaran lain untuk VDI),
BaaS (Cadangan sebagai Layanan - infrastruktur rental untuk cadangan)
«…aaS», .

Bahkan, semua keragaman ini bermuara pada penyewaan mesin virtual dengan satu atau lain nuansa akses dan perangkat lunak yang diinstal.

Awan bersifat pribadi (beroperasi di fasilitas perusahaan untuk menyelesaikan masalah) dan publik (beroperasi untuk berbagai orang berdasarkan operator). Pembaruan dari komentar: layanan seperti cloud pribadi virtual kini telah muncul . Ini adalah saat sebagian dari milik Anda dicadangkan untuk Anda di cloud publik, yang dapat Anda kelola lebih fleksibel daripada set mesin virtual biasa. Tetapi ini masih merupakan cloud pribadi virtual, bukan cloud pribadi.

Lebih lanjut, ini akan membahas tentang cloud publik, yang untuk kesederhanaan saya sebut sebagai cloud. Dari sudut pandang masalah yang dipertimbangkan, tidak begitu penting bahwa sumber daya komputasi perusahaan disajikan: cloud pribadi atau server klasik untuk tugas individu. Oleh karena itu , saya akan memanggil agregat dari sumber daya komputasi kita sendiri dari server lokal perusahaan atau hanya server , tanpa masuk ke kekhasan organisasi proses komputasi. Dengan demikian, perbandingan yang dijanjikan akan dibuat antara penyewaan sumber daya komputasi ("cloud") dan sumber daya kita sendiri ( ~~"ide Juche"~~ "server"). Ini berdasarkan pengalaman pribadi saya dan pengalaman berkomunikasi dengan rekan kerja. Tentu saja, saya tidak berpura-pura menjadi ulasan independen yang komprehensif, jadi saya mengundang semua orang yang tidak setuju untuk memberikan komentar dalam komentar. Mungkin ini akan memungkinkan Anda untuk menemukan kesalahan atau melengkapi perbandingan.

Jadi, mari kita bandingkan dua pendekatan yang dijelaskan sesuai dengan sejumlah kriteria. Bagi mereka yang terlalu malas untuk membaca seluruh teks, saya menyoroti huruf miring di setiap paragraf , sehingga Anda dapat melewati apa yang jelas bagi Anda dan tidak membaca semuanya.

Perbandingan cloud dan server asli

Biaya

Anda sering dapat menemukan klaim bahwa awan menghemat TI. Memang benar, tetapi tidak selalu. Untuk mendapatkan manfaat dari hosting awan, Anda perlu memahami mekanisme pembentukannya: tidak ada keajaiban, terutama di bidang ekonomi. Jika Anda tidak hanya mengurangi biaya, tetapi juga memberikan perantara antara Anda dan besi (operator cloud) untuk mendapatkan roti dan mentega, ini dapat dijelaskan sebagai berikut.

- . , – - ( , , ..). , – [2] (, , , ..). , . 18 2 , ( ) ( ). . - – .
. – . , , , , . , 4 ! , , . , , , . , 3 ( , ). . , . , . , , . . , . - .
. « », . , , . , HPE « » , - .

Total: penghematan saat menggunakan cloud tergantung pada volume. Semakin sedikit kebutuhan Anda akan sumber daya komputasi, semakin menguntungkan untuk menyewa. Bukan tanpa alasan pemain besar pasar TI membangun pusat data mereka sendiri.

Tetapi tidak hanya biaya langsung yang harus diperhitungkan ketika mendukung solusi teknis. Penilaian risiko keuangan (misalnya, pelanggaran ketersediaan layanan) dan biaya tambahan (misalnya, untuk cadangan penuh di luar cloud) dapat mengubah segalanya, bahkan jika cloud pada awalnya tampaknya merupakan solusi yang menguntungkan. Nuansa ini akan dijelaskan nanti.

Fleksibilitas

Alasan tentang biaya di atas berlaku untuk hosting server jangka panjang. Tetapi juga terjadi bahwa kapasitas diperlukan sekali, untuk waktu yang singkat: untuk beberapa jenis acara, karya ilmiah, dll. Contoh-contoh utama termasuk Olimpiade, Piala Dunia, Universiade, atau telecommuting massal selama pandemi virus baru ("sial terjadi"). Oleh karena itu, bahkan jika Anda memerlukan sejumlah besar server dan infrastruktur, tetapi untuk waktu yang singkat setelah itu mereka akan menjadi tidak berguna, maka memperoleh sumber daya Anda sendiri dan membangun sistem teknik tidak akan berhasil (dan bukan fakta bahwa Anda akan berhasil melakukan ini). Lebih mudah disewa.

Untuk peristiwa kecil, persyaratan sumber daya, yang penting bagi Anda, dapat berubah menjadi kesalahan statistik untuk operator.

Untuk proyek besar, tidak setiap operator cloud memiliki fleksibilitas untuk menyediakan 100.500 mesin virtual atas permintaan pertama Anda. Tetapi bahkan dalam kasus ini, ketika operator berencana untuk membelinya, dalam model pengembalian, ia hanya akan mentransfer sebagian dari biaya ke proyek Anda, mengandalkan penyewaan selanjutnya dari sumber daya ini ke pelanggan lain.

Total: untuk acara yang mendesak dan sekali pakai, menghitung penyewaan daya sangat sesuai. Awan lebih fleksibel terhadap kebutuhan. Dan ini bukan hanya masalah harga, tetapi juga waktu: operator sudah memiliki personel yang memenuhi syarat, rencana penskalaan dan pengalaman yang tidak dapat dengan cepat dibeli bahkan untuk banyak uang.

CapEx vs. OpEx

Bisnis suka mengkonversi biaya modal (CapEx) ke operasional (OpEx). Ini terutama menyukai semua jenis direktur keuangan yang bercerai dari "fisika" proses. Mereka lebih disukai untuk membayar secara teratur dalam porsi kecil, bahkan jika ada pembayaran lebih, daripada membeli beberapa jenis sumber daya sekaligus dan kemudian mendepresiasinya untuk waktu yang lama. Itu orang-orang ini menyewa server yang menguntungkan daripada membelinya. Dan di sini butiran penjual awan jatuh di tanah subur. Ekonom akan dengan senang hati mengirim perusahaannya ke cloud, meskipun ada serangan jantung dari direktur TI atau kepala departemen yang bertanggung jawab untuk keamanan.

Tetapi banyak hal berubah secara tak terduga ketika menyangkut perusahaan negara atau semi-negara. Dalam kebanyakan kasus, mereka lebih suka CapEx daripada biaya operasi. Selain itu, ini tidak terjadi sama sekali dari keinginan untuk menyelamatkan, tetapi dari fitur perencanaan. Tugasnya sering ditetapkan sebagai berikut: "Apa yang akan kita beli sekarang, sehingga kita dapat menggunakannya untuk waktu yang lama ketika tidak ada uang?" Setidaknya inilah yang terjadi dalam pendidikan Rusia, perawatan kesehatan, sains, dll. Secara berkala mereka diberikan program untuk pengembangan, daya saing, modernisasi, digitalisasi, dll. Fakta bahwa peralatan mahal yang dibeli memiliki tenggat waktu untuk pekerjaan yang direkomendasikan (dan bukan "sampai rusak"), dan juga bahwa itu tidak perlu perawatan gratis, perbaikan, suku cadang, dll.(dengan perkiraan yang sangat kasar, 10-15% dari biaya peralatan untuk setiap tahun operasi diletakkan) biasanya tidak diperhitungkan. Tapi ini adalah topik untuk diskusi lain.

: , OpEx, – CapEx. , « – », .

Untuk beberapa alasan, para pemimpin sering melihat pendapat bahwa awan itu sangat mudah diakses: "kami akan memberikannya kepada para profesional outsourcing dan akan meminta seseorang (dan mengapa tidak - semuanya bekerja untuk mereka seperti itu)".

Tapi masalahnya adalah semua orang jatuh. Itu saja. Baik profesional dan amatir. Seseorang lebih jarang, seseorang lebih sering. Tapi cepat atau lambat, itu saja. Google, Yandex, Amazon jatuh. Penting di sini bagaimana konsekuensi dari kejatuhan seperti itu dihilangkan. Dan kemudian, apakah Anda sendiri dapat melakukan sesuatu dalam keadaan darurat atau menunggu belas kasihan penyedia (yaitu apakah Anda memiliki cadangan dan kapasitas cadangan). Sebagai contoh, pada tahun 2011 1C-Bitrix jatuh ke awan dari Amazon [ 3 ] (dalam artikel, kesimpulan yang bagus, omong-omong); tetapi pada tahun 2018, Bitrix24 menghabiskan tiga hari (!) di cloud CorpSoft [ 4] Selain itu, dalam kasus terakhir, menurut para korban, mereka memesan layanan penempatan di dua pusat data yang seharusnya independen dari satu operator, tetapi ... keduanya jatuh secara bersamaan. Oleh karena itu, untuk sistem yang sangat kritis, lebih baik menggunakan tidak hanya pusat data yang berbeda, tetapi juga aset data dari operator yang berbeda.

Penyebab kegagalan pusat data tidak hanya kegagalan teknis. Masih ada masalah hukum. Jadi, misalnya, baru-baru ini aset dibagikan oleh pemilik Ayhor [ 5 ] dan Masterhost [ 6 ]. Pertikaian ini menghasilkan penghentian tak terduga mobil-mobil pelanggan. Sangat tidak menyenangkan. Dan ini adalah alasan lain untuk menggunakan operator cloud yang berbeda untuk cadangan.

Roskomnadzor menambahkan sedikit panas pada ketersediaan awan, ketika pada tahun 2018 mulai memblokir secara acak alamat situs asing dan bahkan Rusia dengan cara persegi dalam pertempuran melawan telegram. Bahkan tidak akan memberikan tautan - semua orang sudah tahu.

Karena banyaknya risiko, beberapa perusahaan mengandung replika sumber daya mereka dari operator yang berbeda di berbagai negara (terutama yang pasarnya menjadi fokus kegiatan mereka). Tetapi semua ini mempengaruhi biaya awan.

Contoh yang saya kutip adalah, tentu saja, kasus-kasus penting (dan tidak berarti semua), tetapi ratusan dan bahkan ribuan tetes kecil (mengambil kesempatan ini, saya mengirim salam kepada Mikhail Klimarev, pemilik saluran ZaTelecom , di mana ada bagian yang menarik #HERAX).

Total: rumor tentang keandalan awan sangat dilebih-lebihkan. Mereka menderita tidak hanya karena kegagalan teknis, tetapi juga karena tindakan pemilik, pihak berwenang dan bahkan penyewa lainnya (ada awan dengan reputasi beracun yang diblokir oleh firewall dan antivirus). Jika ketersediaan layanan sangat penting bagi Anda, maka saat menggunakan cloud, Anda harus memiliki rencana "pendaratan" darurat atas kapasitas Anda sendiri atau ke operator lain (setidaknya dalam bentuk yang disingkat).

Beban jaringan

Ketika merencanakan pindah ke cloud, faktor ini terkadang diremehkan. Kita tidak boleh melupakan proses ini:

cadangan cadangan di luar cloud (semua cloud menawarkan cadangan pada kapasitasnya, tetapi jika Anda memerlukan data, Anda harus menyimpannya di suatu tempat di luar; ingat saja pusat data Aichora yang tidak aktif);
, - ;
, , ( , , ).

: . .

Mentransfer data dari satu cloud ke cloud lain itu sulit.

Pertama, karena terbatasnya bandwidth jaringan yang kita bicarakan (bayangkan bahwa Anda memiliki kebutuhan yang tajam untuk mengambil beberapa TB dalam keadaan terbaru, dan bahkan melakukannya dengan cepat, yaitu, tanpa menghentikan virtual mobil).

Kedua, karena kurangnya alat universal. Pemilik cloud tidak tertarik Anda mengambil mesin virtual dari mereka dan tidak bekerja dengan baik ke arah ini.

Ketiga, jika cloud "jatuh", maka Anda sudah tidak memiliki alat untuk ekstraksi data. Di pusat data Anda, pada akhirnya, Anda bahkan dapat menghapus disk dari peralatan yang tidak berfungsi. Di cloud, trik semacam itu tidak akan berhasil. Dan di sini kita kembali lagi ke replika dan cadangan yang dibuat sebelumnya.

Tetapi ada sisi lain dari koin. Beberapa pemilik data takut pemblokiran atau pencurian mereka lebih dari kehilangan. Sekarang kita tidak akan membahas secara terperinci dalam kasus mana hal itu diperlukan, tetapi, saya pikir, banyak profesional TI mengalami masalah seperti itu dalam praktik mereka. Dalam hal ini, pelanggan, sebaliknya, tertarik pada cloud yang berlokasi di suatu tempat yang jauh dari kantor, lebih disukai di negara lain.

Memang, itu terjadi bahwa orang-orang di topeng datang ke kantor dan menyegel pusat data atau mengambil server. Data cloud, di yurisdiksi lain, kemungkinan besar tidak akan terpengaruh. Dan jika terjadi force majeure, setidaknya bagian online bisnis akan dapat melanjutkan pekerjaannya. Atau, minimal, data tidak akan bocor.

Secara teoritis, sebuah situasi dimungkinkan, ketika sebaliknya, data dan perangkat keras di pusat data jarak jauh akan ditangkap. Tapi di sini semuanya tergantung pada sifat aktivitas Anda dan siapa musuh Anda (atau siapa musuh Anda).

Total: jika Anda takut akan penghapusan atau pemblokiran data fisik, maka cloud jarak jauh akan membantu Anda. Tapi itu juga bisa menjadi masalah, dengan masalah dengan ketersediaannya.

Keamanan keuangan

Dikatakan di atas bahwa menarik data dari cloud tidak mudah. Terutama ketika datang untuk pindah ke sistem kompleks tempat tinggal permanen dengan banyak hubungan. Untuk perusahaan besar, perubahan cloud adalah keseluruhan cerita yang dapat berlangsung selama bertahun-tahun. Operator cloud memahami ini, oleh karena itu, ia bertindak dengan pelanggannya seperti dealer yang duduk di "produk" -nya. Pertama gratis, lalu diskon individual, dan kemudian Anda bisa menaikkan harga.
Pada akhir 2019, sebuah cerita yang tidak menyenangkan terjadi: RosNIIROS menjual hampir 490 ribu alamat IP "putih" -nya, yang disewakan kepada organisasi-organisasi pendidikan, ilmu pengetahuan dan lain-lain, perusahaan Komunikasi Andal Handal. Hal pertama yang dilakukan pemilik baru adalah menaikkan harga sewa alamat ini 10-12 kali. Dan hanya karena bisa (dan karena RIPN mempertahankan pelanggannya dengan harga "di bawah pasar"). Tapi kemudian kantor kejaksaan bersemangat, meskipun bukan karena kenaikan harga, tetapi untuk aspek-aspek lain dari kesepakatan itu. Dan kesepakatan itu dimenangkan kembali [ 7 ]. Harga kembali ke level sebelumnya, tetapi sedimen tetap ada.

Contoh ini tidak terlalu mempedulikan pasar cloud, tetapi situasi serupa mungkin terjadi. Bayangkan Anda memiliki bisnis TI yang besar dan beberapa operator berwarna kuning melamar Anda: karena ukuran dan posisi pasar Anda yang luar biasa, Anda akan menerima diskon 80% dan menggunakan cloud kami. Anda setuju dan pindah. Selama beberapa tahun, semuanya baik-baik saja, pemodal senang, Anda sudah menjual layanan murah kepada pelanggan Anda dan Anda cukup terbiasa dengan harganya ... karena operator kuning mulai mengalami masalah karena kebijakan tarifnya yang keliru, "memotong tulang", mengumumkan cloud sebagai aset non-inti dan menjualnya kepada operator biru . Pemilik baru cloud memberi tahu Anda bagaimana ia menghargai pelanggan lama, tetapi tetap ramah dan membayar pasar. Dan di sini pengeluaran Anda meningkat tajam lima kali lipat. Menurut pendapat saya, ini adalah skenario yang sangat nyata, meskipun masih belum memiliki tempat dalam kehidupan.Dan bahkan jika Anda memiliki perjanjian rumit yang membatasi pertumbuhan nilai, kemungkinan besar ada cara untuk menghentikannya.

Pada akhirnya, Anda tidak aman dari kenyataan bahwa operator cloud sama sekali tidak memasukkan pengembangan dalam tarifnya, dan kemudian dihadapkan dengan kebutuhan untuk investasi besar dan akan menaikkan harga (atau hanya menutup). Ini terjadi ketika manajer hidup satu hari dan menit KPI.

Total: hati-hati dengan diskon dan penawaran khusus di cloud. Mereka datang dan pergi, dan infrastruktur untuk waktu yang lama. Anda harus selalu siap untuk menahan harga pasar.

Persyaratan staf

Ketika Anda memelihara armada kecil dari server Anda sendiri (misalnya, beberapa server produksi dan penyimpanan), Anda mungkin mengalami masalah personel. Anda tidak punya tempat untuk mengambil personel dari kualifikasi yang sesuai untuk pemeliharaan perangkat keras, lingkungan virtualisasi, dan cadangan yang kompeten. Dan masalahnya bukan hanya uang. Industri administrasi server berubah sangat cepat. Oleh karena itu, seseorang dengan kualifikasi yang baik hanya akan bosan, dan dia akan secara bertahap menurunkan dalam bidang kegiatan yang kecil ("overkvalifayd", seperti dikatakan petugas personalia), dan seseorang yang Anda ambil "untuk pertumbuhan" dapat dengan cepat meninggalkan Anda (atau sebaliknya berlama-lama, tidak terlalu membaik). Selain itu, satu administrator selalu merupakan titik kegagalan. Minimal diperlukan 2-3 orang yang dapat mengasuransikan satu sama lain saat liburan dan cuti sakit.

Dalam kasus seperti itu, outsourcing administrator, kontrak diperpanjang untuk administrasi server, atau cloud publik yang sedang kita bahas membantu.

Untuk proyek kecil, penyebaran cloud mesin, penghapusan cadangan, dll. Dibutuhkan beberapa klik (ini benar-benar membongkar muatan) dan akan memungkinkan Anda menghemat staf. Tetapi proyek yang kompleks, interaksi beberapa awan dengan replikasi dan pemantauan mungkin, sebaliknya, membutuhkan lebih banyak orang dengan keterampilan yang sama sekali berbeda.

Total: cloud relevan untuk Anda jika volume pemeliharaan tidak memungkinkan Anda mempertahankan setidaknya satu departemen kecil administrator "perangkat keras" dengan beban yang kurang lebih seragam. Dalam hal ini, Anda dapat menghemat staf. Tetapi transisi ke cloud untuk proyek-proyek besar tidak selalu mengarah pada pengurangan staf dan bahkan sebaliknya dapat meningkatkannya.

Kepatuhan SLA

Perjanjian Tingkat Layanan, alias SLA, alias perjanjian kualitas layanan tidak selalu dapat diverifikasi. Anda tidak dapat terus-menerus menggerakkan benchmark, dan hanya memantau kinerja mesin virtual mungkin tidak selalu menunjukkan masalah. Operator, dengan sengaja atau tidak sengaja, dapat membatasi kecepatan baca, kuota CPU yang disediakan, bandwidth jaringan, dan sebagainya.

Selain itu, Anda tidak dapat memeriksa terlebih dahulu janji penyedia tentang independensi platform (lihat kasus Bitrix24 di atas) dan waktu pemecahan masalah tipikal. Di sini hanya kepercayaan Anda, yang bukan hal yang paling dapat diandalkan. Operator, sebaliknya, mengetahui tentang probabilitas rendah dari kecelakaan yang sangat besar, mungkin tidak berinvestasi dalam reservasi selama bertahun-tahun dan menghemat teknologi dan orang-orang yang hidup untuk hari ini. Tentu saja, hanya orang yang sangat buruk dan rakus yang melakukan ini. Tetapi mereka ada.

Total: cloud SLA mungkin tidak memenuhi harapan / perjanjian karena penghematan tersembunyi dari operator. Membuktikannya mungkin sulit atau tidak mungkin.

Persyaratan resmi

Seperti kata pepatah, " Dura Lex, Sed Lex ": banyak negara membuat persyaratan untuk perlindungan informasi wajib (data pribadi, rahasia bank, dll). Kepatuhan terhadap persyaratan nasional adalah yang terbaik (dan terkadang hanya mungkin) di cloud nasional atau di pusat data Anda sendiri. Misalnya, bermasalah untuk memproses data warga Federasi Rusia di cloud Amazon. Minimal, salinannya harus di server domestik.

Itu juga terjadi bahwa Lex modern di bidang keamanan informasi terlalu Dura, tetapi juga tidak mungkin dilakukan (saya tidak akan memberikan contoh, agar tidak terlalu banyak membahas tentang kelayakan langkah-langkah tertentu dari paket terkenal). Maka lebih baik untuk membeli layanan cloud dari operator yang siap mengambil semua risiko pada dirinya sendiri. Bahkan, itu bertindak sebagai "atap" (beberapa operator besar adalah teman baik dengan pihak berwenang, oleh karena itu, mereka dengan mudah mengambil kewajiban dan layanan tersebut). Tetapi mungkin ternyata keamanan cloud hanya di atas kertas atau hanya terhadap ancaman tertentu (sekali lagi, lihat sejarah Bitrix24, di mana perusahaan memilih hosting untuk persyaratan regulator).

: – . , , , .

Beberapa sistem teknik dan ilmiah sangat, sangat buruk dalam pindah ke cloud. Baik untuk alasan keamanan (alarm pencuri, kontrol akses dan sistem manajemen - ACS, sistem kontrol proses otomatis - APCS) atau untuk alasan biaya (pengawasan video jika berisi ratusan dan ribuan kamera, komputer khusus, superkomputer, hasil multi-terabyte) computed tomography, dll.). Organisasi pengoperasiannya hanya dipaksa untuk mempertahankan infrastruktur rekayasa server atau pusat data kecil. Biaya-biaya ini berhubungan dengan biaya konstan bersyarat, oleh karena itu, jika sudah ada, organisasi dapat menggunakannya untuk mengatur proses komputasi lainnya.

Saya juga mencatat bahwa sistem rekayasa pusat data bisa lebih mahal daripada komputasi dan pengisian perangkat lunaknya. Dan dalam hal keandalan, mereka tidak boleh kalah dengan solusi TI yang sebenarnya. Dan di sini juga, mungkin ada prasyarat untuk menabung. Misalnya, jika Anda memiliki akses ke listrik yang sangat murah dan tidak terputus (terpelihara dengan baik), atau sistem pendingin yang kuat, atau kamar Anda sendiri yang tidak digunakan, atau sesuatu seperti itu, mengembangkan pusat data Anda sendiri mungkin lebih menguntungkan daripada awan.

: , , . - . - , .

Dari semua hal di atas dapat disimpulkan bahwa penggunaan awan memiliki banyak nuansa. Jika Anda membayangkan bisnis kecil atau menengah yang diprediksi akan berkembang, yang penting secara lokal dengan profil non-TI, maka cloud adalah pilihan Anda. Dalam semua kasus lain, perlu untuk mempertimbangkan dengan cermat tidak hanya biaya langsung, tetapi juga risiko terhadap bisnis dan reputasi.
Saya berharap semua yang ditulis di sini bermanfaat bagi seseorang. Setidaknya bos saya menyukai laporan tentang kemungkinan pindah ke cloud, atas dasar yang saya tulis artikel ini secara umum.

Server sendiri atau cloud publik?