AZURE – CAF tudnivalók – 1.

A Microsoft Cloud Adoption Framework nélkülözhetetlen segítség minden AZURE felhő architektúra kialakítás esetén. De vannak "érdekes" pontjai, amihez igyekszünk útmutatást adni.
MIRŐL LESZ SZÓ A BLOGBAN?

Felhő architektúra, felhőmigráció, CAF, erőforrás átvitel

Alkalmazva a CAF-ot (Cloud Adoption Framework) a Landing Zone kialakításnál sok „érdekességbe” futhat bele az ember.

A CAF egy olyan támogatás, amivel sikeressé tudod tenni az Azure felhőarchitektúra kialakítását. Rendkívül sok üzleti, felhasználói és technológiai követelmény és elvárás számbavétele alapján mutatja a legideálisabb utat a lehetőségek között. Félreértés ne essék, ez nem egy varázspálca, ami hip-hop tökéletes megoldást varázsol.

A módszertana a következő lépésekből épül fel:

  1. Stratégia – Üzleti igények, a technológiai lehetőségek és a várható eredmények meghatározása
  2. Tervezés – A megvalósítási lehetőségek és az üzletfejlesztési elvárások párhuzamba állítása
  3. Felkészülés – A felhőkörnyezetet előkészítése a tervezett változásokra
  4. Áttelepítés – Meglévő rendszer elemek migrációja és a folyamatok modernizálása
  5. Innováció – Új natív felhőbeli vagy hibrid megoldások fejlesztése
  6. Szabályozás – A környezet és a számítási feladatok kontrolljának kialakítása
  7. Biztonság – A végső állapot modellezése a biztonság maximalizáláshoz
  8. Kezelés – Üzemeltetési menedzsment és a támogató csapatok és szerepkörök összehangolása

EGYSZERŰ FELADAT: MOZGASSUNK ÁT ERŐFORRÁSOKAT A LANDING ZONE-BA!

Nézzünk egy egyszerű példát! Van  egy viszonylag átlagos feladatunk. Át kell mozgatni egy erőforrást az újonnan kialakított Landing Zone megfelelő ágára. Az erőforrás nem más, mint egy Web App service.

Egyszerű, fogjuk meg és mozgassuk egy másik „subscirption” Resource Groupjába a Web App Service-t, ez már úgy is a Landing Zone kialakítási folyamatnak a vége.

Move resources 1

Várunk-várakozunk, megy a „csík húzás”, aztán egyszer csak egy errort kapunk?!

Move resources 2

Na, nézzük csak a hiba részletekből a fontosabb részt!

„This resource is located in resource group ‘RG02’, but hosted in the resource group ‘RG01’. This may be a result of prior move operations. Move it back to respective hosting resource group\r\n.”

Hogy mi?

Tehát, ha App service-t hoztunk létre és időközben Subscription-ön belül mozgatunk egy másik Resource Group-ba, akkor, és csak akkor tudom egy másik Subscription-be mozgatni, ha vissza mozgatom a Subscription-ön belül az eredeti Resource Group-ba, és utána tudom csak egy másik Subscription-be mozgatni.

Legyen így, ha ezt akarja! De itt jön a lényeg! Ugyanis azonnal két lehetőség merül fel:

  1. Visszamozgatom az eredeti RG-be és onnan mozgatom át egy másik Subscription-ba
  2. Amennyiben már töröltem azt a RG-t, amiben eredetileg létre lett hozva az erőforrás, akkor ugyan olyan néven létre kell hoznom újból az RG-t, és visszamozgatnom az erőforrást ide, majd azután tudom mozgatni egy másik Subscription-be.

KÉRJ SZAKMAI KONZULTÁCIÓT SZAKÉRTŐINKTŐL!

Szaktanácsadással segítjük infrastruktúrafejlesztési döntéseidet. Informatikus mérnökeink évtizedes tapasztalattal várják elképzeléseidet legyen szó zöld mezős felhős megoldásról vagy hibrid Azure architektúra kialakításról meglévő helyszíni infrastruktúrád integrálásával!

OLVASS TOVÁBB!

SZAKMAI BLOGUNK

IT rezsicsökkentés
Informatikai tanácsadás

IT REZSICSÖKKENTÉS

Manapság sokan dobálóznak a rezsi és a csökkentés szókombinációval. A kérdés, hogy ez egyáltalán megvalósítható-e az informatikában?

ELOLVASOM »

SZAKMAI BLOG

Iratkozz fel, és értesítünk a következő blog megjelenéséről!

IRATKOZZ FEL!