Den kompletta guiden till Stack Automation: priser, funktioner och avkastning

Steg 1: Vad är Stack Automation och hur fungerar det?

Stack Automation är en plattform för automatiserad driftsättning som utvecklats gemensamt av Cisco och Quali. Den automatiserar hela arbetsflödet från rack till applikation och kortar driftsättningar från veckor till timmar. Plattformen kan driftsätta programvara från Cisco, tredjepartsapplikationer och färdigpaketerade helhetslösningar med stöd av Cisco Validated Designs.

I praktiken väljer du en mall från en central katalog och anger sedan dina variabler. Plattformen samordnar etableringen av fysiska och virtuella resurser samt molnresurser i den ordning som beroendena kräver.

Det grundläggande arbetsflödet har tre faser:

1. Planering dag 0: Du söker bland hundratals färdiga mallar i Solutions Hub. Var och en är kopplad till en Cisco Validated Design, så du väljer bara den som passar din hårdvara och arbetsbelastning.
2. Driftsättning dag 1: Plattformen kör mallen och etablerar nätverk, beräkningskapacitet, lagring och applikationer i beroendeordning. Vi använder också Stack Automation för att driftsätta helhetslösningar som Cisco AI PODs genom ett tjänsteuppdrag vid ett tillfälle. Du kan även göra det själv.
3. Drift från dag 2: Plattformen övervakar driftsatta miljöer för att upptäcka konfigurationsavvikelser, jämför det aktuella läget med den validerade mallen och kopplar kostnader till ansvariga team.

Så här ser arkitekturens flöde ut:

Trycket från marknaden är påtagligt. Det här är ingen gradvis förändring, utan en tvär omsvängning. AI-arbetsbelastningar kräver tätt integrerade teknikstackar där konfigurationerna för nätverk, beräkningskapacitet och lagring är validerade tillsammans på förhand, utan undantag.

När vi granskade vår egen webbplats stod det klart att manuell etablering tog 40 % av vårt infrastrukturteams kapacitet varje vecka. Efter övergången till mallstyrd driftsättning sjönk andelen till under 5 %.

Därför spelar mallmodellen roll

Traditionella automatiseringsverktyg ger dig byggstenarna, men du måste fortfarande sätta ihop dem själv. Stack Automation ger dig färdigbyggda, validerade lösningar. Det är skillnaden mellan att köpa virke och att köpa en färdig väggsektion.

För AI PODs är detta särskilt viktigt: beroendena mellan etablering av GPU-resurser, konfiguration av nätverksinfrastruktur och lagringsnivåer är så komplexa att manuell sammansättning innebär en oacceptabel risk. Plattformen ersätter inte dina befintliga automatiseringsverktyg, utan samordnar dem. Terraform, Ansible, Helm och Python-skript kan alla läggas in i Blueprint Designer som återanvändbara resurser.

Du behöver alltså inte skriva om automatiseringen, utan sätter ihop det du redan har.

Steg 2: Jämför nivåerna i Stack Automation: Essentials och Advantage

Plattformen finns i två nivåer: Essentials (gratis) för standarddriftsättningar från katalogen och Advantage (abonnemang) för avancerad anpassning och GitOps. Skillnaden låter enkel, men konsekvenserna är större. Essentials ger dig tillgång till färdiga mallar.

I Advantage finns möjligheterna att anpassa lösningen för produktionsmiljöer.

Båda nivåerna har ett centralt Solutions Hub med hundratals färdiga mallar för planering dag 0. Med Blueprint Designer kan användare dra in befintliga automatiseringsresurser från Terraform, Ansible, Helm och Python i arbetsflöden. Men här skiljer sig nivåerna tydligt åt.

Jämför funktioner

Dolda kostnader i gratisnivån

Essentials ser gratis ut, och är det också. Men begränsningarna märks snart:

• Du kan inte ändra mallarna så att de passar din befintliga nätverkstopologi.
• Du får varningar om konfigurationsavvikelser, men problemet åtgärdas inte.
• Utan GitOps får du ingen versionshanterad historik över driftsättningar.
• Egna driftsättningar av tredjepartsapplikationer begränsas till ett mindre katalogutbud.

När vi byggde AiGrow blev en sak tydlig: det är i steget från ”gratis” till ”redo för produktion” som de flesta team underskattar kostnaderna. Du sparar på licenser men betalar med timmar av manuella åtgärder.

Kostnadskalkylator

Vilken nivå ska du välja?

