AWS desain aplikasi dan strategi migrasi

Merancang dan mendokumentasikan keadaan masa depan aplikasi Anda adalah faktor keberhasilan migrasi utama. Sebaiknya buat desain untuk semua jenis strategi migrasi, tidak peduli seberapa sederhana atau kompleksnya. Membuat desain akan memunculkan potensi pemblokir, dependensi, dan peluang untuk mengoptimalkan aplikasi bahkan dalam kasus di mana arsitektur tidak diharapkan berubah.

Kami juga merekomendasikan untuk mendekati status aplikasi masa depan AWS dengan lensa strategi migrasi. Pada tahap ini, pastikan Anda menentukan seperti apa tampilan aplikasi AWS sebagai hasil dari migrasi ini. Desain yang dihasilkan akan berfungsi sebagai dasar untuk evolusi lebih lanjut setelah migrasi.

Daftar berikut berisi sumber daya untuk membantu proses desain:

• AWS Architecture Center menggabungkan alat dan panduan, seperti AWS Well-Architected Framework. Selain itu, ia menyediakan arsitektur referensi yang dapat Anda gunakan untuk aplikasi Anda.

• Amazon Builders' Library berisi beberapa sumber tentang bagaimana Amazon membangun dan mengoperasikan perangkat lunak.

• AWS Solutions Library menawarkan koleksi solusi berbasis cloud, diperiksa oleh AWS, untuk puluhan masalah teknis dan bisnis. Ini mencakup banyak koleksi arsitektur referensi.

• AWS Panduan Preskriptif menyediakan strategi, panduan, dan pola yang membantu proses desain dan praktik terbaik migrasi.

• AWS Documentationberisi informasi tentang AWS layanan, termasuk Panduan Pengguna dan Referensi API.

• Getting Started Resource Center menyediakan beberapa tutorial langsung dan penyelaman mendalam untuk mempelajari dasar-dasarnya sehingga Anda dapat mulai membangun. AWS

Tergantung di mana Anda berada dalam perjalanan cloud, AWS yayasan mungkin sudah ada. AWS Yayasan ini meliputi:

• Wilayah AWS telah diidentifikasi.

• Akun telah dibuat atau dapat diperoleh sesuai permintaan.

• Jaringan umum telah diimplementasikan.

• AWS Layanan dasar telah digunakan di dalam akun.

Sebaliknya, Anda mungkin berada di awal proses, dan AWS fondasi belum didirikan. Kurangnya fondasi yang mapan dapat membatasi ruang lingkup desain aplikasi Anda atau memerlukan pekerjaan lebih lanjut untuk mendefinisikannya. Jika ini masalahnya, kami sarankan untuk mendefinisikan dan mengimplementasikan desain dasar dari landing zone secara paralel dengan pekerjaan desain aplikasi. Desain aplikasi membantu mengidentifikasi persyaratan seperti Akun AWS struktur, jaringan, virtual private cloud (VPCs), rentang Classless Inter-Domain Routing (CIDR), layanan bersama, keamanan, dan operasi cloud.

AWS Control Towermenyediakan cara termudah untuk mengatur dan mengatur AWS lingkungan multi-akun yang aman, yang disebut landing zone. AWS Control Tower membuat landing zone Anda menggunakan AWS Organizations, yang menyediakan pengelolaan dan tata kelola akun yang berkelanjutan serta implementasi pengalaman berbasis praktik AWS terbaik bekerja dengan ribuan pelanggan saat mereka pindah ke cloud.

Aplikasi future state

Mulailah dengan menetapkan strategi migrasi awal untuk aplikasi ini. Pada titik ini, strategi dianggap awal karena dapat berubah sebagai bagian dari desain negara masa depan, yang dapat mengungkap potensi keterbatasan. Untuk memvalidasi asumsi awal, lihat pohon keputusan 6 Rs. Juga, dokumentasikan fase migrasi potensial. Misalnya, apakah aplikasi ini akan dimigrasikan dalam satu acara (semua komponen dimigrasikan secara bersamaan)? Atau apakah ini migrasi bertahap (beberapa komponen dimigrasikan nanti)?

