Az alkalmazásplatform finomítása a fejlesztés és az infrastruktúra-kezelés egyszerűsítése érdekében

A szervezet platformmérnöki gyakorlatának fejlesztésének nagy része az alkalmazásplatform kiértékelése. Az alkalmazásplatform tartalmazza a szervezeten belüli fejlesztés, üzembe helyezés és alkalmazáskezelés támogatásához használt összes eszközt és szolgáltatást.

Egyszerűsítés és szabványosítás

Az infrastruktúra kódként (IaC) és automatizálási eszközökként kombinálható sablonokkal az infrastruktúra és az alkalmazások üzembe helyezésének szabványosításához. A végfelhasználó platformspecifikus jellemzőinek csökkentése érdekében elvonhatja a platform részleteit úgy, hogy a választási lehetőségeket átlátható elnevezési konvenciókra bontja, például:

• Erőforrástípus-kategóriák (nagy számítási kapacitás, nagy memória)
• Erőforrás-méretkategóriák (például pólóméret kicsi, közepes és nagy)

A sablonoknak olyan általános követelményeket kell képviselniük, amelyeket előre beállított konfigurációkkal teszteltek, így a fejlesztői csapatok azonnal megkezdhetik a minimális paraméterek megadását, és nem kell áttekinteniük a beállításokat. Vannak azonban olyan esetek, amikor a csapatoknak több lehetőséget kell módosítaniuk a közzétett sablonokon, mint amennyi elérhető vagy kívánatos. Egy jóváhagyott tervnek például szüksége lehet egy olyan konfigurációra, amely kívül esik a támogatott sablon alapértelmezett beállításain. Ebben az esetben az üzemeltetési vagy platformmérnöki csapatok létrehozhatnak egy egyszeri konfigurációt, majd eldönthetik, hogy a sablonnak alapértelmezettként kell-e beépítenie ezeket a módosításokat.

Az IaC-eszközökkel nyomon követheti a változásokat olyan eltolódásészlelési funkciókkal, amelyek automatikusan képesek az eltolódások (GitOps) elhárítására. Ilyen eszközök például a Terraform és a natív felhőbeli IaC-eszközök (például Cluster API, Crossplane, Azure Service Operator v2). Az IaC-eszközök eltérésészlelésén kívül vannak olyan felhőkonfigurációs eszközök, amelyek lekérdezhetik az erőforrás-konfigurációkat, például az Azure Resource Graphot. Ezek két előnyt jelenthetnek; az infrastruktúra-kódon kívüli változások figyelése és a módosított előre beállított konfigurációk áttekintése. A túl merevség elkerülése érdekében előre meghatározott korlátok mellett az üzembe helyezésekben is alkalmazhat tűréshatárokat. Az Azure Policy használatával például korlátozhatja az üzembe helyezéshez használható Kubernetes-csomópontok számát.

Önállóan felügyelt vagy központilag felügyelt?

A nyilvános felhőkben lehetőség van a szoftver szolgáltatásként (Saas), szolgáltatásként nyújtott platform (PaaS) vagy szolgáltatásként nyújtott infrastruktúra (IaaS) használatára. Az SaaS, a PaaS és az IaaS szolgáltatással kapcsolatos további információkért tekintse meg a felhőszolgáltatás-típusokat ismertető betanítási modult. A PaaS-szolgáltatások leegyszerűsített fejlesztési szolgáltatásokat nyújtanak, de előíróbbak az alkalmazásmodelljeikhez. Végső soron kompromisszum van a könnyű használat és az ellenőrzés között, amelyet értékelnie kell.

A platform tervezése során értékelje ki és rangsorolja a szervezet szolgáltatási igényeit. Ha például közvetlenül az Azure Kubernetes Service-en (AKS-en) vagy az Azure Container Appsen keresztül hoz létre alkalmazásokat, az a szolgáltatásra vonatkozó követelményektől, valamint a belső kapacitástól és képességkészlettől függ. Ugyanez vonatkozik az olyan függvénystílusú szolgáltatásokra is, mint az Azure Functions vagy az Azure App Service. A Container Apps, a Functions és az App Service csökkenti az összetettséget, míg az AKS nagyobb rugalmasságot és felügyeletet biztosít. Az olyan kísérleti alkalmazásmodellek, mint a Radius OSS inkubációs projekt, megpróbálnak egyensúlyt teremteni a kettő között, de általában az érettség korábbi szakaszaiban vannak, mint a felhőszolgáltatások teljes támogatással és a meglévő IaC-formátumokban való jelenléttel.

