Artikel

Manfaat Komposabilitas dalam Arsitektur Cloud Pribadi

Jelajahi manfaat biaya dan performa komposabilitas dalam arsitektur cloud pribadi.

Daftar Isi

Manfaat Komposabilitas Arsitektur Cloud Pribadi Manfaat Komposabilitas Arsitektur Cloud Pribadi Manfaat Komposabilitas Arsitektur Cloud Pribadi

Menempatkan pusat data cloud pribadi secara bersamaan seperti membuat sebuah mobil sport dari awal. Pemilihan mesin, suku cadang, dan peralatan yang tepat demi memenuhi tuntutan performa di jalan raya serta pengemudi. Berkat inovasi perangkat keras dan perangkat lunak, arsitek TI dapat menggabungkan pusat data mereka untuk mendapatkan performa yang lebih seperti Lamborghini, bukan seperti mobil tua dari masa lalu.

Cloud pribadi lokal memerlukan pengawasan, manajemen, serta pemeliharaan yang konstan. Biaya operasional, seperti mengganti hard disk atau penyediaan berlebih, dapat bertambah dengan cepat dari waktu ke waktu. Hal ini meningkatkan total biaya kepemilikan (TCO) pusat data dan menguras laba perusahaan. Khususnya dengan pengambilan, pembuatan, dan pemanfaatan data yang tumbuh secara eksponensial setiap tahun.

Masalah tersebut merupakan alasan Seagate menyebut megatren komposabilitas yang akan dihadirkan saat ini sedang dalam proses. Pusat data canggih yang dapat disusun memungkinkan setiap server cloud pribadi terdiri atas komponen yang terpisah, tetapi saling berhubungan dengan jenis susunan dan bandwidth yang optimal. Komposabilitas memberikan cara fleksibel untuk mengelola dan mengakses data dari berbagai aplikasi dan alur kerja.

Arsitek TI harus menentukan apakah akan menggunakan solusi cloud pribadi lokal, atau cloud publik/pribadi yang dihosting oleh pihak ketiga. Cloud pribadi berbagi layanan komputasi di antara pelanggan yang berbeda serta yang dihosting di pusat data eksternal. Penyedia layanan cloud pihak ketiga juga menawarkan cloud pribadi yang dihosting, yang juga dihosting secara eksternal tanpa berbagi layanan.

Cloud lokal pribadi dikelola dan disimpan oleh perusahaan pemilik pusat data dan tidak membagikan layanan dengan organisasi lainnya. Manfaat utama penggunaan cloud pribadi lokal mencakup rasa aman, fleksibilitas, serta performa yang lebih tinggi. Pengguna dapat menyesuaikan sumber daya dan layanan mereka, sehingga perangkat keras secara khusus cocok dengan persyaratan perangkat lunak, daripada pendekatan satu ukuran untuk semua. Pengguna juga memiliki kendali penuh atas keamanan, skalabilitas, dan konfigurasi server.

Saat permintaan aplikasi meningkat atau menurun, komponen dan server berkomunikasi satu sama lain untuk mengalihkan beban kerja. Kini, arsitek TI dapat membuat pusat data dengan rangkaian perangkat keras dan komponen yang lebih luas dari berbagai produsen. Akibatnya, mereka membongkar atau memisahkan infrastruktur pusat data biasa. Setelah sasis dihilangkan, pusat data kemudian dapat direkonstruksi untuk penggunaan sumber daya terpasang yang lebih efisien. Arsitek TI dapat menghindari pembelian perangkat keras yang tidak perlu dengan biaya tambahan serta dapat mengganti komponen dengan mudah tanpa waktu henti operasional.

Pemisahan dan komposabilitas pusat data di cloud pribadi berevolusi dari arsitektur jaringan biasa menjadi infrastruktur dinamis canggih yang menyediakan sistem kuat dan menuntut fungsi. Pemisahan yang dapat disusun memiliki beberapa manfaat utama, termasuk pengurangan latensi dan peningkatan keamanan serta kontrol atas data.

Batasan Pusat Data Biasa