Perhatikan bahwa strategi migrasi untuk aplikasi tertentu mungkin tidak unik. Ini karena beberapa tipe R dapat digunakan untuk memigrasikan komponen aplikasi. Misalnya, pendekatan awal bisa mengangkat dan menggeser aplikasi tanpa perubahan. Namun, komponen aplikasi mungkin berada di aset infrastruktur yang berbeda yang mungkin memerlukan perawatan yang berbeda. Misalnya, aplikasi terdiri dari tiga komponen, masing-masing berjalan di server terpisah, dan salah satu server menjalankan sistem operasi lama yang tidak didukung di cloud. Komponen itu akan memerlukan pendekatan replatform, sementara dua komponen lainnya, berjalan dalam versi server yang didukung, dapat dihosting ulang. Ini adalah kunci untuk menetapkan strategi migrasi ke setiap komponen aplikasi dan infrastruktur terkait yang sedang dimigrasikan.

Selanjutnya, dokumentasikan konteks dan masalah, dan tautkan artefak yang ada yang menentukan status saat ini:

• Mengapa aplikasi ini dimigrasikan?

• Apa saja perubahan yang diusulkan?

• Apa manfaatnya?

• Apakah ada risiko atau pemblokir utama?

• Apa kerugian saat ini?

• Apa yang ada di ruang lingkup dan di luar ruang lingkup?

Pengulangan

Sepanjang pekerjaan desain, pertimbangkan bagaimana solusi dan arsitektur untuk aplikasi ini dapat digunakan kembali untuk aplikasi lain. Bisakah solusi ini digeneralisasi?

Persyaratan

Dokumentasikan persyaratan fungsional dan nonfungsional untuk aplikasi ini, termasuk keamanan. Ini termasuk persyaratan status saat ini dan masa depan, tergantung pada strategi migrasi yang dipilih. Gunakan informasi yang dikumpulkan selama penilaian aplikasi terperinci untuk memandu proses ini.

Arsitektur yang akan datang

Jelaskan arsitektur future untuk aplikasi ini. Pertimbangkan untuk membuat templat diagram yang dapat digunakan kembali yang berisi blok bangunan untuk lingkungan sumber Anda (lokal) dan AWS lingkungan target (misalnya, target, akun Wilayah AWS VPCs, dan Availability Zone).

Buat tabel komponen yang sedang dimigrasikan dan komponen yang akan baru. Sertakan aplikasi dan layanan lain (baik di tempat atau di cloud) yang berinteraksi dengan aplikasi ini.

Tabel berikut mencantumkan contoh komponen. Ini tidak mewakili arsitektur referensi atau konfigurasi yang diperiksa.