Essentials passar bäst för: Små team som driftsätter standardiserade Cisco AI PODs med minimalt behov av anpassning. Pilotprojekt. Testdriftsättningar där du vill utvärdera plattformen innan du avsätter en budget.

Advantage passar bäst för: Produktionsmiljöer med flera team, egna nätverkstopologier, CI/CD-pipelines som styrs med GitOps och integrering av tredjepartsapplikationer. Om du behöver åtgärda konfigurationsavvikelser är det bara den här nivån som har stöd för det.

Här är ett exempel på den webhook-data som Advantage använder för att starta en driftsättning med en mall via GitOps:

{
  "event": "push",
  "repository": "infra/ai-pod-configs",
  "branch": "production",
  "blueprint": "cisco-ai-pod-nvidia-h100",
  "variables": {
    "gpu_count": 8,
    "storage_tier": "premium",
    "network_fabric": "aci"
  },
  "trigger": "stack-automation-advantage",
  "validation": "cisco-validated-design"
}

Steg 3: Hur använder Stack Automation agentisk AI för automatisk felavhjälpning?

Agentbaserad AI inom stack automation innebär att autonoma AI-agenter, som NVIDIA NemoClaw och Claude, skapar, förbättrar och självläker infrastrukturkonfigurationer vid den första driftsättningen, utan att skapa inlåsning till en leverantör. Den första driftsättningen ger snabb, automatiserad etablering av fysisk, virtuell och molnbaserad infrastruktur. Agentlagret finns i Blueprint Designer och arbetar med de Terraform-, Ansible- och Python-resurser du redan har.

Principen är enkel, även om tekniken bakom är komplex. När en blueprint körs övervakar den agentbaserade AI:n driftsättningen i realtid. Om ett konfigurationssteg misslyckas analyserar agenten felet, skapar en korrigerad konfiguration och försöker igen.

Ingen behöver ingripa och inget ärende behöver hamna i en kö.

Så skiljer sig agenterna åt

Det avgörande är att agentbaserade AI-verktyg skapar, förbättrar och självläker konfigurationer utan att låsa dig till en leverantör. Dina Terraform-moduler förblir Terraform-moduler och dina Ansible-playbooks förblir Ansible-playbooks. Agenterna ändrar indata och parametrar, inte de underliggande verktygen.

Ett konkret exempel

Tänk dig en driftsättning där konfigurationen av nätverksstrukturen misslyckas eftersom VLAN-taggningen inte stämmer med den fysiska switchens konfiguration. Traditionell automatisering stannar, ger ett felmeddelande och väntar på att en människa ska ingripa. Agentbaserad AI inom stack automation upptäcker avvikelsen, kontrollerar switchens tillstånd via ett API, skapar om VLAN-konfigurationen och driftsätter på nytt.

Så här ser det självläkande flödet ut:

Agenten loggar varje ändring den gör. Du får ett fullständigt revisionsspår. Om du inte håller med om AI:ns korrigering kan du återställa den ursprungliga konfigurationen och göra en egen ändring. Plattformen tvingar aldrig igenom ett automatiserat beslut utan möjlighet att återställa det.

Vad det betyder för den fortsatta driften

Självläkningen upphör inte efter den första driftsättningen. Samma agentlager upptäcker konfigurationsavvikelser under den fortsatta driften. Om en teammedlem ändrar en brandväggsregel manuellt på en switch i produktion upptäcker agenten avvikelsen från den validerade blueprinten, klassificerar ändringen som avsiktlig eller oavsiktlig och loggar den eller påbörjar en korrigering enligt dina policyinställningar.

Det är här stack automation skiljer sig från generella verktyg för infrastruktur som kod. AI-lagret skapar en återkopplingsslinga som de flesta plattformar helt saknar.

En annan syn: Varför leverans av kompletta stacklösningar inte alltid är det bästa valet

Leverans av kompletta stacklösningar är inte rätt svar för alla. Vi har sett team skynda sig att välja plattformar från en enda leverantör, som stack automation, utan att först fråga sig om deras miljö verkligen passar modellen. Ibland gör den inte det.

En plattform som är optimerad för Cisco Validated Designs hanterar den lokala infrastrukturen utmärkt. Det är i molnet och de containerbaserade miljöerna som det blir mer komplicerat.

Plattformar för tjänsteorkestrering och automatisering (SOAP) är en vidareutveckling av traditionell automatisering av arbetslaster (WLA), ett begrepp som introducerades av Gartner. SOAP-plattformar samordnar specialiserade automatiseringsverktyg i stället för att ersätta dem och fungerar som ett centralt nav för orkestrering i organisationen. Stack automation fungerar utmärkt inom Ciscos verktygsmiljö.