Arsitektur TI biasa mencapai batasnya karena pertumbuhan data eksponensial serta meningkatnya kerumitan aplikasi perangkat lunak. Unit pemrosesan pusat (CPU), unit memori akses dinamis (DRAM), unit memori kelas penyimpanan (SCM), unit solid state disk (SSD), dan hard disk (HDD) berada di antara komponen penting yang membentuk pusat data. Komponen tersebut biasanya ditempatkan secara bersamaan dalam satu kotak atau server dan merupakan fondasi pembuatan pusat data. Dalam arsitektur cloud biasa ini, setiap komponen, seperti HDD terhubung ke server lain secara langsung.

Pada dasarnya, pusat data beroperasi dalam paradigma satu aplikasi per kotak. Saat aplikasi melebihi kapasitas penyimpanan dan pemrosesan data yang dapat disediakan oleh satu server, arsitek TI mulai mengelompokkan beberapa server menjadi beberapa kluster, yang semuanya dapat digunakan sebagai kumpulan sumber daya. Solusi kepemilikan dari tim seperti IBM, EMC, NetApp, dan Dot Hill dari Seagate memimpin perampasan awal industri ke sumber daya server.

Pusat data kemudian dapat meningkatkan skala dan memenuhi kebutuhan aplikasi perangkat lunak saat tumbuh dalam kompleksitas dengan cara berikut: jika aplikasi memerlukan lebih banyak penyimpanan, bandwidth, atau daya CPU, server tambahan, atau node dapat ditambahkan ke kluster. Model terkluster dari sumber daya yang dikumpulkan membentuk dasar dari sistem yang kini kita kenal sebagai infrastruktur cloud perusahaan yang terkonvergensi dan sangat terkonvergensi, menggunakan aplikasi hypervisor perusahaan seperti VMware dan lainnya.

Kluster node telah mencapai tujuannya pada masa perkembangan cloud, tetapi rentan terhadap penyediaan yang berlebihan. Hal ini terjadi saat arsitek TI membeli lebih banyak server yang terkait berisi lebih banyak sumber daya dari satu jenis atau lainnya yang dibutuhkan sumber daya yang kemudian tidak akan digunakan. Meskipun pendekatan yang terkluster mempunyai keuntungan, seperti jaminan penyimpanan yang cukup dan daya pemrosesan, sehingga sumber daya yang tidak digunakan di dalam server tidak efisien. Namun, arsitek TI harus bergantung pada penyediaan berlebih untuk mencapai skala, karena tidak ada cara bagi pusat data untuk secara dinamis menskalakan sumber daya atau beban kerja tertentu yang sesuai permintaan aplikasi perangkat lunak. Kelebihan biaya merupakan dampak sampingan alami akibat penyediaan berlebihan.

Arsitek TI juga terbatas dalam hal komponen perangkat keras yang dapat digunakan untuk membentuk server. Perangkat keras untuk setiap server atau kluster harus dibeli dari produsen tunggal untuk tujuan kompatibilitas. Selain itu, tidak ada antarmuka pemograman aplikasi (API) terbuka yang tersedia untuk membantu perangkat keras dari berbagai komunikasi dan koordinasi produsen. Jika arsitek ingin menukarkan CPU ke yang lebih cepat dari produsen satu ke yang lainnya, misalnya, sering kali mereka kurang beruntung karena inkompatibilitas. Perangkat keras dari produsen berbeda tidak dapat berkomunikasi atau berkoordinasi antara satu dengan lainnya.

Namun, inkompatibilitas perangkat keras bukanlah satu-satunya hal yang membebani infrastruktur data biasa. Ada juga masalah banyaknya data yang perlu dikumpulkan, disimpan, dan dianalisa. Ledakan data besar tidak hanya mendorong batas penyimpanan kluster cloud pribadi biasa, namun juga menciptakan kemacetan pemrosesan data. Setiap CPU sering kali terlalu sibuk pada pemrosesan data lokal untuk berbagi sumber daya dengan aplikasi lain, sehingga menghasilkan inefisiensi penskalaan sumber daya secara keseluruhan di pusat data.

Misalnya, aplikasi kecerdasan buatan (AI) yang kompleks didasarkan pada kemampuan untuk memproses data dalam jumlah besar dalam waktu singkat. Saat aplikasi AI menggunakan pusat data yang terkluster, kemacetan dalam pengumpulan dan pemrosesan data cenderung terjadi. Selain itu, jika aplikasi memerlukan lebih banyak daya untuk memproses, tidak ada cara untuk mengalihkan beban kerja tambahan ke kluster lain. Latensi atau jeda dalam transmisi data antara perangkat merupakan konsekuensi negatif lainnya.