Nama	Deskripsi	Detail
Aplikasi	Layanan eksternal (koneksi masuk)	Layanan menggunakan data dari API yang terbuka.
DNS	Resolusi nama (internal)	Amazon Route 53 digunakan sebagai bagian dari pengaturan akun dasar
Penyeimbang Beban Aplikasi	Mendistribusikan lalu lintas di antara layanan backend	Menggantikan penyeimbang beban lokal. Migrasi Kolam A.
Keamanan aplikasi	Perlindungan DDoS	Diimplementasikan dengan menggunakan AWS Shield
Grup keamanan	Firewall virtual	Batasi akses ke instance aplikasi pada port 443 (inbound).
Server A	Front-end	Rehost, menggunakan Amazon Elastic Compute Cloud (Amazon EC2).
Peladen B	Front-end	Rehost menggunakan Amazon EC2.
Peladen C	Logika aplikasi	Rehost menggunakan Amazon EC2.
Peladen D	Logika aplikasi	Rehost menggunakan Amazon EC2.
Layanan Database Relasional Amazon (Amazon RDS) - Amazon Aurora	Basis Data	Menggantikan server E dan F
Pemantauan dan peringatan	Ubah kontrol	Amazon CloudWatch
Pencatatan audit	Ubah kontrol	AWS CloudTrail
Penambalan dan akses jarak jauh	Maintenance	AWS Systems Manager
Akses sumber daya	Kontrol akses yang aman	AWS Identity and Access Management (IAM)
Autentikasi	Akses pengguna	Amazon Cognito
Sertifikat	SSL/TLS	AWS Certificate Manager
API 1	API Eksternal	Amazon API Gateway
Penyimpanan objek	Hosting gambar	Amazon Simple Storage Service (Amazon S3)
Kredensial	Manajemen dan hosting kredensional	AWS Secrets Manager
AWS Lambda fungsi	Pengambilan kredensi database dan kunci API	AWS Lambda
gateway internet	Akses internet outbound	Gerbang internet ke VPC
Subnet pribadi 1	Backend dan DB	Zona Ketersediaan 1 — VPC 1
Subnet pribadi 2	Backend dan DB	Zona Ketersediaan 2 — VPC 1
Subnet publik 1	Front-end	Zona Ketersediaan 1 — VPC 1
Subnet publik 2	Front-end	Zona Ketersediaan 2 — VPC 1
Layanan Backup	Database dan cadangan EC2 instance	AWS Backup
DR	EC2 Ketahanan Amazon	AWS Elastic Disaster Recovery

Setelah komponen diidentifikasi, plot mereka dalam diagram menggunakan alat pilihan Anda. Bagikan desain awal dengan pemangku kepentingan aplikasi utama, termasuk pemilik aplikasi, arsitek perusahaan, dan tim platform dan migrasi. Pertimbangkan untuk mengajukan pertanyaan-pertanyaan berikut:

• Apakah tim umumnya setuju dengan desainnya?

• Bisakah tim operasi mendukungnya?

• Bisakah desain dikembangkan?

• Apakah ada pilihan lain?

• Apakah desain sesuai dengan standar arsitektur dan kebijakan keamanan?

• Apakah ada komponen yang hilang (misalnya, repositori kode, perkakas CI/CD, titik akhir VPC)?

Keputusan arsitektur

Sebagai bagian dari proses desain, Anda mungkin akan menemukan lebih banyak opsi untuk keseluruhan arsitektur atau bagian tertentu darinya. Dokumentasikan opsi ini di samping alasan untuk opsi yang disukai atau dipilih. Keputusan ini dapat didokumentasikan sebagai keputusan arsitektur.

Pastikan bahwa opsi utama terdaftar dan dijelaskan dengan cukup detail bagi pembaca baru untuk memahami opsi dan alasan di balik keputusan untuk menggunakan satu opsi di atas yang lain.

Lingkungan siklus hidup perangkat lunak

Dokumentasikan setiap perubahan pada lingkungan saat ini. Misalnya, lingkungan pengujian dan pengembangan akan dibuat ulang AWS dan tidak dimigrasikan.

Penandaan

Jelaskan penandaan wajib dan direkomendasikan untuk setiap komponen infrastruktur serta nilai penandaan untuk desain ini.

Strategi migrasi

Pada titik desain ini, asumsi awal tentang strategi migrasi harus divalidasi. Konfirmasikan bahwa ada konsensus tentang strategi R yang dipilih. Dokumentasikan strategi migrasi aplikasi secara keseluruhan dan strategi untuk komponen aplikasi individual. Seperti disebutkan sebelumnya, komponen aplikasi yang berbeda mungkin memerlukan tipe R yang berbeda untuk migrasi.

Selain itu, selaraskan strategi migrasi dengan pendorong dan hasil bisnis utama. Juga, jelaskan setiap pendekatan bertahap untuk migrasi, seperti pergerakan komponen dalam peristiwa migrasi yang berbeda.

Untuk informasi lebih lanjut tentang menentukan 6 Rs Anda, lihat rekomendasi AWS Migration Hub strategi.

Pola dan alat migrasi

