Antagandet av cloud computing har ökat snabbt de senaste åren. Många organisationer är nu beroende av sina molnsystem. Detta ger mindre utrymme för fel vid utformning av nya arkitekturer.
Ett dåligt planerat system kan vara en börda för verksamheten som använder det. Omkonfigurering av en arkitektur är en kostsam och tidskrävande process, särskilt om den ursprungliga molnmigrationen inte gick smidigt. Medan vissa misstag är oundvikliga, här är fem gotchas som du bör se upp för.
1. Blindt fokus
Molnteknologier är fortfarande omgivna av en viss hype och surr. Detta kan uppmana organisationer att fixa det senaste “stora”, & # 8221; även om en äldre lösning faktiskt kan vara mer lämplig.
Flytta inte till molnet bara för att du kan. Utvärdera dina alternativ objektivt inom ramen för din verksamhet. Att anta att molnet kommer att lösa alla dina IT-infrastrukturproblem är ett av de största misstagen du kan göra. En framgångsrik migrering kräver att du använder ett moln-första tankesätt, inte en lista över tekniker och tjänsteleverantörer.
En dåligt övervägande molnmigration kan förvärra befintliga organisatoriska problem. Bred distribution av tjänster över olika plattformar hindrar din förmåga att övervaka dina system. Du måste lära dig nya hanteringsverktyg och processer så att du kan behålla kontrollen.
Antagande av molnteknik medför en kostnad. Detta bekräftas normalt inom den tidsram som krävs för att omskola personalen när de anpassar sig till det nya systemet. Du bör bedöma varje arbetsbelastning för att avgöra om det är vettigt att flytta den till molnet. Inte varje migration kommer att vara värt det.
Glöm inte var dina data lagras. Du måste veta var dina servrar finns, hur många servrar du har och hur data distribueras över dem. Kom ihåg att du inte flyttar till ett heltäckande moln som du kan ställa in och glömma. Det är viktigt att dokumentera hur din arkitektur fungerar och var din data finns.
Molnmigrationer ska drivas av ett legitimt affärsbehov. Du måste kunna identifiera vad ett molnsystem kommer att lägga till i din organisation. Annars kan du sluta med kostsam infrastruktur som är underutnyttjad och dåligt anpassad till din verksamhet.
2. Tillhandahållande av fel
Molnet gör det enkelt att snurra upp nya instanser av servrar, tjänster och datalager. Tyvärr kan detta resultera i ooptimerad provisionering, vilket sväljer din budget och kan påverka prestandan.
Delade servrar kan vara meningsfulla för vissa komponenter i din stack. Om du har tio servrar som sitter inaktiva större delen av dagen kan det vara meningsfullt att konsolidera till en enda maskin.
Kom ihåg att & # 8220; molnet & # 8221; har fortfarande de grundläggande reglerna för design av hårdvaruarkitektur. Även om du kan skapa dussintals servrar spridda över geografiska regioner kan detta öka latensen och kräva hållbara nivåer av nätverksgenomströmning.
Dessa problem är särskilt vanliga i större organisationer, där enskilda avdelningar får skapa sina egna infrastruktur. Du kan snabbt avsluta med en förekomsträkning som överstiger dina kostnadsberäkningar.
Om en individ lämnar organisationen kan sällan använda instanser glömmas bort. Håll en inventering av dina molnservrar så att du vet när instanser har blivit överflödiga. I små team kan det vara mer hållbart att låta medarbetare snurra upp virtuella maskiner på en delad server. Att ge full tillgång till en molnmiljö kan snabbt visa sig beklagligt.
3. Inget utrymme för förändring
RELATERAD Vad är “GitOps” och varför betyder det?
Moln är dagens teknik. Om det är en sak som är uppenbart från de senaste decennierna, kanske det inte nödvändigtvis är relevant i morgon. Även om den allmänna uppfattningen om att & # 8220; placera den i molnet & # 8221; verkar osannolikt att försvinna, enskilda tekniker utvecklas och ersätts regelbundet.
Om du tar dig tid att migrera till molnet, gör dig själv en tjänst och använd chansen för att bedöma hur dina system kan hantera förändringar. Denna övning är också bra för att bestämma en effektiv migrationsstrategi.
Att utforma för förändring innebär ofta att man delar upp monoliter i enskilda mikrotjänster. Det i sig kan kräva betydande refactoring, men det kan ge utdelning på lång sikt.
När du väl har antagit en mikrotjänstarkitektur har du friheten att lokalisera varje enskild tjänst i molnet som passar bäst. Om en teknik ersätts i framtiden kommer du att kunna fokusera på att migrera de specifika mikrotjänster som använde den.
I större skala kan molnleverantörer utveckla sina produktstackar, gå samman, eller stäng av. Du bör planera hur ditt system kommer att reagera på dessa händelser, hur osannolikt de än kan verka. Antag inte att situationen idag kommer att förbli densamma för alltid.
4. Ingen migrationsplan
RELATERAD Hur du migrerar din databas till AWS
Att implementera en molnarkitektur är inte något du gör på en eftermiddag. Framgångsrika migrationer kräver en handlingsplan som tar hänsyn till alla eventualiteter. Du bör se till att alla intressenter är informerade om vad som händer, varför det behövs och hur du kommer att svara på eventuella oförutsedda problem.
Du bör sträva efter att gradvis migrera dina arbetsbelastningar. Om du flyttar allt på en gång kommer alla problem att bli mycket mer effektfulla. Att börja med en tjänst med relativt låg trafik ger dig mer andrum om något går fel.
Utvärdera varje migrering för att identifiera lärdomar som du kan använda för nästa. Gradvis öka din antagning av molnet tills du är där du vill vara. En migration kan bli en övning i flera månader, men det ger dig mer tid att analysera dess effekter på din organisation.
Om inget annat är en dokumenterad strategi viktig så att du har en referens för framtiden. Dina efterträdare tackar dig om du kan peka på en migrationsplan som förklarar hur din infrastruktur nådde sin nuvarande status. Det är viktigt att redovisa affärsfallet för varje steg samt de tekniska detaljerna. Detta hjälper till att illustrera varför ett system valdes istället för att bara beskriva vad som var installerat.
5. Prioriterar säkerhet
Den här listan skulle inte vara komplett utan att nämna säkerhet. Säkerhet måste vara mer än en eftertanke. Det bör bakas in i alla aspekter av din arkitektur. Att flytta säkerheten till början av din beslutsprocess säkerställer att den inte kan förbises.
RELATERAD: Vad är de tre pelarna i cybersäkerhet?
Antag inte att dina molnsystem är i sig säkra. Användning av stora namnleverantörer kan ge falsk försäkran om att dina uppgifter är skyddade. I verkligheten är inget moln helt säkert. Många allvarliga överträdelser härrör från grundläggande konfigurationsfel, som att oavsiktligt exponera en objektlagringsskopa.
Integrering av säkerhet i din design minskar risken för dolda problem. Att ha en enda granskning i slutet av processen kan leda till att du saknar sårbarheter som ligger i enskilda komponenter.
Systemisk säkerhetsintegration tillför tid och kostnad till den ursprungliga byggnaden men är viktig för långvarig användning. Du måste tänka på varje händelse som en angripare kan få tillgång till dina servrar, data och konfigurationsbutiker.
Kom också ihåg att låsa åtkomst till molnvärdens kontrollpaneler. Det är inte bra att ha stränga säkerhetsskydd för arbetsbelastningen om du använder ett osäkert lösenord för att komma åt din värdleverantör. Använd ett starkt lösenord, ställ in tvåfaktorautentisering och delegera bara åtkomst till viktiga teammedlemmar.
Sammanfattning
En effektiv molnarkitektur hjälper dig att maximera möjligheterna tillhandahålls av dina system. Molnteknik kan vara effektivare, mer skalbar och enklare att integrera med andra tjänster. Det betyder dock inte att det är ditt enda alternativ.
Bedöm hela spektrumet av tillgänglig teknik, skapa en detaljerad plan innan du migrerar och vara öppen för förändring. Integrera säkerhet från början så att du vet att dina data är säkra. Du kanske fortfarande gör misstag, men åtminstone är du bättre beredd att förutse och lösa dem.