A tervezés során azonosított problémáknak segíteniük kell annak kiértékelésében, hogy a skálázás melyik vége megfelelő önnek. A döntés meghozatalakor mindenképpen vegye figyelembe a saját belső, meglévő készségkészletét.

Megosztott és dedikált erőforrások

A szervezeten belül vannak olyan erőforrások, amelyeket több alkalmazás is megoszthat a kihasználtság és a költséghatékonyság növelése érdekében. Minden megosztott erőforrásnak megvannak a saját szempontjai. Ezek például a Kubernetes-fürtök megosztásának szempontjai, de vannak, amelyek más típusú erőforrásokra is vonatkoznak:

• Szervezet: Az erőforrások, például a fürtök szervezeten belüli, nem pedig szervezeti határokon túli megosztása javíthatja, hogy azok mennyire igazodnak a szervezeti irányhoz, a követelményekhez és a prioritásokhoz.
• Alkalmazás bérlői: Az alkalmazások különböző bérlői elkülönítési követelményekkel rendelkezhetnek; szükség van az egyes alkalmazások biztonságának és jogszabályi megfelelőségének áttekintésére, ha az más alkalmazásokkal együtt is létezhet. A Kubernetesben például az alkalmazások névtérelkülönítést használhatnak. Azonban érdemes megfontolni az alkalmazásbérletet a különböző környezettípusok esetén. Például gyakran célszerű elkerülni, hogy a tesztalkalmazások és az ugyanazon fürtökön futó éles alkalmazások keveredjenek, így elkerülhetők a helytelen konfigurációk vagy biztonsági problémák miatti váratlan hatások. Vagy dönthet úgy is, hogy először dedikált Kubernetes-fürtökön tesztel és hangol, hogy ezeket a problémákat a megosztott fürtön való üzembe helyezés előtt nyomon követhesse. Ettől függetlenül a konzisztencia a megközelítésben a félreértések és hibák elkerülésének kulcsa.
• Erőforrás-felhasználás: Ismerje meg az egyes alkalmazások erőforrás-használatát és szabad kapacitását, és készítsen előrejelzést annak becslésére, hogy a megosztás működőképes-e. Tisztában kell lennie a felhasznált erőforrások korlátaival is (adatközponti kapacitás vagy előfizetési korlátok). A cél az, hogy az alkalmazás és a függőségek ne legyenek áthelyezve egy megosztott környezetben lévő erőforrás-korlátozások miatt, vagy hogy a kapacitás elfogyásakor ne legyenek élő webhelyesemények. Erőforráskorlátok, reprezentatív tesztelés, monitorozási riasztások és jelentéskészítés használata az erőforrás-felhasználás azonosításához és a túl sok erőforrást használó alkalmazások elleni védelemhez.
• Megosztott konfigurációk optimalizálása: A megosztott erőforrások, mint például a megosztott fürtök, alaposabb mérlegelést és további konfigurációt igényelnek. Ezek a szempontok közé tartozik a keresztterhelés, az erőforrás-kiosztás, az engedélyek kezelése, a számítási feladatok tulajdonjoga, az adatmegosztás, a frissítési koordináció, a számítási feladatok elhelyezése, az alapkonfiguráció létrehozása, kezelése és iterálása, a kapacitáskezelés és a számítási feladatok elhelyezése. A megosztott erőforrásoknak vannak előnyei, de ha a standard konfigurációk túl korlátozóak, és nem fejlődnek, akkor elavulttá válnak.

Szabályozási stratégiák implementálása

A szabályozás kulcsfontosságú része az önkiszolgálóságnak a védőkorlátokkal való engedélyezésében, de a megfelelőségi szabályok olyan módon történő alkalmazása, amely nem befolyásolja az alkalmazások üzleti értékére vonatkozó időt, gyakori kihívást jelent. A szabályozásnak két része van:

• Kezdeti üzembe helyezési megfelelőség (kezdés jobbra): Ez olyan szabványosított IaC-sablonokkal érhető el, amelyek katalógusokon keresztül érhetők el, engedélykezeléssel és szabályzatokkal, hogy csak az engedélyezett erőforrások és konfigurációk legyenek üzembe helyezve.
• A megfelelőség fenntartása (maradjon a megfelelő úton): A szabályzatalapú eszközök megakadályozhatják vagy riasztást adhatnak, ha erőforrás-módosítások történnek. Az alapinfrastruktúra mellett fontolja meg az olyan erőforrásokon belüli megfelelőséget is támogató eszközöket, mint a Kubernetes, valamint a tárolókban vagy virtuális gépeken használt operációs rendszer. Előfordulhat például, hogy egy zárolt operációsrendszer-konfigurációt szeretne kikényszeríteni, vagy olyan biztonsági szoftvereszközöket szeretne telepíteni, mint a Windows Csoportházirend, a SELinux, az AppArmor, az Azure Policy vagy a Kyverno. Ha a fejlesztők csak IaC-adattárakhoz férnek hozzá, jóváhagyási munkafolyamatokat adhat hozzá a javasolt módosítások áttekintéséhez, és megakadályozhatja az erőforrás-vezérlési síkokhoz, például az Azure-hoz való közvetlen hozzáférést.

A megfelelőség fenntartásához eszközre van szükség a hozzáféréshez, a jelentéskészítéshez és a problémák elhárításához. Az Azure Policy például számos Azure-szolgáltatással használható naplózáshoz, jelentéskészítéshez és szervizeléshez. Emellett különböző módokat is tartalmaz, mint például Naplózás, Megtagadás és DeployIfNotExists, az igényeknek megfelelően.

Bár a szabályzatok kikényszeríthetik a megfelelőséget, az alkalmazásokat is váratlanul megszakíthatják. Ezért érdemes megfontolni a szabályzatok kódolási (PaC) gyakorlatként való alkalmazását a nagy léptékű működés során. A PaC a „kezdd el helyesen és maradj a helyes úton” megközelítés kulcsfontosságú részeként biztosítja a következőket:

• Központilag felügyelt szabványok
• A szabályzatok verziókövetése
• Automatizált tesztelés és ellenőrzés
• Kevesebb idő a bevezetésre
• Folyamatos üzembe helyezés

A PaC segíthet minimalizálni egy potenciálisan rossz szabályzat robbanási sugarát olyan képességekkel, mint például:

• A szabályzatdefiníciók kódként vannak tárolva egy áttekintett és jóváhagyott adattárban
• Automatizálás teszteléshez és ellenőrzéshez
• A szabályzatok gyűrűalapú fokozatos bevezetése és a meglévő erőforrások helyrehozása segít minimalizálni a potenciálisan rossz szabályzatok hatókörét.
• A szervizelési tevékenység beépített biztonsági megoldásokkal rendelkezik, például leállítja a szervizelési feladatot, ha az üzembe helyezés több mint 90%-a sikertelen

Szerepkörspecifikus megfigyelhetőség és naplózás megvalósítása

Az alkalmazások és az infrastruktúra támogatásához megfigyelhetőségre és naplózásra van szükség a teljes technológiai stacken.

A követelmények szerepkörenként eltérőek. A platformmérnöki és üzemeltetési csapatoknak például irányítópultokra van szükségük az infrastruktúra állapotának és kapacitásának megfelelő riasztásokkal történő áttekintéséhez. A fejlesztőknek alkalmazásmetrikákra, naplókra és nyomkövetésekre van szükségük az alkalmazás- és infrastruktúra állapotát mutató, hibaelhárítási és testreszabott irányítópultokhoz. Az egyik probléma, amelyet ezen szerepkörök bármelyike tapasztalhat, a kognitív túlterhelés a túl sok információtól vagy a hasznos információk hiánya miatti tudáshiánytól.

A kihívások megoldásához vegye figyelembe a következőket:

• Színvonal: A naplózási szabványok alkalmazásával egyszerűbben hozhat létre és használhat újra szabványos irányítópultokat, és egyszerűsítheti a betöltési feldolgozást az OpenTelemetry megfigyelhetőségi keretrendszeréhez hasonló módon.
• Engedélyek: Csapat- vagy alkalmazásszintű irányítópultok biztosítása a Grafana-hoz hasonló módon, hogy az összesített adatokat bárki számára elérhetővé tegye, valamint egy olyan létesítményt, amellyel az alkalmazáscsapatok megbízható tagjai biztonságosan hozzáférhetnek a naplókhoz, ha szükséges.
• Visszatartás: A naplók és metrikák megőrzése költséges lehet, és nem szándékos kockázatokat vagy megfelelőségi szabálysértéseket okozhat. Hozzon létre megőrzési alapértelmezett értékeket, és tegye közzé őket a megfelelő kezdési útmutató részeként.
• Erőforráskorlátok figyelése: Az üzemeltetési csapatoknak képesnek kell lenniük az adott típusú erőforrásra vonatkozó korlátozások azonosítására és nyomon követésére. Ezeket a korlátozásokat IaC-sablonokban vagy szabályzatokban kell figyelembe venni olyan eszközökkel, mint az Azure Policy. A műveleteknek ezután proaktív módon az irányítópultok használatával kell monitorozniuk Grafanában, és ki kell bővíteni a megosztott erőforrásokat, ahol az automatizált skálázás nem lehetséges vagy nincs engedélyezve. Például figyelheti a Kubernetes-fürt csomópontok számát a kapacitás szempontjából, ahogy az alkalmazások idővel integrálásra és módosításra kerülnek. Riasztásra van szükség, és ezeket a definíciókat kódként kell tárolni, hogy programozott módon hozzáadhatók legyenek az erőforrásokhoz.
• A legfontosabb kapacitás- és állapotmetrikák azonosítása: Monitorozza és riasztja az operációs rendszert és a megosztott erőforrásokat (például processzort, memóriát és tárterületet) az éhezés érdekében, a metrikák gyűjtésével, például a Prometheus vagy a Kubernetes monitorozásával az Azure Monitorban. Figyelheti a használatban lévő socketeket/portokat, az adatforgalmas alkalmazások hálózati sávszélesség-használatát és a fürtön üzemeltetett állapotalapú alkalmazások számát.

A biztonság kialakítása a minimális jogosultság elve, az egységes biztonságkezelés és a fenyegetésészlelés elvével

Biztonság minden rétegben szükséges: a kód, a tároló, a fürt és a felhő/infrastruktúra szintjén. Ezek a minimálisan ajánlott biztonsági lépések:

• Kövesse a minimális jogosultság elvét.
• A DevOps biztonsági felügyeletének egységesítése több folyamaton keresztül.
• Győződjön meg arról, hogy a környezeti betekintések láthatók a legkritikusabb kockázat azonosításához és elhárításához.
• Engedélyezze a modern fenyegetések észlelését és elhárítását a felhőbeli számítási feladatokban futásidőben.

Az ezen a területen jelentkező problémák megoldásához olyan eszközökre van szüksége, amelyek az Ön mérnöki és alkalmazási rendszerein, erőforrásain és szolgáltatásain keresztül működnek a felhőkön és hibrid környezeteken át (például a Microsoft Defender for Cloud). Az alkalmazásbiztonságon túl értékelje ki a következőt:

• Külső támadási felületkezelés a Microsoft Defender külső támadási felületkezelésével (Defender EASM).
• Hálózati biztonsági szolgáltatások – Alkalmazások és felhőbeli számítási feladatok védelme a hálózati alapú kibertámadásoktól az Azure Network Securityhez hasonló használatával.
• Intelligens biztonsági elemzés biztonsági információk és eseménykezelési (SIEM) megoldás, például a Microsoft Sentinel használatával.
• Az adatvagyon biztonságos szabályozásának, védelmének, vizualizációinak és kezelésének módjai, mint a Microsoft Purview.
• A kód lehetséges biztonsági rések keresésének, a titkos kódok észlelésének, a függőségek, például a GitHub Advanced Security és az Azure DevOps GitHub Advanced Security általi áttekintésének módjai.
• A szoftverellátási lánc kezelése, különösen a tárolók esetében. Alkalmazza például a Tárolók biztonságos ellátási lánc keretrendszerét.

Az engedélykövetelmények környezetenként eltérhetnek. Egyes szervezetekben például a csapatok nem férhetnek hozzá az éles erőforrásokhoz, és az új alkalmazások nem települhetnek automatikusan a felülvizsgálatok befejezéséig. A fejlesztési és tesztelési környezetekben azonban engedélyezett lehetnek az automatizált erőforrás- és alkalmazástelepítések, valamint a fürtökhöz hibaelhárítás céljából való hozzáférés.