Dengan strategi migrasi yang ditentukan untuk komponen aplikasi dan infrastruktur, Anda sekarang dapat menjelajahi pola teknis tertentu. Misalnya, strategi rehost dapat diimplementasikan dengan alat migrasi seperti. AWS Application Migration Service Jika Anda tidak perlu mereplikasi status atau data, Anda dapat mencapai hasil yang sama dengan menerapkan ulang aplikasi menggunakan Amazon Machine Image (AMI) dan pipeline penerapan aplikasi.

Demikian pula, untuk memplatform ulang atau memfaktorkan ulang (arsitek ulang) aplikasi, Anda dapat menggunakan alat seperti AWS App2Container, AWS Database Migration Service (AWS DMS), (), AWS Schema Conversion Tool.AWS SCTAWS DataSync Untuk containerizing, Anda dapat menggunakan Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), atau. AWS Fargate Saat membeli kembali, Anda dapat menggunakan AMI untuk produk tertentu atau solusi perangkat lunak sebagai layanan (SaaS) dari. AWS Marketplace

Evaluasi berbagai pola dan opsi yang tersedia untuk mencapai tujuan. Pertimbangkan pro dan kontra, dan kesiapan operasional migrasi. Untuk membantu analisis Anda, gunakan pertanyaan-pertanyaan berikut:

• Dapatkah tim migrasi mendukung pola-pola ini?

• Apa keseimbangan antara biaya dan manfaat?

• Dapatkah aplikasi, layanan, atau komponen ini dipindahkan ke layanan terkelola?

• Apa upaya untuk menerapkan pola ini?

• Apakah ada peraturan atau kebijakan kepatuhan yang mencegah penggunaan pola tertentu?

• Bisakah pola ini digunakan kembali? Pola yang dapat digunakan kembali lebih disukai. Namun, terkadang sebuah pola hanya akan digunakan satu kali. Pertimbangkan keseimbangan antara upaya pola sekali pakai atas pola alternatif yang dapat digunakan kembali.

AWS Panduan Preskriptif berisi berbagai pola dan teknik migrasi.

Manajemen dan operasi layanan

Saat membuat desain aplikasi untuk migrasi ke AWS, pertimbangkan kesiapan operasional. Saat mengevaluasi persyaratan kesiapan dengan tim aplikasi dan infrastruktur Anda, pertimbangkan pertanyaan-pertanyaan berikut:

• Apakah mereka siap untuk mengoperasikannya?

• Apakah prosedur respons insiden didefinisikan?

• Apa perjanjian tingkat layanan yang diharapkan (SLA)?

• Apakah pemisahan tugas diperlukan?

• Apakah tim yang berbeda siap untuk mengoordinasikan tindakan dukungan?

• Siapa yang bertanggung jawab untuk apa?

Pertimbangan cutover

Mempertimbangkan strategi dan pola migrasi, apa yang penting untuk diketahui saat aplikasi dimigrasikan? Perencanaan cutover adalah kegiatan pasca-desain. Namun, dokumentasikan pertimbangan apa pun untuk kegiatan dan persyaratan yang dapat diantisipasi. Misalnya, mendokumentasikan persyaratan untuk melakukan bukti konsep, jika berlaku, dan menguraikan persyaratan pengujian, audit, atau validasi.

Risiko, asumsi, masalah, dan ketergantungan

Dokumentasikan setiap risiko terbuka, asumsi, dan potensi masalah yang belum terselesaikan. Tetapkan kepemilikan yang jelas untuk item-item ini, dan lacak kemajuan sehingga desain dan strategi keseluruhan dapat disetujui untuk implementasi. Selain itu, dependensi kunci dokumen untuk mengimplementasikan desain ini.

Memperkirakan biaya operasional

Untuk memperkirakan biaya AWS arsitektur target Anda, gunakan Kalkulator AWS Harga. Tambahkan komponen infrastruktur Anda seperti yang ditentukan oleh desain Anda, dan dapatkan perkiraan biaya operasional. Faktor dalam lisensi perangkat lunak yang diperlukan untuk komponen aplikasi Anda dan yang belum termasuk dalam AWS layanan yang akan Anda gunakan.