Posouzení aplikací

  • Článek

Racionalizace cloudu je proces vyhodnocování aplikací, aby bylo možné určit nejlepší způsob, jak je migrovat nebo modernizovat pro cloud.

Mezi metody racionalizace patří:

  • Změna hostitele. Migrace metodou "lift and shift" se označuje také jako migrace metodou "lift and shift" , přesune aktuální aplikaci do cloudu s minimálními změnami.
  • Refaktoring. Mírně refaktoring aplikace tak, aby vyhovovala možnostem založeným na platformě jako službě (PaaS), může snížit provozní náklady.
  • Změna architektury. Změnaarchitekturych
  • Přestavba. Pokud jsou změny nebo náklady na přenos aplikace příliš velké, zvažte vytvoření nového základu kódu nativního pro cloud. Opětovné sestavení je zvláště vhodné pro aplikace, které dříve splňovaly obchodní potřeby, ale nyní nejsou podporované nebo nesprávně zarovnané s aktuálními obchodními procesy.

Než se rozhodnete o vhodné strategii, analyzujte aktuální aplikaci a určete riziko a složitost jednotlivých metod. Zvažte životní cyklus aplikací, technologie, infrastrukturu, výkon a provoz a monitorování. V případě vícevrstvých architektur vyhodnoťte prezentační vrstvu, úroveň služby, úroveň integrace a datovou úroveň.

Následující kontrolní seznamy vyhodnocují aplikaci, aby určila složitost a riziko přecházení nebo opětovného sestavení.

Složitost a rizika

Každý z následujících faktorů zvyšuje složitost, riziko nebo obojí.

Architektura

Definujte architekturu vysoké úrovně, jako je webová aplikace, webové služby, úložiště dat nebo ukládání do mezipaměti.

Faktor Složitost Riziko
Komponenty aplikací se nepřekládají přímo do Azure. ✔ ✔
Aplikace potřebuje ke spuštění v Azure změny kódu. ✔ ✔
Aplikace potřebuje velké komplexní změny kódu ke spuštění v Azure. ✔ ✔

Obchodní faktory

Starší aplikace můžou vyžadovat rozsáhlé změny, aby se dostaly do cloudu.

Faktor Složitost Riziko
Tato aplikace je už více než tři roky. ✔
Tato aplikace je důležitá pro chod firmy. ✔
Migrace blokuje technologie. ✔
Existují obchodní překážky pro migraci. ✔
Tato aplikace má požadavky na dodržování předpisů. ✔
Aplikace podléhá požadavkům na data, které jsou specifické pro zemi nebo oblast. ✔
Aplikace je veřejně přístupná. ✔ ✔

Technologie

Faktor Složitost Riziko
Nejedná se o webovou aplikaci a není hostovaná na webovém serveru. ✔
Aplikace není hostovaná ve službě Windows IIS. ✔
Aplikace není hostovaná v Linuxu. ✔
Aplikace je hostovaná ve webové farmě a k hostování webových komponent vyžaduje více serverů. ✔ ✔
Aplikace vyžaduje instalaci softwaru třetích stran na servery. ✔ ✔
Aplikace je hostovaná v jednom datacentru a operace se provádějí v jednom umístění. ✔
Aplikace přistupuje k registru serveru. ✔
Aplikace odesílá e-maily a potřebuje přístup k serveru SMTP. ✔
Nejedná se o aplikaci .NET. ✔
Aplikace jako své úložiště dat používá SQL Server. ✔
Aplikace ukládá data na místní disky a potřebuje přístup k diskům, aby fungovala správně. ✔
Aplikace používá služby Systému Windows ke zpracování asynchronních operací nebo potřebuje externí služby ke zpracování dat nebo operací. ✔

Nasazení

Při posuzování požadavků na nasazení zvažte:

  • Počet denních uživatelů
  • Průměrný počet souběžných uživatelů
  • Očekávaný provoz
  • Šířka pásma v Gb/s
  • Počet žádostí za sekundu
  • Potřebné množství paměti

Riziko nasazení můžete snížit uložením kódu do správy zdrojového kódu v systému správy verzí, jako je Git, Azure DevOps Server nebo SVN.

Faktor Složitost Riziko
Použití existujícího kódu a dat je prioritou č. 1. ✔ ✔
Kód aplikace není pod správou zdrojového kódu. ✔
Neexistuje žádný automatizovaný proces sestavení, jako je Azure DevOps Server nebo Jenkins. ✔
K nasazení aplikace neexistuje žádný automatizovaný proces vydávání. ✔ ✔
Aplikace má smlouvu o úrovni služeb (SLA), která určuje očekávané výpadky. ✔
Aplikace má špičku nebo proměnlivou dobu využití nebo načítání. ✔
Webová aplikace ukládá svůj stav relace v procesu místo externího úložiště dat. ✔

Operace

Faktor Složitost Riziko
Aplikace nemá dobře zavedenou strategii instrumentace ani standardní architekturu instrumentace. ✔
Aplikace nepoužívá monitorovací nástroje a provozní tým nemonitoruje výkon aplikace. ✔
Aplikace měřila smlouvu SLA a provozní tým monitoruje výkon aplikace. ✔
Aplikace zapisuje do úložiště protokolů, protokolu událostí, souboru protokolu, databáze protokolů nebo aplikace Přehledy. ✔
Aplikace nezapisuje do úložiště protokolů, protokolu událostí, souboru protokolu, databáze protokolů nebo aplikace Přehledy. ✔
Aplikace není součástí plánu zotavení po havárii organizace. ✔

