Bagikan melalui

Antipattern kesiapan cloud

  • Artikel

Pelanggan sering mengalami antipattern selama fase kesiapan adopsi cloud. Antipattern ini dapat menyebabkan waktu henti yang tidak terduga, masalah pemulihan bencana, dan masalah ketersediaan.

Antipattern: Mengasumsikan layanan yang dirilis siap untuk produksi

Karena komputasi cloud berkembang pesat, perusahaan sering merilis versi pratinjau layanan baru. Pelanggan cenderung berasumsi bahwa mereka dapat menggunakan layanan cloud yang tersedia di lingkungan produksi. Namun, masalah dapat terjadi, karena alasan ini:

  • Layanan pratinjau biasanya tidak menyediakan SLA waktu aktif.
  • Layanan baru sering kali tidak matang seperti layanan cloud yang sudah tersedia.

Contoh: Menggunakan layanan pratinjau dalam produksi

Sebuah lembaga penelitian menggunakan layanan cloud pratinjau dalam produksi. Layanan ini tampaknya cocok untuk kasus penggunaannya. Tapi, lembaga tersebut tidak melakukan uji tuntas pada layanan. Lembaga ini juga tidak mengikuti persyaratan dan panduan arsitektur referensinya.

Masalah muncul dengan layanan pratinjau yang menyebabkan waktu henti yang tidak terduga. Lembaga ini mulai berpikir bahwa layanan cloud secara umum tidak matang atau tangguh seperti yang dijanjikan.

Hasil yang disukai: Gunakan layanan cloud yang telah disetujui sebelumnya dalam produksi

Saat mengevaluasi layanan baru yang sedang dalam pratinjau, gunakan layanan ini hanya dalam skenario bukti konsep (POC). Jangan gunakan layanan ini di lingkungan produksi, karena lingkungan tersebut tidak memiliki SLA. Temukan keseimbangan yang tepat antara fungsionalitas dan kematangan saat menyetujui layanan cloud. Lihat Daftar periksa uji tuntas layanan Cloud untuk kerangka kerja yang dibuat yang dapat Anda gunakan untuk mengevaluasi layanan cloud dengan cepat.

Antipattern: Mengasumsikan peningkatan ketahanan dan ketersediaan

Komputasi cloud sering menawarkan keuntungan dibandingkan komputasi lokal. Contohnya meliputi:

  • Peningkatan ketahanan: Pulih setelah gagal.
  • Ketersediaan: Berjalan dalam kondisi sehat tanpa waktu henti yang signifikan.

Karena sebagian besar layanan cloud menawarkan keuntungan ini, banyak perusahaan berasumsi bahwa semua layanan cloud menawarkan ketahanan dan ketersediaan tinggi secara default. Pada kenyataannya, fitur-fitur ini seringnya hanya tersedia dengan biaya tambahan dan dengan upaya teknis tambahan.

Contoh: Mengasumsikan ketersediaan tinggi

Sebuah startup mengimplementasikan aplikasi dengan misi penting pada layanan infrastruktur sebagai layanan. Pengembang di start-up telah memeriksa ke mesin virtual dengan SLA waktu aktif 99,9%. Karena mereka ingin menghemat biaya, mereka menggunakan satu mesin virtual dan penyimpanan premium.

Ketika mesin virtual gagal, aplikasi mereka tidak dapat dipulihkan. Hasil waktu henti yang tidak terduga. Mereka berasumsi bahwa cloud menawarkan ketersediaan tinggi secara default. Mereka tidak menyadari bahwa jaminan performa dapat berbeda antara:

  • Model layanan seperti PaaS dan SaaS.
  • Arsitektur teknis seperti set ketersediaan yang seimbang dan Zona Ketersediaan.

Hasil yang disukai: Mengurangi kegagalan sambil menyeimbangkan ketahanan dan biaya

Lihat sumber daya tepercaya dan matang untuk informasi tentang praktik terbaik arsitektur yang dapat mengurangi cakupan kegagalan:

Identifikasi keseimbangan yang tepat antara biaya dan fitur seperti ketahanan dan ketersediaan tinggi. Peningkatan ketahanan dan ketersediaan biasanya menyebabkan peningkatan biaya. Contohnya:

  • Satu waktu aktif mungkin memiliki SLA dengan waktu aktif yang dijamin sebesar 99,9%.
  • Dua mesin virtual yang menjalankan beban kerja yang sama akan memberikan waktu aktif pada SLA antara 99,95 dan 99,99 persen.

Terlibat dalam proses penting rekayasa persyaratan saat merancang solusi berbasis cloud. Gunakan estimator SLA untuk membantu menghitung SLA ujung ke ujung aplikasi Anda.

Antipattern: Menjadi penyedia cloud

Beberapa perusahaan mencoba menjadikan departemen TI internal mereka sebagai penyedia cloud. Kemudian departemen TI bertanggung jawab untuk arsitektur referensi. Departemen TI juga perlu menyediakan IaaS dan PaaS ke unit bisnis. Karena jenis pekerjaan ini biasanya bukan bagian dari bisnis inti TI, penawaran layanan yang dihasilkan dapat mengalami kekurangan pada kegunaan, ketahanan, efisiensi, dan keamanan.

Contoh: Menyediakan layanan cloud terkelola monolitik

Departemen TI perusahaan mendirikan pusat keunggulan cloud (CCoE) yang berfungsi sebagai broker antara TI dan unit bisnis. Untuk memastikan perusahaan mematuhi cloud, dewan pengelola memberi CCoE tugas untuk menyediakan layanan ujung-ke-ujung monolitik. CCoE menyiapkan portal pengadaan cloud internal yang dapat digunakan unit bisnis untuk memesan mesin virtual cloud yang dikelola penuh sebagai layanan. Tapi, TI mengontrol siapa yang dapat mengakses dan menggunakan seluruh platform. Akibatnya, TI secara aktif mencegah unit bisnis agar tidak memanfaatkan berbagai layanan yang disediakan Azure. Unit bisnis tidak dapat mengakses portal cloud. Unit tersebut hanya mendapatkan akses melalui Secure Shell (SSH) dan Protokol Desktop Jauh (RDP) ke server yang dipesan.

Untuk beberapa alasan, CCoE mengalami kesulitan menyediakan layanan terkelola monolitik untuk menyelesaikan setiap layanan yang tersedia di cloud:

  • Cloud ini menawarkan sejumlah besar layanan di berbagai area solusi. Dibandingkan dengan pengembangan solusi IaaS, merancang dan merekayasa solusi Internet of Things (IoT) dan AI membutuhkan keahlian dan keahlian yang berbeda.
  • Layanan cloud sering berubah.
  • Mencoba menyediakan layanan monolitik akan meningkatkan waktu untuk memasarkan secara substansial, dan departemen TI yang mengelola proses, bukan unit bisnis.

Hasil yang disukai: Menyediakan pagar pembatas

Saat mengadopsi teknologi cloud, departemen TI mendapatkan pengalaman langsung menggunakan cloud dengan mulai mencoba beban kerja TI. Gunakan Kerangka Kerja Adopsi Microsoft Cloud untuk Azure untuk mengidentifikasi proyek adopsi pertama Anda.

Gunakan model operasi cloud yang matang seperti operasi terpusat yang membuat TI bertanggung jawab untuk mendefinisikan pagar pembatas platform seperti tata kelola. Kemudian unit bisnis dapat mengadopsi proyek cloud dengan cara yang aman dan konsisten, di dalam pagar pembatas yang didefinisikan TI.

Pertimbangkan untuk mengadopsi hanya satu penyedia cloud publik utama di awal, karena semua platform utama berbeda secara signifikan dalam penyiapan, manajemen, dan penggunaan.

Gunakan solusi SaaS sebanyak mungkin untuk alat TI, seperti:

  • Repositori kode.
  • Integrasi Berkelanjutan dan Penyediaan Berkelanjutan (CI/CD).
  • Sistem kolaborasi.

Untuk beban kerja cloud, sarankan TI untuk menggunakan prosedur yang sudah dikenal yang beroperasi dengan aman dalam skala besar.

Langkah berikutnya