Misalnya, mungkin ada dua kluster server dalam pusat data yang sama, salah satunya kelebihan beban dan yang lainnya kurang dimanfaatkan. Aplikasi yang menggunakan kluster yang kelebihan beban mungkin akan melambat atau mengalami masalah performa, suatu masalah yang dapat diatasi dengan mudah dengan mengintegrasikan kluster yang kurang dimanfaatkan dan tersedia secara berlebihan untuk membantu. Namun, kumpulan sumber daya yang dapat didorong aplikasi sangat terbatas pada kluster tunggal yang didedikasikan untuk aplikasi tersebut. Hal ini merupakan ilustrasi sempurna alasan arsitek TI mencari cara yang lebih efisien untuk menyusun pusat data.

Era kepemilikan akan segera berakhir. jika memang belum terjadi, Aplikasi perangkat lunak canggih menuntut lebih banyak daya pemrosesan dan penyimpanan daripada yang dapat disediakan oleh pusat data terkluster biasa. Selain itu, arsitek TI terbatas dalam memilih perangkat keras yang dapat digunakan karena kurangnya API yang memungkinkan komunikasi antar perangkat. Agar arsitek TI dapat bergerak maju, mereka memerlukan pemahaman yang lebih mendalam terkait cara aplikasi canggih memengaruhi arsitektur cloud pribadi dan cara komposabilitas dapat membantu mengatasi tantangan infrastruktur TI biasa.

Cara Aplikasi Memengaruhi Pusat Data Cloud Pribadi

Salah satu kekuatan terbesar yang mendorong megatren komposabilitas adalah tuntutan aplikasi perangkat lunak. Perangkat lunak seperti AI atau analitik bisnis menuntut persyaratan khusus perangkat keras yang semakin kompleks untuk kebutuhan aplikasi. Hal ini menciptakan persaingan ketat untuk kumpulan sumber daya penyimpanan dan pemrosesan.

Sebagaimana tercatat, pusat data biasa kini telah mencapai titik puncak yang daya pemrosesannya diperlukan oleh berbagai aplikasi secara teratur melebihi batas model terkluster. Persyaratan aplikasi juga terus mengalami perkembangan seiring waktu, dan perubahan dapat terjadi dengan cepat. Aplikasi bisnis versi terbaru misalnya, mungkin membutuhkan penyimpanan atau kekuatan pemrosesan dua kali lipat dari versi lama. Jika melebihi batas kluster khusus, lebih banyak perangkat keras yang harus dibeli. Kemajuan dalam perangkat lunak menekan hal yang dapat ditawarkan oleh pusat data terkluster biasa.

Komposabilitas memberi aplikasi akses ke kumpulan sumber daya di luar kluster khusus mereka, membuka daya pemrosesan, atau sumber daya lain yang tersedia dalam server yang disediakan secara berlebih. Setiap node CPU, GPU, atau penyimpanan dapat diskalakan secara independen berdasarkan kebutuhan harga setiap aplikasi.

Tuntutan pemrosesan tambahan juga menciptakan kemacetan dalam struktur pusat data biasa. Struktur pusat data inilah yang menghubungkan berbagai node dan kluster. Idealnya, struktur yang dapat disusun yang memenuhi kebutuhan aplikasi perangkat lunak canggih harus menciptakan kumpulan kapasitas struktur yang fleksibel. Struktur tersebut harusnya dapat dikonfigurasi secara instan untuk menyediakan infrastruktur dan sumber daya secara dinamis seiring dengan meningkatnya kebutuhan pemrosesan aplikasi. Tujuannya adalah untuk menyediakan aplikasi canggih yang tidak hanya cepat, tetapi pemrosesan secara real time yang memfasilitasi aplikasi tersebut bekerja dalam kecepatan yang optimal.

Komposabilitas dan pemisahan merupakan hal penting untuk memenuhi tuntutan aplikasi perangkat lunak canggih. Arsitektur terkluster biasa tidak sesuai dengan tugasnya, dan tidak dapat menyebarkan informasi melalui struktur ethernet dengan cukup cepat untuk memungkinkan aplikasi canggih seperti AI berfungsi dengan baik. Dengan memisahkan komponen dalam kotak server dan memberikan cara untuk berkomunikasi dengan protokol API, pusat data dapat menyajikan aplikasi yang kompleks dengan cara yang hemat biaya.

