“ Multimoln ” avser användning av flera molntjänster inom en enda arkitektur. Förespråkare för tillvägagångssättet hävdar att det ger dig större flexibilitet och motståndskraft genom att eliminera allt beroende av en enda leverantör. Omvänt kan multimolnsystem vara svårare att konfigurera och skala, vilket gör långsiktigt underhåll till ett jobb.
När du väl använder några produkter från en leverantör kan det vara ett logiskt steg att välja deras erbjudande för ditt nästa krav. Du behöver dock inte lägga alla dina ägg i en korg: att välja en annan plattform för din nya komponent kan ge dig mer funktionalitet till en lägre kostnad.
Att använda flera moln är ett strategiskt val som låter dig få tillgång till det bästa av allt. För att spridas över leverantörer krävs att din tjänst delas in i distribuerade mikrotjänster, vilket hjälper dig att bli molnmässig.
Du kan köra din kärntjänst på Microsoft Azure, använda Amazon S3 för fillagring och Google Cloud för vissa specialiserade AI -arbetsbelastningar. Att försöka lita på en av dessa leverantörer ensam kan vara en suboptimal lösning, även om de alla erbjuder i stort sett jämförbara funktioner.
When to Go Multi -Moln?
Att välja en molnleverantör är vanligtvis en involverad process. Om du får ett felaktigt beslut kan det hända att din tjänst hindras av en begränsad funktionsuppsättning, dålig skalbarhet eller överskottskostnader.
Annonsering
Att hitta en plattform som bockar alla dina rutor gör det vanligtvis till den främsta utmanaren för ditt nästa molninfrastrukturköp. Att blinda välja tjänsten eftersom du redan använder den kanske inte är den bästa åtgärden dock – du kan skapa ett beroende av en uppsättning sammankopplade tredjepartssystem, vilket leder till att leverantören låser sig.
Att välja att använda ett annat moln tvingar dig att kritiskt utvärdera hela marknaden när du lägger till en produkt i din stack. För större kunder kan det öka din köpkraft om ingen enskild leverantör får ta din sed för givet. Du uppmuntrar innovation och konkurrens som skapar bättre affärer och fler möjligheter för din arkitektur.
Ibland kan beslutet att anta ett andra eller tredje moln tvingas av yttre faktorer. Om kunder börjar klaga på funktioner som din nuvarande plattform inte erbjuder, kan du bli tvungen att titta utanför rutan. Eller ditt företag kan bli föremål för myndighetskrav som kräver att du lagrar viss data i enlighet med specifika säkerhetsstandarder.
Multimoln är på samma sätt användbart när du behöver använda en teknik som inte regelbundet paras med din nuvarande leverantörs fokusområde. Ett företag som använder en Linux-orienterad virtuell datorleverantör kan utveckla ett behov av att köra en Windows-server. En sådan arbetsbelastning kan vara mer meningsfull på Microsoft Azure där det finns stöd från första part för operativsystemet.
En sista drivkraft för flera molnarkitekturer är när du behöver placera en kritisk tjänst närmare dina kunder. Att komma in på en ny marknad kan vara farligt om din nuvarande leverantör inte kan erbjuda ett lokalt datacenter. Du riskerar att öka latensen för alla dina utländska användare. Att lägga till en ny instans av din tjänst i ett moln som stöder regionen skulle hjälpa dig att ge en bättre kundupplevelse.
Problem du kan stöta på
< p> Övergång till multimoln är inget som händer över en natt. Det behöver inköp och acceptans i hela din organisation eftersom det kommer att påverka alla team.
Annons
Utvecklare måste bygga med distribuerade tjänster i åtanke. Driftsteam måste vara medvetna om de olika molnen som används, vilka tjänster som tillhör varje och hur data flödar mellan dem. Säkerhetsutövare kommer att se en ökning av antalet referenser och kontrollpaneler som måste skyddas mot intrång. Arkitekturer med flera moln ger en ökad attackyta som kan göra ditt system mer mottagligt för intrång.
Den största utmaningen med multi-cloud är hur lätt flexibilitet kan bli ett betungande ansvar. Att anta en strategi för flera moln kan sänka fakturerade kostnader, men besparingarna försvinner snabbt om ditt team behöver lägga mer tid på att hantera servrar och granska svagheter.
Konsekvens är ett annat problem som du måste lösa från början. Även om du vill utnyttja fördelarna med varje plattform, bör din egen applikation fortfarande vara enhetlig i hur den utvecklas och distribueras. Använder du automatiserade CI/CD -distributioner med dina projekt på AWS? Se till att du använder något liknande med dina Azure -arbetsbelastningar också.
Att normalisera ditt övergripande tillvägagångssätt för att tillämpa ändringar hjälper till att undvika onödig fragmentering. Om möjligt, försök att använda ett abstraktionsskikt ovanpå varje enskild leverantörs tjänster. En plattform som Kubernetes ger dig konsekvens i vad du riktar dig mot, så att du kan flytta mellan moln relativt enkelt.
Att övervaka de olika molnen som är inblandade i ditt system kan vara en kamp. De flesta organisationer väljer en form av övervakningssystem över flera moln, till exempel Datadog, Grafana eller New Relic. Dessa verktyg har sin egen komplexitet och inlärningskurvor, men låter dig sammanställa alla dina resurser till en enda visualisering. Detta är mer effektivt än att försöka arbeta med flera molnleverantörers instrumentpaneler för att förstå var ett avbrott har uppstått.
Vad ska du tänka på annars?
Du behöver inte nödvändigtvis gå all-in på flera moln. För vissa organisationer kan en effektiv multi-cloud-strategi vara en enkel replikering av viktiga tjänster på två eller flera plattformar. Detta kan hjälpa katastrofåterställningsscenarier, vilket ger dig redundans om en tjänst upplever ett avbrott. Även om det kan vara frestande att behandla offentliga molnplattformar som ofelbara, har i själva verket även de största tjänsterna oplanerade stilleståndstider som kan orsaka störningar för dina kunder.
Annonsering
Mer allmänt bör en multimoln-strategi grundas på ett verkligt affärsbehov. Var avsiktlig och avsiktlig när du utvärderar nya tjänster och håll ditt mål i spetsen för ditt sinne. Det kan finnas ett annat sätt att uppnå dina mål som har mindre inverkan på dina befintliga arbetsflöden.
Ta exemplet med att sänka driftskostnaderna: att flytta nyckeltjänster till ett annat moln kan hjälpa här, men du kanske överser alternativ närmare hemmet. Granskning av din användning av dina befintliga plattformar kan avslöja sätt att öka effektiviteten genom att ändra planer, begära ett skräddarsytt erbjudande eller justera dina användningsmönster.
En annan faktor är extrakostnaden för multimoln. I vissa scenarier kan en multi-molnarkitektur vara dyrare, särskilt om du regelbundet flyttar data mellan leverantörer. De flesta stora leverantörer tar ut betydande avgifter för datautträde och inträde som kan urholka eventuella besparingar i vila.
Slutsats
Multi-cloud är ett modeord som hänvisar till att använda tjänster från flera olika molnleverantörer som en del av ett enda system. Det låter dig ta reda på fördelarna med alla plattformar på marknaden men kan vara svårt att konfigurera och underhålla.
Det bästa sättet att närma sig någon ny molnarkitektur är genom att undvika onödig tonvikt på termer som multi-cloud och hybrid-moln. Istället bör du utvärdera de alternativ som är tillgängliga för dig, oavsett leverantör, och sedan utarbeta en plan för att kombinera dem på ett sätt som gynnar alla team.
När det inte ser ut som multimoln kommer att fungera utan att öka komplexiteten, lägga till oacceptabla säkerhetsrisker eller skapa en börda för driftsteam, det finns ingen anledning att driva det vidare. Du kan alltid flytta din forskning till att hitta den bästa enskilda plattformen som erbjuder all teknik du behöver i ett paket. Se bara till att det har ett lämpligt servicenivåavtal (SLA) och lämpliga procedurer för att hantera oplanerade avbrott.