Men om din miljö omfattar AWS, Azure, Kubernetes-kluster och lokal Cisco-hårdvara finns det ingen enskild plattform som hanterar allt lika bra.

Där leverans av kompletta stacklösningar brister

• Miljöer med flera molnleverantörer, där varje moln har egna inbyggda automatiseringsverktyg med mer djupgående funktioner än någon plattformsoberoende lösning.
• Äldre system som utvecklades före modern API-baserad automatisering och kräver specialskrivna integrationsskript.
• Miljöer med strikta efterlevnadskrav, där konfigurationsändringar måste godkännas av en ändringskommitté före varje driftsättning.
• Team som redan har investerat mycket i sina verktyg, till exempel Terraform Cloud, Ansible Automation Platform eller ArgoCD, och där en ny plattform delvis skulle överlappa befintliga funktioner.

Risken för ännu fler verktyg

Att införa en ny orkestreringsplattform för att minska antalet verktyg kan i stället öka det, om plattformen inte kan ta över det de befintliga verktygen gör. Om ditt team använder Terraform för molnet, Ansible för konfigurationshantering, ArgoCD för Kubernetes och Jenkins för CI/CD löser det inte problemet att lägga till stack automation som ett femte verktyg. Det tillför ett sjätte.

Rätt utgångspunkt är att bedöma om plattformen fungerar som ett nav för orkestrering eller blir ännu en isolerad lösning. Stack automation integrerar befintliga verktyg via Blueprint Designer. Men hur djup integrationen är spelar roll.

Ett dra-och-släpp-gränssnitt ovanpå en Terraform-modul är inte samma sak som Terraform Cloud med inbyggd tillämpning av policy som kod.

När en enda leverantör är rätt val

Vi är inte emot leverans av kompletta stacklösningar, men vi tycker inte att det ska vara standardvalet. Plattformar från en enda leverantör, som stack automation, passar bäst när:

1. Din infrastruktur till största delen består av Cisco. 2. Du driftsätter AI-arbetslaster som gynnas av förvaliderade lösningar för hela stacken.
2. Ditt team behöver vägledda arbetsflöden eftersom det saknar djup kompetens inom automatisering.
3. Du börjar från grunden och har inte investerat i någon befintlig verktygskedja.

Om alla fyra punkterna stämmer är stack automation ett starkt alternativ. Om högst två stämmer bör du först utvärdera SOAP-plattformar som kan samordna dina befintliga verktyg, innan du lägger till en ny plattform.

Steg 4: Utvärdera stack automation för hybrida IT-miljöer

Stack automation beställs via Cisco CCW genom valfri Cisco-partner. Det säger något viktigt: plattformen är inriktad på Cisco. Den marknadsförs inte som ett leverantörsneutralt orkestreringsverktyg. Den utgångspunkten är viktig att förstå innan du utvärderar plattformen för hybrida miljöer.

Plattformen kan driftsätta infrastruktur från andra leverantörer via Blueprint Designer, men de färdiga blueprintsen är fortfarande till övervägande del inriktade på Cisco. Vi använder stack automation för att driftsätta kompletta stacklösningar som Cisco AI PODs inom ramen för ett engångsuppdrag. För hårdvara från andra leverantörer måste du bygga egna blueprints från grunden.

Verkligheten i hybrid IT

Förutsättningar för driftsättning av infrastruktur från andra leverantörer

Innan du driftsätter stack automation i en hybrid miljö behöver du kontrollera följande: Du behöver API-åtkomst till varje komponent som inte kommer från Cisco, tillgång till Advantage-nivån för att bygga egna blueprints och ansvar för valideringen av hårdvara från andra leverantörer, eftersom Cisco Validated Designs inte omfattar den. Ciscos support täcker plattformen och Ciscos blueprints, men problem vid driftsättning av annan hårdvara kräver kontakt med respektive leverantör.

Stack automations plats bland SOAP-verktygen

Stack automation är inte en SOAP-plattform enligt Gartners definition, utan en plattform för automatiserad driftsättning med ett snävare användningsområde. En SOAP-plattform samordnar arbetslaster i hela organisationen. Stack automation orkestrerar driftsättning av infrastruktur inom en specifik stack.

Om du redan har en SOAP-plattform är frågan om stack automation integreras med den eller konkurrerar med den. Svaret beror på hur utvecklat SOAP-plattformens API är. De flesta moderna SOAP-plattformar har REST-API:er som kan starta driftsättningar i stack automation som en del av ett större arbetsflöde.

