Az ügyfél saját AWS-környezete
Az ügyfél saját AWS backendjei WordPresshez
A WordPress maradjon ismerős a szerkesztők számára, miközben az ügyfél birtokolja az identitást, AI-t, munkafolyamatokat, API-kat és védett kézbesítést kezelő felhőszolgáltatásokat.
Röviden Nem kell választania a hagyományos WordPress és egy teljesen egyedi felhőalkalmazás között. Tartsa meg a WordPresst szerkesztői rétegként, és csak az erősebb elkülönítést vagy felhőnatív szolgáltatásokat igénylő futásidejű feladatokat helyezze át az ügyfél AWS-fiókjába. A WP Suite Deployment Access irányított telepítési útvonalakat biztosít a támogatott identitási, AI-, munkafolyamat- és védett kézbesítési backendekhez.
A tulajdonlás problémája
A kezelt kényelem és a teljesen egyedi fejlesztés nem az egyetlen két lehetőség
Az ügynökségeknek gyakran tisztább átadási határra van szükségük, mint amit egy szolgáltató tulajdonában lévő SaaS kínál, de nem akarják minden ügyfélnél újra felépíteni ugyanazt az AWS-architektúrát.
1. probléma
A szolgáltatói backend újabb futásidejű határt hoz létre
Egy kezelt SaaS backend kényelmes lehet, de az infrastruktúra, a szolgáltatási számlázás és az üzemeltetési adatút egy része az ügyfél AWS-fiókján kívül marad.
2. probléma
Az egyszeri AWS-fejlesztések megismétlik a mérnöki munkát
A Cognito-, AI-, munkafolyamat-, API- és védett kézbesítési környezetek ügyfelenkénti, nulláról történő felépítése növeli a megvalósítási és átadási ráfordítást.
3. probléma
Az ügynökség tartósan a futtatókörnyezet tulajdonosává válhat
Ha az infrastruktúra az ügynökség fiókjában marad, a számlázás, a hozzáférés, az átadás és a hosszú távú üzemeltetési felelősség nehezebben választható el a webhelyprojekttől.
Üzemeltetési következmény A támogatott futásidejű komponenseket ismételhető sablonokkal és irányított konfigurációval telepítse a vásárló AWS-fiókjába, miközben a WordPress marad a szerkesztői vezérlősík.
Ajánlott architektúra
Válassza külön a WordPress szerkesztői rétegét a kijelölt futásidejű szolgáltatásoktól
Csak azokat a képességeket helyezze át, amelyek számára előnyös az ügyfél tulajdonában lévő AWS-határ.
WordPress CMS / szerkesztő
|
+--> Gatey-konfiguráció --------> Cognito / identitás
+--> AI-Kit-konfiguráció --------> AI backend / tudásszolgáltatások
+--> Flow-konfiguráció ----------> munkafolyamat-backend
+--> Statikus kézbesítés --------> S3 / CloudFront / védett kézbesítés
|
v
Deployment Access varázsló
|
v
CloudFormation környezetek az ÜGYFÉL AWS-FIÓKJÁBAN
|
+--> az infrastruktúra az ügyfél tulajdona
+--> az AWS szolgáltatási díjait az ügyfél fizeti
+--> a környezet kimenetei konfigurálják a WordPress-integrációkat
Megerősített WP Suite-működés A Deployment Access irányított CloudFormation-indítási folyamatokat használ a támogatott WP Suite backendcsaládokhoz. A telepített AWS-erőforrások és az AWS szolgáltatási díjai a vásárló fiókjában maradnak; a WordPress-bővítmények a létrejött konfigurációt használják.
Megvalósítási útvonal
Szabványosítsa a telepítést anélkül, hogy elvenné a tulajdonjogot az ügyféltől
Az infrastruktúra kimeneteit kezelje szerződésként az AWS és a WordPress-réteg között.
- Válassza ki a futásidejű felelősséget — Azonosítsa, hogy az identitásnak, az AI-nak, a munkafolyamatoknak, a védett kézbesítésnek vagy más támogatott szolgáltatásnak a WordPressen kívül kell-e futnia.
- Indítsa el a vásárló fiókjában — Az irányított telepítési útvonalon hozza létre a támogatott CloudFormation környezetet az ügyfél AWS-fiókjában.
- Adja vissza a környezet kimeneteit a WordPressnek — Az azonosítókat, végpontokat, régiókat és más létrehozott kimeneteket használja a megfelelő WP Suite-bővítmény vagy projektintegráció konfigurációjaként.
- Tegye egyértelművé az üzemeltetési tulajdont — Dokumentálja, hogy az AWS-erőforrások, jogosultságok, adathatárok és szolgáltatási díjak a vásárló fiókjához tartoznak, míg a WP Suite a telepítési és integrációs útvonalat biztosítja.
Amikor az ügyfél-tulajdonú AWS a jobb határ
Legjobb választás
Kifejezett infrastruktúra-tulajdont igénylő projektek
- Nagyobb értékű vagy szabályozott ügyfélrendszereket átadó ügynökségek számára.
- Olyan csapatoknak, amelyek már használnak AWS-t, és az identitást, AI-t, munkafolyamatokat vagy védett kézbesítést a saját fiókjukban szeretnék működtetni.
- Olyan projektekhez, amelyek meg akarják tartani a WordPress-szerkesztést anélkül, hogy az ügynökség vagy egy SaaS-szolgáltató válna a futtatókörnyezet tartós tulajdonosává.
A kezelt tárhely elegendő lehet, ha
A probléma csak a WordPress tárhelyszolgáltatása
- A webhelynek nincs szüksége külön felhőnatív identitási, AI-, munkafolyamat-, API- vagy védett kézbesítési szolgáltatásokra.
- Az ügyfél nem kíván AWS-fiókot üzemeltetni.
- Egy kezelt WordPress tárhelyszolgáltató már megfelel a futásidejű, biztonsági és tulajdonosi követelményeknek.
Gyakori kérdések
Ügyfél-tulajdonú AWS és WordPress
Ki fizeti az AWS szolgáltatási díjait?
A vásárló, mert a támogatott backendkörnyezetek a vásárló AWS-fiókjába kerülnek. A Deployment Access elkülönül az erőforrások által igénybe vett AWS-szolgáltatásoktól.
A WordPress továbbra is tartalomkezelő rendszer marad?
Igen. Ebben a modellben a WordPress marad a szerkesztői réteg, miközben a kijelölt futásidejű feladatok AWS-szolgáltatásokba kerülnek.
Ez ugyanaz, mint a headless WordPress?
Nem. Nincs szükség külön frontendalkalmazásra. A WordPress továbbra is kezelheti az oldalakat és a Gutenberg-szerkesztést, miközben a böngészőoldali komponensek az ügyfél tulajdonában lévő szolgáltatásokat hívják.
Miért érdemes ismételhető telepítési sablonokat használni?
Csökkentik annak szükségét, hogy ugyanazt az infrastruktúra-architektúrát projektenként manuálisan újra létrehozzák, miközben a létrejövő erőforrások az ügyfél tulajdonában maradnak.
Az irányítás maradjon az ügyfélnél
Ott telepítse a futtatókörnyezetet, ahol az ügyfél már birtokolja a felhőhatárt
A Deployment Access segítségével indítsa el a támogatott WP Suite backendeket a vásárló AWS-fiókjában, majd kapcsolja vissza a létrejött kimeneteket a WordPresshez.