Manfaat Pemisahan Cloud Pribadi

Memisahkan pusat data cloud pribadi artinya menghapus model kotak server secara penuh. Komponen sumber daya seperti CPU, GPU, memori di segala tingkat, SSD, dan penyimpanan HDD, dapat dipisah dan disusun ulang à la carte dengan struktur yang sesuai. Sumber daya tersebut kemudian dapat digunakan berdasarkan kebutuhan aplikasi tertentu, bukan berdasarkan cara komponen dikonfigurasi dalam server fisik tertentu. Semua hal yang dapat diakses dalam struktur jaringan dapat di dipisah, lalu disusun ulang.

Misalnya, kumpulan sumber daya penyimpanan yang ditarik oleh aplikasi mungkin terdiri atas HDD di 10 rak server berbeda di berbagai lokasi pusat data. Jika aplikasi memerlukan penyimpanan lebih banyak dari yang digunakan saat ini, satu HDD dapat berkomunikasi dengan HDD lainnya yang memiliki ruang serta secara mudah memindahkan data tanpa hambatan. Pemrosesan beban kerja juga dapat diubah secara dinamis saat tuntutan aplikasi meningkat. Sebaliknya, saat tuntutan aplikasi menurun, penyimpanan dan pemrosesan dapat dialokasikan ulang dengan cara yang paling hemat energi untuk mengurangi atau menghilangkan penyediaan berlebih yang mahal.

Hal ini merupakan perubahan mencolok dari JBOD, atau hanya sekumpulan disk yang dibatasi pada rak server tunggal. JBOD telah berevolusi menjadi kumpulan yang dapat dipanggil aplikasi kapan saja, sehingga membuat alokasi sumber daya pusat data yang lebih cerdas. Arsitek kemudian mulai beralih ke penyimpanan eksternal standar yang dapat berkomunikasi satu sama lain.

Pemisahan juga memperkenalkan pemantauan antarmuka standar serta memungkinkan arsitek TI untuk mengelola seluruh pusat data yang dapat disusun. Memilih perangkat keras berdasarkan persyaratan — baik SSD, HDD, CPU, atau struktur komponen hanyalah satu bagian dari pemisahan pusat data biasa dan beralih ke pembuatan yang dapat digabungkan. Arsitek masih memerlukan protokol API terbuka yang tepat, seperti Redfish atau Swordfish untuk integrasi tanpa jeda dan antarmuka pengguna tunggal dalam mengelola pusat data. API terbuka memungkinkan perangkat keras dan perangkat lunak berbicara dalam bahasa berbeda untuk berkomunikasi dan bekerja sama.

Memungkinkan aplikasi menentukan cara pusat data disusun, bukan sebaliknya, menghasilkan jaringan yang ditentukan perangkat lunak (SDN), dan penyimpanan yang ditentukan perangkat lunak (SDS). Evolusi berikutnya dari SDN dan SDS adalah pusat data yang sangat tersusun. Hal ini dapat menempatkan arsitektur cloud pribadi setara dengan beberapa hyperscaler seperti Amazon Web Services (AWS) dan Microsoft Azure. Hyperscaler adalah penyedia pusat data besar yang dapat meningkatkan pemrosesan dan penyimpanan berskala besar. Struktur ethernet, tulang punggung jaringan pusat data, bahkan dapat dibuat khusus untuk dijalankan bersama dengan perangkat HDD dan SSD berlatensi rendah. Penyesuaian ini menurunkan jeda dalam lalu lintas atau pemrosesan data, karena aplikasi dapat mengambil dari kumpulan sumber daya terpisah yang beroperasi pada struktur berlatensi rendah.

Protokol API terbuka seperti Redfish dan Swordfish, merupakan hal penting untuk semua komponen terpisah yang bekerja dengan selaras. Seagate memiliki REST API lama tersendiri yang dipertahankan untuk kelas spesifik produk pusat data yang mendorong pengoperasian antar perangkat. Di masa lalu, pemasangan dan integrasi perangkat menghabiskan waktu hingga berminggu-minggu. Protokol API memungkinkan arsitek pusat data melakukan pendekatan à-la-carte serta pasang dan gunakan untuk mencari sumber perangkat keras. Perangkat baru dari produsen berbeda dapat dipasang dan berfungsi dalam waktu singkat.