Integrationen fungerar, men är inte särskilt djupt inbyggd.

En realistisk bedömning

Det här är vår uppriktiga bedömning efter att ha utvärderat plattformen i blandade miljöer. Stack automation är som bäst i infrastruktur där Cisco dominerar. Den fungerar även i blandade miljöer, men kräver mycket arbete.

Om över 90% av din infrastruktur kommer från andra leverantörer är det fel verktyg.

Beslutsmodellen är enkel:

Stack automation kan öka komplexiteten när plattformens förutsättningar inte stämmer med miljön. Utvärdera vilka gränssnitt som stöds, vem som ansvarar för driften, hur fel hanteras och vilka arbetslaster som ska köras innan du inför den.

Steg 5: Så beräknar du avkastningen och undviker leverantörsinlåsning med stack automation

För att räkna på avkastningen från Stack Automation behövs konkreta siffror, inte allmänna påståenden om ökad produktivitet. Här går vi igenom ett räkneexempel med siffror som du kan anpassa till din verksamhet.

Så räknar du ut avkastningen

Avkastningen kommer från tre håll: kortare tid för driftsättning, färre konfigurationsfel och mindre arbete med att åtgärda konfigurationsavvikelser efter driftsättning. Stack Automation övervakar driftsatta miljöer för att upptäcka avvikelser från validerade mallar och kopplar kostnader till ansvariga team. Plattformen är utformad för att överbrygga glappet mellan planeringen inför driftsättning och den löpande driften, vilket minskar risken för att allt hänger på en enda kritisk punkt.

Räkneexempel

Tänk dig ett medelstort företag som driftsätter 4 AI POD per kvartal. Så här ser kostnaderna ut.

Det ger en årlig besparing på $60,000. Investeringen går jämnt upp månad 8 under år 1, och vid slutet av år 2 har plattformen betalat för sig och dessutom gett $72,000 i nettobesparingar.

Undvik leverantörsinlåsning

Oron för inlåsning är befogad. Så här minskar Stack Automation den risken:

1. Öppen verktygskedja: Dina Terraform-moduler, Ansible-playbooks och Python-skript går fortfarande att använda på andra plattformar. Plattformen samordnar dem utan att skriva om dem till egna format.
2. Möjlighet att exportera: Mallarna kan exporteras som standardiserade IaC-filer. Du blir inte låst till ett leverantörsspecifikt DSL.
3. API som grund: Alla plattformsfunktioner är tillgängliga via REST API. Vid behov kan du bygga en annan lösning för orkestrering ovanpå dem.
4. Insyn i agenterna: Konfigurationer för AI-agenter loggas och kan återställas. Inga ändringar sker i en svart låda.

Marknadsläget inför investeringen

Marknaden förändras. Frågan är inte om du ska investera i automatisering, utan vilken plattform som passar din miljö.

Så upptäcks konfigurationsavvikelser

Rent tekniskt fungerar upptäckten av avvikelser efter driftsättning så här:

{
 "drift_event": {
 "environment": "ai-pod-production-01",
 "component": "network_fabric",
 "expected_state": {"vlan": 100, "mtu": 9000},
 "actual_state": {"vlan": 100, "mtu": 1500},
 "severity": "high",
 "owning_team": "network-ops",
 "monthly_cost_attribution": {
 "compute": "$12,400",
 "storage": "$3,200",
 "network": "$1,800",
 "team": "network-ops"
 },
 "remediation_action": "agent_auto_fix_pending_approval",
 "blueprint_reference": "cisco-ai-pod-nvidia-h100-v3"
 }
}

Det här är informationen som skickas till ansvariga team. Att kunna koppla kostnader till rätt team är inte bara en bonus. Det är så teamen får ansvar för infrastrukturen de använder. Utan den kopplingen kan kostnaderna för moln och lokal drift växa utan att någon märker det.

Slutsats

Passar bäst för Stack Automation: Miljöer där Cisco dominerar och AI-arbetslaster driftsätts. Där kan förvaliderade mallar minska både risk och tid för driftsättning. Det gäller även team som vill ha vägledning vid driftsättning utan att bygga automatiseringen från grunden.

Passar sämre för: Miljöer som främst använder flera moln, redan har investerat mycket i sina verktyg och har lite Cisco-hårdvara. Det gäller också team som behöver leverantörsneutral orkestrering av blandad infrastruktur. Men hur är det med undantagsfallen?