# REL 3 Bagaimana cara mendesain arsitektur layanan beban kerja Anda?
Bangun beban kerja yang mudah diskalakan dan andal menggunakan arsitektur berorientasi layanan (SOA) atau arsitektur layanan mikro. Arsitektur berorientasi layanan (SOA) adalah praktik untuk membuat komponen perangkat lunak dapat digunakan ulang lewat antarmuka layanan. Arsitektur layanan mikro melangkah lebih jauh untuk membuat komponen menjadi lebih kecil dan lebih sederhana.
**Topics**
+ [REL03-BP01 Memilih cara untuk menyegmentasi beban kerja](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Berikan kontrak layanan per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Memilih cara untuk menyegmentasi beban kerja
Segmentasi beban kerja penting saat menentukan persyaratan ketahanan aplikasi Anda. Arsitektur monolitik harus dihindari jika memungkinkan. Sebagai gantinya, pertimbangkan dengan cermat komponen aplikasi mana yang dapat dipecah menjadi layanan mikro. Bergantung pada persyaratan aplikasi Anda, solusinya mungkin merupakan kombinasi arsitektur berorientasi layanan (SOA) dengan layanan mikro jika memungkinkan. Beban kerja yang mampu berada dalam kondisi stateless akan lebih mampu di-deploy sebagai layanan mikro.
**Hasil yang diinginkan:** Beban kerja harus dapat didukung, dapat diskalakan, dan di-coupling selonggar mungkin.
Saat membuat pilihan tentang cara menyegmentasikan beban kerja Anda, seimbangkan manfaat dengan kerumitannya. Hal yang tepat untuk produk baru yang mengejar jadwal peluncuran pertama akan berbeda dengan hal yang dibutuhkan oleh beban kerja yang dibangun untuk diskalakan dari awal. Saat memfaktor ulang monolit yang ada, Anda perlu mempertimbangkan seberapa baik aplikasi akan mendukung dekomposisi menuju kondisi stateless. Dengan memecah layanan menjadi bagian-bagian yang lebih kecil, tim kecil yang diberi tanggung jawab khusus akan dapat mengembangkan dan mengelolanya. Namun, layanan yang lebih kecil dapat menimbulkan kompleksitas yang mencakup kemungkinan peningkatan latensi, debugging yang lebih kompleks, dan peningkatan beban operasional.
**Antipola umum:**
+ Dalam [layanan mikro, *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) adalah situasi saat komponen atomik menjadi sangat saling bergantung sehingga kegagalan salah satu komponen akan menghasilkan kegagalan yang jauh lebih besar, sehingga komponen ini pun menjadi kaku dan rapuh seperti monolit.
**Manfaat menjalankan praktik ini:**
+ Segmen yang lebih spesifik akan menghasilkan ketangkasan, fleksibilitas organisasi, dan skalabilitas yang lebih besar.
+ Dampak gangguan layanan yang berkurang.
+ Komponen-komponen aplikasi mungkin memiliki persyaratan ketersediaan yang berbeda-beda, yang dapat didukung oleh segmentasi yang lebih atomik.
+ Tanggung jawab yang ditentukan khusus untuk tim yang mendukung beban kerja.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
Pilih jenis arsitektur berdasarkan cara beban kerja disegmentasikan. Pilih arsitektur SOA atau layanan mikro (atau dalam beberapa kasus yang jarang terjadi, arsitektur monolitik). Bahkan jika Anda memilih untuk memulai arsitektur monolit, Anda harus memastikan bahwa arsitektur tersebut modular dan pada akhirnya dapat berkembang menjadi SOA atau layanan mikro seiring dengan skala produk Anda dengan adopsi pengguna. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, yang lebih disarankan sebagai arsitektur modern yang dapat diskalakan dan andal, tetapi ada tarik ulur yang perlu dipertimbangkan, terutama saat melakukan deployment arsitektur layanan mikro.
Salah satu tarik ulur utama adalah Anda sekarang memiliki arsitektur komputasi terdistribusi yang dapat mempersulit dalam memenuhi persyaratan latensi pengguna dan ada kerumitan tambahan dalam proses debugging dan penelusuran interaksi pengguna. Anda dapat menggunakan AWS X-Ray untuk membantu Anda memecahkan masalah ini. Efek lain yang perlu dipertimbangkan adalah peningkatan kompleksitas operasional seiring Anda meningkatkan jumlah aplikasi yang Anda kelola, yang memerlukan deployment banyak komponen independen.
![\[Diagram yang menunjukkan perbandingan antara arsitektur monolitik, berorientasi layanan, dan layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Langkah implementasi
+ Tentukan arsitektur yang sesuai untuk memfaktor ulang atau membangun aplikasi Anda. SOA dan layanan mikro masing-masing menawarkan segmentasi yang lebih kecil, serta diutamakan sebagai arsitektur modern yang dapat diskalakan dan diandalkan. SOA dapat menjadi kompensasi yang baik untuk mencapai segmentasi yang lebih kecil sembari menghindari beberapa kompleksitas dari layanan mikro. Untuk detail selengkapnya, lihat [Tarik Ulur Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Jika dapat diterima beban kerja dan didukung organisasi, Anda harus menggunakan arsitektur layanan mikro untuk mencapai ketangkasan dan keandalan terbaik. Untuk detail selengkapnya, lihat [Menerapkan Layanan Mikro di AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Pertimbangkan untuk mengikuti karakteristik pohon [*Strangler Fig* , yaitu pola](https://martinfowler.com/bliki/StranglerFigApplication.html) untuk memfaktor ulang monolit menjadi komponen yang lebih kecil. Hal ini memerlukan penggantian komponen aplikasi tertentu secara bertahap dengan aplikasi dan layanan baru. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) bertindak sebagai titik awal untuk pemfaktoran ulang secara bertahap. Untuk detail selengkapnya, lihat [Memigrasikan beban kerja lama di on-premise dengan lancar menggunakan pola strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Implementasi layanan mikro mungkin memerlukan mekanisme penemuan layanan untuk memungkinkan layanan terdistribusi ini berkomunikasi satu sama lain. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) dapat digunakan dengan arsitektur berorientasi layanan untuk menyediakan penemuan dan akses layanan yang andal. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) juga dapat digunakan untuk penemuan layanan berbasis DNS yang dinamis.
+ Jika Anda bermigrasi dari monolit ke SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) dapat membantu menjembatani kesenjangan sebagai bus layanan saat mendesain ulang aplikasi lama di cloud.
+ Untuk monolit yang ada dengan satu basis data bersama, pilih cara mengatur ulang data menjadi segmen yang lebih kecil. Segmentasi ini dapat didasarkan pada unit bisnis, pola akses, atau struktur data. Pada titik ini dalam proses pemfaktoran ulang, Anda harus memilih untuk melanjutkan dengan jenis basis data relasional atau nonrelasional (NoSQL). Untuk detail selengkapnya, lihat [Dari SQL ke NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Tingkat upaya untuk rencana implementasi:** Tinggi
## Sumber daya
**Praktik terbaik terkait:**
+ [REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus](rel_service_architecture_business_domains.md)
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Apa itu Arsitektur Berorientasi Layanan?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Mengimplementasikan Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompensasi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
+ [Apa itu AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Contoh terkait:**
+ [Lokakarya Modernisasi Aplikasi Iteratif](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video terkait:**
+ [Memberikan Keunggulan dengan Layanan Mikro di AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus
Arsitektur berorientasi layanan (SOA) membangun layanan dengan fungsi yang digambarkan dengan baik berdasarkan kebutuhan bisnis. Layanan mikro menggunakan model domain dan konteks terbatas untuk membatasinya lebih lanjut sehingga tiap-tiap layanan hanya melakukan satu hal. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
Dalam merancang arsitektur layanan mikro, penggunaan Desain yang Didorong Domain (DDD) bermanfaat untuk memodelkan masalah bisnis menggunakan entitas. Misalnya, untuk situs web Amazon.com, entitas dapat meliputi paket, pengantaran, jadwal, harga, diskon, dan mata uang. Model ini kemudian dibagi lebih lanjut ke dalam model-model yang lebih kecil menggunakan [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), di mana entitas dengan fitur dan atribut yang serupa dikelompokkan masing-masing. Jadi, menggunakan untuk kasus Amazon.com, paket, pengantaran, dan jadwal adalah bagian dari konteks pengiriman, sedangkan harga, diskon, dan mata uang adalah bagian dari konteks harga. Dengan model yang dibagi ke dalam konteks, muncul templat untuk membatasi layanan mikro.
![\[Memodelkan templat untuk cara membatasi layanan mikro\]](http://docs.aws.amazon.com/id_id/wellarchitected/2022-03-31/framework/images/building-services.png)
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan:** Tinggi
## Panduan implementasi
+ Rancang beban kerja Anda berdasarkan domain bisnis Anda serta fungsionalitasnya masing-masing. Dengan berfokus pada fungsionalitas tertentu, Anda dapat memilah-milah persyaratan keandalan berbagai layanan, dan menargetkan investasi dengan lebih spesifik. Masalah bisnis yang ringkas dan adanya tim kecil terkait tiap-tiap layanan juga memungkinkan penskalaan organisasi yang lebih mudah.
+ Lakukan Analisis Domain untuk memetakan desain yang didorong domain (DDD) untuk beban kerja Anda. Lalu, Anda dapat memilih tipe arsitektur untuk memenuhi kebutuhan beban kerja Anda.
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Urai layanan Anda menjadi komponen-komponen sekecil mungkin. Dengan arsitektur layanan mikro, Anda dapat memisahkan beban kerja Anda menjadi komponen-komponen dengan fungsionalitas minimal guna memungkinkan skalabilitas dan ketangkasan organisasi.
+ Tetapkan API untuk beban kerja serta tujuan desainnya, batas, dan pertimbangan lainnya untuk penggunaan.
+ Tetapkan API.
+ Penetapan API harus memungkinkan pertumbuhan dan parameter tambahan.
+ Tetapkan ketersediaan yang dirancang.
+ API Anda mungkin memiliki beberapa tujuan desain untuk berbagai fitur.
+ Buat batasan
+ Gunakan pengujian untuk menetapkan batasan kemampuan beban kerja Anda.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terbatas (pola sentral dalam Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [Mulai Menggunakan DDD di Tengah-Tengah Sistem Warisan](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cara memecah Monolit menjadi Layanan-Layanan Mikro](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Berikan kontrak layanan per API
Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa. Strategi versioning memungkinkan klien Anda untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap. Deployment dapat terjadi kapan saja, selama kontrak tidak dilanggar. Tim penyedia layanan dapat menggunakan tumpukan teknologi pilihan mereka untuk memenuhi kontrak API. Demikian juga, konsumen layanan dapat menggunakan teknologi mereka sendiri.
Layanan mikro mengambil konsep arsitektur yang berorientasi pada layanan (SOA) sampai pada titik membuat layanan yang memiliki serangkaian fungsionalitas minimal. Setiap layanan mempublikasikan sasaran dan batas desain dan API, serta pertimbangan lainnya untuk menggunakan layanan. Ini menetapkan *kontrak* dengan aplikasi yang memanggil. Hal ini akan mencapai tiga manfaat utama:
+ Layanan memiliki masalah bisnis yang ringkas untuk dilayani dan tim kecil yang memiliki masalah bisnis tersebut. Ini memungkinkan penskalaan organisasi yang lebih baik.
+ Tim dapat melakukan deploy kapan saja selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
+ Tim dapat menggunakan tumpulkan teknologi apa pun yang mereka inginkan selama mereka memenuhi persyaratan API mereka dan persyaratan kontrak lainnya.
Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat, mempublikasikan, memelihara, memantau, dan mengamankan API dalam skala apa pun. Amazon API Gateway menangani semua tugas yang terlibat dalam menerima dan memproses hingga ratusan ribu panggilan API bersamaan, termasuk manajemen lalu lintas, otorisasi dan kontrol akses, pemantauan, dan manajemen versi API. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
+ Berikan kontrak layanan per API Kontrak layanan merupakan perjanjian yang didokumentasikan antara tim terkait integrasi layanan dan ini meliputi definisi API yang dapat dibaca mesin, batas tingkat, dan harapan akan performa.
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Strategi versioning memungkinkan klien untuk terus menggunakan API yang ada dan memigrasikan aplikasi mereka ke API yang lebih baru ketika mereka siap.
+ Amazon API Gateway adalah layanan terkelola penuh yang memudahkan developer membuat API dalam skala apa pun. Menggunakan OpenAPI Specification (OAS), yang sebelumnya disebut sebagai Swagger Specification, Anda dapat menetapkan kontrak API Anda dan mengimpornya ke API Gateway. Dengan API Gateway, kemudian Anda dapat memversikan dan melakukan deploy API.
## Sumber daya
**Dokumen terkait:**
+ [Amazon API Gateway: Mengonfigurasi API REST Menggunakan OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Konteks Terikat (pola sentral di Desain yang Didorong Domain)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementasi Layanan Mikro di AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromi Layanan Mikro](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Layanan mikro - definisi istilah arsitektur baru ini](https://www.martinfowler.com/articles/microservices.html)
+ [Layanan mikro di AWS](https://aws.amazon.com/microservices/)