Memisahkan pusat data adalah hal yang memungkinkan komposabilitas. Setelah arsitek memilih perangkat keras khusus untuk kebutuhan aplikasi perangkat lunak, mereka dapat membangun, mengoperasikan, dan mengoptimalkan pusat data yang disusun di masa mendatang.

Efisiensi Pusat Data Canggih yang Dapat Disusun untuk Cloud Pribadi

Komposabilitas pusat data tidak hanya tersambung ke semua komponen terpisah, juga membantu meningkatkan indikator performa utama (KPI) yang berkaitan dengan efisiensi biaya serta performa pusat data. Di pusat data biasa, ketersediaan berlebih merupakan salah satu penguras anggaran terbesar. Saat pusat data disediakan secara berlebihan, server dan sumber daya yang dibayar menjadi tidak termanfaatkan. Intinya, arsitek TI membayar untuk kumpulan sumber daya yang kurang dimanfaatkan, sehingga hard disk tersebut tidak tersedia.

Sumber daya yang tidak tersedia menghasilkan hal yang disebut sebagai kumpulan sumber daya tanpa induk yang tidak ditempatkan karena kurang dimanfaatkan. Hal ini termasuk CPU, GPU, FPGA (field programmable gate array), DRAM (dynamicrandom-access memory), SSD, HDD, atau SCM (memori kelas penyimpanan). Bangunan blok ini disusun secara dinamis untuk menciptakan perangkat keras khusus aplikasi melalui perangkat lunak API.

Sebelum dapat disusun, arsitektur pusat data terbuka, cloud pribadi yang dibangun basanya menggunakan perangkat keras dari vendor tunggal. Pusat data yang terhubung secara fisik lebih mahal dan organisasi sering kali terkunci pada arsitektur khusus vendor yang menjadi mahal dari waktu ke waktu.

Tren komposabilitas mulai mendapatkan daya tarik sebagai bagian arsitektur cloud publik. Misalnya, produk seperti AWS dan Microsoft Azure. Pendekatan yang sama dapat diambil dalam penerapan cloud pribadi, menghemat sumber daya moneter dengan menghindari penguncian vendor dan menyusun pusat data dengan perangkat dari beberapa vendor.

Memungkinkan pengelola TI untuk mengalokasikan lebih banyak sumber daya anggaran ke kapasitas penyimpanan yang lebih besar yang memberdayakan mereka untuk mengekstrak informasi dan nilai dari data yang tersimpan.

Kini, organisasi dapat menggunakan solusi penyimpanan pihak ketiga, memasukannya ke pusat data, dan mengintegrasikannya dengan API sumber terbuka secara lancar. Jika arsitek TI menginginkan SSD dari satu produsen, tetapi pusat data mereka dibangun dari produsen komponen yang berbeda, SSD tersebut dapat ditempatkan di pusat data tanpa banyak kesulitan. API memastikan semua komponen bekerja secara bersamaan. Pengelola pusat data tidak perlu terobsesi dengan cara komponen akan berkomunikasi melalui telemetri, misalnya, mengurangi biaya dan tekanan yang terkait dengan vendor yang saat ini bukan bagian dari pusat data.

Manfaat utama lainnya dari memori gabungan atau bersama adalah peluang bagi aplikasi untuk bertahan dari kegagalan node tanpa gangguan status pada mesin virtual atau kluster kontainer yang dipengaruhi node ini. Idenya adalah bahwa node lain kini dapat menyalin status terakhir dari memori mesin virtual ke dalam ruang memori mereka sendiri (dalam kasus arsitektur memori yang dikumpulkan) atau menggunakan proses tanpa salinan dengan pengalihan penunjuk melintasi struktur latensi yang sangat rendah dan melanjutkan di tempat yang ditinggalkan node yang gagal dengan lancar (dalam kasus arsitektur memori bersama). Hal ini dapat dianggap sebagai evolusi yang signifikan dalam hal kemampuan toleransi kesalahan tanpa batas dari pusat data untuk memberikan keandalan dan ketersediaan yang lebih tinggi.

Arsitektur yang dapat disusun juga memungkinkan pengumpulan dan pemrosesan data dari berbagai sumber lebih cepat, dan penggunaan sumber daya terpasang yang lebih efisien secara keseluruhan. Arsitektur sumber data yang dapat disusun biasanya mencakup sensor fisik, simulasi data, informasi buatan pengguna, dan komunikasi melalui telemetri. Pengelola pusat data dapat memutar sumber daya dalam hitungan menit, membagikannya di antara aplikasi dengan cepat.

