Sebagai CSO dan CIO Anda mungkin bertanya-tanya mengapa saya menciptakan sebuah tes diagnostik yang berhubungan dengan pemahaman produk yang paling penting bagi web Anda. Tujuan asli dari diagnostik untuk melihat aplikasi dan bagaimana aplikasi yang diporting berhasil untuk penyedia layanan Cloud.  Menentukan diagnostik dan produk Cloud IaaS (penyimpanan komponen, komponen jaringan, dan mesin virtualisasi) yang diperlukan untuk suatu aplikasi. Agenda tersebut membahas komponen platform (server / sistem operasi dan web server) dalam lapisan PaaS. Terakhir, berfokus pada aplikasi perangkat lunak SaaS.

Setelah, analisis ini dilakukan secara akurat, semua korporasi 10 aplikasi teratas yang dipetakan ke Cloud publik / swasta. Port Simple (versi berbeda dari perangkat lunak virtualisasi atau yang lebih baru rilis sebuah sistem operasi) dapat terjadi selama mereka tidak mempengaruhi perangkat lunak yang berjalan dalam lapisan SaaS. Sebuah matriks dapat dibuat untuk semua sepuluh aplikasi dan dimungkinkan untuk mengintegrasikan lebih dari satu aplikasi pada bagian yang berbeda dari produk infrastruktur. Jadi apa yang harus diuji untuk menjamin kesuksesan?

Saya berpendapat dalam artikel sebelumnya bahwa tes pemulihan bencana adalah pekerjaan yang paling penting dan sulit bagi penyedia layanan yang dapat menunjukkan kepada klien Cloud potensial. Oleh karena itu, pengujian rencana pemulihan bencana adalah prioritas yang sangat tinggi. Selain itu, ini hanya terjadi bahwa informasi yang dikumpulkan untuk pemulihan bencana merupakan superset dari informasi yang diperlukan untuk port aplikasi utama web Anda ke penyedia layanan Cloud.  Analisis mendalam dari setiap aplikasi menunjukkan penyedia layanan cara untuk port dan mengujinya di Cloud.  Ini tes aplikasi dasar di konfigurasi layanan penyedia Cloud (apa yang dibutuhkan untuk semua sepuluh aplikasi) dan juga fungsi tambahan yang diperlukan untuk pemulihan bencana sukses dari aplikasi yang sama.

Lebih penting lagi, diagnostik membantu dalam menentukan fungsi apa yang dibutuhkan untuk Input ke dalam SLA (Service Level Agreement) antara sebuah perusahaan dan penyedia jasa layanan Cloud. Terciptanya akurat dari SLA adalah satu tujuan akhir dari analisis. Bagaimana seseorang memperoleh keyakinan bahwa SLA mencakup semua berbagai jenis kegagalan oleh penyedia layanan? Apa yang seharusnya dianalisa pertama? Metrik performa masih diperlukan untuk setiap aplikasi yang didukung. Berikut adalah beberapa pertanyaan lain yang perlu dijawab untuk mengetahui dengan benar tampilan dengan metrik performa. Sekali lagi ini adalah sebuah daftar perwakilan, itu belum tentu lengkap.

Yang terakhir, kotak informasi, baris setiap aplikasi, harus dimasukkan ke dalam SLA. Dengan SLA, setiap aplikasi harus memiliki persyaratan fungsionalitas, metrik performa dan sanksi denda untuk berbagai jenis kesalahan downtime. Perhatikan penyedia layanan tidak diperlukan untuk menyebarkan suatu arsitektur yang identik dengan produk dan software yang sama dengan model dan release sebagai arsitektur klien. Penyedia layanan harus memenuhi fungsi dan waktu respon  yang sama. Area risiko arsitektur juga harus dicatat dalam SLA. Sebagai contoh: produk database dalam lapisan PaaS mungkin hanya satu vendor. Kelemahan dalam database vendor yang di release oleh software dapat berdampak pada semua aplikasi yang menggunakan database yang diberikan, resiko yang sistemik. Ini harus dicatat dan diperhitungkan biaya downtime. Biaya kerugian merek (jika aplikasi tersebut memiliki data rahasia umum) dan tuntutan hukum potensial juga harus dimasukkan dalam SLA untuk setiap aplikasi.

Singkatnya, diagnostik dapat digunakan untuk menganalisis secara kritis aplikasi perusahaan berbasis web untuk pertimbangan perusahaan dalam menempatkan aplikasinya oleh penyedia Cloud. Penyedia tidak perlu menggunakan arsitektur yang sama atau produk tetapi harus memenuhi SLA untuk setiap aplikasi. Selain beberapa pertanyaan diagnostik data performa sebagian dibutuhkan untuk aplikasi web yang harus dikumpulkan sehingga SLA bisa lengkap.