Sejarah ekonomi industri adalah sejarah konsumsi sumber daya yang terbatas. Dalam kasus listrik, ada puncak malam yang jelas, dan karena itu pemilik pembangkit listrik melobi transportasi perkotaan modern, dan dibuat dari awal, pada kenyataannya, industri elektronik konsumen. Artinya, mereka mengubah cara hidup jutaan, sehingga pembangkit listrik dimuat lebih merata.
Sumber daya komputer memiliki cerita yang serupa. Jarang ada orang yang menggunakannya secara efektif. Mari kita bicara tentang eksploitasi dan sedikit tentang generasi pemrograman berikutnya untuk lingkungan seperti itu di mana sangat fleksibel untuk berbagi sumber daya.
Konsumsi musiman
Konsumsi musiman pelanggan musiman terlihat seperti 11 bulan tenang dan sebulan dua kali lipat. Semua orang tahu puncaknya. Ritel membekukan semua kegiatan pada bulan Desember dan penjualan Tahun Baru, mendapat mesin virtual. Setiap orang masih memiliki musim diskon dan penjualan besar - untuk seseorang pada 1 September, untuk hadiah pada 8 Maret, dan seterusnya. Semua layanan B2C memiliki aktivitas musiman yang dapat dipahami hanya dengan jam kerja, misalnya, dengan bank Internet. Kami di Technoserv Cloud tidak merencanakan pekerjaan pemeliharaan untuk periode ini.
Ahli geologi pulang dari ekspedisi dan mulai menghitung fosil mereka di awan. Di perusahaan besar, laporan pada akhir periode dikumpulkan dari sekelompok subsistem - di suatu tempat secara efisien, dan di suatu tempat dengan derit, hampir sampai ke titik dampak. Pembelajaran mesin dan analitik memberikan beban yang sangat besar, tetapi mereka tidak melakukan ini secara permanen.
Puncak musim panas adalah industri wisata, tetapi mereka tidak memiliki lompatan yang signifikan, tetapi ada DDoS di musim, biasanya ketika orang pergi untuk membeli tiket untuk liburan Mei.
Konsumsi normal
Pelanggan rata-rata kami di cloud kami mengonsumsi sumber daya dengan “gergaji harian”: di pagi hari dengan awal hari kerja, kenaikan dimulai, pada sore hari penurunan singkat, pada malam hari penurunan 2-3 kali. Di malam hari, tugas-tugas sistem diluncurkan - pencadangan, limpahan data dalam analisis, inventaris ritel dan perhitungan inventaris logistik, prakiraan penjualan. Keuangan memiliki sejarah kredit yang berbeda dan cache lainnya. Tidak ada ABS di awan, mereka, operator seluler dan perusahaan seperti kereta api telah membersihkan pada malam hari, yaitu, saldo harian untuk semua operasi berkurang. Ini, relatif berbicara, bukan untuk masuk di malam hari, tetapi untuk mengumpulkan transaksi serupa ke dalam paket dan saling mengimbangi selama periode tersebut.
Secara umum, kantor biasa "melihat". Admin paling canggih sudah menentukan skala, tetapi sejauh ini kami hanya melihat contoh yang terisolasi.
Dalam kasus sederhana, tampilannya seperti ini: naikkan mesin virtual lain pada pukul 11:00, letakkan dengan layanan di balancer, berimigrasi dengan lembut pada pukul 19:00 dan lunasi. Artinya, pembayaran hanya untuk sepertiga hari, dan pada waktu puncak ketersediaannya sama dengan penyewaan permanen mesin virtual tambahan.
Ini karena kami memiliki diskritisasi jam Pelanggan kami sering tertarik dengan variasi lain dari skrip ini - autoscaling. Ketika konsumsi sumber daya naik hingga 80%, mesin lain naik. Jatuh ke batas tertentu - mobil mati. Dalam kontrak keuangan, kami memiliki pay-as-you-go, yaitu pasca-pembayaran untuk sumber daya yang benar-benar dikonsumsi, kuantisasi VMs per jam. Di konsol, Anda dapat meningkatkan sendiri jumlah mobil. Administrator masuk dan melakukan ini dengan tangannya di bawah beban (misalnya, pada Black Friday, ketika beban di situs tumbuh), atau ia menulis skrip yang memulai dan memadamkan VM. Ada satu perusahaan, pengembang, secara kondisional, aplikasi perbankan - mereka membutuhkan autoscaling untuk pengujian dan puncak penggilingan database. Mereka memiliki arsitektur yang sangat cocok untuk otomatisasi, dan bersama mereka kami menguji sistem yang sepenuhnya otomatis ketika cloud itu sendiri mengalokasikan jumlah VM yang tepat. Yaitu, bagaimana, dengan sendirinya - melalui server vitnes terpisah (VM khusus atau mesin eksternal), yang dapat mengelola beban, distribusi aplikasi, dan menyeimbangkan melalui API. Mereka mendapatkan autoscaling terlebih dahulu, membantu memprioritaskan dengan benar. Dan pada saat yang sama mereka bekerja sebagai penguji bagi kita, pada kenyataannya. Produk ini ditulis sangat murah sesuai dengan kebutuhan mereka: kami tidak memiliki layanan seperti itu di cloud sebagai layanan plug-in, tetapi kami sedang bereksperimen. Sejauh ini, semuanya manual, ditambah alfa ini: kami memiliki semua laporan dan percakapan terperinci dari teknolog produk dengan pengembang mereka untuk pekerjaan itu. Dengan demikian, sebuah produk lahir yang akan dibutuhkan oleh semua tim tersebut.
Fitur Arsitektur Perangkat Lunak
Mengapa ada beberapa admin autoscaling, meskipun ini lebih menguntungkan? Karena untuk skala yang tepat beban di cloud, Anda harus memiliki aplikasi dan arsitektur database yang disiapkan. Jika aplikasi seperti front web biasanya berskala mudah, maka menulis ke database sudah menjadi pertanyaan yang lebih menarik. Tidak semua aplikasi hanya dipecah menjadi front-back atau layanan microser untuk mendistribusikannya ke mesin yang berbeda.
Mereka yang memilikinya - mereka, tentu saja, menyelamatkan. Dan mereka mendapatkan nilai tambah untuk stabilitas, yang kami tulis di sini di posting tentang
kesalahan arsitektur umum .
Secara alami, Anda perlu menulis ulang perangkat lunak untuk ini. Yang tidak selalu memungkinkan dengan cepat dan pada prinsipnya tidak selalu mungkin.
Tetapi generasi selanjutnya dari sejarah cloud terlihat lebih menarik.
Virtualisasi kontainer
Generasi berikutnya adalah wadah. Sekarang sepertinya semacam mesin virtual ringan dengan layanan microser yang naik selama penanganan dan dibongkar dari RAM tanpa adanya aktivitas. Artinya, mereka muncul dan digantikan sebagai aplikasi dalam RAM dan swap sistem operasi modern - seperti yang digunakan. Kedengarannya sederhana, dan banyak pemain besar telah menulis ulang arsitektur mereka secara khusus untuk wadah.
Artinya, ini bahkan bukan VM yang terpisah, tetapi hanya memprosesnya, seperti aplikasi Citrix Xen. Atau VM tua yang baik dalam wadah shell - yaitu, mesin yang sama dengan autoscaling dalam.
Tapi ini hanya langkah pertama. Faktanya adalah bahwa lebih jauh pada hal yang lebih menarik adalah kemasukan fungsi. Ini masih merupakan fantasi arsitek, tetapi jika Anda menulis kode segera di bawah sistem wadah pop-up, Anda dapat membungkusnya di setiap fungsi tunggal. Ada input, ada output dan ada "kotak hitam" - wadah itu sendiri. Fungsi ini disebut dalam kode - wadah "muncul", bekerja dan kembali untuk menunggu panggilan berikutnya.
Kode, tentu saja, harus refactor dan mengoptimalkan kembali keseluruhan. Tapi itu sepadan, dan ini adalah salah satu cabang masa depan yang mungkin. Menurut penilaian kami, memang benar bahwa itu sangat jauh - tiga tahun setidaknya sampai implementasi pertama dari raksasa dan 15 tahun sebelum penggunaan industri di Rusia.
Sementara itu, wadah - alas, produk untuk Geeks, karena tidak berfungsi dengan baik. Dan tidak ada permintaan untuk mereka di Rusia, tetapi ada permintaan untuk penskalaan. Dan tidak ada satu kontrak baru yang ditandatangani tanpa pay-as-you-go.