Tampilan Tunggal Semua Sumber Daya

Orkestrasi dan pengelolaan pusat data cloud pribadi juga lebih mudah dengan arsitektur yang dapat disusun menggunakan klien orkestrasi dalam kontainer. Semua perangkat keras dapat dipisah, disusun, dan dipantau dari antarmuka tunggal. Pengelola pusat data mendapatkan gambar yang jelas dan real-time tentang kumpulan sumber daya yang digunakan dan memastikan tidak ada penyediaan yang berlebihan. Di banyak kasus, manajemen akan dilakukan menggunakan perangkat lunak standar. Ini dapat dikatakan seperti kepemilikan, atau sumber terbuka.

Penyebaran aplikasi perangkat lunak baru dalam sumber terbuka, lingkungan dalam kontainer juga lebih fleksibel, terutama karena cara sumber daya penyimpanan yang fleksibel dapat dibeli dan ditata. Misalnya, arsitek pusat data tidak perlu lagi menyediakan terlalu banyak tingkatan penyimpanan flash yang mahal. Karena beban kerja aplikasi apa pun dapat dialihkan secara langsung ke kumpulan sumber daya SSD yang ada sesuai kebutuhan, di mana pun. Hal ini mencegah penyediaan berlebih, serta ruang fisik yang dapat digunakan untuk tujuan lain seperti peningkatan kapasitas penyimpanan mentah.

Menciptakan lebih banyak kapasitas penyimpanan mentah merupakan hal yang lebih penting karena pertumbuhan dan ledakan data mentah. Selain itu, organisasi berusaha keras untuk mendapatkan lebih banyak nilai dan informasi yang dapat ditindaklanjuti dari lebih banyak data tersebut untuk memungkinkan peluang baru yang meningkatkan laba. Yang krusial adalah arsitek TI dapat mendesain infrastruktur yang dikumpulkan, disimpan, dan memindahkan data dalam jumlah besar. Tata letak perangkat keras komputasi yang lebih efisien berarti lebih banyak ruang yang tersedia untuk penyimpanan mentah berkapasitas besar yang diperlukan untuk lingkungan data besar saat ini.

Solusinya adalah pusat data yang dapat disusun yang terhubung ke kumpulan CPU dan penyimpanan mana pun dengan perangkat lain yang diperlukan. Semua perangkat lain menggunakan CSI, Redfish, dan Swordfish untuk dihubungkan ke jaringan manajemen yang terorkestrasi oleh mesin perangkat lunak. Semua blok bangunan lain dari pusat data dapat disusun secara dinamis untuk aplikasi khusus melalui perangkat lunak API.

Biaya, Performa, dan Efisiensi

Tren pemisahan dan komposabilitas dalam pusat data didorong oleh biaya, performa, dan efisiensi. Berakhirlah era CPU menjadi pusat dunia yang diketahui, dengan semua perangkat lain dimasukkan ke dalam kotak yang sama bersamaan dengannya. Arsitek cloud pribadi kini dapat memilih perangkat, perangkat keras, dan perangkat lunak yang paling sesuai berdasarkan pada kasus penggunaan dan kebutuhan khusus.

Pusat data kluster dalam kontainer biasa memberikan akses ke aplikasi yang lebih kompleks, tetapi kini perangkat lunak memiliki performa yang sangat tinggi sehingga memerlukan arsitektur yang lebih dinamis. Dan di masa mendatang, GPU, FPGA, dan memori yang dapat disusun akan diaktifkan oleh antarmuka latensi yang sangat rendah.

Komposabilitas berarti pemrosesan beban kerja terdistribusi secara real-time, membaginya dengan perangkat yang kurang dimanfaatkan, dan meniadakan kumpulan data tanpa induk. Hasilnya, infrastruktur cloud pribadi yang terorkestrasi sepenuhnya membantu pusat data memproses beban kerja lebih cepat dan hemat biaya pengoperasian. Dengan pemisahan dan komposabilitas, arsitek TI dapat memenuhi kebutuhan aplikasi perangkat lunak yang paling berat. Pusat data yang dapat disusun lebih dari sekadar jumlah bagiannya.