Zabezpečení

Faktor Složitost Riziko
Aplikace používá k ověřování uživatelů službu Active Directory. ✔ ✔
Organizace ještě nenakonfigurovala ID Microsoft Entra nebo nenakonfigurovala microsoft Entra Připojení pro synchronizaci místní služby AD s ID Microsoft Entra. ✔
Aplikace vyžaduje přístup k místním prostředkům, které budou vyžadovat připojení VPN z Azure. ✔
Organizace ještě nenakonfigurovala připojení VPN mezi Azure a místním prostředím. ✔ ✔
Aplikace vyžaduje ke spuštění certifikát SSL. ✔ ✔

Výsledky

Pomocí výše uvedených tabulek určete, jestli se každý faktor vztahuje na vaši aplikaci. Spočítejte počet značek složitosti a rizika pro faktory, které platí pro vaši aplikaci.

  • Očekávaná úroveň složitosti migrace nebo modernizace aplikace do Azure je: Odpovídající faktory složitosti / Celkové možné složitosti Faktory.
  • Očekávané riziko je: Odpovídající rizikové faktory/Celkové možné rizikové faktory.

Total Possible Complexity Factors = 28, Total Possible Risk Factors = 23

V případě složitosti i rizika skóre získané z výše uvedeného <výpočtu 0,3 = nízké, <0,7 = střední, >0,7 = vysoké. Tato skóre poskytují relativní rozsah složitosti a rizika.

Refaktoring, změna architektury nebo opětovné sestavení

Pokud chcete racionalizovat, jestli se má změna hostitele, refaktoring, změna architektury nebo opětovné sestavení aplikace, zamyslete se nad následujícími body. Mnohé z těchto faktorů také přispívají ke složitosti a riziku.

Určete, jestli se komponenty aplikace můžou překládat přímo do Azure. Pokud ano, k přesunutí aplikace do Azure nepotřebujete změny kódu a můžete použít strategie změny hostitele nebo refaktoringu. Pokud ne, musíte přepsat kód, takže potřebujete změnit architekturu nebo znovu sestavit.

Pokud aplikace potřebuje změny kódu, určete složitost a rozsah potřebných změn. Menší změny můžou umožňovat změnu architektury, zatímco hlavní změny můžou vyžadovat opětovné sestavení.

Změna hostitele nebo refaktoringu

  • Pokud používáte existující kód a data jako hlavní prioritu, zvažte raději strategii refaktoringu, a ne změňte architekturu nebo opětovné sestavení.

  • Pokud máte stisknutou časovou osu, jako je vypnutí datacentra nebo vypršení platnosti smlouvy, licencování na konci životnosti nebo fúze nebo akvizice, nejrychlejší způsob, jak získat aplikaci do Azure, může být změna hostitele a refaktoring pro využívání cloudových funkcí.

Změna architektury nebo opětovného sestavení

  • Pokud ve vašem portfoliu existují aplikace, které obsluhují podobné potřeby, může to být příležitost změnit architekturu nebo znovu sestavit celé řešení.

  • Pokud chcete implementovat architekturu vícevrstvých nebo mikroslužeb pro monolitickou aplikaci, musíte ji změnit nebo znovu sestavit. Pokud vám nevadí zachovat monolitickou strukturu, možná budete moct změnit hostitele nebo refaktorovat.

  • Změna architektury nebo opětovného sestavení aplikace tak, aby využívala možnosti cloudu, pokud plánujete aplikaci aktualizovat častěji než ročně, pokud má aplikace špičku nebo proměnlivou dobu využití nebo pokud očekáváte, že aplikace bude zpracovávat vysoký provoz.

Pokud se chcete rozhodnout, jestli chcete změnit architekturu nebo znovu sestavit, vyhodnoťte následující faktory. Největší výsledek bodování označuje nejlepší strategii.

Faktor Změna architektury Opětovné sestavení (Rebuild)
Ve vašem portfoliu existují další aplikace, které obsluhují podobné potřeby. ✔ ✔
Aby se aplikace spustila v Azure, potřebuje menší změny kódu. ✔
Aplikace potřebuje velké komplexní změny kódu ke spuštění v Azure. ✔
Je důležité použít existující kód. ✔
Chcete přesunout monolitickou aplikaci do vícevrstvé architektury. ✔
Chcete přesunout monolitickou aplikaci do architektury mikroslužeb. ✔ ✔
Očekáváte, že tato aplikace přidá převratné funkce, jako jsou AI, IoT nebo roboti. ✔
Mezi funkcemi, náklady, infrastrukturou a procesy jsou funkce nejméně efektivním aspektem této aplikace. ✔
Aplikace vyžaduje software třetích stran nainstalovaný na serverech. ✔
Aplikace přistupuje k registru serveru. ✔
Aplikace odesílá e-maily a potřebuje přístup k serveru SMTP. ✔
Aplikace jako své úložiště dat používá SQL Server. ✔
Aplikace ukládá data na místní disky a potřebuje přístup k diskům, aby fungovala správně. ✔
Aplikace používá služby Systému Windows ke zpracování asynchronních operací nebo potřebuje externí služby ke zpracování dat nebo operací. ✔
Webová aplikace ukládá stav relace v procesu, nikoli do externího úložiště dat. ✔
Aplikace má špičku a proměnlivou dobu využití a načítání. ✔ ✔
Očekáváte, že aplikace bude zpracovávat vysoký provoz. ✔ ✔

Další kroky