A szolgáltatásokhoz, alkalmazásokhoz és infrastruktúrához való identitáshozzáférés nagy léptékű kezelése kihívást jelenthet. Az identitásszolgáltatók identitásadatokat hoznak létre, tartanak fenn és kezelnek. A csomagnak tartalmaznia kell az alkalmazásokhoz és szolgáltatásokhoz tartozó hitelesítési szolgáltatásokat, és ezeknek a szolgáltatásoknak integrálniuk kell a szerepköralapú hozzáférés-vezérlési (RBAC) engedélyezési rendszerekkel nagy léptékben. A Microsoft Entra ID használatával például nagy méretekben biztosíthat hitelesítést és engedélyezést az Azure-szolgáltatásokhoz, például az Azure Kubernetes Service-hez anélkül, hogy az engedélyeket közvetlenül minden egyes fürtön be kellene állítania.

Előfordulhat, hogy az alkalmazásoknak hozzáférésre van szükségük egy identitáshoz a felhőbeli erőforrások, például a tárterület eléréséhez. Át kell tekintenie a követelményeket, és fel kell mérnie, hogy az identitásszolgáltató hogyan tudja ezt a lehető legbiztonságosabb módon támogatni. Az Azure Kubernetes Service-ben például a natív felhőbeli alkalmazások a Microsoft Entra-azonosítóval összevont számítási feladatok identitását használhatják a tárolóalapú számítási feladatok hitelesítésének engedélyezéséhez. Ez a megközelítés lehetővé teszi, hogy az alkalmazások titkos adatcsere nélkül férhessenek hozzá a felhőbeli erőforrásokhoz az alkalmazáskódon belül.

Költségek csökkentése a számítási feladatok tulajdonosainak azonosításával és az erőforrások nyomon követésével

A költségek kezelése a platformfejlesztés egy másik része. Az alkalmazásplatform megfelelő kezeléséhez módot kell adnia a számítási feladatok tulajdonosainak azonosítására. Szeretné lekérni a tulajdonosoknak leképzett erőforrások leltárát egy adott metaadatkészlethez. Az Azure-ban például használhatja az AKS-címkéket, az Azure Resource Manager-címkéket, valamint az azure-beli üzembehelyezési környezetekben lévő projekteket, hogy különböző szinteken csoportosítsa az erőforrásokat. Ahhoz, hogy ez működjön, a választott metaadatoknak kötelező tulajdonságokat kell tartalmazniuk (az Azure Policyhoz hasonló módon) a számítási feladatok és erőforrások üzembe helyezésekor. Ez segít a költségfelosztásban, a megoldáserőforrás-leképezésben és a tulajdonosokban. Érdemes lehet rendszeresen jelentést futtatni az árva erőforrások nyomon követéséhez.

A nyomon követésen túl előfordulhat, hogy az egyes alkalmazáscsoportoknak költségeket kell hozzárendelnie az erőforrás-használatukhoz ugyanazokkal a metaadatokkal, mint például a Microsoft Cost Management. Bár ez a módszer nyomon követi az alkalmazáscsapatok által kiosztott erőforrásokat, nem fedezi a megosztott erőforrások, például az identitásszolgáltató, a naplózás és a metrikatárolás, valamint a hálózati sávszélesség-használat költségeit. Megosztott erőforrások esetén az üzemeltetési költségeket egyenlően oszthatja fel az egyes csapatok között, vagy dedikált rendszereket (például naplózási tárterületet) biztosíthat, ahol nemuniform-felhasználás van. Egyes megosztott erőforrástípusok képesek lehetnek elemzéseket nyújtani az erőforrás-felhasználásról. A Kubernetes például olyan eszközökkel rendelkezik, mint az OpenCost vagy a Kubecost, és segíthetnek.

A költségelemzési eszközöket is érdemes keresnie, ahol áttekintheti az aktuális kiadásokat. Az Azure Portalon például költségriasztások és költségvetés-riasztások találhatók, amelyek nyomon követhetik a csoport erőforrásainak felhasználását, és értesítéseket küldhetnek az előre beállított küszöbértékek elérésekor.

Döntse el, hogy mikor és hol érdemes befektetni

Ha több alkalmazásplatformja van, nehéz lehet eldönteni, hogy mikor és hol érdemes olyan fejlesztéseket beruházni, amelyek olyan problémákat oldanak meg, mint a magas költségek vagy a rossz megfigyelhetőség. Ha most kezdi újra, az Azure Architecture Center számos lehetséges mintával rendelkezik, amelyet kiértékelhet. De ezen túl, íme néhány kérdés, amelyet érdemes megfontolni, amikor elkezdi megtervezni, hogy mit szeretne tenni:

Question	Tippek
Szeretné átalakítani a meglévő alkalmazásplatformot, újrakezdeni vagy használni ezeket a módszereket?	Még akkor is, ha elégedett azzal, ami most van, vagy most kezdi újra, azt szeretné, hogy gondolja át, hogyan kell alkalmazkodni a változáshoz az idő múlásával. Az azonnali módosítások ritkán működnek. Az alkalmazásplatformok mozgó célpontok. Az ideális rendszer az idő múlásával változik. Ezt a gondolkodást és a kapcsolódó migrálási terveket érdemes figyelembe venni az előremutató tervezésben.
Ha meg szeretné változtatni, amit ma csinál, milyen termékekkel, szolgáltatásokkal vagy befektetésekkel elégedett?	Ahogy a mondás mondja, "ha nem törik meg, ne javítsa ki." Ne változtassa meg a dolgokat ok nélkül. Ha azonban rendelkezik otthoni megoldásokkal, fontolja meg, hogy ideje-e egy meglévő termék felé haladni, hogy hosszú távú karbantartást takarítson meg. Ha például saját monitorozási megoldást használ, szeretné tehermentesíteni az operatív csapatát, és áttérni egy új, felügyelt termékre?
Hol látja a legtöbb változást az idő múlásával? Vannak ilyenek olyan területeken, amelyek a szervezet összes (vagy legtöbb) alkalmazástípusára jellemzőek?	Azok a területek, amelyekkel Ön vagy a belső ügyfelei nem elégedettek, és nem valószínű, hogy gyakran változnak, nagyszerű kiindulópontok. Hosszú távon ezek a beruházások a legnagyobb megtérülést érik el. Ez azt is segítheti, hogy miként segítheti elő az új megoldásra való migrálást. Az alkalmazásmodellek például általában folyékonyak, de a naplóelemző eszközök általában hosszabb eltarthatósági idővel rendelkeznek. Az új projektekre és alkalmazásokra is összpontosíthat, amíg meggyőződik arról, hogy az irányváltoztatás a kívánt visszatérési értéket adja.
Egyéni megoldásokba fektet be a legnagyobb hozzáadott értékkel rendelkező területeken? Úgy érzi, hogy az egyedi alkalmazásinfrastruktúra-platform képességei a versenyelőny részét képezik?	Ha hiányosságokat észlelt, mielőtt valami egyénit csinál, fontolja meg, hogy mely területeken fektetnek be a legnagyobb valószínűséggel a beszállítók, és máshol összpontosítják az egyéni gondolkodást. Kezdje azzal, hogy egyéni alkalmazásinfrastruktúra vagy alkalmazásmodell-szolgáltató helyett integrátorként gondolkodik. Minden, amit létrehoz, fenntartani kell, ami elhomályosítja az előzetes költségeket hosszú távon. Ha úgy érzi, hogy sürgősen egyéni megoldást kell létrehoznia egy olyan területen, amelyről azt gyanítja, hogy a szállítók várhatóan hosszú távon megoldást fognak kínálni, tervezze meg a kivezetést vagy a hosszú távú támogatást. A belső ügyfelek általában ugyanolyan elégedettek lesznek (ha nem több) egy polcon kívüli termékkel, mint egyéni termékkel.

A meglévő alkalmazásplatform-beruházások adaptálása jó módszer lehet a kezdésre. Frissítések készítésekor érdemes lehet új alkalmazásokkal kezdeni, hogy egyszerűbb legyen a kísérleti ötletek bevezetése, mielőtt bármilyen bevezetést végez. Ebben a változásban az IaC és az alkalmazás templatingja is szerepet játszik. Az egyedi igényeknek megfelelő egyéni megoldásokba nagy hatású, nagy értékű területeken fektetheti be. Ellenkező esetben próbáljon meg egy polcon kívüli megoldást használni. A mérnöki rendszerekhez hasonlóan összpontosítson a kiépítés, a nyomon követés és az üzembe helyezés automatizálására, ahelyett hogy egy merev útvonalat feltételezne a változás kezelésére az idő múlásával.

Kapcsolódó tartalom

• Fejlesztői önkiszolgáló alaprendszer tervezése